Nabble - Apache XML - Security - Dev

DO NOT REPLY [Bug 48126] no way to indent xmldsig elements

2009-12-04T07:54:06Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=48126

--- Comment #1 from sean.mullan@... 2009-12-04 07:54:03 UTC ---
Yes, we currently don't support this feature. Because pretty-printing after the
signature is generated invalidates the signature, it must be done before the
signature is generated. I'll look into this a bit more to see how difficult it
would be to add.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 48335] New: java.security.InvalidKeyException: Wrong format: RAW bytes needed

2009-12-02T22:41:58Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=48335

Summary: java.security.InvalidKeyException: Wrong format: RAW
bytes needed
Product: Security
Version: unspecified
Platform: PC
OS/Version: Solaris
Status: NEW
Severity: critical
Priority: P2
Component: Encryption
AssignedTo: security-dev@...
ReportedBy: thibd@...

Dear all,

My application encrypt a document and then decrypt it. It works well in Windows
system. When I deployed my app to Solaris, I got this error message:

java.security.InvalidKeyException: Wrong format: RAW bytes needed
at com.sun.crypto.provider.SunJCE_f.a(DashoA13*..)
at com.sun.crypto.provider.SunJCE_f.a(DashoA13*..)
at com.sun.crypto.provider.AESCipher.engineInit(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at
org.apache.xml.security.encryption.XMLCipher.decryptToByteArray(Unknown Source)
at org.apache.xml.security.encryption.XMLCipher.decryptElement(Unknown
Source)
at org.apache.xml.security.encryption.XMLCipher.doFinal(Unknown Source)
at net.paygate.xml.XMLEncrypt.decrypt(Unknown Source)
at net.paygate.xml.hsm.XMLHSMSecure.decryptInHSM(Unknown Source)

----------------------------------
This is the debug information:

INFO [main] (?:?) - Logging in HSM
297570 [main] INFO net.paygate.xml.hsm.HSM_Manager - Logging in HSM
DEBUG [main] (?:?) - Number of Slots: 1
297572 [main] DEBUG net.paygate.xml.hsm.HSM_Manager - Number of Slots: 1
DEBUG [main] (?:?) - Slot: 1 Token Label: partition01
297586 [main] DEBUG net.paygate.xml.hsm.HSM_Manager - Slot: 1 Token Label:
partition01
DEBUG [main] (?:?) - Start decryption by HSM
297602 [main] DEBUG net.paygate.xml.hsm.XMLHSMSecure - Start decryption by HSM
DEBUG [main] (?:?) - Getting key from HSM
297604 [main] DEBUG net.paygate.util.PUtil - Getting key from HSM
DEBUG [main] (?:?) - Key alias: PayGate RSA Private Key
297606 [main] DEBUG net.paygate.util.PUtil - Key alias: PayGate RSA Private
Key
DEBUG [main] (?:?) - Start decryption
297614 [main] DEBUG net.paygate.xml.XMLEncrypt - Start decryption
DEBUG [main] (?:?) - Getting XMLCipher for no transformation...
297619 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - Getting
XMLCipher for no transformation...
DEBUG [main] (?:?) - Constructing XMLCipher...
297621 [main] DEBUG org.apache.xml.security.encryption.XMLCipher -
Constructing XMLCipher...
DEBUG [main] (?:?) - Initializing XMLCipher...
297623 [main] DEBUG org.apache.xml.security.encryption.XMLCipher -
Initializing XMLCipher...
DEBUG [main] (?:?) - opmode = DECRYPT_MODE
297625 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - opmode =
DECRYPT_MODE
DEBUG [main] (?:?) - Processing source element...
297627 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - Processing
source element...
DEBUG [main] (?:?) - Decrypting element...
297630 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - Decrypting
element...
DEBUG [main] (?:?) - Decrypting to ByteArray...
297632 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - Decrypting
to ByteArray...
DEBUG [main] (?:?) - setElement("ds:KeyInfo", "null")
297637 [main] DEBUG org.apache.xml.security.utils.ElementProxy -
setElement("ds:KeyInfo", "null")
DEBUG [main] (?:?) - Try
org.apache.xml.security.keys.keyresolver.implementations.EncryptedKeyResolver
297640 [main] DEBUG org.apache.xml.security.keys.KeyInfo - Try
org.apache.xml.security.keys.keyresolver.implementations.EncryptedKeyResolver
DEBUG [main] (?:?) - EncryptedKeyResolver - Can I resolve xenc:EncryptedKey
297642 [main] DEBUG
org.apache.xml.security.keys.keyresolver.implementations.RSAKeyValueResolver -
EncryptedKeyResolver - Can I resolve xenc:EncryptedKey
DEBUG [main] (?:?) - Passed an Encrypted Key
297645 [main] DEBUG
org.apache.xml.security.keys.keyresolver.implementations.RSAKeyValueResolver -
Passed an Encrypted Key
DEBUG [main] (?:?) - Getting XMLCipher for no transformation...
297647 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - Getting
XMLCipher for no transformation...
DEBUG [main] (?:?) - Constructing XMLCipher...
297649 [main] DEBUG org.apache.xml.security.encryption.XMLCipher -
Constructing XMLCipher...
DEBUG [main] (?:?) - Initializing XMLCipher...
297652 [main] DEBUG org.apache.xml.security.encryption.XMLCipher -
Initializing XMLCipher...
DEBUG [main] (?:?) - opmode = UNWRAP_MODE
297654 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - opmode =
UNWRAP_MODE
DEBUG [main] (?:?) - Loading encrypted key...
297657 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - Loading
encrypted key...
DEBUG [main] (?:?) - Decrypting key from previously loaded EncryptedKey...
297661 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - Decrypting
key from previously loaded EncryptedKey...
DEBUG [main] (?:?) - Encrypted octets:
Gy3fFVo76owt0M1rg/2mLD1cD+TKLf9i1VMqU1cM+NVvbDqXuT47gyXUOyUXL5ujeaVWnu8yAw2T
PAHgku+DWYP+bfzF4xzqw99gn6DFtMmt04yseHqXuG5DrbIb0Nwg44H5mmacSPeUMu2HVhIQMsKy
eJxBLE2PPRURiWIu6Rk=
297663 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - Encrypted
octets:
Gy3fFVo76owt0M1rg/2mLD1cD+TKLf9i1VMqU1cM+NVvbDqXuT47gyXUOyUXL5ujeaVWnu8yAw2T
PAHgku+DWYP+bfzF4x**************
DEBUG [main] (?:?) - Request for URI http://www.w3.org/2001/04/xmlenc#rsa-1_5
297666 [main] DEBUG org.apache.xml.security.algorithms.JCEMapper - Request for
URI http://www.w3.org/2001/04/xmlenc#rsa-1_5
DEBUG [main] (?:?) - JCE Algorithm = RSA/ECB/PKCS1Padding
297669 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - JCE
Algorithm = RSA/ECB/PKCS1Padding
DEBUG [main] (?:?) - Decryption of key type
http://www.w3.org/2001/04/xmlenc#aes128-cbc OK
298093 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - Decryption
of key type http://www.w3.org/2001/04/xmlenc#aes128-cbc OK
DEBUG [main] (?:?) - I could find a secret key using the per-KeyInfo key
resolvers
298095 [main] DEBUG org.apache.xml.security.keys.KeyInfo - I could find a
secret key using the per-KeyInfo key resolvers
DEBUG [main] (?:?) - Encrypted octets:
47buYDgGAsM819iSd9CMJQNmNYpyOErWD+7UZ2IGexC4sETvuCqw7J3YOnTSMlz4CZQj1QXwx0nV
gSvbaAYWzTZHHmGe9YIgmH+DNqd+rJJC2azLgkGyAlP71Ai1GGtTSxk6e6MRklv/BvbqxAgdVxvp
SSsDUvhUHvePMbIfhwp64VtdiwmC4DE7N8GK********
298098 [main] DEBUG org.apache.xml.security.encryption.XMLCipher - Encrypted
octets:
47buYDgGAsM819iSd9CMJQNmNYpyOErWD+7UZ2IGexC4sETvuCqw7J3YOnTSMlz4CZQj1QXwx0nV
gSvbaAYWzTZHHmGe9YIgmH+DNqd+rJJC2azL******
DEBUG [main] (?:?) - Request for URI
http://www.w3.org/2001/04/xmlenc#aes128-cbc
298101 [main] DEBUG org.apache.xml.security.algorithms.JCEMapper - Request for
URI http://www.w3.org/2001/04/xmlenc#aes128-cbc
ERROR [main] (?:?) - org.apache.xml.security.encryption.XMLEncryptionException:
Wrong format: RAW bytes needed
Original Exception was java.security.InvalidKeyException: Wrong format: RAW
bytes needed
298115 [main] ERROR net.paygate.xml.hsm.XMLHSMSecure -
org.apache.xml.security.encryption.XMLEncryptionException: Wrong format: RAW
bytes needed
Original Exception was java.security.InvalidKeyException: Wrong format: RAW
bytes needed
------------------------------------
I could not find solve this issue.
Could you please give me some suggestions solve it?

Thank in advance!

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 48126] no way to indent xmldsig elements

