Re: Build issues on RedHat enterprise 4

Thanks a lot Berin! Next question, a bit related to my build problems. I have no clue if this is good suggestion, or if it has some unexpected side effects or so. Have you considered stepping the Xalan version to 1.10.0? As far as I have investigated, 1.10.0 compiles ok on RedHat Enterprise

C++ feature request

Probably too late to be considered for 1.3, but I thought I'd ask anyway... I'm seeing an upcoming problem in that the Encryption/Decryption calls assume that I want to replace the nodes being fed in with the result (in either direction). In my particular library, this will cause some problems be

Re: Build issues on RedHat enterprise 4

[EMAIL PROTECTED] wrote: > My first question: > Is it a correct behaviour to expect the source distro to be present in > XALANCROOT and XERCESCROOT? > Shouldn't it be enough with the installed stuff ( in my case the dir > /work/xalan/1.9.0 > where I have the dirs bin, include, lib.) It is the exp

Build issues on RedHat enterprise 4

Dear XMLSEC developers, I am new here so forgive me if I am wrong here, but I have a few problems First of all I can't build xalan 1.9.0 with gcc 3.4.4. That has been reported as a bug and fixed in r342313 in svn. So this led me to checking out r342313 from svn. I usually build with --p

Re: signed xml does no more contain:

The C14n spec said clearly that c14n documents must not contain XML declaration. extract from http://www.w3.org/TR/2001/REC-xml-c14n-20010315 - 4.1 No XML Declaration The XML declaration, including version number and character encoding is o

DO NOT REPLY [Bug 38444] - Transform TRANSFORM_XPATH2FILTER subtract filter bug in 1.3 release

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

RE: TLP Resolution

Some random ideas to get the name game going, based on your indicated vision for the project: "SecureSoft," "Security Software," "Vault," "Shield," "Armor," "Guard," "Sanctuary," ,"Citadel," "Surety," "Security Blanket" (or "Linus," with a nod to Charles Schulz' "Peanuts," but you'd want to get per

RE: TLP Resolution

I do not have problems with xml security as an Apache TLP. +1. I do note Raul's concerns however. Ax/ -Original Message- From: Berin Lautenbach [mailto:[EMAIL PROTECTED] Sent: 11 March 2006 05:50 AM To: security-dev@xml.apache.org Subject: TLP Resolution Peoples, Sometime back we talk

Re: TLP Resolution

+0 from me. I think is a good idea to have XKMS server or Federation implemenatation, or more security. But on the other hand I don't know if we can cope with the increase of the scope with the lack of resources we have. For example the web pages haven't been change with the new SVN... We don't

Re: Trouble verifying a SOAP message containing encrypted SAML Assertions

Hi Wes, Do you still have this problem? If so please create a bug report with a test case that shows the problem. Thanks, Raul On 11/15/05, W Strater <[EMAIL PROTECTED]> wrote: > I am having trouble verifying a SOAP message > containing encrypted SAML Assertions. My SOAP message > is as follows.

Ignore previous email!!! RE: TLP Resolution

SORRY, complately wrong addressed, IGNORE Plz Wouter -Original Message- From: Wouter Ketting Sent: Wednesday, March 15, 2006 9:32 To: security-dev@xml.apache.org Subject: RE: TLP Resolution -Original Message- From: Berin Lautenbach [mailto:[EMAIL PROTECTED] Sent: Wednesday, M

RE: TLP Resolution

Hi Guys, I finally got a proper stack trace from glowcode Apparently my system path had another version of the native enoatry libs then the ones with which the application was build (that results in wrong stack info during the GlowCode sessions). I don't know whether this leak was caused in

Re: TLP Resolution

Thoughts welcome :>. Berin Lautenbach wrote: > OK - I'm going to take the idea to the board. > > Before I do - we need a couple of things. > > 1. A name. I'd personally be against anything fancy or non-obvious. > But I don't really want to use "Apache Security" as I think it will get > too co