From qcarrillo@example.net Mon Sep 1 01:32:26 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 63507 invoked from network); 1 Sep 2003 01:32:26 -0000 Received: from unknown (HELO mail.sauria.com) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Sep 2003 01:32:26 -0000 Received: from sauria.com (boo.sauria.com [83.161.120.155]) by mail.sauria.com (Postfix) with ESMTP id 11E7DBFA1; Sun, 31 Aug 2003 16:32:27 -0700 (PDT) Message-ID: <qcarrillo@example.net> Date: Sun, 31 Aug 2003 16:32:19 -0700 From: Ted Leung <qcarrillo@example.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erwin van der Koogh <qcarrillo@example.net> Cc: qcarrillo@example.net, qcarrillo@example.net Subject: Re: next release References: <qcarrillo@example.net> <qcarrillo@example.net> <qcarrillo@example.net> <qcarrillo@example.net> In-Reply-To: <qcarrillo@example.net> X-Enigmail-Version: 83.161.120.155 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 8/31/2003 2:40 AM, Erwin van der Koogh wrote: >>>The C++ library did one recently (beginning of August) - V1.0.0 >>> >>>The Java library has been going fairly slowly - am not sure there is >>>enough to warrant a release at the moment - but Axl/Erwin/Karel might >>>be able to comment more. >>> >>> >>> >>Sorry, I meant the Java release, in particular, the encryption stuff, >>even if it is included source only. >> >> > >I am sorry Ted, > >Axl and myself are trying to work on a roadmap to release a new version, >but as there's a lot of lawyers involved for a few different areas of this >release I don't think there's going to be a new release with encryption >and JSR105 support soon. >Christian is the one that wrote the present APIs and I am quite reluctant >to make extensive changes in it, because I might do more harm than good. >That's why it's my top priority to get a brand spanking new version up, >but it's going to take some time I am afraid while we sort out the few >issues that we have which includes lawyers :( >Erwin > > > If there isn't going to be an encryption / JSR 105 release soon, how about just a 1.0.5 as the last stable release with the current APIS. And a notice that encryption / JSR 105 is up for 1.1. Ted From qcarrillo@example.net Tue Sep 2 10:12:34 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 91389 invoked from network); 2 Sep 2003 10:12:34 -0000 Received: from unknown (HELO mta03.mail.mel.aone.net.au) (83.161.120.155) by daedalus.apache.org with SMTP; 2 Sep 2003 10:12:34 -0000 Received: from ozemail.com.au ([83.161.120.155]) by mta03.mail.mel.aone.net.au with ESMTP id <qcarrillo@example.net>; Tue, 2 Sep 2003 20:12:39 +1000 Message-ID: <qcarrillo@example.net> Date: Tue, 02 Sep 2003 20:12:39 +1000 From: Berin Lautenbach <qcarrillo@example.net> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent Finn <qcarrillo@example.net> CC: Apache XML DSIG <qcarrillo@example.net> Subject: Re: Strange compile error References: <98F7681DB5B4D311AC9D0090279C2173A31F29@SOL> In-Reply-To: <98F7681DB5B4D311AC9D0090279C2173A31F29@SOL> X-Enigmail-Version: 83.161.120.155 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Vincent, Will look into defining _MEM_DEBUG. I think including windows.h for all includes is also overkill - I only need it in some places, so I will look at trying to cut the whole thing down a bit. On the other one, I can see a couple of solutions : 1. Don't inject into global namespace within include files - so have all references to Xerces/Xalan elements be fully qualified until I hit the actual cpp files. This ties everything more tightly with Xerces/Xalan, but that's about the only "negative" I can see. 2. Define a xsec namespace and then inject into there. Seems like overkill, and means people have to worry about Xerces/Xalan and Xsec namespaces. 3. typedef everything to a new type. It's probably the best way to do it architecturally (place an interface between the DOM library and the XSEC library), but we'd then need wrappers around things to get correct types returned, and it could quickly get nasty. So I think I'm leaning with number 1 (for now), but interested in thoughts. Any other options gratefully received :>. Cheers, Berin Vincent Finn wrote: > That sounds fine, undefing _DEBUG before the headers is a bit less hacky > than doing _WINDOWS_ > > > >>-----Original Message----- >>From: Berin Lautenbach [mailto:qcarrillo@example.net] >>Sent: 30 August 2003 03:40 >>To: Vincent Finn >>Cc: 'qcarrillo@example.net' >>Subject: Re: Strange compile error >> >> >>Vincent, >> >>Firstly - apologies for not replying sooner. Was away all week and >>no-where near e-mail. >> >>The reason for afx.h in the debug build is to allow us to use the >>Windows memory debugging routines. But it means you need an >>MFC build. >> Pain in the neck, but it's helped me track some really >>nasty memory leaks. >> >>You could undefine the _DEBUG flag in the debug build - but >>that's messy >>as well. >> >>How about I create a new define _MEM_DEBUG that can be turned off in >>XSECW32Config.h to go back to normal includes? >> >>On the second question - Ouch. Yes I can see the problem. >>Let me have >>a think. >> >>Cheers, >> Berin >> >> >>Vincent Finn wrote: >> >>>Hi, >>> >>>I tracked my problems down and it leaves me with a few questions >>> >>>The first is about the debug error >>> >>>This comes from the fact that in XSECDefs.hpp there is code >> >>that includes >> >>>"afx.h" for debug builds >>>and "windows.h" for release ones >>>afx.h eventually includes afxv_w32.h which will stop windows.h being >>>included twice >>>this will stop any ATL projects from building since they >> >>automatically >> >>>include windows.h >>> >>>why is there a different include for debug (except for the >> >>crtdbg bit >> >>>obviously)? >>> >>>I can get around this by undefing _WINDOWS_ for the xsec >> >>headers but that >> >>>seems to be very hacky >>>the alternative would seem to be to remove the header but >> >>this won't compile >> >>>is there a better solution? >>> >>>--- >>> >>>The second question is why are the Xerces classes being >> >>injected into the >> >>>global namespace? >>>e.g. XSEC_DECLARE_XERCES_CLASS(DOMDocument); >>>this seems a bit extreme to me and causes my other problem >>> >>>The compile bug happens because the VC ATL wizard >> >>automatically includes >> >>>msxml in ATL dll projects >>>(it a hidden dependency somehow, so I can't get rid of it) >>>and they inject DOMDocument into the global namespace >>> >>>so know you get 2 DOMDocuments in the global namespace >>> >>>I am currently running with a modified library >>>with XSEC_DECLARE_XERCES_CLASS(DOMDocument) which requires >> >>a lot of other >> >>>minor changes >>> >>>Is there a better solution for this problem too? >>> >>> >>>I would prefer a solution that could be done in the library >> >>(or my calling >> >>>code) >>>I don't really want to be using a hacked version of the >> >>xsec since it makes >> >>>upgrading a mess! >>> >>>Any suggestions appreciated >>> >>> Vin >>> >>> >>>------------------------------------------------------------- >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Vincent Finn >>>>Sent: 27 August 2003 12:39 >>>>To: 'qcarrillo@example.net' >>>>Subject: Strange compile error >>>> >>>> >>>>Hi, >>>> >>>>I have a strange problem compiling a project using xsec >>>> >>>>I am on WinXP, VC6 SP5, xerces 2.2, openssl 0.9.7b, xsec 1.0 >>>>I have a COM dll which currently uses xerces to create an XML file >>>>I am adding xsec in to sign the file >>>> >>>>when I add the line >>>>#include <xsec/framework/XSECProvider.hpp> >>>>I get errors (the same is true for other xsec includes) >>>> >>>>The strange part is that I have code in a test (console) >> >>project which >> >>>>parses an XML file and signs it and this works, but not in my >>>>real project >>>>also I get very different errors in debug and release >>>> >>>>the only other point I can think of worth mentioning is that >>>>I do have a global using statement >>>>using namespace XERCES_CPP_NAMESPACE; >>>> >>>>Has anyone seen this or have any idea what it might be? >>>> >>>> Thanks, Vin >>>> >>>> >>>>The errors are as follows >>>>in DEBUG >>>>c:\program files\microsoft visual >>>>studio\vc98\mfc\include\afxv_w32.h(14): fatal error C1189: >>>>#error : WINDOWS.H already included. MFC apps must not >>>>#include <windows.h> >>>> >>>>in RELEASE >>>>C:\LIBS\XML-SECURITY-C-1.0.0\INCLUDE\xsec/utils/XSECSafeBuffer >>>>Formatter.hpp(108): warning C4100: 'formatter': unreferenced >>>>formal parameter >>>>C:\LIBS\XML-SECURITY-C-1.0.0\INCLUDE\xsec/dsig/DSIGTransform.h >>>>pp(79): error C2874: using-declaration causes a multiple >>>>declaration of 'DOMDocument' >>>> >>>>C:\LIBS\XERCES-C-SRC2_2_0\SRC\xercesc/dom/DOMDocument.hpp(102) >>>>: see declaration of 'DOMDocument' >>>>C:\LIBS\XML-SECURITY-C-1.0.0\INCLUDE\xsec/dsig/DSIGSignedInfo. >>>>hpp(82): error C2874: using-declaration causes a multiple >>>>declaration of 'DOMDocument' >>>> >>>>C:\LIBS\XERCES-C-SRC2_2_0\SRC\xercesc/dom/DOMDocument.hpp(102) >>>>: see declaration of 'DOMDocument' >>>> >>>>-------------------------------------------------------------- >>>>--------- >>>>qcarrillo@example.net >>>>-------------------------------------------------------------- >>>>--------- >>>>INTEL INSIDE: The worlds most widely used warning label. >>>>------------------------------------------------------------ >> >>---------- >> >>> > From qcarrillo@example.net Tue Sep 2 10:32:04 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 40292 invoked from network); 2 Sep 2003 10:32:04 -0000 Received: from unknown (HELO sol.automsoft.com) (83.161.120.155) by daedalus.apache.org with SMTP; 2 Sep 2003 10:32:04 -0000 Received: by SOL with Internet Mail Service (5.5.2653.19) id <R8L0418D>; Tue, 2 Sep 2003 11:35:02 +0100 Message-ID: <98F7681DB5B4D311AC9D0090279C2173A31F2C@SOL> From: Vincent Finn <qcarrillo@example.net> To: 'Berin Lautenbach' <qcarrillo@example.net>, Vincent Finn <qcarrillo@example.net> Cc: Apache XML DSIG <qcarrillo@example.net> Subject: RE: Strange compile error Date: Tue, 2 Sep 2003 11:34:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N number 1 is what I have done in my local copy is the library not intended to be coupled with Xerces? I thought the 2 projects were (sort of) connected, both being on the XML.Apache site! > -----Original Message----- > From: Berin Lautenbach [mailto:qcarrillo@example.net] > Sent: 02 September 2003 11:13 > To: Vincent Finn > Cc: Apache XML DSIG > Subject: Re: Strange compile error > > > Vincent, > > Will look into defining _MEM_DEBUG. I think including > windows.h for all > includes is also overkill - I only need it in some places, so I will > look at trying to cut the whole thing down a bit. > > On the other one, I can see a couple of solutions : > > 1. Don't inject into global namespace within include files - so have > all references to Xerces/Xalan elements be fully qualified > until I hit > the actual cpp files. This ties everything more tightly with > Xerces/Xalan, but that's about the only "negative" I can see. > > 2. Define a xsec namespace and then inject into there. Seems like > overkill, and means people have to worry about Xerces/Xalan and Xsec > namespaces. > > 3. typedef everything to a new type. It's probably the best > way to do > it architecturally (place an interface between the DOM > library and the > XSEC library), but we'd then need wrappers around things to > get correct > types returned, and it could quickly get nasty. > > So I think I'm leaning with number 1 (for now), but interested in > thoughts. Any other options gratefully received :>. > > Cheers, > Berin > > Vincent Finn wrote: > > That sounds fine, undefing _DEBUG before the headers is a > bit less hacky > > than doing _WINDOWS_ > > > > > > > >>-----Original Message----- > >>From: Berin Lautenbach [mailto:qcarrillo@example.net] > >>Sent: 30 August 2003 03:40 > >>To: Vincent Finn > >>Cc: 'qcarrillo@example.net' > >>Subject: Re: Strange compile error > >> > >> > >>Vincent, > >> > >>Firstly - apologies for not replying sooner. Was away all week and > >>no-where near e-mail. > >> > >>The reason for afx.h in the debug build is to allow us to use the > >>Windows memory debugging routines. But it means you need an > >>MFC build. > >> Pain in the neck, but it's helped me track some really > >>nasty memory leaks. > >> > >>You could undefine the _DEBUG flag in the debug build - but > >>that's messy > >>as well. > >> > >>How about I create a new define _MEM_DEBUG that can be > turned off in > >>XSECW32Config.h to go back to normal includes? > >> > >>On the second question - Ouch. Yes I can see the problem. > >>Let me have > >>a think. > >> > >>Cheers, > >> Berin > >> > >> > >>Vincent Finn wrote: > >> > >>>Hi, > >>> > >>>I tracked my problems down and it leaves me with a few questions > >>> > >>>The first is about the debug error > >>> > >>>This comes from the fact that in XSECDefs.hpp there is code > >> > >>that includes > >> > >>>"afx.h" for debug builds > >>>and "windows.h" for release ones > >>>afx.h eventually includes afxv_w32.h which will stop > windows.h being > >>>included twice > >>>this will stop any ATL projects from building since they > >> > >>automatically > >> > >>>include windows.h > >>> > >>>why is there a different include for debug (except for the > >> > >>crtdbg bit > >> > >>>obviously)? > >>> > >>>I can get around this by undefing _WINDOWS_ for the xsec > >> > >>headers but that > >> > >>>seems to be very hacky > >>>the alternative would seem to be to remove the header but > >> > >>this won't compile > >> > >>>is there a better solution? > >>> > >>>--- > >>> > >>>The second question is why are the Xerces classes being > >> > >>injected into the > >> > >>>global namespace? > >>>e.g. XSEC_DECLARE_XERCES_CLASS(DOMDocument); > >>>this seems a bit extreme to me and causes my other problem > >>> > >>>The compile bug happens because the VC ATL wizard > >> > >>automatically includes > >> > >>>msxml in ATL dll projects > >>>(it a hidden dependency somehow, so I can't get rid of it) > >>>and they inject DOMDocument into the global namespace > >>> > >>>so know you get 2 DOMDocuments in the global namespace > >>> > >>>I am currently running with a modified library > >>>with XSEC_DECLARE_XERCES_CLASS(DOMDocument) which requires > >> > >>a lot of other > >> > >>>minor changes > >>> > >>>Is there a better solution for this problem too? > >>> > >>> > >>>I would prefer a solution that could be done in the library > >> > >>(or my calling > >> > >>>code) > >>>I don't really want to be using a hacked version of the > >> > >>xsec since it makes > >> > >>>upgrading a mess! > >>> > >>>Any suggestions appreciated > >>> > >>> Vin > >>> > >>> > >>>------------------------------------------------------------- > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Vincent Finn > >>>>Sent: 27 August 2003 12:39 > >>>>To: 'qcarrillo@example.net' > >>>>Subject: Strange compile error > >>>> > >>>> > >>>>Hi, > >>>> > >>>>I have a strange problem compiling a project using xsec > >>>> > >>>>I am on WinXP, VC6 SP5, xerces 2.2, openssl 0.9.7b, xsec 1.0 > >>>>I have a COM dll which currently uses xerces to create an XML file > >>>>I am adding xsec in to sign the file > >>>> > >>>>when I add the line > >>>>#include <xsec/framework/XSECProvider.hpp> > >>>>I get errors (the same is true for other xsec includes) > >>>> > >>>>The strange part is that I have code in a test (console) > >> > >>project which > >> > >>>>parses an XML file and signs it and this works, but not in my > >>>>real project > >>>>also I get very different errors in debug and release > >>>> > >>>>the only other point I can think of worth mentioning is that > >>>>I do have a global using statement > >>>>using namespace XERCES_CPP_NAMESPACE; > >>>> > >>>>Has anyone seen this or have any idea what it might be? > >>>> > >>>> Thanks, Vin > >>>> > >>>> > >>>>The errors are as follows > >>>>in DEBUG > >>>>c:\program files\microsoft visual > >>>>studio\vc98\mfc\include\afxv_w32.h(14): fatal error C1189: > >>>>#error : WINDOWS.H already included. MFC apps must not > >>>>#include <windows.h> > >>>> > >>>>in RELEASE > >>>>C:\LIBS\XML-SECURITY-C-1.0.0\INCLUDE\xsec/utils/XSECSafeBuffer > >>>>Formatter.hpp(108): warning C4100: 'formatter': unreferenced > >>>>formal parameter > >>>>C:\LIBS\XML-SECURITY-C-1.0.0\INCLUDE\xsec/dsig/DSIGTransform.h > >>>>pp(79): error C2874: using-declaration causes a multiple > >>>>declaration of 'DOMDocument' > >>>> > >>>>C:\LIBS\XERCES-C-SRC2_2_0\SRC\xercesc/dom/DOMDocument.hpp(102) > >>>>: see declaration of 'DOMDocument' > >>>>C:\LIBS\XML-SECURITY-C-1.0.0\INCLUDE\xsec/dsig/DSIGSignedInfo. > >>>>hpp(82): error C2874: using-declaration causes a multiple > >>>>declaration of 'DOMDocument' > >>>> > >>>>C:\LIBS\XERCES-C-SRC2_2_0\SRC\xercesc/dom/DOMDocument.hpp(102) > >>>>: see declaration of 'DOMDocument' > >>>> > >>>>-------------------------------------------------------------- > >>>>--------- > >>>>qcarrillo@example.net > >>>>-------------------------------------------------------------- > >>>>--------- > >>>>INTEL INSIDE: The worlds most widely used warning label. > >>>>------------------------------------------------------------ > >> > >>---------- > >> > >>> > > > From qcarrillo@example.net Tue Sep 2 11:19:43 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Delivered-To: moderator for qcarrillo@example.net Received: (qmail 32257 invoked from network); 2 Sep 2003 11:19:43 -0000 Received: from unknown (HELO minotaur.apache.org) (83.161.120.155) by daedalus.apache.org with SMTP; 2 Sep 2003 11:19:43 -0000 Received: (qmail 46887 invoked by uid 1064); 2 Sep 2003 11:19:34 -0000 Date: 2 Sep 2003 11:19:34 -0000 Message-ID: <qcarrillo@example.net> From: Sam Ruby <qcarrillo@example.net> To: qcarrillo@example.net Subject: [GUMP] Build Failure - xml-security X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ---------------------------------------------------- This email is autogenerated from the output from: <http://cvs.apache.org/builds/gump/2003-09-02/xml-security.html> ---------------------------------------------------- Buildfile: build.xml [taskdef] dropping /home/rubys/jakarta/xml-security/build/classes from path as it doesn't exist init: [echo] ------------------------------------------------------------------- [echo] --------- Apache-XML-Security-J v1.0.5D2 [2000-2002] ---------------- [echo] ------------------------------------------------------------------- clean-testdata: clean: prepare: [mkdir] Created dir: /home/rubys/jakarta/xml-security/build prepare-src: [mkdir] Created dir: /home/rubys/jakarta/xml-security/build/src [mkdir] Created dir: /home/rubys/jakarta/xml-security/build/classes [copy] Copying 1 file to /home/rubys/jakarta/xml-security/build/classes [copy] Copying 1 file to /home/rubys/jakarta/xml-security/build/classes [copy] Copying 179 files to /home/rubys/jakarta/xml-security/build/src [mkdir] Created dir: /home/rubys/jakarta/xml-security/build/classes/META-INF javadoc: [mkdir] Created dir: /home/rubys/jakarta/xml-security/build/doc [mkdir] Created dir: /home/rubys/jakarta/xml-security/build/doc/html [mkdir] Created dir: /home/rubys/jakarta/xml-security/build/doc/html/api [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.xml.security.algorithms... [javadoc] Loading source files for package org.apache.xml.security.c14n... [javadoc] Loading source files for package org.apache.xml.security.encryption... [javadoc] Loading source files for package org.apache.xml.security.exceptions... [javadoc] Loading source files for package org.apache.xml.security.keys... [javadoc] Loading source files for package org.apache.xml.security.keys.content... [javadoc] Loading source files for package org.apache.xml.security.keys.content.keyvalues... [javadoc] Loading source files for package org.apache.xml.security.keys.content.x509... [javadoc] Loading source files for package org.apache.xml.security.keys.keyresolver... [javadoc] Loading source files for package org.apache.xml.security.keys.storage... [javadoc] Loading source files for package org.apache.xml.security.signature... [javadoc] Loading source files for package org.apache.xml.security.transforms... [javadoc] Loading source files for package org.apache.xml.security.transforms.params... [javadoc] Loading source files for package org.apache.xml.security.utils... [javadoc] Loading source files for package org.apache.xml.security.utils.resolver... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.4.1 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolverSpi.java:100: warning - Tag @link: reference not found: ResourceResolver [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolverSpi.java:100: warning - Tag @link: reference not found: ResourceResolverSpi [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolver.java:210: warning - Tag @link: reference not found: KeyInfo [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolver.java:222: warning - Tag @link: reference not found: KeyInfo [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/utils/XPathFuncHereAPI.java:97: warning - Tag @link: reference not found: XPathAPI [javadoc] Building index for all classes... [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/utils/XPathFuncHereAPI.java:97: warning - Tag @link: reference not found: XPathAPI [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/encryption/Transforms.java:81: warning - Tag @see: reference not found: CipherReference. [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/encryption/ReferenceList.java:88: warning - Tag @see: reference not found: Reference. [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolver.java:210: warning - Tag @link: reference not found: KeyInfo [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolver.java:222: warning - Tag @link: reference not found: KeyInfo [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolver.java:210: warning - Tag @link: reference not found: KeyInfo [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolver.java:210: warning - Tag @link: reference not found: KeyInfo [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolver.java:210: warning - Tag @link: reference not found: KeyInfo#registerInternalKeyResolver [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolver.java:222: warning - Tag @link: reference not found: KeyInfo [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolver.java:222: warning - Tag @link: reference not found: KeyInfo [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolver.java:222: warning - Tag @link: reference not found: KeyInfo#registerInternalKeyResolver [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolverSpi.java:100: warning - Tag @link: reference not found: ResourceResolver [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolverSpi.java:100: warning - Tag @link: reference not found: ResourceResolverSpi [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolverSpi.java:100: warning - Tag @link: reference not found: ResourceResolver [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/keys/keyresolver/KeyResolverSpi.java:100: warning - Tag @link: reference not found: ResourceResolverSpi [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/transforms/Transform.java:98: warning - Tag @see: reference not found: Canonicalizer [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/transforms/params/XPathContainer.java:78: warning - Tag @link: reference not found: Element [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/utils/XPathFuncHereAPI.java:97: warning - Tag @link: reference not found: XPathAPI [javadoc] /home/rubys/jakarta/xml-security/build/src/org/apache/xml/security/utils/resolver/ResourceResolver.java:91: warning - Tag @link: reference not found: javax.xml.transform.stream.StreamSource#getSystemId [javadoc] Generating /home/rubys/jakarta/xml-security/build/doc/html/api/stylesheet.css... [javadoc] 24 warnings get-jce: check-bc: [md5] The hash values of /opt/jce/jce-jdk13-116.jar are OK compile.library: [javac] Compiling 145 source files to /home/rubys/jakarta/xml-security/build/classes [copy] Copying 4 files to /home/rubys/jakarta/xml-security/build/classes compile.samples: [javac] Compiling 40 source files to /home/rubys/jakarta/xml-security/build/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. compile.tests: [javac] Compiling 29 source files to /home/rubys/jakarta/xml-security/build/classes [javac] /home/rubys/jakarta/xml-security/src_unitTests/org/apache/xml/security/test/algorithms/implementations/BlockEncryptionTest.java:73: package org.apache.xml.security.algorithms.encryption does not exist [javac] import org.apache.xml.security.algorithms.encryption.EncryptionMethod; [javac] ^ [javac] /home/rubys/jakarta/xml-security/src_unitTests/org/apache/xml/security/test/algorithms/implementations/KeyWrapTest.java:73: package org.apache.xml.security.algorithms.encryption does not exist [javac] import org.apache.xml.security.algorithms.encryption.EncryptionMethod; [javac] ^ [javac] /home/rubys/jakarta/xml-security/src_unitTests/org/apache/xml/security/test/algorithms/implementations/BlockEncryptionTest.java:168: cannot resolve symbol [javac] symbol : class EncryptionMethod [javac] location: class org.apache.xml.security.test.algorithms.implementations.BlockEncryptionTest [javac] EncryptionMethod bea = new EncryptionMethod(doc, keyURI); [javac] ^ [javac] /home/rubys/jakarta/xml-security/src_unitTests/org/apache/xml/security/test/algorithms/implementations/BlockEncryptionTest.java:168: cannot resolve symbol [javac] symbol : class EncryptionMethod [javac] location: class org.apache.xml.security.test.algorithms.implementations.BlockEncryptionTest [javac] EncryptionMethod bea = new EncryptionMethod(doc, keyURI); [javac] ^ [javac] /home/rubys/jakarta/xml-security/src_unitTests/org/apache/xml/security/test/algorithms/implementations/KeyWrapTest.java:193: cannot resolve symbol [javac] symbol : class EncryptionMethod [javac] location: class org.apache.xml.security.test.algorithms.implementations.KeyWrapTest [javac] EncryptionMethod kwa = new EncryptionMethod(doc, kekURI); [javac] ^ [javac] /home/rubys/jakarta/xml-security/src_unitTests/org/apache/xml/security/test/algorithms/implementations/KeyWrapTest.java:193: cannot resolve symbol [javac] symbol : class EncryptionMethod [javac] location: class org.apache.xml.security.test.algorithms.implementations.KeyWrapTest [javac] EncryptionMethod kwa = new EncryptionMethod(doc, kekURI); [javac] ^ [javac] 6 errors BUILD FAILED /home/rubys/jakarta/xml-security/build.xml:468: Compile failed; see the compiler error output for details. Total time: 21 seconds From qcarrillo@example.net Wed Sep 3 10:02:18 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 77668 invoked from network); 3 Sep 2003 10:02:18 -0000 Received: from unknown (HELO mta03.mail.mel.aone.net.au) (83.161.120.155) by daedalus.apache.org with SMTP; 3 Sep 2003 10:02:18 -0000 Received: from ozemail.com.au ([83.161.120.155]) by mta03.mail.mel.aone.net.au with ESMTP id <qcarrillo@example.net>; Wed, 3 Sep 2003 20:02:19 +1000 Message-ID: <qcarrillo@example.net> Date: Wed, 03 Sep 2003 20:02:19 +1000 From: Berin Lautenbach <qcarrillo@example.net> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent Finn <qcarrillo@example.net> CC: Apache XML DSIG <qcarrillo@example.net> Subject: Re: Strange compile error References: <98F7681DB5B4D311AC9D0090279C2173A31F2C@SOL> In-Reply-To: <98F7681DB5B4D311AC9D0090279C2173A31F2C@SOL> X-Enigmail-Version: 83.161.120.155 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Vincent Finn wrote: > number 1 is what I have done in my local copy > is the library not intended to be coupled with Xerces? > I thought the 2 projects were (sort of) connected, both being on the > XML.Apache site! <GRIN>. Yup. But it's always nice to think about how to make things more flexible. Cheers, Berin From qcarrillo@example.net Wed Sep 3 19:38:56 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 56487 invoked from network); 3 Sep 2003 19:38:56 -0000 Received: from unknown (HELO mail-mta4.service.ohio-state.edu) (83.161.120.155) by daedalus.apache.org with SMTP; 3 Sep 2003 19:38:56 -0000 Received: from SAIDIN (dhcp-840.935.1472.it.ohio-state.edu [83.161.120.155]) by mail-mta4.service.ohio-state.edu (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <qcarrillo@example.net> for qcarrillo@example.net; Wed, 03 Sep 2003 15:38:58 -0400 (EDT) Date: Wed, 03 Sep 2003 15:38:55 -0400 From: Scott Cantor <qcarrillo@example.net> Subject: Extra linefeed in base64 encoder? To: qcarrillo@example.net Message-id: <002301c37253$02bf0130$5cf39280@SAIDIN> Organization: The Ohio State University MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Not sure if this is a bug or not, but the Base64 encoder used by the Java xmlsec code inserts an extra linefeed if an encoded object is exactly the length of a multiple of the line length setting. (IOW, if you wrap after 76 bytes, it puts an extra linefeed in if the object is a multiple of 76 after encoding). There's even a comment in the code about it, and it says Sun did something similar. Well, Xerces-C claims it's not valid base64 when it schema-validates. Now, Xerces-C as of 2.2 is horrendously strict, so much so that I'm pretty sure it rejects legal stuff, and I've sent in a note about it. But they may actually be following the letter of the spec, I don't know. I'm not sure there *is* a clear spec for putting base64 in XML, frankly. It's a mess, to me. So I guess my question is, does anybody know who's wrong? And if xmlsec is, can that code be patched? -- Scott From qcarrillo@example.net Wed Sep 3 20:11:58 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 65778 invoked from network); 3 Sep 2003 20:11:58 -0000 Received: from unknown (HELO aalbes.hosting.west.nl) (83.161.120.155) by daedalus.apache.org with SMTP; 3 Sep 2003 20:11:58 -0000 Received: from mydomain.com (localhost [83.161.120.155]) by aalbes.hosting.west.nl (Postfix) with SMTP id 5994BB77B; Wed, 3 Sep 2003 22:11:58 +0200 (CEST) Received: from 83.161.120.155 (SquirrelMail authenticated user erwin) by aalbes.hosting.west.nl with HTTP; Wed, 3 Sep 2003 22:11:58 +0200 (CEST) Message-ID: <qcarrillo@example.net> Date: Wed, 3 Sep 2003 22:11:58 +0200 (CEST) Subject: Re: Extra linefeed in base64 encoder? From: "Erwin van der Koogh" <qcarrillo@example.net> To: <qcarrillo@example.net> In-Reply-To: <002301c37253$02bf0130$5cf39280@SAIDIN> References: <002301c37253$02bf0130$5cf39280@SAIDIN> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: <qcarrillo@example.net> X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > Not sure if this is a bug or not, but the Base64 encoder used by the > Java xmlsec code inserts an extra linefeed if an encoded object is > exactly the length of a multiple of the line length setting. (IOW, if > you wrap after 76 bytes, it puts an extra linefeed in if the object is > a multiple of 76 after encoding). There's even a comment in the code > about it, and it says Sun did something similar. I would have to go back and read the Base64 spec.. I have done it so many times, but I still get headaches when trying to remember details from it :) > Well, Xerces-C claims it's not valid base64 when it schema-validates. It might be right :) > Now, Xerces-C as of 2.2 is horrendously strict, so much so that I'm > pretty sure it rejects legal stuff, and I've sent in a note about it. > But they may actually be following the letter of the spec, I don't > know. I'm not sure there *is* a clear spec for putting base64 in XML, > frankly. It's a mess, to me. > > So I guess my question is, does anybody know who's wrong? And if xmlsec > is, can that code be patched? I am horrendiously busy this and next week, but I would be more than willing to patch it in the meantime if someone else would be willing to do a little research and c&p the following in an email to the list: - Base64 spec about wrapping - XML spec about base64 encoding (if anything) - XML Signature spec about base64 encoding (if anything) If there is nothing in the specs I will commit a patch if it passes the interop testing. Erwin From qcarrillo@example.net Wed Sep 3 21:18:26 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 30369 invoked from network); 3 Sep 2003 21:18:26 -0000 Received: from unknown (HELO aalbes.hosting.west.nl) (83.161.120.155) by daedalus.apache.org with SMTP; 3 Sep 2003 21:18:26 -0000 Received: from mydomain.com (localhost [83.161.120.155]) by aalbes.hosting.west.nl (Postfix) with SMTP id 8D6C2B77B; Wed, 3 Sep 2003 23:18:26 +0200 (CEST) Received: from 83.161.120.155 (SquirrelMail authenticated user erwin) by aalbes.hosting.west.nl with HTTP; Wed, 3 Sep 2003 23:18:26 +0200 (CEST) Message-ID: <qcarrillo@example.net> Date: Wed, 3 Sep 2003 23:18:26 +0200 (CEST) Subject: RE: Extra linefeed in base64 encoder? From: "Erwin van der Koogh" <qcarrillo@example.net> To: <qcarrillo@example.net> In-Reply-To: <000001c3725c$67fb8380$5cf39280@SAIDIN> References: <qcarrillo@example.net> <000001c3725c$67fb8380$5cf39280@SAIDIN> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: <qcarrillo@example.net> X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > Ok, here's some info: > http://marc.theaimsgroup.com/?l=xerces-c-dev&m=106261978927834&w=2 > > Probably what xmlsec is producing is legal base64, but it's not legal > XML Schema base64: > > http://www.w3.org/2001/05/xmlschema-rec-comments.html#pfibase64 The spec is pretty specific, although somewhat confusing, but it officially doesn't allow more than 1 linefeed after the base64 quartets and does not even allow other white characters other than that. > The base64 spec itself doesn't have much to say about this issue, but > there are specific text-encodings of base64 that do. XML itself has no > such encoding specified that I've ever found. XML Schema apparently now > does, in this errata he referenced. base64 doesn't seem to care too much about whitespace and no decoder (general purpose decoder that is) should fail on any base64 encoding with or without whitespace. > It now dictates that lexically, linefeeds are not required, which is > nice. Too bad so many decoders choke if they're not present, in my > experience, though maybe Xerces-J no longer does. ;-) I would definately be in favor of keeping the linefeeds in the base64 encoded strings within Xerces, if nothing else because it looks prettier :) > Lexically speaking, Xerces-C claims that you can't have multiple > whitespace characters in a row according to that grammar, which would > show up if you have the extra linefeed at the end. They are right and I think it should be fixed. If anyone has any objections, please let me know sometime soon. I will be looking to commit a patch at the earliest opportunity from Sunday on, but Sunday is not all that unlikely. Patches are welcome :) >> I am horrendiously busy this and next week, but I would be >> more than willing to patch it in the meantime if someone else >> would be willing to do a little research and c&p the >> following in an email to the list: >> - Base64 spec about wrapping >> - XML spec about base64 encoding (if anything) >> - XML Signature spec about base64 encoding (if anything) > > I don't think the Signature spec says anything, but I could be wrong. I > think the issue here is with XML Schema, and I would think it would be > preferable for anything outputting base64 to shoot for > schema-compliance lest it produce XML that can't validate. I don't expect the signature spec to say anything but "the xml must be well-formed according to XML-Schema" of something similar, but I'll check just to be sure. Erwin From qcarrillo@example.net Wed Sep 3 21:24:36 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 47115 invoked from network); 3 Sep 2003 21:24:36 -0000 Received: from unknown (HELO mail-mta4.service.ohio-state.edu) (83.161.120.155) by daedalus.apache.org with SMTP; 3 Sep 2003 21:24:36 -0000 Received: from SAIDIN (dhcp-840.935.1472.it.ohio-state.edu [83.161.120.155]) by mail-mta4.service.ohio-state.edu (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <qcarrillo@example.net> for qcarrillo@example.net; Wed, 03 Sep 2003 17:24:38 -0400 (EDT) Date: Wed, 03 Sep 2003 17:24:37 -0400 From: Scott Cantor <qcarrillo@example.net> Subject: RE: Extra linefeed in base64 encoder? In-reply-to: <qcarrillo@example.net> To: 'Erwin van der Koogh' <qcarrillo@example.net> Cc: qcarrillo@example.net Message-id: <000501c37261$c777feb0$5cf39280@SAIDIN> Organization: The Ohio State University MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > base64 doesn't seem to care too much about whitespace and no > decoder (general purpose decoder that is) should fail on any > base64 encoding with or without whitespace. Xerces-C admittedly doesn't promise that their decoder class is for public consumption, but this error is being thrown by the validator anyway, so that's technically correct no matter what their decoder might allow. > They are right and I think it should be fixed. If anyone has > any objections, please let me know sometime soon. I will be > looking to commit a patch at the earliest opportunity from > Sunday on, but Sunday is not all that unlikely. Patches are welcome :) I'm jammed myself, and we won't be shipping a new release immediately anyway, so I'm not in a major hurry. So far only one cert ended up aligning on a 76 byte boundary in the whole testing community. ;-) Thanks...I mostly wanted to make sure it got addressed before any new release of the codebase, which I saw was being tossed around. -- Scott From qcarrillo@example.net Wed Sep 3 21:46:32 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 19740 invoked from network); 3 Sep 2003 21:46:32 -0000 Received: from unknown (HELO mail-mta4.service.ohio-state.edu) (83.161.120.155) by daedalus.apache.org with SMTP; 3 Sep 2003 21:46:32 -0000 Received: from SAIDIN (dhcp-840.935.1472.it.ohio-state.edu [83.161.120.155]) by mail-mta4.service.ohio-state.edu (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <qcarrillo@example.net> for qcarrillo@example.net; Wed, 03 Sep 2003 16:46:10 -0400 (EDT) Date: Wed, 03 Sep 2003 16:46:10 -0400 From: Scott Cantor <qcarrillo@example.net> Subject: RE: Extra linefeed in base64 encoder? In-reply-to: <qcarrillo@example.net> To: 'Erwin van der Koogh' <qcarrillo@example.net> Cc: qcarrillo@example.net Message-id: <000001c3725c$67fb8380$5cf39280@SAIDIN> Organization: The Ohio State University MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > I would have to go back and read the Base64 spec.. I have > done it so many times, but I still get headaches when trying > to remember details from it +1 > > Well, Xerces-C claims it's not valid base64 when it schema-validates. > > It might be right :) Ok, here's some info: http://marc.theaimsgroup.com/?l=xerces-c-dev&m=106261978927834&w=2 Probably what xmlsec is producing is legal base64, but it's not legal XML Schema base64: http://www.w3.org/2001/05/xmlschema-rec-comments.html#pfibase64 The base64 spec itself doesn't have much to say about this issue, but there are specific text-encodings of base64 that do. XML itself has no such encoding specified that I've ever found. XML Schema apparently now does, in this errata he referenced. It now dictates that lexically, linefeeds are not required, which is nice. Too bad so many decoders choke if they're not present, in my experience, though maybe Xerces-J no longer does. ;-) Lexically speaking, Xerces-C claims that you can't have multiple whitespace characters in a row according to that grammar, which would show up if you have the extra linefeed at the end. > I am horrendiously busy this and next week, but I would be > more than willing to patch it in the meantime if someone else > would be willing to do a little research and c&p the > following in an email to the list: > - Base64 spec about wrapping > - XML spec about base64 encoding (if anything) > - XML Signature spec about base64 encoding (if anything) I don't think the Signature spec says anything, but I could be wrong. I think the issue here is with XML Schema, and I would think it would be preferable for anything outputting base64 to shoot for schema-compliance lest it produce XML that can't validate. -- Scott From qcarrillo@example.net Fri Sep 5 18:11:01 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Delivered-To: moderator for qcarrillo@example.net Received: (qmail 28113 invoked from network); 5 Sep 2003 18:11:01 -0000 Received: from unknown (HELO fort-point-station.mit.edu) (83.161.120.155) by daedalus.apache.org with SMTP; 5 Sep 2003 18:11:01 -0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [83.161.120.155]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h85HmGNX009253; Fri, 5 Sep 2003 13:50:49 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [83.161.120.155]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h85HjiSZ004877; Fri, 5 Sep 2003 13:45:45 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [83.161.120.155]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h85HjiGr028321; Fri, 5 Sep 2003 13:45:44 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h85HjhWS029106; Fri, 5 Sep 2003 13:45:43 -0400 (EDT) To: qcarrillo@example.net Cc: qcarrillo@example.net Subject: Xml-Security-1.0.0 fails to use OPENSSL properly From: Derek Atkins <qcarrillo@example.net> Date: 05 Sep 2003 13:45:43 -0400 Message-ID: <qcarrillo@example.net> Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --=-=-= I just tried building xml-security-c-1.0.0 and it failed to accept my OPENSSL configure setting properly. The enclosed (trivial) patch to configure.ac fixes the problem. Thanks, -derek --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=xml-security-c-1.0.0.diff Content-Description: XML Security Patch --- src/configure.ac~ 2003-08-05 07:49:49.000000000 -0400 +++ src/configure.ac 2003-09-05 13:22:02.000000000 -0400 @@ -430,7 +430,7 @@ AC_TRY_CPP([#include <openssl/opensslv.h>], openssl_found=yes AC_DEFINE(HAVE_OPENSSL) - LIBS="${LIBS} -L${OPENSSL} -lcrypto" + LIBS="${LIBS} -L${OPENSSL}/lib -lcrypto" [AC_MSG_RESULT([found])], CPPFLAGS=$OLD_CPPFLAGS [AC_MSG_RESULT([no])]); --=-=-= -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH qcarrillo@example.net PGP key available --=-=-=-- From qcarrillo@example.net Fri Sep 5 23:58:31 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 97879 invoked from network); 5 Sep 2003 23:58:31 -0000 Received: from unknown (HELO mta05.mail.mel.aone.net.au) (83.161.120.155) by daedalus.apache.org with SMTP; 5 Sep 2003 23:58:31 -0000 Received: from ozemail.com.au ([83.161.120.155]) by mta05.mail.mel.aone.net.au with ESMTP id <qcarrillo@example.net>; Sat, 6 Sep 2003 09:58:31 +1000 Message-ID: <qcarrillo@example.net> Date: Sat, 06 Sep 2003 09:58:31 +1000 From: Berin Lautenbach <qcarrillo@example.net> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek Atkins <qcarrillo@example.net> CC: qcarrillo@example.net Subject: Re: Xml-Security-1.0.0 fails to use OPENSSL properly References: <qcarrillo@example.net> In-Reply-To: <qcarrillo@example.net> X-Enigmail-Version: 83.161.120.155 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Derek, That's a strange one. What version of OpenSSL are you using and what platform? I've got an "out of the box" 0.9.7b that compiles up on linux with the libraries in the base directory, so the original settings work correctly. Are you trying to point the configure script to something different? If that's the case, then maybe I need to be a bit more clever in testing for OpenSSL? (configure is very niaeve at the moment.) Cheers, Berin Derek Atkins wrote: > I just tried building xml-security-c-1.0.0 and it failed to > accept my OPENSSL configure setting properly. The enclosed > (trivial) patch to configure.ac fixes the problem. > > Thanks, > > -derek > > > > ------------------------------------------------------------------------ > > --- src/configure.ac~ 2003-08-05 07:49:49.000000000 -0400 > +++ src/configure.ac 2003-09-05 13:22:02.000000000 -0400 > @@ -430,7 +430,7 @@ > AC_TRY_CPP([#include <openssl/opensslv.h>], > openssl_found=yes > AC_DEFINE(HAVE_OPENSSL) > - LIBS="${LIBS} -L${OPENSSL} -lcrypto" > + LIBS="${LIBS} -L${OPENSSL}/lib -lcrypto" > [AC_MSG_RESULT([found])], > CPPFLAGS=$OLD_CPPFLAGS > [AC_MSG_RESULT([no])]); > > > ------------------------------------------------------------------------ > > From qcarrillo@example.net Sat Sep 6 00:19:43 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 37329 invoked from network); 6 Sep 2003 00:19:43 -0000 Received: from unknown (HELO fort-point-station.mit.edu) (83.161.120.155) by daedalus.apache.org with SMTP; 6 Sep 2003 00:19:43 -0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [83.161.120.155]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h860Jg8I014352; Fri, 5 Sep 2003 20:19:42 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [83.161.120.155]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h860HQ0F015360; Fri, 5 Sep 2003 20:17:26 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [83.161.120.155]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h860BRGr001894; Fri, 5 Sep 2003 20:11:27 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h860BQCh029808; Fri, 5 Sep 2003 20:11:26 -0400 (EDT) To: Berin Lautenbach <qcarrillo@example.net> Cc: qcarrillo@example.net Subject: Re: Xml-Security-1.0.0 fails to use OPENSSL properly References: <qcarrillo@example.net> <qcarrillo@example.net> From: Derek Atkins <qcarrillo@example.net> Date: 05 Sep 2003 20:11:26 -0400 In-Reply-To: <qcarrillo@example.net> Message-ID: <qcarrillo@example.net> Lines: 78 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi, Berin Lautenbach <qcarrillo@example.net> writes: > Derek, > > That's a strange one. What version of OpenSSL are you using and what > platform? It's not strange at all, it's a clear bug in configure.ac when trying to use a user-supplied ${OPENSSL}. Consider this patch in the face of the rest of configure.ac (in particular, look at line 428 in the 1.0.0 release). I've got multiple versions of OpenSSL and I'm trying to use OPENSSL=... to point xml-security-c-1.0.0 at a specific version. Line 428 says: CPPFLAGS=["${CPPFLAGS} -I${OPENSSL}/include"] This is correct, and it successfully finds the ssl .h file using this include path. But then after this succeeds you have: AC_DEFINE(HAVE_OPENSSL) LIBS="${LIBS} -L${OPENSSL} -lcrypto" This is clearly wrong; this should be adding ${OPENSSL}/lib to the LIBS path so it finds the correct library. > I've got an "out of the box" 0.9.7b that compiles up on linux with the > libraries in the base directory, so the original settings work > correctly. > > Are you trying to point the configure script to something different? Yes. I'm trying to point it at a specific version of OPENSSL using the ${OPENSSL} environment variable. > If that's the case, then maybe I need to be a bit more clever in > testing for OpenSSL? (configure is very niaeve at the moment.) Nope.. You just need to use the provided ${OPENSSL} correctly as per my patch. See above. > Cheers, > Berin FWIW I've tested with this patch, and it works perfectly for me. -derek > Derek Atkins wrote: > > I just tried building xml-security-c-1.0.0 and it failed to > > accept my OPENSSL configure setting properly. The enclosed > > (trivial) patch to configure.ac fixes the problem. > > Thanks, > > -derek > > ------------------------------------------------------------------------ > > --- src/configure.ac~ 2003-08-05 07:49:49.000000000 -0400 > > +++ src/configure.ac 2003-09-05 13:22:02.000000000 -0400 > > @@ -430,7 +430,7 @@ > > AC_TRY_CPP([#include <openssl/opensslv.h>], openssl_found=yes > > AC_DEFINE(HAVE_OPENSSL) > > - LIBS="${LIBS} -L${OPENSSL} -lcrypto" > > + LIBS="${LIBS} -L${OPENSSL}/lib -lcrypto" > > [AC_MSG_RESULT([found])], CPPFLAGS=$OLD_CPPFLAGS > > [AC_MSG_RESULT([no])]); > > ------------------------------------------------------------------------ > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH qcarrillo@example.net PGP key available From qcarrillo@example.net Mon Sep 8 12:39:05 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 88952 invoked from network); 8 Sep 2003 12:39:05 -0000 Received: from unknown (HELO mta09.mail.mel.aone.net.au) (83.161.120.155) by daedalus.apache.org with SMTP; 8 Sep 2003 12:39:05 -0000 Received: from ozemail.com.au ([83.161.120.155]) by mta04.mail.mel.aone.net.au with ESMTP id <qcarrillo@example.net>; Mon, 8 Sep 2003 21:36:37 +1000 Message-ID: <qcarrillo@example.net> Date: Mon, 08 Sep 2003 21:36:36 +1000 From: Berin Lautenbach <qcarrillo@example.net> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek Atkins <qcarrillo@example.net> CC: qcarrillo@example.net Subject: Re: Xml-Security-1.0.0 fails to use OPENSSL properly References: <qcarrillo@example.net> <qcarrillo@example.net> <qcarrillo@example.net> In-Reply-To: <qcarrillo@example.net> X-Enigmail-Version: 83.161.120.155 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Derek, Apologies - didn't make myself clear. The OPENSSL env variable is used to point to a standard *non-installed* copy of OpenSSL. I.e. un-tar, and compile, and you will come up with a directory structure where the includes are in $OPENSSL/include, but the libraries are placed in $OPENSSL. (The compilation doesn't make a lib directory for normal linux/solaris installs.) I *think* you have then done a "make install" into specific directory structures somewhere, at which point the install will place libs into a lib directory off the base install point. So, for what the configure.ac is designed for, it's not broken. (Note that Xerces and Xalan create a lib directory within their own directory structures, thus the usage of "lib" in configure.ac for these.) I've put a patch into cvs that first tries to link using -L${OPENSSL} and if that fails then tries -L{OPENSSL}/lib. That should make it work for your purposes but still preserve the original intent. Cheers, Berin Derek Atkins wrote: > Hi, > > Berin Lautenbach <qcarrillo@example.net> writes: > > >>Derek, >> >>That's a strange one. What version of OpenSSL are you using and what >>platform? > > > It's not strange at all, it's a clear bug in configure.ac when trying > to use a user-supplied ${OPENSSL}. Consider this patch in the face of > the rest of configure.ac (in particular, look at line 428 in the 1.0.0 > release). > > I've got multiple versions of OpenSSL and I'm trying to use > OPENSSL=... to point xml-security-c-1.0.0 at a specific > version. > > Line 428 says: > > CPPFLAGS=["${CPPFLAGS} -I${OPENSSL}/include"] > > This is correct, and it successfully finds the ssl .h file using this > include path. But then after this succeeds you have: > > AC_DEFINE(HAVE_OPENSSL) > LIBS="${LIBS} -L${OPENSSL} -lcrypto" > > This is clearly wrong; this should be adding ${OPENSSL}/lib to the > LIBS path so it finds the correct library. > > >>I've got an "out of the box" 0.9.7b that compiles up on linux with the >>libraries in the base directory, so the original settings work >>correctly. >> >>Are you trying to point the configure script to something different? > > > Yes. I'm trying to point it at a specific version of OPENSSL using > the ${OPENSSL} environment variable. > > >>If that's the case, then maybe I need to be a bit more clever in >>testing for OpenSSL? (configure is very niaeve at the moment.) > > > Nope.. You just need to use the provided ${OPENSSL} correctly as per > my patch. See above. > > >>Cheers, >> Berin > > > FWIW I've tested with this patch, and it works perfectly for me. > > -derek > > >>Derek Atkins wrote: >> >>>I just tried building xml-security-c-1.0.0 and it failed to >>>accept my OPENSSL configure setting properly. The enclosed >>>(trivial) patch to configure.ac fixes the problem. >>>Thanks, >>>-derek >>>------------------------------------------------------------------------ >>>--- src/configure.ac~ 2003-08-05 07:49:49.000000000 -0400 >>>+++ src/configure.ac 2003-09-05 13:22:02.000000000 -0400 >>>@@ -430,7 +430,7 @@ >>> AC_TRY_CPP([#include <openssl/opensslv.h>], openssl_found=yes >>>AC_DEFINE(HAVE_OPENSSL) >>>- LIBS="${LIBS} -L${OPENSSL} -lcrypto" >>>+ LIBS="${LIBS} -L${OPENSSL}/lib -lcrypto" >>> [AC_MSG_RESULT([found])], CPPFLAGS=$OLD_CPPFLAGS >>> [AC_MSG_RESULT([no])]); >>>------------------------------------------------------------------------ >>> >> > From qcarrillo@example.net Fri Sep 12 09:53:35 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 3517 invoked from network); 12 Sep 2003 09:53:35 -0000 Received: from unknown (HELO mta09.mail.mel.aone.net.au) (83.161.120.155) by daedalus.apache.org with SMTP; 12 Sep 2003 09:53:35 -0000 Received: from ozemail.com.au ([83.161.120.155]) by mta09.mail.mel.aone.net.au with ESMTP id <qcarrillo@example.net> for <qcarrillo@example.net>; Fri, 12 Sep 2003 19:53:47 +1000 Message-ID: <qcarrillo@example.net> Date: Fri, 12 Sep 2003 19:53:48 +1000 From: Berin Lautenbach <qcarrillo@example.net> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Apache XML DSIG <qcarrillo@example.net> Subject: [Fwd: Crypto Binaries Revisited] X-Enigmail-Version: 83.161.120.155 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Peoples, May be of interest. We are getting closer to being able to distribute the binary version of the library once encryption is included. Note however that this has _not_ been approved by the board. Cheers, Berin -------- Original Message -------- Subject: Crypto Binaries Revisited Date: Wed, 10 Sep 2003 16:57:33 +0100 From: Ben Laurie <qcarrillo@example.net> Reply-To: qcarrillo@example.net To: Apache Board <qcarrillo@example.net> I just had a chat with Mark Murray (FreeBSD Core) about crypto and free software, and he pointed me at a URL: http://www.bis.doc.gov/Encryption/ENCFACTSHEET6_17_02.html This says, right at the end: "Encryption source code that would be considered publicly available (and the corresponding object code) may be exported and reexported to most destinations (see Note) under License Exception TSU (Technology and Software Unrestricted) once proper notification (or a copy of the source code) is provided to BIS and the ENC Encryption Request Coordinator, regardless of whether a fee or royalty is charged for commercial production or sale of products developed using this software. See 15 C.F.R. § 740.13(e)." He also confirmed that FreeBSD do export crypto binaries based on their published source (for example, in the ISO images), and that they gave the BXA notice as required, and were told that it was fine. I therefore propose that we do the same. I can see no reason for further hesitation. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From qcarrillo@example.net Mon Sep 15 14:24:34 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 55763 invoked from network); 15 Sep 2003 14:24:34 -0000 Received: from unknown (HELO mta09.mail.mel.aone.net.au) (83.161.120.155) by daedalus.apache.org with SMTP; 15 Sep 2003 14:24:34 -0000 Received: from ozemail.com.au ([83.161.120.155]) by mta07.mail.mel.aone.net.au with ESMTP id <qcarrillo@example.net>; Mon, 15 Sep 2003 22:17:41 +1000 Message-ID: <qcarrillo@example.net> Date: Mon, 15 Sep 2003 22:17:41 +1000 From: Berin Lautenbach <qcarrillo@example.net> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent Finn <qcarrillo@example.net> CC: qcarrillo@example.net Subject: Re: Strange compile error References: <98F7681DB5B4D311AC9D0090279C2173A31F16@SOL> In-Reply-To: <98F7681DB5B4D311AC9D0090279C2173A31F16@SOL> X-Enigmail-Version: 83.161.120.155 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Vincent Finn wrote: > > The second question is why are the Xerces classes being injected into the > global namespace? > e.g. XSEC_DECLARE_XERCES_CLASS(DOMDocument); > this seems a bit extreme to me and causes my other problem Just to let you know - I have checked in some updates to CVS that simplify Xerces namespace usage. All Xerces classes should now be qualified use only within hpp files. In the CPP files I simply inject all of Xerces namespace into global to make the code easier to handle. Have updated XSEC_DECLARE_XERCES_CLASS to declare only. Cheers, Berin From qcarrillo@example.net Mon Sep 15 15:28:36 2003 Return-Path: <qcarrillo@example.net> Mailing-List: contact qcarrillo@example.net; run by ezmlm Delivered-To: mailing list qcarrillo@example.net Received: (qmail 2811 invoked from network); 15 Sep 2003 15:28:36 -0000 Received: from unknown (HELO nwkea-mail-2.sun.com) (83.161.120.155) by daedalus.apache.org with SMTP; 15 Sep 2003 15:28:36 -0000 Received: from phys-eris-1 ([83.161.120.155]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8FFScoj004775 for <qcarrillo@example.net>; Mon, 15 Sep 2003 08:28:38 -0700 (PDT) Received: from sun.com (dhcp-edub03-220-156.Ireland.Sun.COM [83.161.120.155]) by eris-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <qcarrillo@example.net> for qcarrillo@example.net; Mon, 15 Sep 2003 16:28:38 +0100 (BST) Date: Mon, 15 Sep 2003 16:28:19 +0100 From: Axl Mattheus <qcarrillo@example.net> Subject: Broken org.apache.xml.security.c14n.Canonicalizer? To: qcarrillo@example.net Message-id: <qcarrillo@example.net> MIME-version: 1.0 Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> All,<br> <br>
{'source': 'Apache Software Foundation Public Mail Archives'}