Imort system certificates in crypt32 at Wine

[Donat Enikeev]

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

> 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.
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).aspx 
), 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

Considering these, what do you think?

Best,
Donnie

On Вс, окт 16, 2016 at 10:07 , Jacek Caban <jacek at codeweavers.com> 
wrote:
> Hi Donat,
> 
> 
> On 10/16/16 7:50 PM, Donat Enikeev wrote:
>> Hi Guys,
>> Watched video recently from WineConf 2015, and resulting directions 
>> around opening community looks really promising, so I am performing 
>> 3rd attempt to be useful here :)
>> The bug https://bugs.winehq.org/show_bug.cgi?id=30187 : Cisco IP 
>> Communicator failing to setup due to 'certmgr.exe' tool fails to 
>> install certificate to the system-wide trusted certificate store.
>> Wine uses registry-based certificates stores by default, but treats 
>> HKLM\Root store as a special case. Whenever app opens such store, 
>> Crypt32 goes through hard-coded paths in rootstore.c:
>> static const char * const CRYPT_knownLocations[] = { 
>> "/etc/ssl/certs/ca-certificates.crt", "/etc/ssl/certs", ... };
>> And adds all found certificates to the special store. In the context 
>> of bug, this special-case store doesn't support adding certificates, 
>> and thus Cisco IP fails to install.
>> So a backward compatible patch (attached) that just fixes this bug 
>> looks straightforward: make a stores collection, add there HKLM\Root 
>> certificates registry store at first and then that system store with 
>> certificates from the environment, and return the collection. It 
>> will allow applications do whatever they used to with certificates, 
>> keeping all the linux certificates available for verification of any 
>> kind.
>> The problem with this approach is that current wine crypt32 doesn't 
>> actually save certificates that were added to a collection of stores 
>> (the test for this attached), while Win does. Although it could be 
>> fixed with a different patch in one function,
>> but I would like to hear your thoughts first around following 
>> questions:
>> 1. Does this backward-compatible patch-set make sense at all and 
>> worth proceeding? Probably you have some ongoing activities
>> 2. Do you still think that wine should import system certificates 
>> during HKLM\Root request at all, not just shipping with those from 
>> typical windows installation?
>> 3. Have you considered different approach of utilizing system 
>> certificates in Wine? For example, import all system certificates to 
>> the *registry* during wine-prefix initialization process, and work 
>> with them from there in a way windows does (even native crypt32 will 
>> benefit from this approach). That will allow to unify and simplify 
>> crypt32 and remove all that arguable hard-coded paths in the code, 
>> and bring more familiar environment to the windows application and, 
>> at the same time, isolation.
> 
> First of all, I think we want to keep current solution of using host 
> system's cert store and configuration as much as possible. I agree 
> that hardcoded paths are not nice, but if we don't have better 
> generic solution, we have to live with that (although it's possible 
> to improve it in some cases, like it's done for Mac).
> 
> That said, I think that expressing system certificates in Wine 
> registry would be the right solution. How about instead of current 
> CRYPT_RootOpenStore call, we'd create registry entries expressing 
> system certificates using REG_OPTION_VIOLATILE once for Wine session? 
> Then we could use regular registry store for root store.
> 
> Thanks,
> Jacek *
> *