[xmlsec] Mscrypto patch no 3
wsh at xs4all.nl
Fri Sep 12 00:08:12 PDT 2003
> >Regarding this, I'm not sure if the mscrypto lib should become the
> >default library for windows...
> Well, it was just an idea :) The only reason I have for this
> is that on
> Linux you expect to have
> OpenSSL installed. On Windows you have to install it. IMHO,
> the default
> choice should give
> user as less pain as possible. If you understand what you are doing
> (i.e. you know *why*
> OpenSSL is better than MSCrypto for you) then you probably
> know how to
> change default
> settings too. Anyway, it was just an idea. Since nobody likes
> it then we
> just let it die. I don't care :)
You're right here. Installing OpenSSL as well *is* a disadvantage. To
reach the largest group possible one should choose for MS Crypto support
======== snipsnip ==========
> > 1) /tmp folder is in the sh at a different location then in
> > the application (xmlsec.exe) (c:\cygwin\tmp versus c:\tmp) on
> > my machine. It means you need c:\tmp folder to run the
> > tests.
> I am not sure I understand that. I believe that the only
> place where we
> /tmp folder is in the tests/test*.sh. And on Windows it is always
> <cygwin install root>/tmp
> (i.e. c:\cygwin\tmp). Who requires c:\tmp folder?
What happens is this: The shell script gives a temporary file name where
a new xml-signature-file must be created. The folder path is=
/tmp/<filename>, for cygwin the absolute path to
/tmp/<filename> is c:\cygwin\tmp\<filename>. The windows application,
xmlsec.exe in this case, gets the same path (/tmp/<filename>) and
creates there the file. However for xmlsec.exe, that runs outside cygwin
environment, the absolute path is: C:\tmp\<filename>. After creation the
shell script takes over and does some checks, but then can't find the,
since it's located at another position. So in the first place c:\tmp
folder *must* exist to run the dsig tests, and the diff command in the
enc test script will fail because it can't find the files. (see item 4)
> > 2) Since the working directory is xmlsec/win32, instead of
> > xmlsec, some files with keys are not found. (Causes raw-cert
> > sig test to fail, for example.)
> Yes. This can and should be fixed in win32 Makefile. I'll do
> it. Also I would like to execute test suite for all available
> xmlsec-crypto libs on Windows (in the same way as we do it on
> Linux). Anyone knows how to do
> for i in .... ;
> in Windows makefiles?
> > 3) Thirdly the command diff is used, but this may
> result into
> > finding differences in files simply because of the original
> > file may have lf and the newly generated files have crlf as
> > linebreaks. Use diff --strip-trailing-cr to avoid these
> > problems.
> I don't think I like the idea of using --strip-trailing-cr.
> The end of line difference might be a real problem and if we
> use such an option then we can miss it. I don't see it
> myself. Which tests are you talking about?
It's the enc tests where the diff command is user. If the files are
properly checked out in a windows environment (with crlf linebreaks),
this problem will not occur. However one someone like me checks out in
unix format (lf linebreak) you'll get these kind of problems.
> > 4) With the diff option files generated by the xmlsec.exe
> > command are compared. The files are created in
> c:\tmp folder,
> > but in the shell /tmp is c:\cygwin\tmp (on my machine). Add
> > /cygdrive/c before the filename variable.
> Can you check the TMP environment variable, please?
It should be checked and used in the test script then.
> > 5) Since HMAC is not supported at all, the generate keys
> > fails. All key generations are done in 1 command.
> Yes, this could be fixed. I'll do it.
> > 6) Apparently the keys from the encryption tests from phaos
> > tests are not read/imported correctly, or possibly something
> > in the import code is wrong. This results in lots of
> > failures. Since plain private key import is not supported,
> > decryption without using pkcs 12 keys is not supported.
> Sounds like this requires an investigation. OpenSSL and NSS
> have no problems opening these files thus I would expect the
> same from MSCrypto. Can you take a look at this, please?
I'll investigate this further. The key import went well, but when using
the key ms crypto is complaining that the key is invalid :(
> > 7) Most other failures at my site are the results of not
> > implemented functionalities.
> > Fixing the problems without breaking unix/linux environments
> > will take some effort, but should be done at the
> end. I would
> > prefer an environment for windows where cygwin is
> not needed :)
> Actually I know how to fix that but as usual did not have
> time and it was not a priority :( The idea is:
> - Create tests description in platform neutral format
> (XML, csv, etc.)
> - Process these decriptions before running the tests and generate
> platform specific files (*.sh, *.bat, etc.)
> In case of XML format, the processing could be done with XSLT
> stylesheet thus one can use xsltproc for that :) Any volunteers?
Sounds like a nice idea :)
> >Aleksey: Could you apply this patch, and commit into cvs,
> and add the 2
> >new files in the attached zip file?
> Done. Thanks a lot again!
More information about the xmlsec