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.

 

Please share your thoughts,

Donnie