DO NOT REPLY [Bug 44984] if base64 is used after xpath expression it should extract only text nodes

https://issues.apache.org/bugzilla/show_bug.cgi?id=44984 --- Comment #1 from Scott Cantor 2010-05-11 17:25:49 EDT --- Just looking at this, and my suspicion is that the check is in there because the code provided to add the self::text() transform would break or not do the right thing if the input

DO NOT REPLY [Bug 44984] New: if base64 is used after xpath expression it should extract only text nodes

https://issues.apache.org/bugzilla/show_bug.cgi?id=44984 Summary: if base64 is used after xpath expression it should extract only text nodes Product: Security Version: cvs Platform: PC OS/Version: Windows XP Status

Xmlsec question: when is base64 done

Team, I had a question about how xmlsec (the standard) processes elements that are base64 encoded. Will these two structures be hashed to the same value? Will the encoding attribute be added to the hash? Will both "6dnN..." payloads be base64 decoded before being processed? Thanks

DO NOT REPLY [Bug 35919] - Base64 transform closed stream

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35919] - Base64 transform closed stream

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33393] - Base64 Transform throws "Stream is closed" IOExceptions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 5946] - StringIndexOutOfBoundsException in Base64.decode(String)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug

Re: base64 elements linebreak

.org/TR/xmlschema-2/#base64Binary_ - or they have new lines within 76 chars, per RFC2045. Unfortunately bitter experience says that you have to support people who do wierd things outside the 76 chars. I also don't want to pre-scan base64 data, which could be megabytes. So I try to avoid

RE: base64 elements linebreak

> So, for example, if the original base64 encoded data > comes through SMTP, we will have to decode and encode > it again if we have to put the same value in an XML? No, precisely the opposite. Anything you get that's legal base64, whatever the line length, is "legal" XM

RE: base64 elements linebreak

--- Scott Cantor <[EMAIL PROTECTED]> wrote: > > There is no spec in XML-land that says base64 > content uses any particular > line length. > So, for example, if the original base64 encoded data comes through SMTP, we will have to decode and encode it again if we have to

RE: base64 elements linebreak

> I am not sure if you are implying that normalization removes > line breaks. Yep. Schema normalization does exactly that. > AFAIK, normalization just 'joins' adjacent text > nodes - not dealing with new lines in any way. (I am > referring to the doc.normalize() call. Please let me know if >

RE: base64 elements linebreak

> Yes, that is true. This flag does not work if there are NL > chars in the message (anywhere). Thus, you will have to scan > the message to find out if there are NL chars - but the input > has to follow some spec - There is no spec in XML-land that says base64 content uses any par

RE: base64 elements linebreak

ott Cantor <[EMAIL PROTECTED]> wrote: > It also means you have to pre-scan the base64 text to work out what you > are going to do - which is just plain ugly.Yeah. The bottom line is that anything that can't consume something with orwithout breaks is non-compliant, so clearly OpenS

Re: base64 elements linebreak

ere it puts the line break, you are out of luck.It also means you have to pre-scan the base64 text t o work out what you are going to do - which is just plain ugly.Cheers,Berin Do you Yahoo!? With a free 1 GB, there's more in store with Yahoo! Mail.

RE: base64 elements linebreak

> It also means you have to pre-scan the base64 text to work out what you > are going to do - which is just plain ugly. Yeah. The bottom line is that anything that can't consume something with or without breaks is non-compliant, so clearly OpenSSL is borderline because the flag is not

Re: base64 elements linebreak

have something that is non-spec with where it puts the line break, you are out of luck. It also means you have to pre-scan the base64 text to work out what you are going to do - which is just plain ugly. Cheers, Berin

RE: base64 elements linebreak

> BTW, OpenSSL has a flag for such cases - > BIO_FLAGS_BASE64_NO_NL. Setting this flag would allow data > with no line breaks to be decoded. How new is the flag? I ask because it seemed to be a problem in so many places for quite a while. -- Scott

RE: base64 elements linebreak

BTW, OpenSSL has a flag for such cases - BIO_FLAGS_BASE64_NO_NL. Setting this flag would allow data with no line breaks to be decoded.   -ramsScott Cantor <[EMAIL PROTECTED]> wrote: > While wrapping at 76 appears to do neither good nor> harm in the XML world, I still "feel" this is "ugly".> > La

RE: base64 elements linebreak

> While wrapping at 76 appears to do neither good nor > harm in the XML world, I still "feel" this is "ugly". > > Large autogenerated XML docs usually contain no > linebreaks and appear on one line. > Except when you sign them with Apache xmlsec, now > they get a few extra linebreaks... > > I per

base64 elements linebreak

Hello... While doing interoperability experiments with XML documents containing digital signatures created with the Apache xmlsec project libraries (=the libraries contained in the Java WSDP package), I noticed a difference to other providers output. Base64 coded components, e.g. the Modulus of

DO NOT REPLY [Bug 35919] - Base64 transform closed stream

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35919] New: - Base64 transform closed stream

