http://bugs.winehq.org/show_bug.cgi?id=59275 --- Comment #1 from Hans Leidekker <hans@meelstraat.net> --- (In reply to mkrsym1 from comment #0)
A potential solution I see is to allow (optionally?) specifying a certificate and a signing key at ./configure time, which would then be used to sign the DLLs, afterwards a catalog will be generated and signed by it too. The certificate would then be installed via wine.inf. This however comes at a cost of technically making builds non-reproducible, unless the signing key is public? Alternatively, maybe it could be possible to generate a new authority on every ./configure?
I think it's reasonable for Wine's build system to support signing DLLs but it can be done separately as well. You would need to supply a valid certificate for WinVerifyTrust to succeed of course. For reproducible builds you could do what CryptCATAdminCalcHashFromFileHandle() does: it skips the parts of a PE image that change when you sign it.
Another potential "solution" would be to make both APIs pretend that builtin DLLs are signed, which I would imagine comes with it's own set of issues.
Verifying the signature is a way for the app to check that it's using unmodified DLLs and we should support that. Apps could go one step further and check that the publisher is MS. Then your options are to accept that the app doesn't want to run on Wine or you could spoof a valid signature. I don't think we want to make that decision for the user. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.