<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#3333FF">
<div class="moz-cite-prefix">Thanks for getting back to me anyway
Aleksey.<br>
<br>
I will just have to figure it out on my own I guess.<br>
<br>
Weirdly, your response even helps... if <u>you</u> couldn't get
it to work, it makes me feel not <i>quite</i> so inadequate and
stupid that I am having problems. ;-)<br>
<br>
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>)<br>
<br>
Thanks again.<br>
<br>
Mike<br>
<br>
On 11/10/2012 20:03, Aleksey Sanin wrote:<br>
</div>
<blockquote cite="mid:50771819.1060504@aleksey.com" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">Great! Actually I suggest to do it 'the right way' and simply
create 'cid' protocol handlers:
<a class="moz-txt-link-freetext" href="http://www.aleksey.com/xmlsec/api/xmlsec-io.html#XMLSECIOREGISTERCALLBACKS">http://www.aleksey.com/xmlsec/api/xmlsec-io.html#XMLSECIOREGISTERCALLBACKS</a>
Aleksey
On 10/4/12 5:43 AM, Mike Peat wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="cid:/xxxxxxx/">"cid:/xxxxxxx/"</a>, 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:
</pre>
<blockquote type="cite">
<pre wrap="">Mike,
You will probably need to write code to support "cid" URL scheme
and resolve references correctly to the MIME attachments:
<a class="moz-txt-link-freetext" href="http://www.aleksey.com/xmlsec/api/xmlsec-io.html">http://www.aleksey.com/xmlsec/api/xmlsec-io.html</a>
Aleksey
On 9/14/12 7:50 AM, Mike Peat wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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=<a class="moz-txt-link-rfc2396E" href="cid:xxxxxxxx">"cid:xxxxxxxx"</a>, 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
<a class="moz-txt-link-abbreviated" href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</a>
<a class="moz-txt-link-freetext" href="http://www.aleksey.com/mailman/listinfo/xmlsec">http://www.aleksey.com/mailman/listinfo/xmlsec</a>
</pre>
</blockquote>
<pre wrap="">.
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">.
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">.
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
xmlsec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</a>
<a class="moz-txt-link-freetext" href="http://www.aleksey.com/mailman/listinfo/xmlsec">http://www.aleksey.com/mailman/listinfo/xmlsec</a>
</pre>
</blockquote>
<pre wrap="">.
</pre>
</blockquote>
<br>
</body>
</html>