gzilla/show_bug.cgi?id=35919 Summary: Base64 transform closed stream Product: Security Version: Java 1.2.1 Platform: Other OS/Version: other Status: NEW Severity: critical Priority: P2 Component: Sig

Signing Base64-encoded data and SignatureProperties

Hi all!! I am trying to sign (detached) some base64-encoded data along with a SignatureProperty (SigningTime). If I base64-decode the data before signing and specify C14N transform for the SignatureProperty, everything is OK; however, if I do not base64-decode the data but I include Base64

Re: base64 transform

gt; > >On Tue, 22 Mar 2005 09:17:31 -0700, Lyudmila Balakireva <[EMAIL PROTECTED]> > > >wrote: > > > > Hello, > > > > I have problem "java.io.IOException.Stream closed" with Base64 > > > > transform ( > > > > I downl

Re: base64 transform

use me, which version of xml-sec are you using? > >Is the 1.2.1? > > > >Regards, > > > > > >On Tue, 22 Mar 2005 09:17:31 -0700, Lyudmila Balakireva <[EMAIL PROTECTED]> > >wrote: > > > Hello, > > > I have problem "java.io.IOExcept

Re: base64 transform

Yes, Thank you At 05:18 PM 3/22/2005 +0100, you wrote: excuse me, which version of xml-sec are you using? Is the 1.2.1? Regards, On Tue, 22 Mar 2005 09:17:31 -0700, Lyudmila Balakireva <[EMAIL PROTECTED]> wrote: > Hello, > I have problem "java.io.IOException.Stream closed"

Re: base64 transform

excuse me, which version of xml-sec are you using? Is the 1.2.1? Regards, On Tue, 22 Mar 2005 09:17:31 -0700, Lyudmila Balakireva <[EMAIL PROTECTED]> wrote: > Hello, > I have problem "java.io.IOException.Stream closed" with Base64 transform ( > I downloaded lates

base64 transform

Hello, I have problem "java.io.IOException.Stream closed" with Base64 transform ( I downloaded latest code) . The Base64 Transform is second after Xpath Transform. Please, help Luda The code snipet: Transforms transforms = new Transforms(doc); XPathContainer x

RE: XML-Security-C with OpenSSL overly strict about base64 line lengths

> Sent: Saturday, March 19, 2005 9:28 PM > To: security-dev@xml.apache.org > Subject: Re: XML-Security-C with OpenSSL overly strict about > base64 line lengths > > Jesse Pelton wrote: > > > OpenSSLCryptoKeyRSA::verifySHA1PKCS1Base64Signature() uses OpenSSL's > &g

Re: XML-Security-C with OpenSSL overly strict about base64 line lengths

Jesse Pelton wrote: OpenSSLCryptoKeyRSA::verifySHA1PKCS1Base64Signature() uses OpenSSL's EVP_Decode...() routines to decode the base64 contents of SignatureValue. This fails if line breaks don't occur where OpenSSL thinks they should. I think this is contrary to the specification (see

XML-Security-C with OpenSSL overly strict about base64 line lengths

OpenSSLCryptoKeyRSA::verifySHA1PKCS1Base64Signature() uses OpenSSL's EVP_Decode...() routines to decode the base64 contents of SignatureValue. This fails if line breaks don't occur where OpenSSL thinks they should. I think this is contrary to the specification (see rationale below)

RE: Base64 question + Preparing for a 1.2 C++ release

> Scott - you are the person with the most experience in schema validation > and signatures. Is it worthwhile adding some form of switch to tell the > library to output base64 data in normalised form? (I.e. no line feeds > etc.) That way normalisation won't touch th

Base64 question + Preparing for a 1.2 C++ release

Now builds against OpenSSL 0.9.8 as well as 0.9.7 and 0.9.6, and supports SHA 224/256/384/512 if they are supported by the version of OpenSSL. Before we do a 1.2 however, I'm wondering if we can do something about the base64 and validation problems. Scott - you are the person with the mos

DO NOT REPLY [Bug 33393] - Base64 Transform throws "Stream is closed" IOExceptions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33393] - Base64 Transform throws "Stream is closed" IOExceptions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33393] - Base64 Transform throws "Stream is closed" IOExceptions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33393] New: - Base64 Transform throws "Stream is closed" IOExceptions

