[xmlsec] Signing over multiple files

Aleksey Sanin aleksey at aleksey.com
Thu Oct 11 12:03:53 PDT 2012 

Sorry, no ideas. I was never able to compile xmlsec with MinGW for
various reasons.

Aleksey

On 10/11/12 10:35 AM, Mike Peat wrote:
> 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.
> 
> TIA
> 
> Mike
> 
> 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 
>>>>>> .
>>>>>>
>>>>>  
>>>> .
>>>>
>>>  
>> .
>>
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
>

More information about the xmlsec mailing list