2009-11-04T04:10:00Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=48126

William Wollis <wollis@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P5

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 48126] New: no way to indent xmldsig elements

2009-11-04T04:08:25Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=48126

Summary: no way to indent xmldsig elements
Product: Security
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: enhancement
Priority: P2
Component: Signature
AssignedTo: security-dev@...
ReportedBy: wollis@...

There is (probably) no way to indent (format as I wish) XML Signature elments
created through xmldsig Java API.
It would be helpful to have a way to indenting XML output like in
javax.xml.transform TransformerFactory and Transformer classes throgh
tf.setAttribute("indent-number", new Integer(2)) and
t.setOutputProperty(OutputKeys.INDENT, "yes");
Post-creation transformation cannot be used in conjuction with standard
canonicalization methods (CanonicalizationMethod.EXCLUSIVE_WITH_COMMENTS,
CanonicalizationMethod.EXCLUSIVE,
CanonicalizationMethod.INCLUSIVE_WITH_COMMENTS,CanonicalizationMethod.INCLUSIVE),
so there is no way to achive "pretty print".

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

RE: problems with final link for xml-security-c and solaris

2009-10-16T15:03:57Z

Philip Brown wrote on 2009-10-16:
>> It's probably overdue on my part to regenerate and check in updated
>> libtool files for most of my projects, and this one.
>
> I should mention that xmltooling has similar problems, except worse.

