[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.
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
>>>>> .
>>>>>
>>>>
>>> .
>>>
>>
> .
>
-------------- 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