[xmlsec] Signing over multiple files

Mike Peat mpeat at unicorninterglobal.com
Thu Oct 11 10:35:06 PDT 2012

Hi Aleksey

Not quite as great as I had thought I'm afraid. :-(

When I went to run my shiny new xmlsec on the target platform it wanted 
msvcr100.dll. I gave it that, but it then turned out that my version was 
crashing (quietly - I had to look into the Windows Event Log to discover 
what was going on) with a problem in ntdll.dll.

I remembered the note in the README that pointed out that all the code 
had to use exactly the same version of the MS C runtime and suspected 
that the other libraries were using msvcrt.dll rather than the "100" 
version (10.0 - I was using Visual Studio 2010) my code wanted. I tried 
using older versions of Visual Studio to do the build (picture a lot of 
thumb-twiddling while I installed version after version of it <g>), but 
that was no real help: VS6 failed to understand a lot of the code; 
VS2003 had just a couple of things it was unhappy about; VS2005 compiled 
and built it all OK, but on running on the target it wanted 
msvcr80.dll... which of course resulted in the same silent runtime crash 
in ntdll.dll.

So I have now given up on Microsoft and switched to using MinGW as a 
build environment. After a bit of fighting to discover the right way to 
configure it and get to to start building, it is now coming up with an 
error during the make which I really don't understand:

    dl.c: In function 'xmlSecCryptoDLLibraryConstructFilename':
    dl.c:295:30: error: 'PACKAGE' undeclared (first use in this function)
    dl.c:295:30: note: each undeclared identifier is reported only once
    for each fun
    ction it appears in
    make[3]: *** [dl.lo] Error 1

...and bombs out.

The line (295) in dl.c that is causing the problem (in 
xmlSecCryptoDLLibraryConstructFilename) is:

    len = xmlStrlen(BAD_CAST PACKAGE) + xmlStrlen(name) +
    xmlStrlen(tmpl) + 1;

and it has a /* TODO */ comment in front of it.

I am a bit stumped.  Obviously I have some aspect of the configuration 
wrong, since the same code built OK under Visual Studio, but I have no 
idea just what in order to start fixing it.

One thing is a bit messy about how I am doing things: I couldn't get the 
configure script to work out where I had put xmllib2, so in the end I 
put the source version of that in there and told it about that instead 
(via "--with-libxml-src") and it appeared to build that without a 
problem. However I now note (in looking for any occurrence of "PACKAGE" 
- there are quite a few: almost 7,000!) that "acconfig.h" in libxml2 has 
an "#undef PACKAGE" statement in it, while its "config.h.in" has a 
couple of them, and am wondering if that could somehow be to blame. 
(Probably not, but it is the sort of thought I have when I have no idea 
what is actually going on.)

Any thoughts would be much appreciated.