gzilla/show_bug.cgi?id=33393 Summary: Base64 Transform throws "Stream is closed" IOExceptions Product: Security Version: cvs Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Comp

RE: how we can encode SHA-1 hash to Base64

Hi Berin,Dims,All Now encoding is working, Thanks for help :). Now problem is I try to decode the base64 encoded data. But my program generates runtime error :((.I am using apache xml parser libs to do that. I kindly request to every one please help me to solve this issue. Regards G J Asanka

Re: how we can encode SHA-1 hash to Base64

Asanka, I assume you want to do the encode using OpenSSL? There is some stuff in the OpenSSL interface for Base64 in xsec that might provide some pointers. http://cvs.apache.org/viewcvs.cgi/xml-security/c/src/enc/OpenSSL/OpenSSLCryptoBase64.cpp?rev=1.7&view=markup If you want to do it using

Re: how we can encode SHA-1 hash to Base64

Check xerces-c source code (http://xml.apache.org/xerces-c/apiDocs/Base64_8hpp-source.html) -- dims - Original Message - From: Asanka Priyanjitih <[EMAIL PROTECTED]> Date: Thu, 8 Jul 2004 09:58:06 +0600 Subject: how we can encode SHA-1 hash to Base64 To: [EMAIL PRO

how we can encode SHA-1 hash to Base64

Hi Team     I wrote a piece of code to generate a password digest. But this is not complete one. After generating SHA-1 hash, we have to encode SHA-1 hash to Base64.If some one knows how can we do that using that libraries or some other suitable method please tell me?   This is that

RE: Java xmlsec still contains base64 bug

> For now I've fixed the bug in CVS - probably best to not introduce > anything majorly new until after 1.1. Thanks much. I'm hoping to be able to ship the next Shibboleth/OpenSAML releases with the 1.1 versions of both languages, this will give me additional incentive. ;-) -- Scott

Re: Java xmlsec still contains base64 bug

Scott/Erwin, For now I've fixed the bug in CVS - probably best to not introduce anything majorly new until after 1.1. Cheers, Berin Erwin van der Koogh wrote: With the talk of a release, I'd note that the Java Base64 encoder in the utility class is still adding an extra lin

Re: Java xmlsec still contains base64 bug

+1 (non-binding) :) --- Axl Mattheus <[EMAIL PROTECTED]> wrote: > Erwin van der Koogh wrote: > > >> With the talk of a release, I'd note that the Java Base64 encoder in the > >> utility class is still adding an extra linefeed when the encoded data >

Re: Java xmlsec still contains base64 bug

Erwin van der Koogh wrote: With the talk of a release, I'd note that the Java Base64 encoder in the utility class is still adding an extra linefeed when the encoded data ends up exactly on a line wrap boundary (e.g. last line of 72 chars if wrap length is 72). This is treated as invalid b

Re: Java xmlsec still contains base64 bug

With the talk of a release, I'd note that the Java Base64 encoder in the utility class is still adding an extra linefeed when the encoded data ends up exactly on a line wrap boundary (e.g. last line of 72 chars if wrap length is 72). This is treated as invalid by the Xerces C++ base64 data

Java xmlsec still contains base64 bug

With the talk of a release, I'd note that the Java Base64 encoder in the utility class is still adding an extra linefeed when the encoded data ends up exactly on a line wrap boundary (e.g. last line of 72 chars if wrap length is 72). This is treated as invalid by the Xerces C++ base64 data

Re: Base64

Which smells to be like a bug in the code. If we are dropping bytes without either a) throwing an exception; or b) storing them in a buffer to be retrieved on the next call to ::encode() then I think something is wrong. I will have a look at this. Thanks! Cheers, Berin Milan Tomic wro

