Hi Donat,
On 10/16/16 9:34 PM, Donat Enikeev wrote:
Hi Jacek,
I agree that hardcoded paths are not nice, but if we don't have better generic solution, we have to live with that
So, could expressing certificates into registry once and beforehand during wine-prefix creation - be that one "better generic solution"? I think I could spend some time on it, if that considered a right way to go
This solution would change nothing in that regards - you still need hardcoded list of paths to do the import. You would just use it slightly differently.
Also, I did not say to do that for wine prefix creation. User may intentionally remove a certificate in host system after wineserver is created and we should reflect that in Wine (not to mention moving wine prefix to another machine). That's why I suggested using REG_OPTION_VIOLATILE - so that registry keys would be gone when wineserver terminates (aka. Windows shutdown) and we'd recreate them the next time root store is created.
And yes, I would consider such solution better.
How about instead of current CRYPT_RootOpenStore call, we'd create registry entries expressing system certificates using REG_OPTION_VIOLATILE once for Wine session?
That will work as well, but would require another custom wine-specific piece of code for the certificates import using that flag for registry keys OR passing special flag to the existing Store management functions.
I'm not sure why you need more that we already have. We already have special handling for root store in CRYPT_SysRegOpenStoreW. You could just change it to call new import_system_certs function and continue like for other stores instead of calling CRYPT_RootOpenStore and returning.
In general, if sticking to the current way of implementation is the most reasonable option in the context, just proper handling of flags and priorities for collections is required (following Remarks at https://msdn.microsoft.com/en-us/library/windows/desktop/aa376022(v=vs.85).a... ), so the collection will forward added certificates to the appropriate store: registry one with RW access, not the memory based created by CRYPT_RootOpenStore with RO access
I would need deeper look at the code to comment that. However, note that with that we'd use registry stores that are already used for non-root cases. That said, I wouldn't be surprised if you find that existing code would needs fixes.
Thanks, Jacek