[xmlsec] Big patch to xmlsec in recent OpenOffice.org sources

Andrew Fan Xuelei.Fan at Sun.COM
Sun Feb 27 19:38:52 PST 2005

Aleksey Sanin wrote:

> Hi, Andrew!
> Thanks for your reply! See my comments interlaced with your answers.
>>> 0) After applying the patch, I have quite a lot of failures in
>>> xmlsec regression test suite. I wonder if you run the tests and know
>>> the reasons for these failures?
>> If I correct, the patch doesn't implement app* routines, which are 
>> not used at openoffice, so I don't implement it in time. Because some 
>> APIs have changed or added to the kernel, so it is necessary to 
>> adjust the app* programs. However, I think Channdler and Michael may 
>> be in the implementing process.
> Hm.. I don't see any changes to core xmlsec code except the big numbers
> routines changes that are already in xmlsec 1.2.7. May be test errors
> were caused by the new AppliedKeyManager that does not implement all
> of the necessary callbacks?
Yes, that's what I mean. Not only the AppliedKeyManager in mscrypto 
engine, but also include some callbacks for nss engine.

>>> 1) xmlsec/include/xmlsec/mscrypto/akmngr.c, 
>>> xmlsec/src/mscrypto/akmngr.c
>>> Why do you need "AppliedKeyManager"? How is it different from the
>>> "DefaultKeyManager" and do you think it would be easier to just
>>> merge the two?
>> The AppliedKeyManager enable user specify their preferred key store 
>> and certificate store. It would be a good idea just simply support 
>> both of the two manager.
> I would really love to merge these two guys together. May be we can just
> add functions to set prefered key/certs store to the DefaultKeysManager
> and provide reasonable defaults as we do now. I believe this way we can
> avoid un-necessary code duplication (see item 0) too).
It's a little harder, but definitely better. :-)

>>> 2) xmlsec/src/mscrypto/certkeys.c
>>> I understand that you are using refcounting for HCRYPTKEY and
>>> HCRYPTPROV instead of system "duplicate" functionality to support
>>> NT 4.0. However, it seems a little bit dangerouse to me to re-use
>>> the same key handler from multiple threads. Do you know if MS
>>> documentation says anything about this? Did you do any tests in
>>> multithreading environment?
>> Good suggest, we will do tests on multithreads. Or add some syn 
>> mechanism if necessary.
> Thanks!
>>> 3) xmlsec/src/mscrypto/x509.c,
>>> xmlSecMSCryptoKeyDataX509VerifyAndExtractKey function
>>> You commented out the code to get public key from a verified 
>>> certificate
>>> and replaced it with code that gets either public or private key.
>>> I am not sure I understand why would you need a private key for
>>> a "verify cert" operation. It seems impossible to me.
>> I don't think this function only used to verify, sometime it is also 
>> used to sign. In our cases, all of the signature/encryption process 
>> are controlled by signature/encryption template, the function is 
>> called during signning.
> OK, this sounds strange to me. Can you share the templates you use for
> signing and I'll try to investigate this?
It's a very simple template,  only including cert issuer and serial 
number. Refer to 


> Aleksey
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

More information about the xmlsec mailing list