The projects are all checked in with ltmain.sh in svn, so the only way to
get bugfixes is to regenerate that with libtool and update the checked-in
copy. I was basically told that "this is how to do it".

I have no idea *why* I was told to do that, since you still need
automake/autoconf to bootstrap from svn, but that's what I was told. It
seems pointless to me not to just regenerate the libtool files in the
bootstrap and keep it current, so I may just do that. Anybody without
libtool is not likely to have autotools installed either.

-- Scott

Re: problems with final link for xml-security-c and solaris

2009-10-16T14:53:54Z

Scott Cantor wrote:
> Philip Brown wrote on 2009-10-16:
>> well, apparently, installing the most recent libtool (2.2.6a), and then
>> after the compile fails to link the library, doing
>>
>> cd lib; LIBTOOL=libtool gmake -e
>>
>> makes it link
>
> So presumably starting from scratch with that version is the resolution?

maybe, dunno.

> It's probably overdue on my part to regenerate and check in updated libtool
> files for most of my projects, and this one.

I should mention that xmltooling has similar problems, except worse.

it actually CONTINUES the build after silently failing to link
libxmltooling.so.3.0.0

and a similar hack, fixes it.

cd xmltooling; rm libxmltooling.la
LIBTOOL=libtool gmake -e

RE: problems with final link for xml-security-c and solaris

2009-10-16T13:11:01Z

Philip Brown wrote on 2009-10-16:
> well, apparently, installing the most recent libtool (2.2.6a), and then
> after the compile fails to link the library, doing
>
> cd lib; LIBTOOL=libtool gmake -e
>
> makes it link

So presumably starting from scratch with that version is the resolution?
It's probably overdue on my part to regenerate and check in updated libtool
files for most of my projects, and this one.

-- Scott

Re: problems with final link for xml-security-c and solaris

2009-10-16T13:00:52Z

Philip Brown wrote:
> ....
> This may be a key to the mystery, even though a clean way of how to
> SOLVE it, is unclear.
>

hmm.
well, apparently, installing the most recent libtool (2.2.6a), and then
after the compile fails to link the library, doing

cd lib; LIBTOOL=libtool gmake -e

makes it link

Re: problems with final link for xml-security-c and solaris

2009-10-16T12:07:59Z

A bit more on the solaris, sun CC, 64bit oddessy ;

Rebuilding base stuff and trying again with sun cc, even though I know gcc
"works".

Once again, I'm trying to compile xml-security-c with sun (v12) compiler, in
64bit mode.

I was previously building things with

CXX="CC -m64".

Now I'm trying with

CXX=CC
CXXFLAGS=-xO2 -m64 -mt -norunpath
LDFLAGS="-R/var/local/64/lib -L/var/local/64/lib -m64"

it actually builds pretty well, until the last final link. The complains
about 32bit vs 64bit object mismatch.
Turns out that when libtool is called with

bash ../libtool --mode=link CC -xO2 -m64 -mt -norunpath -mt -D_REENTRANT
-DXSEC_LIBRARY_BUILD blah blah...

for some odd reason, it decides to throw away a bunch of its arguments and
instead uses:

CC -G -nolib -hlibxml-security-c.so.15 -o .libs/libxml-security-c.so.15.0.1
.libs/XSECC14n20010315.o blah blah...

No more "-m64". So it tries to generate a 32bit final library, and bombs.

This may be a key to the mystery, even though a clean way of how to SOLVE
it, is unclear.

Mandatory statement: Libtool is Eeeevil. (and broken)

Re: Info required on SAX implementation of XML Dgital Signature verification

2009-10-14T07:13:43Z

I found the missing files and checked them in. Try updating your workspace (svn
update) and recompiling.

