Re: Public discussion on future of C++ library

> So far we have 2 official votes to retire and migrate the C++ library. > Pending objections, > I will add something to the wiki about the decision later this week. Didn't get to it last week, but am working on edits today, so this should be publicly visible shortly. -- Scott

Re: Public discussion on future of C++ library

So far we have 2 official votes to retire and migrate the C++ library. Pending objections, I will add something to the wiki about the decision later this week. We have a lot going on on my side so I don't know at what point we'll be able to spend time on the svn to git conversion to get the

Re: Public discussion on future of C++ library

> IMO yes we should have a vote to retire the project at ASF, obviously > it's just a formality at this stage. Ok. Obviously this is my +1. -- Scott

Re: Public discussion on future of C++ library

> I can begin the import/migration process if you don't feel the need for a > formal vote to approve this step. Even with that, we'll be working on converting the svn history to git, and that might take a little while, so I've just put the wheels in motion. -- Scott

Re: Public discussion on future of C++ library

> I would just need to check with ASF if there are any legalities > involved with not changing the package names or copyright etc. Our copyright header is much the same as Apache's so I have no strong desire to change it but it does specifically mention the ASF licensing the code so it could be

Re: Public discussion on future of C++ library

So, I've given this another week and considered the limited feedback, and at this point I think I'm prepared to propose to the PMC that we treat this as the code migrating from Apache Santuario to the Shibboleth Project as an official hand off of responsibility. That comes with the

Re: Public discussion on future of C++ library

Notably, we have semi-automated builds of RPMs for a variety of variants that have never required any special workarounds, and build now with Docker. Those files are here (obviously much more than just this code, but it includes the Xerces dependency):

Re: Public discussion on future of C++ library

> Has anyone already migrated to RHEL9 and confirmed that Santuario 2.0.4 > builds and runs on that platform? Yes, for as long as it's existed, early betas and such. > I do not have a good enough understanding of SSL There's no SSL code in this library at all, it's an XML document

Re: Public discussion on future of C++ library

> As you are the sole maintainer, IMO it's your decision to make. > Personally I'd be fine with Option (2), but are you willing to > maintain the code, review any rare patches submitted, release > sporadically etc.? Otherwise I think it's time to archive the project. I'm willing for a few years

Re: Public discussion on future of C++ library

On 2/21/24, 4:07 PM, "Berin Lautenbach" mailto:be...@wingsofhermes.org>> wrote: Thanks for weighing in, obviously I think you get some say on this. > and there are extra overheads on you if you have to do a level of > management of the code within the ASF. There are, and I don't dispute it, if

Public discussion on future of C++ library

I didn't get any feedback on this amongst the PMC, but after discussing things with my project team, I'm going to float what is essentially my proposal for the future of the Santuario C++ branch. As the sole maintainer left, you can think of this as an ultimatum I guess, but it's not really

Re: [VOTE] - Release Apache Santuario - XML Security for Java 4.0.2/3.0.4

+1 from me. -- Scott

Re: Apache Santuario config states that libcrypto is not found

> Was it determined that the users of Santuario shouldn't need this or is > there something in how the build is configured that could cause this? It was explicitly removed from the public API because a few people were using it when they should not have. 2.0 did not have to be compatible (at all)

Re: Apache Santuario config states that libcrypto is not found

> When we built Santuario v1.7.3, we never had to update > LD_LIBRARY_PATH to make the build work. Then the circumstances were different, but I can assure that's not new, I've had to use it in plenty of cases for a very long time. The only possible way of avoiding it is installing to known

Re: Apache Santuario config states that libcrypto is not found

I cannot spend enough time to really review your build, but the most obvious thing was that it can't find Xerces during the Xalan link tests, and that should obviously be down to LD_LIBRARY_PATH issues. You can't install shared libraries to unusual locations and expect a build will work if

Re: Apache Santuario config states that libcrypto is not found

> Does anyone have a copy of an old config.log output to share that would > show me what the output looks like after a successful configure? One of mine from a Mac is attached. All of that environment stuff is long dead, none of that is required for this build, and some of it might even break