RE: Base64

I've found solution. This: int outLen = 10 * 1024 * 4/3 + 4; should be: int outLen = 10 * 1024 * 2; there was no enough space in output baffer. Thank you, Milan

Re: Base64

n the output buffer for the final piece of output. However that shoulnd't leave you with such a large amount missing. How big is the file, and when you say you are missing 1K, are you sure it is at the end (just to rule out the base64 encoder dropping bytes at the end of buffers during each roun

Base64

Title: Base64     Is this OK: CString cEncodedFile; XSCryptCryptoBase64 b64; b64.encodeInit(); CFile f; f.Open(cXMLFile.GetBuffer(999), CFile::modeRead); int outLen = 10 * 1024 * 4/3 + 4; BYTE *input = new BYTE[10 * 1024]; BYTE *output = new BYTE[outLen]; int inputSz = f.Read

Re: Base64 Transformation

Way cool! One I don't have to worry about :>. Cheers, Berin (Although if it doesn't work without Xalan, maybe I do) Milan Tomic wrote: Berin, Could you provide your exact configuration? I have run this against current CVS and V1.0.0 and it works fine. That's on Windows NT, Xerces 2.

RE: Base64 Transformation

Berin, > Could you provide your exact configuration? I have run this against > current CVS and V1.0.0 and it works fine. > > That's on Windows NT, Xerces 2.3, Xalan 1.6. > > Are you running Xalan? No, I wasn't running Xalan, but I was beliving I did. Thank you. Now, it works perfect.

Re: Base64 Transformation

with a single reference and a base64 txfm - to xtest and it works fine. Can you send us the full code that you are using to create the sig? I'm sending to you in the attachment one file. It doesn't work with templatesign.exe 1.0.0. (if you try to sign it). The same error message

RE: Base64 Transformation

Erwin, > I am no C++ library expert, but if Base64 is thought to be > the problem, > could it have anything to do with one line being twice the > length of the > others. The Base64 encoding is trimmed at 76 characters, as > specified in > the spec (as optional), but one

Re: Base64 Transformation

Just added something very simple - just create a sig with a single reference and a base64 txfm - to xtest and it works fine. Can you send us the full code that you are using to create the sig? I'm sending to you in the attachment one file. It doesn't work with templatesign.exe 1.0.0. (

Re: Base64 Transformation

Berin, > Just added something very simple - just create a sig with a single > reference and a base64 txfm - to xtest and it works fine. Can you send > us the full code that you are using to create the sig? I'm sending to you in the attachment one file. It doesn't work wi

Re: Base64 Transformation

Milan, Just added something very simple - just create a sig with a single reference and a base64 txfm - to xtest and it works fine. Can you send us the full code that you are using to create the sig? Cheers, Berin Milan Tomic wrote: When signing with enveloping signature I add

Re: Base64 Transformation

lan Tomic wrote: When signing with enveloping signature I add Base64 transformation like this: DSIGReference *ref = sig->createReference(MAKE_UNICODE_STRING("#data")); //Object tag ref->appendBase64Transform(); And allways got "Error mapping context node" error here:

Base64 Transformation

Title: Base64 Transformation     When signing with enveloping signature I add Base64 transformation like this: DSIGReference *ref = sig->createReference(MAKE_UNICODE_STRING("#data")); //Object tag ref->appendBase64Transform();     And allways got "Error mapping con