[xmlsec] Mscrypto patch no 3

[Wouter]

> >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
by default. 

======== 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 
> reference
> /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 .... ;
>     do
>           ...
>     done
> 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!

Great!

Wouter
-- 
Wouter Ketting