Michael wrote:
There is also a DES implementation in dlls/advapi32/crypt_des.c. However, this one is not exported by advapi32.dll. I could copy the code over to dlls/rsaenh, but this would mean unnecessary code duplication. How are such cases handled in wine typically?
They are typically handled by copying the code. If linking between the two requires a private export, then our DLLs can't work with native ones, and that's something we try to avoid. If we use a static library, the number of static libraries can potentially get very large, and the makefiles unmanageable. It's really best to accept code duplication, especially for something like DES that is quite stable.
Although it is of no concern at the moment, another problem will arise in the future: advapi32 and cryptographic service provider dll's check each other against tempering by the use of digital signatures in windows
Yes, I know. The functions in advapi32 for verifying a provider always return success at the moment, unfortunately. Maybe with more crypto support we can tackle this, but not yet.
(Probably because of US export restrictions on cryptographic software).
I'd be surprised if this were the motivation. US export restriction is on key length, not on algorithm, and the signatures don't say anything about these, just that the files have not been modified and their source can be verified. I expect the motivation is more along the lines of, I'm trusting these DLLs to encrypt my credit card number and whatnot, so how can I trust the DLLs?
--Juan
__________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
On wtorek 26 październik 2004 11:52 am, Juan Lang wrote:
Michael wrote:
There is also a DES implementation in dlls/advapi32/crypt_des.c. However, this one is not exported by advapi32.dll. I could copy the code over to dlls/rsaenh, but this would mean unnecessary code duplication. How are such cases handled in wine typically?
They are typically handled by copying the code. If linking between the two requires a private export, then our DLLs can't work with native ones, and that's something we try to avoid. If we use a static library, the number of static libraries can potentially get very large, and the makefiles unmanageable. It's really best to accept code duplication, especially for something like DES that is quite stable.
What about simply linking in the required object files in rsaenh w/o generating an intermediate static library?
Cheers, Kuba Ober
-
Juan Lang -
Kuba Ober