Re: [VOTE] - Release Apache Santuario - XML Security for Java 4.0.1

+1 from me. -- Scott

Re: Trouble with configuring the build for Santuario 2.0.4

> Am I misunderstanding something about the changes to the configure > script? Nope. All the environment variable nonsense was just broken, and the script was modernized to rely on pkgconfig for locating everything. All of the dependencies should have pkgconfig support, but there are plenty of

Re: Apache Santuario config states that libcrypto is not found

> I'm confused by the purpose of specifying the location of the openssl that I > have built if the dependency mechanism is searching for libcrypt > somewhere else. Because it found a pkgconfig from OpenSSL somewhere else and it told it something you don't want to use. That's the point of the

Re: Apache Santuario config states that libcrypto is not found

I can't debug your build, you need to use config.log for that, but the main dependency mechanism in the autoconf script is pkgconfig, not via explicit locations. You need to ensure your PKG_CONFIG_PATH is set if you're using non-standard locations, it figures out the rest from the pkgconfig

Re: Apache Santuario and OpenSSL native library use on RHEL8

> I appreciate the info. That sounds promising. This is maintained in SVN > rather than git isn't it? It has not been migrated to git, that is correct. I do not have the cycles to do that. > My question was not phrased correctly. I did not mean to ask if *you* > support RHEL7, but rather

Re: Apache Santuario and OpenSSL native library use on RHEL8

> I appreciate that information. Do you still support RHEL7? Well, in some sense *I* only support Shibboleth period and I'm the sole maintainer left for this, so...I wouldn't be using it unless you're prepared to join the project. That's just reality now. Xerces is all but dead and if that

Re: Apache Santuario and OpenSSL native library use on RHEL8

> Thus far, I have not been able to find any release notes or documentation > that suggests a combination of SW versions that will work successfully on > the RHEL8 operating system. If anyone has any information to share on the > topic I’d appreciate it. If you're talking about C++, 1.7 is long

Re: [VOTE] - Release Apache Santuario - XML Security for Java 4.0.0

+1 from me. -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 3.0.3, 2.3.4 and 2.2.6

+1 from me. -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 4.0.0-M1

> This is a vote to release Apache Santuario - XML Security for Java > 4.0.0-M1. It is a milestone release and not meant for production. +1 -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.2.5

+1 from me -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.2.5

> Issues fixed: This was empty: could you update Jira to capture what's been changed? All I saw in git seemed to be updating BC (which I'm aware had some CVEs, so that might be what you meant). -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 3.0.2 and 2.3.3

+1 from me. -- Scott

Re: C++ release

Ah, my mistake, I did get this released already, but the Jira version was never updated. Thought I had forgotten. Oh well, on to Xerces... -- Scott On 10/5/22, 9:21 AM, "Cantor, Scott" wrote: Just a heads up that I am planning to get a small patch release done asap beca

C++ release

Just a heads up that I am planning to get a small patch release done asap because I have a bit of a window to get it done. The fix list is small apart from another attempt to get DSA working, though it's largely unused at this point. I'll get a RC posted and call for a vote, hopefully starting

Re: [VOTE] - Release Apache Santuario - XML Security for Java 3.0.1 and 2.3.2

+1 from me. -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.1.8

>This is a vote to release Apache Santuario - XML Security for Java >2.1.8. This is the last planned release on this branch. +1 -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.2.4

>This is a vote to release Apache Sanutario - XML Security for Java 2.2.4. +1 -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.3.1

On 4/28/22, 4:18 AM, "Colm O hEigeartaigh" wrote: >This is a vote to release Apache Santuario - XML Security for Java 2.3.1. +1 -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 3.0.0

>This is a vote to release Apache Santuario - XML Security for Java >3.0.0. This is a new major release which has switched to use the >Jakarta namespace. +1 -- Scott

Re: Support for 2.1 branch / EOL?

On 3/7/22, 3:02 AM, "Colm O hEigeartaigh" wrote: >We're going to release 2.4.0 pretty soon, so ideally we would end it >then. I recall though you asked for support until June or so, in which >case we can extend it until then? We're working towards shipping a new minor version by

