[xmlsec] Signing over multiple files

Mike Peat mpeat at unicorninterglobal.com
Thu Oct 11 15:34:05 PDT 2012 

Thanks for getting back to me anyway Aleksey.

I will just have to figure it out on my own I guess.

Weirdly, your response even helps... if _you_ couldn't get it to work, 
it makes me feel not /quite/ so inadequate and stupid that I am having 
problems. ;-)

I will let you know if I crack it (if I can get it to all work, I may 
even document it... if I have the strength! <g>)

Thanks again.

Mike

On 11/10/2012 20:03, Aleksey Sanin wrote:
> 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
>>   
> .
>

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

More information about the xmlsec mailing list