--Sean

Pankaj.Kharbe@... wrote:

> Sean,
> It would be great if you provide me those classes.
>
> Thanking in anticipation.
>
> Regards,
> Pankaj Kharbe
>
> -----Original Message-----
> From: Sean.Mullan@... [mailto:Sean.Mullan@...]
> Sent: Tuesday, October 13, 2009 11:14 PM
> To: security-dev@...
> Subject: Re: Info required on SAX implementation of XML Dgital Signature
> verification
>
> The difference in memory usage should be noticeable in a streaming
> implementation, especially when validating large signatures. Also, the
> amount of memory used should be fairly constant as the size of the data
> increases.
>
> --Sean
>
> Sean Mullan wrote:
>> It seems like the last time I worked on this, I didn't check in those
>> new classes. Let me see if I can find an old workspace and I'll get
> back
>> to you.
>>
>> --Sean
>>
>> Pankaj.Kharbe@... wrote:
>>> Hi all,
>>>
>>> We are trying to use the SAX implementation of the XML Digital
>>> Signature verification. The reason of choosing SAX over DOM is
> because
>>> we are having huge files(10-30MB) whose signature needs to be created
>
>>> and verified( Also it should be multithreaded). And in the DOM
>>> implementation we are not able to meet NFRs in the processing time
> and
>>> the Memory usage. Using the SAX implementation has reduced the
>>> processing time and memory usage also but the difference is not huge.
>
>>> Has anyone got any different implementation or way of using the SAX
>>> parser for the signature validation?
>>>
>>>
>>>
>>> I was also looking at the STAX implementation code
>>> (https://svn.apache.org/repos/asf/xml/security/branches/stax_jsr105/)
>
>>> but I found that the branch code itself is incomplete. There are
>>> couple of missing classes which have been used in it and its giving
>>> compilation error.
>>>
>>> Missing Classes name are -
>>>
>>>> com.r_bg.stax.StaxStructure
>>>> com.r_bg.stax.c14n.StaxCanonicalizationMethod
>>>
>>>
>>> Can anyone point out where I can find these classes or how to
>>> implement these classes?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Pankaj Kharbe
>>>
>>>
>>>
>>> This e-mail and any files transmitted with it are for the sole use of
>
>>> the intended recipient(s) and may contain confidential and privileged
>
>>> information.
>>> If you are not the intended recipient, please contact the sender by
>>> reply e-mail and destroy all copies of the original message.
>>> Any unauthorised review, use, disclosure, dissemination, forwarding,
>>> printing or copying of this email or any action taken in reliance on
>>> this e-mail is strictly
>>> prohibited and may be unlawful.
>>>
>
>
> This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
> If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
> Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly
> prohibited and may be unlawful.

RE: Info required on SAX implementation of XML Dgital Signature verification

2009-10-14T00:07:29Z

Sean,
It would be great if you provide me those classes.

Thanking in anticipation.

Regards,
Pankaj Kharbe

-----Original Message-----
From: Sean.Mullan@... [mailto:Sean.Mullan@...]
Sent: Tuesday, October 13, 2009 11:14 PM
To: security-dev@...
Subject: Re: Info required on SAX implementation of XML Dgital Signature
verification

The difference in memory usage should be noticeable in a streaming
implementation, especially when validating large signatures. Also, the
amount of memory used should be fairly constant as the size of the data
increases.

--Sean

Sean Mullan wrote:
> It seems like the last time I worked on this, I didn't check in those
> new classes. Let me see if I can find an old workspace and I'll get
back
> to you.
>
> --Sean
>
> Pankaj.Kharbe@... wrote:
>> Hi all,
>>
>> We are trying to use the SAX implementation of the XML Digital
>> Signature verification. The reason of choosing SAX over DOM is
because
>> we are having huge files(10-30MB) whose signature needs to be created

>> and verified( Also it should be multithreaded). And in the DOM
>> implementation we are not able to meet NFRs in the processing time
and
>> the Memory usage. Using the SAX implementation has reduced the
>> processing time and memory usage also but the difference is not huge.

>> Has anyone got any different implementation or way of using the SAX
>> parser for the signature validation?
>>
>>
>>
>> I was also looking at the STAX implementation code
>> (https://svn.apache.org/repos/asf/xml/security/branches/stax_jsr105/)

>> but I found that the branch code itself is incomplete. There are
>> couple of missing classes which have been used in it and its giving
>> compilation error.
>>
>> Missing Classes name are -
>>
>>> com.r_bg.stax.StaxStructure
>>
>>> com.r_bg.stax.c14n.StaxCanonicalizationMethod
>>
>>
>>
>> Can anyone point out where I can find these classes or how to
>> implement these classes?
>>
>>
>>
>> Regards,
>>
>> Pankaj Kharbe
>>
>>
>>
>> This e-mail and any files transmitted with it are for the sole use of

>> the intended recipient(s) and may contain confidential and privileged

>> information.
>> If you are not the intended recipient, please contact the sender by
>> reply e-mail and destroy all copies of the original message.
>> Any unauthorised review, use, disclosure, dissemination, forwarding,
>> printing or copying of this email or any action taken in reliance on
>> this e-mail is strictly
>> prohibited and may be unlawful.
>>
>

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly
prohibited and may be unlawful.

Re: Info required on SAX implementation of XML Dgital Signature verification

2009-10-13T10:44:27Z

The difference in memory usage should be noticeable in a streaming
implementation, especially when validating large signatures. Also, the
amount of memory used should be fairly constant as the size of the data
increases.

--Sean

Sean Mullan wrote:

> It seems like the last time I worked on this, I didn't check in those
> new classes. Let me see if I can find an old workspace and I'll get back
> to you.
>
> --Sean
>
> Pankaj.Kharbe@... wrote:
>> Hi all,
>>
>> We are trying to use the SAX implementation of the XML Digital
>> Signature verification. The reason of choosing SAX over DOM is because
>> we are having huge files(10-30MB) whose signature needs to be created
>> and verified( Also it should be multithreaded). And in the DOM
>> implementation we are not able to meet NFRs in the processing time and
>> the Memory usage. Using the SAX implementation has reduced the
>> processing time and memory usage also but the difference is not huge.
>> Has anyone got any different implementation or way of using the SAX
>> parser for the signature validation?
>>
>>
>>
>> I was also looking at the STAX implementation code
>> (https://svn.apache.org/repos/asf/xml/security/branches/stax_jsr105/)
>> but I found that the branch code itself is incomplete. There are
>> couple of missing classes which have been used in it and its giving
>> compilation error.
>>
>> Missing Classes name are –
>>
>>> com.r_bg.stax.StaxStructure
>>
>>> com.r_bg.stax.c14n.StaxCanonicalizationMethod
>>
>>
>>
>> Can anyone point out where I can find these classes or how to
>> implement these classes?
>>
>>
>>
>> Regards,
>>
>> Pankaj Kharbe
>>
>>
>>
>> This e-mail and any files transmitted with it are for the sole use of
>> the intended recipient(s) and may contain confidential and privileged
>> information.
>> If you are not the intended recipient, please contact the sender by
>> reply e-mail and destroy all copies of the original message.
>> Any unauthorised review, use, disclosure, dissemination, forwarding,
>> printing or copying of this email or any action taken in reliance on
>> this e-mail is strictly
>> prohibited and may be unlawful.
>>
>

Re: Info required on SAX implementation of XML Dgital Signature verification

2009-10-13T10:38:01Z

It seems like the last time I worked on this, I didn't check in those
new classes. Let me see if I can find an old workspace and I'll get back
to you.

--Sean

Pankaj.Kharbe@... wrote:

> Hi all,
>
> We are trying to use the SAX implementation of the XML Digital Signature
> verification. The reason of choosing SAX over DOM is because we are
> having huge files(10-30MB) whose signature needs to be created and
> verified( Also it should be multithreaded). And in the DOM
> implementation we are not able to meet NFRs in the processing time and
> the Memory usage. Using the SAX implementation has reduced the
> processing time and memory usage also but the difference is not huge.
> Has anyone got any different implementation or way of using the SAX
> parser for the signature validation?
>
>
>
> I was also looking at the STAX implementation code
> (https://svn.apache.org/repos/asf/xml/security/branches/stax_jsr105/)
> but I found that the branch code itself is incomplete. There are couple
> of missing classes which have been used in it and its giving compilation
> error.
>
> Missing Classes name are –
>
>>com.r_bg.stax.StaxStructure
>
>>com.r_bg.stax.c14n.StaxCanonicalizationMethod
>
>
>
> Can anyone point out where I can find these classes or how to implement
> these classes?
>
>
>
> Regards,
>
> Pankaj Kharbe
>
>
>
> This e-mail and any files transmitted with it are for the sole use of
> the intended recipient(s) and may contain confidential and privileged
> information.
> If you are not the intended recipient, please contact the sender by
> reply e-mail and destroy all copies of the original message.
> Any unauthorised review, use, disclosure, dissemination, forwarding,
> printing or copying of this email or any action taken in reliance on
> this e-mail is strictly
> prohibited and may be unlawful.
>

Re: Apache XML Security compatibility between v1.4.3 and 1.3

2009-10-13T10:34:23Z

Thanks for the follow up.

Regards,
Sasha.

Re: Apache XML Security compatibility between v1.4.3 and 1.3

2009-10-13T06:49:16Z

Sasha wrote:
> I mean if I have a program that is written against Apache XML Security v1.3 will
> it continue to work if I relink it against Apache XML Security v1.4.3?
>

I believe it should, but I can't make any guarantees. We didn't
(intentionally) break compatibility going from 1.3 to 1.4. Let us know
what you find out.

--Sean

Re: Apache XML Security compatibility between v1.4.3 and 1.3

2009-10-12T15:02:42Z

I mean if I have a program that is written against Apache XML Security v1.3 will
it continue to work if I relink it against Apache XML Security v1.4.3?

Thanks,
Sasha.

Re: Apache XML Security compatibility between v1.4.3 and 1.3

2009-10-12T14:52:55Z

Sasha wrote:
> Hi,
>
> I have a quick question. Is Apache XML Security v1.4.3 compatible with 1.3?

Do you mean JDK 1.3? No.

JDK 1.4 and up.

--Sean

>
> Thanks,
> Sasha.
>
> Sasha Matison
> ca
> Manager, Software Engineering
> Sasha.Matison@...
>
>

Apache XML Security compatibility between v1.4.3 and 1.3

2009-10-12T13:55:51Z

Hi,

I have a quick question. Is Apache XML Security v1.4.3 compatible with 1.3?

Thanks,
Sasha.

Sasha Matison
ca
Manager, Software Engineering
Sasha.Matison@...

Info required on SAX implementation of XML Dgital Signature verification

2009-10-12T03:43:19Z

Hi all,

We are trying to use the SAX implementation of the XML Digital Signature verification. The reason of choosing SAX over DOM is because we are having huge files(10-30MB) whose signature needs to be created and verified( Also it should be multithreaded). And in the DOM implementation we are not able to meet NFRs in the processing time and the Memory usage. Using the SAX implementation has reduced the processing time and memory usage also but the difference is not huge. Has anyone got any different implementation or way of using the SAX parser for the signature validation?

I was also looking at the STAX implementation code (https://svn.apache.org/repos/asf/xml/security/branches/stax_jsr105/) but I found that the branch code itself is incomplete. There are couple of missing classes which have been used in it and its giving compilation error.

Missing Classes name are –

>com.r_bg.stax.StaxStructure

>com.r_bg.stax.c14n.StaxCanonicalizationMethod

Can anyone point out where I can find these classes or how to implement these classes?

Regards,

Pankaj Kharbe

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly
prohibited and may be unlawful.

RE: problems with final link for xml-security-c and solaris

2009-10-11T10:16:43Z

Philip Brown wrote on 2009-10-09:
> I just went back and rebuilt xerces2 with plain gcc/g++ -m64
> then rebuilt xml-security-c with same.
> it appears to be happier this way.
> progress i suppose... but i'd much rather have it work with sun CC !

That's particularly true in the case of Shibboleth because I don't support
gcc on Solaris.

-- Scott

Re: problems with final link for xml-security-c and solaris

2009-10-09T16:16:33Z

Scott Cantor wrote:

> Philip Brown wrote on 2009-10-09:
>> I'm trying to compile xml-security-c, in 64bits, in solaris.
>
> I've never done it (the 64-bit case), and since nothing but a Shibboleth
> build would be likely to try this, I doubt that it works.
>
> These particular makefiles have a long history of screwing up on every
> dynamic linking variant that gets introduced, and I imagine this is just
> another case of that. This isn't likely to be a libtool problem, it's
> probably an autotools issue related to the non-automake history of this
> project.
>

Hmm

well, previously, I was using sun cc with stuff like,

CFLAGS="-xO2 -m64 -mt -xnorunpath"
CXXFLAGS="-xO2 -m64 -mt -norunpath"

I just went back and rebuilt xerces2 with plain gcc/g++ -m64

then rebuilt xml-security-c with same.

it appears to be happier this way.

progress i suppose... but i'd much rather have it work with sun CC !

Re: problems with final link for xml-security-c and solaris

2009-10-09T15:59:05Z

Scott Cantor wrote:
>
> I have no idea how to attempt a 64-bit build, but if you provide the
> necessary instructions in a bug report, I'll take a look when I have a
> chance.

that's pretty easy...just replace

CC=x

with

CC="x -m64"

works for both sun cc and gcc

Although you then have to make sure whatever your $prefix is, is pretty much
empty before you start, or you'll end up trying to link against 32bit libs

RE: problems with final link for xml-security-c and solaris

2009-10-09T15:47:59Z

Philip Brown wrote on 2009-10-09:
> I'm trying to compile xml-security-c, in 64bits, in solaris.

I've never done it (the 64-bit case), and since nothing but a Shibboleth
build would be likely to try this, I doubt that it works.

These particular makefiles have a long history of screwing up on every
dynamic linking variant that gets introduced, and I imagine this is just
another case of that. This isn't likely to be a libtool problem, it's
probably an autotools issue related to the non-automake history of this
project.

I have no idea how to attempt a 64-bit build, but if you provide the
necessary instructions in a bug report, I'll take a look when I have a
chance. Needless to say, though, the chance that I would understand how to
fix something on Solaris more than you would is small.

> I thought there was some magic libtool command to use the .la file, and
> force generation of the shared lib, to somehow debug that process.... but
I
> have no idea what that is.

Normally what I do is run the libtool commands to get the actual command
line it's generating and then run the command line myself, but I do that
much more often with compiles than links.

It doesn't really sound like this is the problem, but I guess I'd check to
make sure the bug isn't more with the symlink commands or other shell
behavior after the link completes. That certainly used to come up in the
other projects that didn't have 64-bit support initially and assumed certain
paths.

-- Scott

problems with final link for xml-security-c and solaris

2009-10-09T14:39:00Z

I'm trying to compile xml-security-c, in 64bits, in solaris.

I have had no problems compiling all the myriad dependancies required.
However, when it comes to xml-security-c, I hit a silent failure to link.

Configuration happens with little problem. I have tried version 1.4.0, and 1.5.1
I have tried with, and without, xalan-c.

All with basically the same result.
Things get hidden in libtool obscurity:

/bin/bash ../libtool --mode=link CC -m64 -xO2 -KPIC -mt -norunpath -mt
-D_REENTRANT -DXSEC_LIBRARY_BUILD -xO2 -DNDEBUG -R/var/local/64/lib
-L/var/local/64/lib -o libxml-security-c.la -rpath /var/local/64/lib
-version-info 15:1 XSECC14n20010315.lo XSECXMLNSStack.lo XSECCanon.lo
......
OpenSSLCryptoKeyHMAC.lo -L/var/local/64/lib -lxalan-c -L/var/local/64/lib
-lxerces-c -lsocket -lm -lpthread -lxalanMsg -lcrypto
(cd .libs && rm -f libxml-security-c.so.15 && ln -s
libxml-security-c.so.15.0.1 libxml-security-c.so.15)
(cd .libs && rm -f libxml-security-c.so && ln -s libxml-security-c.so.15.0.1
libxml-security-c.so)
creating libxml-security-c.la
(cd .libs && rm -f libxml-security-c.la && ln -s ../libxml-security-c.la
libxml-security-c.la)
gmake[1]: Leaving directory
`/auto/src/common/local/xml-security-c/xml-security-c-1.5.1-sparc64/lib'
Making all in bin

As you can see, it seems to continue as if all is well.
However, all it has succeeded indoing, is creating a libxml-security-c.la,
without an actual shared library??

(i hate libtool, for just this reason!)

Then it eventually fails, a little later, with

CC -m64 -xO2 -KPIC -norunpath -D_REENTRANT -DXSEC_LIBRARY_BUILD -xO2
-DNDEBUG -o .libs/xtest xtest.o -mt -L/var/local/64/lib
../lib/.libs/libxml-security-c.so -lxalan-c -lxerces-c -lsocket -lm
-lpthread -lxalanMsg -lcrypto
ld: fatal: file ../lib/.libs/libxml-security-c.so: open failed: No such file
or directory
ld: fatal: File processing errors. No output written to .libs/xtest

The failure is not surprising, because "../lib/.libs/libxml-security-c.so"
is now a symlink -> libxml-security-c.so.15.0.1
which does not exist.

Can someone help me out here please?

Solaris 10, CC -V
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25

I've just built everything from scratch today.

I thought there was some magic libtool command to use the .la file, and
force generation of the shared lib, to somehow debug that process.... but I
have no idea what that is.

Re: xml dsig streaming impl.

2009-10-09T06:10:22Z

There's an implementation available, but just be warned it is very much a work
in progress (actually nobody has worked on it for a while) and does not support
all of the XML Signature features. In particular, the following are not
supported: signature generation, inclusive c14n, enveloped signatures, xpath
transform, and backward references (those appearing before the signature). You
can get it from the svn repository:

svn co https://svn.apache.org/repos/asf/xml/security/branches/stax_jsr105

XML Signature 2.0 is currently being worked on and one of the requirements is to
enable it to better support streaming implementations. So we should try to adapt
the STaX implementation as that specification progresses.

Thanks,
Sean

Styrman, Igor wrote:

> Hello,
>
> i run into a document at w3c.org/next steps from 2007 describing Raul
> Benito being involved with STaX-based XML Digital Signature. I'm
> wondering whats the status of this project?
>
> Thanks,
>
> Igor Styrman
>

xml dsig streaming impl.

2009-10-09T04:28:12Z

Hello,

i run into a document at w3c.org/next steps from 2007 describing Raul Benito being involved with STaX-based XML Digital Signature. I'm wondering whats the status of this project?

Thanks,

Igor Styrman

DO NOT REPLY [Bug 47779] ConcurrentModificationException in XMLUtils

2009-10-08T04:31:25Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=47779

coheigea <coheigea@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #4 from coheigea <coheigea@...> 2009-10-08 04:31:22 PDT ---
Fix applied.

Colm.

--- Comment #5 from coheigea <coheigea@...> 2009-10-08 04:31:22 PDT ---
Fix applied.

Colm.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 47779] ConcurrentModificationException in XMLUtils

2009-10-08T04:31:25Z

DO NOT REPLY [Bug 47758] Signature validation failure

2009-10-08T03:06:42Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=47758

coheigea <coheigea@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX

--- Comment #6 from coheigea <coheigea@...> 2009-10-08 03:06:38 PDT ---
Marking this as won't fix as per my comment.

Colm.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 47761] xmlns:xml namespace improperly emitted during excl c14n

2009-10-01T14:11:32Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=47761

sean.mullan@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #1 from sean.mullan@... 2009-10-01 14:11:30 PDT ---
Fixed in main trunk.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45388] We need a POM file added to the Maven repository

2009-09-29T02:18:33Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45388

--- Comment #10 from coheigea <coheigea@...> 2009-09-29 02:18:30 PDT ---
(In reply to comment #9)
> It may be that I'm missing something, but I still don't see this pom out there
> in the central repo. Was this indeed deployed to central, or am I and my build
> infrastructure just not seeing it?

http://repo2.maven.org/maven2/org/apache/santuario/xmlsec/1.4.3/xmlsec-1.4.3.pom

Colm.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45388] We need a POM file added to the Maven repository

2009-09-28T20:04:18Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45388

--- Comment #9 from Stuart James Penrose <stu@...> 2009-09-28 20:04:17 PDT ---
It may be that I'm missing something, but I still don't see this pom out there
in the central repo. Was this indeed deployed to central, or am I and my build
infrastructure just not seeing it?

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45388] We need a POM file added to the Maven repository

2009-09-28T20:01:32Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45388

Stuart James Penrose <stu@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |stu@...

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

RE: Xml-security-c 1.5.x won't compile under Cygwin [SEC=UNCLASSIFIED]

2009-09-24T18:52:03Z

UNCLASSIFIED

G'day Scott,

To get the error message I'm reporting I did the following under a
Cygwin shell:

1. tar -xvzf xml-security-c-1.5.1.tar.gz 2. cd xml-security-c-1.5.1 3.
./configure 4. make

Never got anywhere near an MSVC compile. I don't even have it installed.
The Xerces library should be the one that comes with Cygwin and are
currently xerces-c-3.0.1.

I'll try compiling my own version of xerces-c under Cygwin and see if
this fixes the issue.

Have Fun !!

Shane Hill

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@...]
Sent: Friday, 25 September 2009 11:03 AM
To: security-dev@...
Subject: RE: Xml-security-c 1.5.x won't compile under Cygwin
[SEC=UNCLASSIFIED]

Hill, Shane wrote on 2009-09-24:
> Has anyone had this issue of not being able to compile xml-security-c
> 1.5.0 or 1.5.1 under Cygwin? Something to do with DLL import/export.
> Very nasty ... should not need this under Cygwin. Just treat a Cygwin
> compile just like it were Linux and all should be fine. Except I can't

> seem to get the makefile structure to allow me to do this ... Yet.

Whatever you're doing is not the right thing, you're pulling in Xerces
headers based on MSVC and they're defining the macros properly for
standard Windows builds. The xmlsec macros depend on those directly.

You have to use a configure-based build certainly, all the way down the
stack.

None of which is to say this will work on cygwin no matter what you do,
but that's the reason you're getting errors.

-- Scott

IMPORTANT: This email remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this email in error, you are
requested to contact the sender and delete the email.

RE: Xml-security-c 1.5.x won't compile under Cygwin [SEC=UNCLASSIFIED]

2009-09-24T18:02:45Z

Hill, Shane wrote on 2009-09-24:
> Has anyone had this issue of not being able to compile xml-security-c
> 1.5.0 or 1.5.1 under Cygwin? Something to do with DLL import/export.
> Very nasty ... should not need this under Cygwin. Just treat a Cygwin
> compile just like it were Linux and all should be fine. Except I can't
> seem to get the makefile structure to allow me to do this ... Yet.

Whatever you're doing is not the right thing, you're pulling in Xerces
headers based on MSVC and they're defining the macros properly for standard
Windows builds. The xmlsec macros depend on those directly.

You have to use a configure-based build certainly, all the way down the
stack.

None of which is to say this will work on cygwin no matter what you do, but
that's the reason you're getting errors.

-- Scott