Support for 2.1 branch / EOL?

Was there a final decision made about support ending this year for the 2.1 branch of the Java lib? -- Scott

Re: SANTUARIO-513 bug status

On 1/19/22, 10:39 AM, "BEEK Graham" wrote: >This bug was raised 2 and a bit years ago and would seem quite important > at first glance, but there has been > no activity. Would someone be able to confirm whether it is as important as > it sounds and whether a patch is > available or even

Re: [xml-security-c] Patch to use newer version of OpenSSL APIs for RSA OAEP

There are no more releases of this code planned, but if you want the patch filed or if another committer emerges to do the work, please file it in Jira. For the record, I would not disallow the use of the code on any OpenSSL version without a good reason, it's just needless breakage.

Re: A jakarta namespace version

On 12/2/21, 8:14 AM, "Colm O hEigeartaigh" wrote: >If there is demand then I don't mind keeping 2.1.x for a while longer. I doubt there's demand from anyone but me, but we don't generally break API compatibility outside of a major version, which isn't imminent for us until Spring 6 is out

Re: A jakarta namespace version

On 12/2/21, 5:16 AM, "Colm O hEigeartaigh" wrote: >The main reason is that we have just released a new major version of >Santuario (2.3.0). However, I think we could get 2.4.0 out in >January/Feb next year with the changes and drop 2.1.x, does it work >for you? Dropping 2.1 with

Re: Santuario web site

On 11/12/21, 4:32 AM, "Colm O hEigeartaigh" wrote: >The website updates seem to be working again. Were you able to get that Atlassian API trick to run via maven to rebuild the site? That just died on me out of the gate. -- Scott

Re: Santuario web site