On 04/10/2012 15:06, Aleksey Sanin wrote:
> Great! Actually I suggest to do it 'the right way' and simply
> create 'cid' protocol handlers:
> http://www.aleksey.com/xmlsec/api/xmlsec-io.html#XMLSECIOREGISTERCALLBACKS
> Aleksey
> On 10/4/12 5:43 AM, Mike Peat wrote:
>> Aleksey
>> Just to let you know that I have (finally!) cracked it and got xmlsec to
>> build and run on Windows (and even with an addendum to your copyright
>> notice that indicates that it is my own bodged version! <g>).
>> Now I just have to work out how to modify it (in
>> xmlSecTransformInputURIOpen I think...) to strip off any leading "cid:"
>> from the URI.
>> Thank you for your help!
>> Mike
>> On 21/09/2012 05:02, Aleksey Sanin wrote:
>>> Mike,
>>> You will need to look into win32/ folder and use Microsoft C compiler.
>>> Honestly, I haven't touched Windows for years so it will be hard for
>>> me to give you a better advice.
>>> Another option is of course to use a VM with linux and just run it
>>> through VM.
>>> Aleksey
>>> On 9/20/12 6:53 AM, Mike Peat wrote:
>>>> Thanks for that Aleksey
>>>> Initially I thought I had found a work-around, but I am now back looking
>>>> at the problem from square one again.  Let me explain...
>>>> Another customer of the organisation I am communicating with was using
>>>> xmlsec at the command-line to do this, which is what led me down this
>>>> route initially.
>>>> It turns out that if the document (file) referred to in the <Reference>
>>>> URI attribute is in the _same directory_ as the SOAP document being
>>>> signed, xmlsec actually picks it up OK and includes its hash-value in
>>>> the <Reference> -> <DigestValue> element... problem solved!
>>>> (Apparently...)  However, life is not so simple.
>>>> They are working on a Linux system, while I am cursed with being in
>>>> Windows.  :-(
>>>> They are thus able to have files named "cid:/xxxxxxx/", while I am not
>>>> (no colons allowed in file-names in Windows!).  So I changed the URI
>>>> attribute in my Reference element to just contain a file-name with no
>>>> "cid:" prefix, and that got things working as far as digitally signing
>>>> the whole thing with xmlsec was concerned.  However now I am getting
>>>> messages through to the other party's back-end system, which are being
>>>> rejected because now _it_ can't identify the referred to document: it
>>>> seems that it insists on using that "cid:" scheme.
>>>> So...
>>>> I need to persuade xmlsec to recognise that "cid:" prefix and, in
>>>> effect, ignore it (if the referred-to file-name starts with "cid:",
>>>> replace that with nothing prior to trying to open the file).
>>>> I have got the xmlsec source, but up until now have just been using Igor
>>>> Zlatkovic's Windows binaries.
>>>> I need to (a) get xmlsec to compile in a Win32 environment and (b) know
>>>> where to make the changes in xmlsec (or perhaps one of its libraries) in
>>>> order to create a version which will do what I need.
>>>> I am not really a C/C++ programmer, but I can usually get by in pretty
>>>> much anything (I have been programming since about 1972 - Oh Lord!
>>>> That's 40 years! I'm getting too old for this!).
>>>> What compiler will I need and where do I find the code I will need to
>>>> change?  And what build process do I need to go through?  Is there a
>>>> make file or something similar?
>>>> Alternatively... what would it take to get somebody who actually knows
>>>> what (s)he is doing to do this for us? We don't have much in the way of
>>>> budget, but this is stopping a project that has months of work in it
>>>> dead in its tracks right now, so...
>>>> TIA
>>>> Mike Peat
>>>> On 14/09/2012 16:57, Aleksey Sanin wrote:
>>>>> Mike,
>>>>> You will probably need to write code to support "cid" URL scheme
>>>>> and resolve references correctly to the MIME attachments:
>>>>> http://www.aleksey.com/xmlsec/api/xmlsec-io.html
>>>>> Aleksey
>>>>> On 9/14/12 7:50 AM, Mike Peat wrote:
>>>>>> Hi
>>>>>> I am using xmlsec at the command line in an ebXML application.  As you
>>>>>> probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its
>>>>>> messages.  The message thus consists of multipart-MIME content in the
>>>>>> HTTP body: the first part being a SOAP document containing (among other
>>>>>> things) the Signature stuff and the second being an XML document which
>>>>>> is the business payload.
>>>>>> The Signature->SignedInfo in the SOAP document needs to contain two
>>>>>> <Reference> elements: one for the SOAP document itself (URI="") and one
>>>>>> for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content
>>>>>> ID of the second MIME part).
>>>>>> I am managing to successfully sign simple SOAP messages with no payload
>>>>>> (and hence no second <Reference> element), but I just can't work out how
>>>>>> to get xmlsec to sign both documents together.  I have tried many
>>>>>> different ways, but to no avail.  I am sure I am missing something
>>>>>> simple, but...  :-(
>>>>>> Any help would be very much appreciated - I've been banging my head off
>>>>>> this brick wall for a week... and it is starting to really hurt!  :-(
>>>>>> (That takes a while, because my brain is so dense, but even it starts
>>>>>> gets sore eventually!)
>>>>>> TIA
>>>>>> Mike Peat _______________________________________________
>>>>>> xmlsec mailing list
>>>>>> xmlsec at aleksey.com
>>>>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>>> .
>>> .
> .

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121011/58f917be/attachment.html>

More information about the xmlsec mailing list