On 11/5/21, 11:34 AM, "Colm O hEigeartaigh" wrote: >Yes it appears that Infra have frozen publishing from SVN, so I will >have to research a different way of doing it from Git (I know Apache >Directory made this change, so I hope it won't be too complicated). I noticed content as of

Santuario web site

I've never managed to get the site to publish in recent memory, so if somebody knows how to do that, I made the changes to the wiki. -- Scott 

Re: Proposed release of xml-security-c 2.0.4 - Call for Vote

With 4 binding +1 votes, this passes. I will finalize the release today if possible. -- Scott

Proposed release of xml-security-c 2.0.4 - Call for Vote

I have posted a release candidate for 2.0.4 [1] to correct a regression on OpenSSL 1.0.0 and older from the DSA bug fix included in the release last week. The only change apart from the versioning bits is [2], inlining a small function introduced in OpenSSL 1.1. This is my +1. -- Scott [1]

Re: How about new xml-security-c bugreports?

As you'll have seen, I do have to spin another release next week so if you want something reviewed, now's the time. But as I noted, the chances I'd patch anything aroung RSA signatures is about nil without a really serious bug unless it was just fixing a crash with a controlled error path. --

Re: Sigh, new version needed

The fix is done, I'll give downstream the weekend to likely confirm they don't plan to work on a downlevel fix, and then I'll release it as fixed for OpenSSL 1.1+ If there are any other fixable issues filed I'll of course review before a release next week. -- Scott

Sigh, new version needed

Of course one of the patches I applied from Debian was not properly tested on older OpenSSL versions, so I'm going to have to do another release next week. -- Scott 

Re: How about new xml-security-c bugreports?

>Is it worth the effort to report that kind of issues and work on better > quality patches? That's not a simple yes/no answer. Generally speaking, I'm only going to do releases when the Shibboleth Project has a need for them. There is no other reason I can spend time on this code. That

Re: RC2 of xml-security-c 2.0.3 posted, call for vote

With several +1 votes and no objections, the vote has passed, and I will complete the release of the RC2 artifact as the final version. -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.3.0

+1 -- Scott On 10/25/21, 6:53 AM, "Colm O hEigeartaigh" wrote: This is a vote to release Apache Santuario - XML Security for Java 2.3.0. This is a major new release of the library

Re: RC1 of xml-security-c 2.0.3 posted, call for vote

On 10/19/21, 8:40 AM, "Cantor, Scott" wrote: I have posted [1] a signed RC1 of V2.0.3 of the C++ library and would like to release it. >The list of issues addressed is at [2] and is confined to some build > issues save for a one line const fix to > support Ope

RC1 of xml-security-c 2.0.3 posted, call for vote

I have posted [1] a signed RC1 of V2.0.3 of the C++ library and would like to release it. The list of issues addressed is at [2] and is confined to some build issues save for a one line const fix to support OpenSSL 3.0. I've done several builds in various ways and have tested the code in my

C++ lib update coming

Now that OpenSSL 3.0 is out, a very small patch for that is queued up so I'll be getting a 2.0.3 release done with that fix along with any other minor backlog. -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.2.3

+1 -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.1.7

+1, assuming those Jenkins failures don't mean anything to do with this release? -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.2.2

+1 -- Scott On 4/30/21, 5:19 AM, "Colm O hEigeartaigh" wrote: This is a vote to release Apache Santuario - XML Security for Java 2.2.2.

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.2.1/2.1.6

On 12/8/20, 7:41 AM, "Colm O hEigeartaigh" wrote: >This is a vote to release Apache Santuario - XML Security for Java > 2.2.1/2.1.6. +1 -- Scott

Re: Tarballs linked on download.html different from linked checksums

On 9/10/20, 4:22 PM, "Kurt Mosiejczuk" wrote: >I was looking at porting xml-security-c to OpenBSD today, and noticed that >the tarballs linked no download.html are different than the tarballs at > https://downloads.apache.org/santuario/c-library I just checked one by hand, the bz2, and

RE: [VOTE] - Release Apache Santuario - XML Security for Java 2.1.5

> This is a vote to release Apache Santuario - XML Security for Java 2.1.5. +1 -- Scott

RE: Java + canonicalization: unused namespaces prevail

> I'd like to ask whether it's possible to have a Canonicalizer remove unused > namespace declarations from input XML files That's what Exclusive C14N does, modulo the fact that it's practically impossible to actually know when namespaces are in fact used in many common protocols (your example

RE: Created SANTUARIO-523 + pull request on GitHub - did I contribute correctly?

> The information on that page seems a bit outdated - it refers to svn and this > mailing list, but I also found a GitHub project: That isn't official yet, it's just a mirror. > Is it enough if I create bugs and pull requests on GitHub, and discuss > everything > in there, or should I still use

Re: Moving to GIT

On 1/14/20, 4:40 AM, "Colm O hEigeartaigh" wrote: > @Scott Cantor would you like to also move > xml-security-cpp to git, or do you just want > to leave it in svn? Moving it is fine as long as it's the Apache gitbox service and not github exclusively. -- Scott

Re: CRLF change in Java 8 patch

On 10/17/19, 2:46 PM, "Sean Mullan" wrote: [snip] That answers my question, thank you. -- Scott

Re: CRLF change in Java 8 patch

On 10/17/19, 10:22 AM, "Colm O hEigeartaigh" wrote: > Are you referring to the fix that was made for 2.1.2? > As in, the latest Oracle patch, does not have this fix above? I was referring to the original CR change from back before the property was even added. I don't know if Java's copy

CRLF change in Java 8 patch

Sean, mostly: Were folks expecting to see Java 8 mid-stream pick up that Base64 change in Santuario that adds the CR character to the wrapped base64 blobs? It showed up in the latest Oracle patch, but has *not* appeared in the other OpenJDK 8 patch releases we have under test. That is not an

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.1.4

On 7/16/19, 12:56 PM, "Colm O hEigeartaigh" wrote: > Yes I was thinking along those lines for 2.3.0. Patches definitely welcome! Cool, will consider then, thanks! -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.1.4

On 7/16/19, 11:59 AM, "Colm O hEigeartaigh" wrote: > This is a vote to release Apache Santuario - XML Security for Java 2.1.4. +1 Regarding the changes, is a decent summary of the places where there would be any use of the DocumentBuilder and any XML parsing by the library itself: -

Re: Canonicalization support

On 6/7/19, 3:04 PM, "João M. S. Silva" wrote: > One more related question: how can Santuario deal with the fact that base64 > text nodes are parsed by Xerces with > whitespace being modified (normalized?) It can't, you can't normalize. > I can't see an option in Xerces to keep whitespace in

Re: Canonicalization support

On 5/24/19, 12:14 PM, "João M. S. Silva" wrote: > Is this mapped somewhere? It's literally defined in the XML Signature and Encryption specifications. The URIs are what those documents say they are. -- Scott

Re: Canonicalization support

On 5/24/19, 3:13 AM, "Colm O hEigeartaigh" wrote: > It does support Canonical XML 1.1. However, it uses the older namespace of > http://www.w3.org/2006/12/xml-c14n11 that is defined in the XML Signature > spec: > > https://www.w3.org/TR/xmldsig-core1/#sec-c14nAlg Well, it's not a namespace,

Re: How to install DOM utils

On 4/10/19, 1:29 PM, "João M. S. Silva" wrote: > But in the cheksig.cpp example under tools there is: That's a path relative to the source tree during the build, not the installed files. -- Scott

Re: How to install DOM utils

On 4/9/19, 9:04 PM, "João M. S. Silva" wrote: > how to build Santuario (xml-security-c) with support for DOM? I built routinely on many platforms, so the sources now work fine. -- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.1.3

On 3/26/19, 9:00 AM, "Colm O hEigeartaigh" wrote: > This is a vote to release Apache Santuario - XML Security for Java 2.1.3. +1 -- Scott

Re: xml-security-c 2.0.2 (call for vote)

With three +1 votes and no objections, I'll call this approved. I'll release that build later today or tonight. Thanks, -- Scott

xml-security-c 2.0.2 (call for vote)

I have a couple of small patches to release to address another bug [1] and I've had a colleague beating on the code to try and find any other similar problems and we haven't found anything else to this point, so I'd like to get this patch set released as V2.0.2. I've uploaded a signed artifact

XML-Security-C 2.0.1 released

A patch release for XML-Security-C, 2.0.1, is now available to correct a bug [1] that can cause crashes in upstream applications, so users of the library should review their use of the code for the impact it may have and make sure to update. I have no plans at present to backport the fix to

RE: Call for vote on xml-security-c 2.0.1

Having three +1 votes and no objections, I'll call this approved and will complete the release this evening. Time permitting I will do a more thorough walk over the related code paths and see if anything else similar pops up worth fixing. Thanks, -- Scott

Call for vote on xml-security-c 2.0.1

A patch for a reported bug [1] has been prepared and I've uploaded RC2 source artifacts [2] for approval based on svn revision 1837241. Only a couple of source files are impacted, adding some null checks. I found an additional area of the code to address while testing, necessitating the RC2

Re: linking error when building xml-security-c with xalan support

On 7/20/18, 6:36 AM, "Guillaume Rousse" wrote: > I'm not a C++ expert, but if the linker tries to resolve symbols in > xalan library using xerces 3.2 namespace, does it means than the actual > dependency is not just "xalan >= 1.11", but "xalan >= 1.11, build > against xerces >= 3.2" ? Yes,

Re: Call for vote (#2): xml-security-c-2.0.0

The release is mostly done, I updated the wiki pages as best I could to get more accurate information there, don't have a lot of time to devote to it unfortunately. It hasn't successfully published to the web yet but I'll keep an eye on it. -- Scott

Re: Call for vote (#2): xml-security-c-2.0.0

With three +1 votes and no nays, I consider this approved and will complete the release tomorrow using the RC4 artifact. Thanks, -- Scott On 6/22/18, 3:45 PM, "Cantor, Scott" wrote: I'd like to ask for a vote to release RC4, posted at [1], as the final release of V2.0.0 of the C++

RE: Call for vote (#2): xml-security-c-2.0.0

> Builds fine (Gentoo, gcc-7.3.0, autoconf-2.69, automake-1.15.1), code looks > ok so far I can see/follow, so > > +1 > > from me. Thanks. I'll give it until end of day in case anybody else wants to check it or find a problem and then call it. -- Scott

Re: Vote rescinded (was Re: Call for vote: xml-security-c-2.0.0)

Actually, the "bug" in this case is I believe a failure to detect and enable OpenSSL. The code's not really meant to be built with *no* crypto option, so this is a bit pathological, but if it got that far in the build I'm fine patching it if I can. But if you check your config.log, you'll see

Re: Call for vote: xml-security-c-2.0.0

On 6/22/18, 12:39 PM, "Colm O hEigeartaigh" wrote: > Ubuntu 18.04 bionic. I have not tested Ubuntu but if there's a vagrant VM for it I'll try a quick test later. > It's not a big deal though if it works on other platforms. If you want I can > create a JIRA for it? Not necessary, I'll hold

Re: Call for vote: xml-security-c-2.0.0

>* The CHANGELOG is not updated for 2.0.0. I was correct. It already says "see issue tracker, and has for the last several releases". I'm happy to remove the file outright for a 2.0.0 release if preferred but I won't keep it up to date inside the distribution, it's just duplicative work. I'll

Re: Call for vote: xml-security-c-2.0.0

On 6/22/18, 6:37 AM, "Colm O hEigeartaigh" wrote: > When trying to build the source distribution with "make" I get an error: On what OS? It's been built all over the place at this point. There's not likely I lot I can do to debug it unless I have access to the OS involved, and my list of

RC3 (was Re: xml-security-c 2.0.0 RC2 posted)

I've uploaded a third RC with a number of autoconf changes but no code changes. This is probably the final build unless something comes up. -- Scott On 6/11/18, 9:02 PM, "Cantor, Scott" wrote: Signed copies of RC2 of the upcoming C++ library upgrade are available [1] for testing

RE: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.11 (take II)

I'm rescinding my +1 vote and voting -1, as I have identified a breaking change in the ThreadLocal approach. -- Scott > -Original Message- > From: Cantor, Scott > Sent: Thursday, June 7, 2018 11:25 AM > To: dev@santuario.apache.org; cohei...@apache.org > Subject: RE: [

RE: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.11 (take II)

Colm, I got a little spooked by all those commits and reverts, can you clarify exactly what the "fix" was and what portions of the code were impacted? -- Scott

RE: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.11

> This is a vote to release Apache Santuario - XML Security for Java 2.0.11. +1 -- Scott

RE: [security] Protections against Duo Labs type attacks

> Is there any reason why the standard allowed #WithComments? I cannot think > a single reason why would you want comments in SAML elements. It makes life > so much more complicated. That's not what breaks it. In fact, using #WithComments can harden it, it's the omission of comments from the

RE: [security] Protections against Duo Labs type attacks

> Do you know what the Java settings are that would make it vulnerable to this > attack? Ignoring comments, the usual entity expansion and DTD issues, and a setting to coalesce CDATA into Text nodes are the ones that can create or prevent problems. That in combination with the actual DOM calls

RE: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.10

> This is a vote to release Apache Santuario - XML Security for Java 2.0.10. +1 -- Scott

xml-security-c-2.0.0rc1 available

I've published a release candidate build for testing. [1] Nothing is removed from this version, but the follow pieces are on the chopping block if a maintainer doesn't emerge: - NSS - WinCAPI - XKMS The former two are so rotted with respect to algorithm support that they're really not safe to

RE: Is there support for "derived keys"?

> I wanted to do some tests on the “derived key” features of XML encryption > 1.1. While doing some research (in the Java version), I found some > references to this part of the standard in the documentation (e.g. > DerivedKeyToken), or in the source code (DerivedKeyType). However, I do > not find

Re: Patch for xml-security-cpp XPath namespace resolving

On 10/9/17, 6:05 AM, "Yuri" <0x3...@gmail.com> wrote: > This patch is from my company's mercurial repo and is made against 1.7.3 > release. Is it useful? Are you interested in it? If it impacts code that isn't specific to a Xalan build, I would be unlikely to be able to test it sufficiently to

RE: [VOTE] - Release Apache Santuario - XML Security for Java 2.1.0

+1 -- Scott

  1   2   >