Re: Public discussion on future of C++ library

[Colm O hEigeartaigh]

+1 from me.

Colm.

On Thu, Mar 7, 2024 at 2:20 PM Cantor, Scott  wrote:
>
> > 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

[Colm O hEigeartaigh]

IMO yes we should have a vote to retire the project at ASF, obviously
it's just a formality at this stage.

Colm.

On Wed, Mar 6, 2024 at 4:18 PM Cantor, Scott  wrote:
>
> > 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

[Colm O hEigeartaigh]

Hi Scott,

I think on the ASF side we would just add a note to the README in the
repo saying the project is no longer maintained and a updated version
is available at Shibboleth, and to update the website as well. I don't
think we need to do anything regarding "migrating" as such, from our
PoV the project would be inactive at ASF and people would have to go
elsewhere for support.

I would just need to check with ASF if there are any legalities
involved with not changing the package names or copyright etc.

Colm.

On Fri, Mar 1, 2024 at 5:19 PM Cantor, Scott  wrote:
>
> 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 understanding that decisions about the code's future are 
> no longer subject to Apache project discussion and process, but by that 
> project, driven by its needs.
>
> The code would remain Apache-licensed, as all Shibboleth code is, and be 
> publically available in a publically accessible Git repository (not GitHub, 
> that's not legally feasible right now), have an open bug reporting process, 
> etc.
>
> But in terms of what would happen in the future, that would be dictated by 
> the needs of the Shibboleth Project alone, and anything beyond cursory help 
> would be limited to members of our Consortium, which pays for the support we 
> provide to members.
>
> My intention would be to handle it as a handoff to avoid having to rename the 
> library artifacts, change the version, etc. at least until such time as a new 
> version were needed, and that would pick up from where it stands today.
>
> I appreciate this won't make everybody happy, but being blunt (the only way I 
> know how to be), show up and you can take over if you like and I will back 
> off. Otherwise this is no longer a matter of much debate for me.
>
> I will ask the PMC to consider this in private in case they want to discuss 
> any of what I'm suggesting before making a decision, and I'll abide by that 
> decision.
>
> -- Scott
>
>

Re: Public discussion on future of C++ library

[Colm O hEigeartaigh]

Hey Scott,

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.

Colm.

Cop;l,

On Wed, Feb 21, 2024 at 9:36 PM Cantor, Scott  wrote:
>
> On 2/21/24, 4:07 PM, "Berin Lautenbach"  > 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 I were making the decision alone, the 
> only reason for not forking it is having to consider renaming the artifacts, 
> which creates a lot of work for me on the packaging side.
>
> And in fact, we have no plans right now to even produce a subsequent release 
> of our C++ software that would pull in a new version of this code either, so 
> it's quite possible I would fork it in principle but not in practice, 
> depending on how things go.
>
> Obviously that becomes totally a "me" decision if it's retired here, that's 
> why I decided it was time to just raise it.
>
> > So as the only person maintaining - I’d say go the path that is easiest for
> > you.
>
> I definitely will if there isn't push back on doing it.
>
> Thx,
> -- Scott
>
>

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

[Colm O hEigeartaigh]

With 6 +1 votes, including at least 3 binding votes, and no other
votes, this vote passes.

Colm.

On Tue, Feb 20, 2024 at 2:27 PM Sean Mullan  wrote:
>
> +1
>
> --Sean
>
> On 2/19/24 5:38 AM, Colm O hEigeartaigh wrote:
> > This is a vote to release Apache Santuario - XML Security for Java
> > 4.0.2 and 3.0.4. They contain a new feature to support Key Agreement
> > using ECDH-ES.
> >
> > 4.0.2:
> >Release notes:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353948
> >Git tag: 
> > https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-4.0.2
> >Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachesantuario-1047/
> >
> > 3.0.4:
> >Release notes:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353740.
> >Git tag: 
> > https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-3.0.4
> >Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachesantuario-1048/
> >
> > +1 from me.
> >
> > Colm.

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java
4.0.2 and 3.0.4. They contain a new feature to support Key Agreement
using ECDH-ES.

4.0.2:
  Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353948
  Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-4.0.2
  Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1047/

3.0.4:
  Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353740.
  Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-3.0.4
  Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1048/

+1 from me.

Colm.

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

[Colm O hEigeartaigh]

With 4 +1 votes, and at least 3 binding votes, this vote passes.

Colm.

On Mon, Nov 27, 2023 at 4:14 PM Sean Mullan  wrote:
>
> +1.
>
> —Sean
>
> > On Nov 24, 2023, at 9:50 AM, Colm O hEigeartaigh  
> > wrote:
> >
> > This is a vote to release Apache Santuario XML Security for Java
> > 4.0.1. It contains a bug fix
> > https://issues.apache.org/jira/browse/SANTUARIO-609 "Remove call to
> > Signature.getProvider() in debug log"
> >
> > Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachesantuario-1046/
> > Git tag: 
> > https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-4.0.1
> >
> > +1 from me.
> >
> > Colm.
>

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario XML Security for Java
4.0.1. It contains a bug fix
https://issues.apache.org/jira/browse/SANTUARIO-609 "Remove call to
Signature.getProvider() in debug log"

Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1046/
Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-4.0.1

+1 from me.

Colm.

CVE-2023-44483: Apache Santuario: Private Key disclosure in debug-log output

[Colm O hEigeartaigh]

Severity: moderate

Affected versions:

- Apache Santuario  before < 2.2.6
- Apache Santuario  before < 2.3.4
- Apache Santuario  before < 3.0.3

Description:

All versions of Apache Santuario - XML Security for Java prior to
2.2.6, 2.3.4, and 3.0.3, when using the JSR 105 API, are vulnerable to
an issue where a private key may be disclosed in log files when
generating an XML Signature and logging with debug level is enabled.
Users are recommended to upgrade to version 2.2.6, 2.3.4, or 3.0.3,
which fixes this issue.

Credit:

Apache Santuario would like to thank Max Fichtelmann for reporting
this issue. (finder)

References:

https://santuario.apache.org/
https://www.cve.org/CVERecord?id=CVE-2023-44483

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

[Colm O hEigeartaigh]

With 4 binding +1 votes and no other votes, the vote passes. I'll do
the release.

Colm.

On Mon, Oct 16, 2023 at 1:48 PM Daniel Kulp  wrote:
>
> +1
> Dan
>
>
> On Oct 16, 2023, at 8:18 AM, Sean Mullan  wrote:
>
> +1
>
> —Sean
>
> On Oct 13, 2023, at 10:05 AM, Colm O hEigeartaigh  wrote:
>
> This is a vote to release Apache Santuario - XML Security for Java
> 3.0.3, 2.3.4 and 2.2.6. These are all bug fix releases.
>
> All artifacts are in the same maven repo for release:
> https://repository.apache.org/content/repositories/orgapachesantuario-1045/
>
> 3.0.3 git tag: 
> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-3.0.3
> 2.3.4 git tag: 
> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.3.4
> 2.2.6 git tag: 
> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.2.6
>
> 3.0.3 issues fixed:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353074
> 2.3.4 issues fixed:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353075
>
> +1 from me.
>
> Colm.
>
>
>
> --
> Daniel Kulp
> dk...@apache.org
> Qlik - https://qlik.com
>

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

[Colm O hEigeartaigh]

With 4 binding +1 votes and no other votes, the vote passes. I'll do
the release.

Colm.

On Mon, Oct 16, 2023 at 1:47 PM Daniel Kulp  wrote:
>
> +1
>
> Dan
>
>
> On Oct 13, 2023, at 9:39 AM, Colm O hEigeartaigh  wrote:
>
> This is a vote to release Apache Santuario - XML Security for Java
> 4.0.0. 4.0.0 is a new major release with the following features:
>
> - Java 11 requirement
> - Removing SLF4J and using System.Logger
> - AutoCloseable for several types
>
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachesantuario-1044/
> Git tag: 
> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-4.0.0
>
> +1 from me.
>
> Colm.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> Qlik - https://qlik.com
>

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java
3.0.3, 2.3.4 and 2.2.6. These are all bug fix releases.

All artifacts are in the same maven repo for release:
https://repository.apache.org/content/repositories/orgapachesantuario-1045/

3.0.3 git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-3.0.3
2.3.4 git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.3.4
2.2.6 git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.2.6

3.0.3 issues fixed:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353074
2.3.4 issues fixed:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353075

+1 from me.

Colm.

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java
4.0.0. 4.0.0 is a new major release with the following features:

 - Java 11 requirement
 - Removing SLF4J and using System.Logger
 - AutoCloseable for several types

Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1044/
Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-4.0.0

+1 from me.

Colm.

Re: New releases

[Colm O hEigeartaigh]

Hi,

It'll be too late for these releases, but yes it should be possible to
get everything released for beginning 2024.

Colm.

On Wed, Oct 11, 2023 at 10:15 AM Jože Rihtaršič
 wrote:
>
> Hi Colm
>
> I am preparing the PR for implementing ECDH_ES for EC and XEC keys 
> secp256r1,secp384r1,secp521r1,x25519,x448
>
> My final goal is to have this option to be configured out of the box  in
> apache-cxf WSS4 Interceptors  using  JDK8+ or at least JDK11 and  Jakarta EE 
> 8+.
>
> To achieve that, I probably need to tackle and test with libraries
> org.apache.santuario:xmlsec:2.3.x
> org.apache.wss4j:wss4j:2.4.x
> org.apache.cxf:cxf-rt-ws-security:3.5.c
>
> I have already implemented working example for wss4j
> https://github.com/apache/ws-wss4j/pull/208
> but I guess the right place for this is in xmlsec
>
> My question is, if I provide the initial PR  next week, is there any chance
> to have released this feature at the beginning of 2024 for all the libraries 
> up to cxf-rt-ws-security?
>
> Best regards
> Joze
>
> On Tue, 10 Oct 2023 at 11:14, Colm O hEigeartaigh  wrote:
>>
>> Hi,
>>
>> I intend to call votes on new releases of the 3.0.x, 2.3.x and 2.2.x
>> branches before the end of the week. Please shout now if anything else
>> should go into these releases.
>>
>> Colm.

New releases

[Colm O hEigeartaigh]

Hi,

I intend to call votes on new releases of the 3.0.x, 2.3.x and 2.2.x
branches before the end of the week. Please shout now if anything else
should go into these releases.

Colm.

New releases

[Colm O hEigeartaigh]

I'd like to get 3.0.3 + 2.3.4 out soon, is there anything remaining
that should go into the releases?

Colm.

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

[Colm O hEigeartaigh]

With 4 +1 votes and no other votes, this vote passes. I'll do the release.

Colm.

On Tue, Sep 5, 2023 at 5:01 PM Alessio Soldano  wrote:
>
> +1
> Thanks!
>
> On Mon, Aug 28, 2023 at 3:22 PM Colm O hEigeartaigh  
> wrote:
>>
>> 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.
>>
>> The main new features of the release come from this PR
>> https://github.com/apache/santuario-xml-security-java/pull/192
>>  - Java 11 requirement
>>  - Removing SLF4J and using System.Logger
>>  - AutoCloseable for several types
>>
>> Git tag: 
>> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-4.0.0-M1
>> Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachesantuario-1043/
>>
>> +1 from me.
>>
>> Colm.
>>

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

[Colm O hEigeartaigh]

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.

The main new features of the release come from this PR
https://github.com/apache/santuario-xml-security-java/pull/192
 - Java 11 requirement
 - Removing SLF4J and using System.Logger
 - AutoCloseable for several types

Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-4.0.0-M1
Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1043/

+1 from me.

Colm.

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

[Colm O hEigeartaigh]

With 6 +1 votes, and at least 3 binding +1 votes, and no other votes
this vote passes. I'll do the release.

Colm.

On Wed, Aug 16, 2023 at 9:27 PM Alessio Soldano  wrote:
>
> +1, thanks
>
> On Tue, Aug 15, 2023 at 1:36 PM Colm O hEigeartaigh  
> wrote:
>>
>> This is a vote to release Apache Santuario - XML Security for Java
>> 2.2.5. It just contains some dependency updates to fix CVEs.
>>
>> Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachesantuario-1041/
>> Git tag: 
>> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.2.5
>> Issues fixed: 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12351693
>>
>> +1 from me.
>>
>> Colm.
>>

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

[Colm O hEigeartaigh]

Hi Scott,

You can review all changes between 2.2.5 and 2.2.4 here:
https://github.com/apache/santuario-xml-security-java/compare/xmlsec-2.2.4...xmlsec-2.2.5

Essentially it's just Xalan, BouncyCastle, Woodstox and Jetty upgrades.

Colm.

On Tue, Aug 15, 2023 at 3:34 PM Cantor, Scott  wrote:
>
> > 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
>
>

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java
2.2.5. It just contains some dependency updates to fix CVEs.

Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1041/
Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.2.5
Issues fixed: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12351693

+1 from me.

Colm.

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java
3.0.2 and 2.3.3.

3.0.2:
 - Issues fixed:
https://issues.apache.org/jira/projects/SANTUARIO/versions/12352305
 - Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1039/
 - Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-3.0.2

2.3.3:
 - Issues fixed:
https://issues.apache.org/jira/projects/SANTUARIO/versions/12352306
 - Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1040/
 - Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.3.3

+1 from me.

Colm.-

New Java releases

[Colm O hEigeartaigh]

Hi,

I propose to call votes next week on new Java releases to get the
EdDSA contribution released, let me know please if there is anything
else that should make it in.

Colm.

Re: Failing builds

[Colm O hEigeartaigh]

The JDK8 version has been updated in Jenkins and the build is passing again.

Colm.

On Fri, Jan 20, 2023 at 11:15 AM Colm O hEigeartaigh
 wrote:
>
> Hi,
>
> FYI the JDK8 builds are failing with the recent EdDSA commit, as the
> JDK version is too old (1.8.0_291). I've filed a request for INFRA to
> upgrade: https://issues.apache.org/jira/browse/INFRA-24102
>
> Colm.

Failing builds

[Colm O hEigeartaigh]

Hi,

FYI the JDK8 builds are failing with the recent EdDSA commit, as the
JDK version is too old (1.8.0_291). I've filed a request for INFRA to
upgrade: https://issues.apache.org/jira/browse/INFRA-24102

Colm.

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

[Colm O hEigeartaigh]

With 5 +1 votes, and no other votes, this vote passes.

Colm.

On Thu, Sep 15, 2022 at 8:05 AM Alessio Soldano  wrote:
>
> +1
> thanks!
>
> On Mon, Sep 12, 2022 at 5:13 PM Colm O hEigeartaigh  
> wrote:
>>
>> This is a vote to release Apache Santuario - XML Security for Java
>> 3.0.1 and 2.3.2. The main change is to remove Xalan as a provided
>> (optional) dependency.
>>
>> 3.0.1:
>>
>> Issues fixed: 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12351689
>> Git tag: 
>> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-3.0.1
>> Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachesantuario-1037/
>>
>> 2.3.2:
>>
>> Issues fixed: 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12351691
>> Git tag: 
>> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.3.2
>> Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachesantuario-1038/
>>
>> +1 from me.
>>
>> Colm.
>>

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java
3.0.1 and 2.3.2. The main change is to remove Xalan as a provided
(optional) dependency.

3.0.1:

Issues fixed: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12351689
Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-3.0.1
Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1037/

2.3.2:

Issues fixed: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12351691
Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.3.2
Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1038/

+1 from me.

Colm.

New releases

[Colm O hEigeartaigh]

Hi all,

Let's get new Java releases out soon - 2.3.2 and 3.0.1. Let me know if
there is anything left to go into these releases.

Colm.

Default branch change in github/gitbox for the santuario-xml-security-java

[Colm O hEigeartaigh]

Hi all,

As discussed some time ago on the mailing list, the default branch of
santuario-xml-security-java has changed from master to main. Please
update your local checkouts accordingly.

Colm.

Re: Remove Xalan and here() function support

[Colm O hEigeartaigh]

Yes thanks, I marked it as a duplicate.

Colm.

On Thu, Sep 1, 2022 at 12:14 PM Sean Mullan  wrote:
>
> Colm,
>
> Should SANTUARIO-583 [1] also be closed or marked as a duplicate of
> SANTUARIO-593 [2]?
>
> --Sean
>
> [1] https://issues.apache.org/jira/browse/SANTUARIO-583
> [2] https://issues.apache.org/jira/browse/SANTUARIO-593
>
> On 8/30/22 8:03 AM, Sean Mullan wrote:
> > I support this proposal. I think the "here" function was never specified
> > correctly anyway as I have been told a while ago by an XPath expert that
> > it should have been defined in a namespace in order to be properly
> > processed as an XPath extension.
> >
> > --Sean
> >
> > On 8/30/22 4:04 AM, Colm O hEigeartaigh wrote:
> >> Hi all,
> >>
> >> I'd like to propose removing Xalan as an (optional) dependency and
> >> also support as a result for the here() function defined in the spec:
> >> https://www.w3.org/TR/xmldsig-core1/#function-here
> >>
> >> To re-cap, currently for XPath we use the default Java implementation.
> >> Xalan is an optional dependency, meaning that someone has the ability
> >> to add Xalan to the classpath, in which case Xalan will be used
> >> instead. For Xalan, we do some hacking to support the here() function:
> >>
> >> https://github.com/apache/santuario-xml-security-java/blob/12466b78dcac65e6442d50571c1e6d5dd7748b84/src/main/java/org/apache/xml/security/utils/XalanXPathAPI.java#L162
> >>
> >> This is a little-used part of the spec, that causes a few tests to
> >> fail if we remove it. From previous conversations it doesn't seem
> >> easily possible to support this function using the JDK implementation.
> >>
> >> A recent serious security issue was published for Xalan which makes it
> >> clear the project is being retired -
> >> https://nvd.nist.gov/vuln/detail/CVE-2022-34169. I think it's time
> >> that we removed it, even though it's obviously not ideal that we are
> >> then not fully implementing the spec. We can make it pluggable so that
> >> someone can add the code back in if they want to use it.
> >>
> >> Thoughts?
> >>
> >> Colm.

Remove Xalan and here() function support

[Colm O hEigeartaigh]

Hi all,

I'd like to propose removing Xalan as an (optional) dependency and
also support as a result for the here() function defined in the spec:
https://www.w3.org/TR/xmldsig-core1/#function-here

To re-cap, currently for XPath we use the default Java implementation.
Xalan is an optional dependency, meaning that someone has the ability
to add Xalan to the classpath, in which case Xalan will be used
instead. For Xalan, we do some hacking to support the here() function:

https://github.com/apache/santuario-xml-security-java/blob/12466b78dcac65e6442d50571c1e6d5dd7748b84/src/main/java/org/apache/xml/security/utils/XalanXPathAPI.java#L162

This is a little-used part of the spec, that causes a few tests to
fail if we remove it. From previous conversations it doesn't seem
easily possible to support this function using the JDK implementation.

A recent serious security issue was published for Xalan which makes it
clear the project is being retired -
https://nvd.nist.gov/vuln/detail/CVE-2022-34169. I think it's time
that we removed it, even though it's obviously not ideal that we are
then not fully implementing the spec. We can make it pluggable so that
someone can add the code back in if they want to use it.

Thoughts?

Colm.

Switching Git default branch to main

[Colm O hEigeartaigh]

Hi all,

Unless I hear some strong objections I intend to file a JIRA with
INFRA to switch the default branch of the java git project from
"master" to "main". For some time any new GitHub project uses "main"
as the default branch, and most of the Apache projects I work with
(ActiveMQ, CXF, Karaf, Camel, etc.) have already made the change.

Once the change is made the easiest way is just to delete the local
copy and clone the repo again, or else there are some steps you can
follow to update the branch locally.

Colm.

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

[Colm O hEigeartaigh]

With 5 +1 votes, this vote passes. I'll do the release.

Colm.

On Mon, May 2, 2022 at 5:08 PM Daniel Kulp  wrote:
>
> +1
>
> Dan
>
>
> On Apr 29, 2022, at 2:46 AM, Colm O hEigeartaigh  wrote:
>
> This is a vote to release Apache Santuario - XML Security for Java
> 2.1.8. This is the last planned release on this branch.
>
> Issues fixed: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12351644
> Git tag: 
> https://github.com/apache/santuario-xml-security-java/tree/xmlsec-2.1.8
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachesantuario-1036/
>
> +1 from me.
>
> Colm.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> Talend - https://talend.com
>

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

[Colm O hEigeartaigh]

With 6 +1 votes, this vote passes. I'll do the release.

Colm.

On Mon, May 2, 2022 at 5:08 PM Daniel Kulp  wrote:
>
> +1
>
> Dan
>
>
> On Apr 29, 2022, at 2:25 AM, Colm O hEigeartaigh  wrote:
>
> This is a vote to release Apache Sanutario - XML Security for Java 2.2.4.
>
> Issues fixed: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12350604
> Git tag: 
> https://github.com/apache/santuario-xml-security-java/tree/xmlsec-2.2.4
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachesantuario-1035/
>
> +1 from me.
>
> Colm.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> Talend - https://talend.com
>

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

[Colm O hEigeartaigh]

With 7 binding +1 votes, this vote passes. I'll do the release.

Colm.

On Thu, Apr 28, 2022 at 1:20 PM Daniel Kulp  wrote:
>
> +1
>
> Dan
>
>
> On Apr 28, 2022, at 4:18 AM, Colm O hEigeartaigh  wrote:
>
> This is a vote to release Apache Santuario - XML Security for Java 2.3.1.
>
> Issues fixed: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12350855
> Git tag: 
> https://github.com/apache/santuario-xml-security-java/tree/xmlsec-2.3.1
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachesantuario-1034/
>
> +1 from me.
>
> Colm.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> Talend - https://talend.com
>

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

[Colm O hEigeartaigh]

With 7 +1 votes, and no other votes, this vote passes. I'll do the release.

Colm.

On Thu, Apr 28, 2022 at 1:19 PM Daniel Kulp  wrote:
>
> +1
>
> Dan
>
>
> On Apr 28, 2022, at 3:17 AM, Colm O hEigeartaigh  wrote:
>
> 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.
>
> Issues fixed: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12351397
> git tag: 
> https://github.com/apache/santuario-xml-security-java/tree/xmlsec-3.0.0
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachesantuario-1033/
>
> +1 from me.
>
> Colm.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> Talend - https://talend.com
>

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

[Colm O hEigeartaigh]

This is a vote to release Apache Sanutario - XML Security for Java 2.2.4.

Issues fixed: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12350604
Git tag: https://github.com/apache/santuario-xml-security-java/tree/xmlsec-2.2.4
Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1035/

+1 from me.

Colm.

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java 2.3.1.

Issues fixed: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12350855
Git tag: https://github.com/apache/santuario-xml-security-java/tree/xmlsec-2.3.1
Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1034/

+1 from me.

Colm.

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

[Colm O hEigeartaigh]

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.

Issues fixed: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12351397
git tag: https://github.com/apache/santuario-xml-security-java/tree/xmlsec-3.0.0
Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1033/

+1 from me.

Colm.

Re: xmlsec with slf4j-api ?

[Colm O hEigeartaigh]

Hi,

You can't avoid it, it's a compile time dependency of the library.

Colm.

On Mon, Apr 25, 2022 at 7:09 AM Sateesh K Kolusu
 wrote:
>
> Hello Colm  - Thank you for your response. NOPLogger still needs slf4j jar. 
> But my question is - How to avoid CLASSPATH entry of slf4j-api-1.7.30.jar 
> during runtime. If I do not include this jar, I see the following exception 
> during runtime.
>
> java.lang.NoClassDefFoundError: org.slf4j.LoggerFactory
> at org.apache.xml.security.Init.(Init.java:55)
> at 
> org.apache.ws.security.WSSConfig.setXmlSecIgnoreLineBreak(WSSConfig.java:404)
> at org.apache.ws.security.WSSConfig.init(WSSConfig.java:442)
> at org.apache.ws.security.WSSConfig.getNewInstance(WSSConfig.java:486)
>
> ---
> Thanks
> Sateesh
>
> -Original Message-
> From: Colm O hEigeartaigh 
> Sent: 25 April 2022 02:14 AM
> To: dev@santuario.apache.org
> Subject: [EXTERNAL] Re: xmlsec with slf4j-api ?
>
> It's just an API jar, I believe you can use a NOPLogger if you don't want any 
> logging (https://www.slf4j.org/api/org/slf4j/helpers/NOPLogger.html )
>
> Colm.
>
> On Thu, Apr 21, 2022 at 2:11 AM Sateesh K Kolusu  
> wrote:
> >
> >
> > Hello - I have a question with usage of xmlsec-2.1.7.jar. I see 
> > slf4j-api-1.7.30.jar logger class being called in xmlsec-2.1.7.jar and 
> > needs run time dependency of slf4j-api. Since my application does not 
> > implement logging using 3rd party, how to stop run time usage of 
> > slf4j-api-1.7.30.jar?
> >
> > ---
> > Thanks
> > Sateesh
> >

Re: xmlsec with slf4j-api ?

[Colm O hEigeartaigh]

It's just an API jar, I believe you can use a NOPLogger if you don't
want any logging
(https://www.slf4j.org/api/org/slf4j/helpers/NOPLogger.html)

Colm.

On Thu, Apr 21, 2022 at 2:11 AM Sateesh K Kolusu
 wrote:
>
>
> Hello - I have a question with usage of xmlsec-2.1.7.jar. I see 
> slf4j-api-1.7.30.jar logger class being called in xmlsec-2.1.7.jar and needs 
> run time dependency of slf4j-api. Since my application does not implement 
> logging using 3rd party, how to stop run time usage of slf4j-api-1.7.30.jar?
>
> ---
> Thanks
> Sateesh
>

Releases soon

[Colm O hEigeartaigh]

Hi,

I'd like to call a vote soon on some new releases:
 - a new major release (3.0.0) that has switched to use the Jakarta bindings
 - New 2.2.x and 2.3.x releases
 - and the final release on the 2.1.x branch with a few minor fixes.

Let me know if there are any thoughts or anything you want to see changed.

Colm.

Re: Support for 2.1 branch / EOL?

[Colm O hEigeartaigh]

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?

Colm.

On Fri, Mar 4, 2022 at 3:05 PM Cantor, Scott  wrote:
>
> Was there a final decision made about support ending this year for the 2.1 
> branch of the Java lib?
>
> -- Scott
>
>

Re: [IMPORTANT] - ci.apache.org and CMS Shutdown end of January 2022

[Colm O hEigeartaigh]

Thanks Gavin, it seems everything is working correctly.

Colm.

On Thu, Jan 13, 2022 at 12:40 PM Gavin McDonald  wrote:
>
> As per the update on the Jira ticket, I have a replacement script in place.
> What I will do next is make a test edit to one of your wiki pages and see if 
> it publishes.
>
>
> On 2022/01/12 14:43:17 Gavin McDonald wrote:
> >
> >
> > On 2022/01/12 14:42:45 Gavin McDonald wrote:
> > > Ticket created for tracking, you have 2 weeks.
> >
> > https://issues.apache.org/jira/browse/INFRA-22730
> >
> >
> > >
> > >
> > > On 2021/12/31 11:37:51 Gavin McDonald wrote:
> > > > Hi All,
> > > >
> > > > (This email is BCC many (19) lists, please reply to bui...@apache.org 
> > > > only)
> > > >
> > > > Infra has set a FINAL date of January 31st 2022 for the turn off of
> > > > ci.apache.org. This includes all of its nodes , of which the CMS node is
> > > > one. Therefore the CMS is also going to be gone on the 31st January 
> > > > 2022.
> > > >
> > > > Any project that still uses the CMS in any way shape or form, MUST 
> > > > migrate
> > > > to another build and publish method.
> > > >
> > > > Any project using ci.apache.org for the building and testing/publishing 
> > > > of
> > > > CI builds MUST also migrate away to another CI - the direct replacement 
> > > > is
> > > > ci2.apache.org the new Buildbot 3.2 based instance. Publishing of 
> > > > Javadocs
> > > > and versioned websites etc that normally publish to 
> > > > ci.apache.org/projects
> > > > will need to migrate their jobs to ci2.apache.org and publish results to
> > > > nightlies.apache.org instead (via an rsync step).
> > > >
> > > > Projects have been repeatedly informed of the deprecation of both
> > > > ci.apache.org and also the CMS itself, so this notice should not be a
> > > > surprise to anybody.
> > > >
> > > > If you don't  have an INFRA ticket already open, or you don't know if 
> > > > there
> > > > is an INFRA ticket already open for your project, please open one
> > > > immediately so that we can get working on your migration ASAP. One or 
> > > > two
> > > > projects I know of have a non-standard setup of publishing and so the
> > > > earlier we get started the better.
> > > >
> > > > Below is a list of projects I know to still be using either the CMS (in
> > > > whole or in part) and ci.apache.org for CI builds, there may be more.
> > > >
> > > > Projects fully using the CMS
> > > > ==
> > > >
> > > > Commons
> > > > DB (and subprojects)
> > > > Hive
> > > > Oozie
> > > >
> > > > Projects partially using the CMS
> > > > =
> > > >
> > > > Lucene
> > > > CXF
> > > > Tapestry
> > > > Santuario
> > > > Geronimo
> > > > Nutch
> > > >
> > > > All the above except Nutch I believe are exporting from Confluence and
> > > > committing to
> > > > svn.apache.org/repos/infra/websites/production/ - I have been working 
> > > > on an
> > > > alternate
> > > > method that does not involve the CMS agent (or its dependents like
> > > > build_external.pl)
> > > > CXF and Tapestry at least have INFRA tickets open regarding this.
> > > >
> > > > Projects using ci.apache.org for CI jobs
> > > > 
> > > >
> > > > The Board - board-site build.
> > > > Perl/mod_perl - several test builds.
> > > > AsterixDB - docs build
> > > > HTTPD - test builds
> > > > Juddi - Several test builds
> > > > OpenJPA - Several test builds
> > > > Creadur - Several test builds
> > > > JMeter - test builds
> > > > OpenNLP - site build ?
> > > > Commons - site build ?
> > > > Ponymail - site build ?
> > > > TrafficServer - Test Build + site build ?
> > > > Tapestry - test build
> > > >
> > > > All builds that need migrating can be seen on this page:
> > > >
> > > > https://ci.apache.org/buildslaves
> > > >
> > > > Ok, those are the details, lets get started please people
> > > >
> > > > Oh, and Happy New Year!
> > > >
> > > > Gavin McDonald
> > > > Systems Administrator
> > > > ASF Infrastructure Team
> > > >
> > >
> >

Re: SANTUARIO-513 bug status

[Colm O hEigeartaigh]

Note, this comment only applies to the C++ library, not the Java library.

Colm.

On Wed, Jan 19, 2022 at 3:39 PM BEEK Graham  wrote:
>
> Hi,
>
>
>
> 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 where the check mentioned is located?
>
>
>
> This is the description:
>
>
>
> There's a bug in the Signature load routine that relates to a commented out 
> check that was failing the load when unknown content appeared at the end of a 
> Signature element.
>
> The code was unwisely changed to permit "non-conformant signatures", which is 
> an absolutely indefensible decision. This is how you get security bugs. 
> Non-conformant signatures can go right to hell.
>
> Adding an option to control this behavior is the absolute minimum we should 
> do, but the default should be strict, and the rest of the load methods should 
> be reviewed for any similar permissiveness.
>
>
>
>
>
>
>
> Many thanks,
> Graham
>
>
>
> This message contains information that may be privileged or confidential and 
> is the property of the Capgemini Group. It is intended only for the person to 
> whom it is addressed. If you are not the intended recipient, you are not 
> authorized to read, print, retain, copy, disseminate, distribute, or use this 
> message or any part thereof. If you receive this message in error, please 
> notify the sender immediately and delete all copies of this message.

Re: A jakarta namespace version

[Colm O hEigeartaigh]

If there is demand then I don't mind keeping 2.1.x for a while longer.
It only gets security fixes anyway at this stage.

Colm.

On Thu, Dec 2, 2021 at 1:02 PM Cantor, Scott  wrote:
>
> 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 that little notice is a little inconvenient, but I guess if 
> that's the notice my project will have to make do.
>
> -- Scott
>
>

Re: A jakarta namespace version

[Colm O hEigeartaigh]

Yes, good point.

Colm.

On Thu, Dec 2, 2021 at 10:26 AM Matti Aarnio  wrote:
>
> Given that the Jakarta-namespace change is major incompatibility with 
> previous versions,
> perhaps you should call it 3.0.0 ?
>
> Best Regards,
> Matti
>
> On 02/12/2021 12.16, 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?
>
> Colm.
>
>

Re: A jakarta namespace version

[Colm O hEigeartaigh]

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?

Colm.

On Mon, Nov 29, 2021 at 3:59 PM Rebecca Searls  wrote:
>
> > WSS4J only uses the javax.xml.bind dependencies for the streaming 
> > implementation,
> > which is currently only consumed by CXF. CXF won't switch to using Jakarta 
> > for a
> > while, so until then I think there's not much point in updating WSS4J.
>
> CXF is NOT the only consumer of WSS4J and its streaming code. Wildfly and thus
> EAP use it as do some of its (our) customers.  And I would expect there are
> other products outside the CXF and Wildfly realm that use it as well.
>
> In the hierarchy of this ecosystem Santuario is a foundational component.  
> Waiting
> for higher level components to move before moving this foundational component
> impedes the progress of all.  Why must all be tied to CXF's schedule?  Why 
> can't the
> jakarta native version  (e.g. 
> https://github.com/apache/santuario-xml-security-java/pull/63)
> be provided for those who want to move now?
>
> On Mon, Nov 29, 2021 at 6:19 AM Colm O hEigeartaigh  
> wrote:
>>
>> We don't have an imminent release date yet, because the Santuario StAX
>> implementation is really only used by Apache CXF, and CXF confirmed to
>> me that it would be a while before they switch to using Jakarta.
>>
>> Colm.
>>
>> On Tue, Nov 23, 2021 at 8:14 PM Rebecca Searls  wrote:
>> >
>> > Yes,  When will this be available and in a public repository?
>> >
>> > On Tue, Nov 23, 2021 at 12:22 PM Colm O hEigeartaigh  
>> > wrote:
>> >>
>> >> Hi Rebecca,
>> >>
>> >> I believe we have an existing PR -
>> >> https://github.com/apache/santuario-xml-security-java/pull/63
>> >> Or are you referring to something else?
>> >>
>> >> Colm.
>> >>
>> >> On Tue, Nov 23, 2021 at 1:25 PM Rebecca Searls  wrote:
>> >> >
>> >> > Wildfly components requires a jakarta namesapce version of 
>> >> > org.apache.santuario:xmlsec.
>> >> > I have created such a version.  I would like to submit a PR for it.
>> >>
>>

Re: A jakarta namespace version

[Colm O hEigeartaigh]

We don't have an imminent release date yet, because the Santuario StAX
implementation is really only used by Apache CXF, and CXF confirmed to
me that it would be a while before they switch to using Jakarta.

Colm.

On Tue, Nov 23, 2021 at 8:14 PM Rebecca Searls  wrote:
>
> Yes,  When will this be available and in a public repository?
>
> On Tue, Nov 23, 2021 at 12:22 PM Colm O hEigeartaigh  
> wrote:
>>
>> Hi Rebecca,
>>
>> I believe we have an existing PR -
>> https://github.com/apache/santuario-xml-security-java/pull/63
>> Or are you referring to something else?
>>
>> Colm.
>>
>> On Tue, Nov 23, 2021 at 1:25 PM Rebecca Searls  wrote:
>> >
>> > Wildfly components requires a jakarta namesapce version of 
>> > org.apache.santuario:xmlsec.
>> > I have created such a version.  I would like to submit a PR for it.
>>

Re: A jakarta namespace version

[Colm O hEigeartaigh]

Hi Rebecca,

I believe we have an existing PR -
https://github.com/apache/santuario-xml-security-java/pull/63
Or are you referring to something else?

Colm.

On Tue, Nov 23, 2021 at 1:25 PM Rebecca Searls  wrote:
>
> Wildfly components requires a jakarta namesapce version of 
> org.apache.santuario:xmlsec.
> I have created such a version.  I would like to submit a PR for it.

Re: Santuario web site

[Colm O hEigeartaigh]

The website updates seem to be working again.

Colm.

On Fri, Nov 5, 2021 at 3:53 PM Cantor, Scott  wrote:
>
> 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 Sept, so I assumed it was me, but maybe they froze it 
> after that date. I assumed my backstop was tweaking the HTML in svn a bit and 
> skipping the wiki -> svn step but sounds like that won't work either.
>
> -- Scott
>
>

Re: Santuario web site

[Colm O hEigeartaigh]

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).

Colm.

On Thu, Nov 4, 2021 at 2:27 PM Cantor, Scott  wrote:
>
> 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

[Colm O hEigeartaigh]

+1.

Colm.

On Mon, Nov 1, 2021 at 12:34 PM Daniel Kulp  wrote:
>
> +1
>
> Dan
>
>
> On Nov 1, 2021, at 8:25 AM, Cantor, Scott  wrote:
>
> 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] https://dist.apache.org/repos/dist/dev/santuario/c-library/
> [2] 
> https://svn.apache.org/viewvc/santuario/xml-security-cpp/trunk/xsec/?view=log
>
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend - http://talend.com
>

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

[Colm O hEigeartaigh]

With 4 binding +1 votes, this vote passes.

Colm.

On Mon, Oct 25, 2021 at 1:57 PM Sean Mullan  wrote:
>
> +1
>
> --Sean
>
> On 10/25/21 6:52 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. Some of the
> > significant changes include:

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java
2.3.0. This is a major new release of the library. Some of the
significant changes include:

 * A rewrite for the StAX output processor chain to make it
deterministic - https://issues.apache.org/jira/browse/SANTUARIO-555
 * Secure Validation is now enabled by default -
https://issues.apache.org/jira/browse/SANTUARIO-574
 * Local + HTTP ResourceResolvers are disabled by default -
https://issues.apache.org/jira/browse/SANTUARIO-573

Release notes: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12348798
Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.3.0
Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1032/

+1 from me.

Colm.

[CVE-2021-40690] - Apache Santuario - XML Security for Java

[Colm O hEigeartaigh]

The Apache Santuario™ project is aimed at providing implementation of
the primary security standards for XML:

- XML-Signature Syntax and Processing
- XML Encryption Syntax and Processing.

A new CVE is released for Apache Santuario - XML Security for Java,
which is fixed in the latest 2.2.3 and 2.1.7 releases:

CVE-2021-40690 - Bypass of the secureValidation property
(https://santuario.apache.org/secadv.data/CVE-2021-40690.txt.asc)

Please see the main site for more information: https://santuario.apache.org/

Colm.

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

[Colm O hEigeartaigh]

With 4 binding +1 votes this vote passes, I'll do the release

Colm.

On Fri, Sep 10, 2021 at 2:59 PM Colm O hEigeartaigh  wrote:
>
> No, I need to increment the build number for the next release.
>
> Colm.
>
> On Fri, Sep 10, 2021 at 2:45 PM Cantor, Scott  wrote:
> >
> > +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.3

[Colm O hEigeartaigh]

With 4 binding +1 votes this vote passes, I'll do the release

Colm.

On Fri, Sep 10, 2021 at 2:45 PM Cantor, Scott  wrote:
>
> +1
>
> -- Scott
>
>

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

[Colm O hEigeartaigh]

No, I need to increment the build number for the next release.

Colm.

On Fri, Sep 10, 2021 at 2:45 PM Cantor, Scott  wrote:
>
> +1, assuming those Jenkins failures don't mean anything to do with this 
> release?
>
> -- Scott
>
>

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java 2.1.7

Issues fixed: 
https://issues.apache.org/jira/projects/SANTUARIO/versions/12349490
Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1031/
Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.1.7

+1 from me.

Colm.

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java 2.2.3.

Issues fixed: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12350144
Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1030/
Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.2.3

+1 from me.

Colm.

Re: Regarding support of SHA224 as mgfalgorithm during encryption

[Colm O hEigeartaigh]

I added a test-case here and it seems to work:
https://github.com/apache/santuario-xml-security-java/commit/d0bc3285f82b9f4de4e023c2f9b4ec8a22db8211

Colm.

On Thu, Sep 9, 2021 at 2:43 PM sreenivas somavarapu
 wrote:
>
> Hi Colm,
>
> Thank you for your response. One final query is Will SHA224 be supported in 
> both cases?
> - Construction of OAEPParameters in constructOAEPParameters method
> - Construction of cipher using SHA224 digest algorithm in constructCipher 
> method
>
> Regards,
> Sreenivas
>
>
> On Wed 8 Sep, 2021, 4:22 PM Colm O hEigeartaigh,  wrote:
>>
>> Hi,
>>
>> It will be fixed for the next release here -
>> https://issues.apache.org/jira/browse/SANTUARIO-579
>>
>> Colm.
>>
>> On Tue, Sep 7, 2021 at 11:48 PM Sreenivas Somavarapu
>>  wrote:
>> >
>> > Hi Team,
>> >
>> >
>> >
>> > Not sure if this is correct forum / mailing list to put this query. If 
>> > this is not could you let me know where could I post this query.
>> >
>> >
>> >
>> > We are using XMLCipher API to perform encrypt and decrypt operations of 
>> > SAML assertions and we are seeing a issue when integrating with Shibboleth 
>> > / HSM devices (Any third-party which is not using xmlsec) and when using 
>> > only RSAOAEP 1.1 with mgfalgorithm as SHA224 (rest all are working fine). 
>> > When referred xmlsec code  @ santuario-xml-security-java/XMLCipher.java at 
>> > xmlsec-2.2.2 · apache/santuario-xml-security-java · GitHub and during 
>> > encryptkey call xmlsec is trying to construct OAEP parameters in 
>> > constructOAEPParameters function. In that function while constructing 
>> > MGF1ParameterSpec there is an if else which has SHA1 (default), SHA256, 
>> > SHA384 and SHA512 but not SHA224 (even this is the same case in 
>> > constructCipher function as well).
>> >
>> >
>> >
>> > Is there any reason behind omitting SHA224 in these places? Also is there 
>> > any place in API documentation / website where I could find list of all 
>> > algorithms supported by xmlsec for different crypto operations?
>> >
>> >
>> >
>> > Sample Code for wrapping key is as below
>> >
>> > KeyGenerator keyGenerator = KeyGenerator.getInstance("AES", jceProvider);
>> >
>> > keyGenerator.init(256, SecureRandom);
>> >
>> > SecretKey dek = keyGenerator.generateKey();
>> >
>> > XMLCipher cipher = XMLCipher.getProviderInstance(XMLCipher.RSA_OAEP_11, 
>> > jceProvider, Canonicalizer.ALGO_ID_C14N_PHYSICAL, 
>> > MessageDigestAlgorithm.ALGO_ID_DIGEST_SHA224);
>> >
>> > cipher.init(XMLCipher.WRAP_MODE, publickey);
>> >
>> > EncryptedKey encryptedKey = cipher.encryptKey(xmlDoc, dek, 
>> > "http://www.w3.org/2009/xmlenc11#mgf1sha224;, null);
>> >
>> >
>> >
>> > Thanks in Advance.
>> >
>> >
>> >
>> > Regards,
>> >
>> > Sreenivas

Re: Regarding support of SHA224 as mgfalgorithm during encryption

[Colm O hEigeartaigh]

Hi,

It will be fixed for the next release here -
https://issues.apache.org/jira/browse/SANTUARIO-579

Colm.

On Tue, Sep 7, 2021 at 11:48 PM Sreenivas Somavarapu
 wrote:
>
> Hi Team,
>
>
>
> Not sure if this is correct forum / mailing list to put this query. If this 
> is not could you let me know where could I post this query.
>
>
>
> We are using XMLCipher API to perform encrypt and decrypt operations of SAML 
> assertions and we are seeing a issue when integrating with Shibboleth / HSM 
> devices (Any third-party which is not using xmlsec) and when using only 
> RSAOAEP 1.1 with mgfalgorithm as SHA224 (rest all are working fine). When 
> referred xmlsec code  @ santuario-xml-security-java/XMLCipher.java at 
> xmlsec-2.2.2 · apache/santuario-xml-security-java · GitHub and during 
> encryptkey call xmlsec is trying to construct OAEP parameters in 
> constructOAEPParameters function. In that function while constructing 
> MGF1ParameterSpec there is an if else which has SHA1 (default), SHA256, 
> SHA384 and SHA512 but not SHA224 (even this is the same case in 
> constructCipher function as well).
>
>
>
> Is there any reason behind omitting SHA224 in these places? Also is there any 
> place in API documentation / website where I could find list of all 
> algorithms supported by xmlsec for different crypto operations?
>
>
>
> Sample Code for wrapping key is as below
>
> KeyGenerator keyGenerator = KeyGenerator.getInstance("AES", jceProvider);
>
> keyGenerator.init(256, SecureRandom);
>
> SecretKey dek = keyGenerator.generateKey();
>
> XMLCipher cipher = XMLCipher.getProviderInstanceXMLCipher.RSA_OAEP_11, 
> jceProvider, Canonicalizer.ALGO_ID_C14N_PHYSICAL, 
> MessageDigestAlgorithm.ALGO_ID_DIGEST_SHA224);
>
> cipher.init(XMLCipher.WRAP_MODE, publickey);
>
> EncryptedKey encryptedKey = cipher.encryptKey(xmlDoc, dek, 
> "http://www.w3.org/2009/xmlenc11#mgf1sha224;, null);
>
>
>
> Thanks in Advance.
>
>
>
> Regards,
>
> Sreenivas

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

[Colm O hEigeartaigh]

With 4 binding +1 votes, and no other votes, this vote passes - I'll
do the release.

Colm.

On Fri, Apr 30, 2021 at 5:33 PM Cantor, Scott  wrote:
>
> +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.
>
>

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java 2.2.2.

Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1029/
Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.2.2
Issues fixed: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12349491

+1 from me.

Colm.

Release of 2.2.1 soon

[Colm O hEigeartaigh]

Hi all,

I plan to call a vote on the 2.2.1 release this week, let me know if
there are any last minute changes.

Colm.

Re: Apache XML Security (xmlsec) for Java EOL versions?

[Colm O hEigeartaigh]

Hi,

The current releases are 2.2.1 and 2.1.6 - the 2.2.x and 2.1.x branches are
still supported. Anything before 2.1.x is EOL. As for dates, I would go
with the JIRA releases page which lists the dates of each release:
https://issues.apache.org/jira/projects/SANTUARIO?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page

Colm.

On Tue, Dec 15, 2020 at 4:55 PM Symphoni Bush - NOAA Affiliate <
symphoni.b...@noaa.gov> wrote:

> Good morning,
>
> I am trying to figure out what versions of Apache XML Security (xmlsec)
> for Java are EOL and if so, what dates these versions became EOL. If there
> is somewhere this information is stored, please let me know.
>
> Thanks
>

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

[Colm O hEigeartaigh]

With 4 binding +1 votes, this vote passes - I'll do the release.

Colm.

On Tue, Dec 8, 2020 at 3:45 PM Daniel Kulp  wrote:

> +1
>
> Dan
>
>
> On Dec 8, 2020, at 7:40 AM, Colm O hEigeartaigh 
> wrote:
>
> This is a vote to release Apache Santuario - XML Security for Java 2.2.1/
> 2.1.6. <http://2.1.0.6/>
>
> 2.2.1:
> Issues fixed:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12348362
> Git tag:
> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.2.1
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachesantuario-1028/org/apache/santuario/xmlsec/2.2.1/
>
> 2.1.6:
> Issued fixed:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12347790
> Git tag:
> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.1.6
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachesantuario-1028/org/apache/santuario/xmlsec/2.1.6/
>
> +1 from me.
>
> Colm.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend - http://talend.com <http://coders.talend.com>
>
>

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java 2.2.1/
2.1.6.

2.2.1:
Issues fixed:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12348362
Git tag:
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.2.1
Artifacts:
https://repository.apache.org/content/repositories/orgapachesantuario-1028/org/apache/santuario/xmlsec/2.2.1/

2.1.6:
Issued fixed:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12347790
Git tag:
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.1.6
Artifacts:
https://repository.apache.org/content/repositories/orgapachesantuario-1028/org/apache/santuario/xmlsec/2.1.6/

+1 from me.

Colm.

Releases soon

[Colm O hEigeartaigh]

Hi all,

I plan to call a vote on new 2.2.1 + 2.1.6 releases next week. Let me know
if there is anything else that should go into these releases.

Colm.

Re: method signature issue in xmlsec 2.2.0

[Colm O hEigeartaigh]

Hi,

Answers inline.


> I have been looking at upgrading our xmlsec dependency to 2.2.0, on the
> basis that at some point the 2.1.x series will lose support. Is that
> already the case? Not obvious from the web site at present.
>

It's not already the case, there will be at least a 2.1.6 release at some
point.


>
> Anyway, I ran into an issue with method signatures that I am not sure was
> intended in 2.2.0. It seems to have come about from this issue:
>
> It doesn't seem to me as if this was intentional (given the Javadoc allows
> the original method to be passed a `null`), and the Jira ticket doesn't
> discuss adding new methods. I guess I'd be interested to know what the
> thinking was here, whether this was intentional and whether it might make
> sense to fix the regression in a future 2.2.x release.
>

Yes good catch, it was not intentional to have a conflict between the two
methods. For now you can upgrade just by casting null to a String. Any
change I make to the method signatures for 2.2.1 will break backwards
compatibility. So for 2.3.0 I will fix it by re-ordering the parameters for
the Serializer case.

Colm.




>
> Cheers,
>
> -- Ian
>
>
>
>
>

Build Server moved

[Colm O hEigeartaigh]

Hi,

The build server has migrated at Apache from Jenkins to CloudBees - the new
build jobs for the Java project are here:

https://ci-builds.apache.org/job/Santuario/

There are builds for the master branch using JDK8, 11 and 14. The JDK8
build also deploys SNAPSHOTS to
https://repository.apache.org/content/groups/snapshots/org/apache/santuario/xmlsec/

Colm.

[ANNOUNCE] - Apache Santuario - XML Security for Java 2.2.0 released

[Colm O hEigeartaigh]

The Apache Santuario team announces the release of XML Security for Java
2.2.0.

This is a new major release with the following features:

   - Added support for RSASSA-PSS with Parameters
   - Extensive refactoring and code simplification
   - JDK14 officially supported
   - Ability to set a security provider when using
   org.apache.xml.security.signature.XMLSignature
   - Added support for customizing how to parse a Inputstream into a DOM
   Document

Please refer to the website (http://santuario.apache.org/) for further
information and download details.

Colm.

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

[Colm O hEigeartaigh]

With 4 binding +1 votes, this vote passes - I'll do the release.

Colm.

On Tue, May 26, 2020 at 2:13 PM Cantor, Scott  wrote:

> +1
>
> -- Scott
>
>
>

[VOTE] - Release Apache Santuario - XML Security for Java 2.2.0

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java 2.2.0.
This is a new major release with the following features:

 * Added support for RSASSA-PSS with Parameters
 * Extensive refactoring and code simplification
 * JDK14 officially supported
 * Ability to set a security provider when using
org.apache.xml.security.signature.XMLSignature
 * Added support for customizing how to parse a Inputstream into a DOM
Document

Issues fixed:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12344983
Git tag:
https://github.com/apache/santuario-xml-security-java/tree/xmlsec-2.2.0
Artifacts:
https://repository.apache.org/content/repositories/orgapachesantuario-1027/

+1 from me.

Colm.

Source repository change for XML Security for Java

[Colm O hEigeartaigh]

Hi all,

We have migrated the Apache Santuario - XML Security for Java project from
SVN to GIT. Please update your local checkouts to either the gitbox or
github repositories as listed on the website:

http://santuario.apache.org/java-source-repository.html

The old "https://github.com/apache/santuario-java; SVN mirror is invalid
and will be deleted.

Note the C++ project is still on SVN.

Colm.

Re: Release soon...

[Colm O hEigeartaigh]

I've completed the planned work for 2.2.0:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12344983

I hope to call a vote maybe in 3 weeks or so, so if there's anything else
to go in please let me know.

Colm.

On Mon, Mar 2, 2020 at 3:37 PM Colm O hEigeartaigh 
wrote:

> I want to get a new Java release of 2.1.x out soon, so please let me know
> ASAP if there is anything else to go in.
>
> Current issues fixed:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12345945
>
> Colm.
>

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

[Colm O hEigeartaigh]

Hi Peter,

As Scott said, the github mirror is read-only at the moment, although we
will move shortly to use git instead of svn. However if you prefer to
submit pull requests to the mirror for now, I am OK with applying them
manually.

In terms of a next release, I want to get 2.1.5 out in a few weeks (maybe
up to a month), and 2.2.0 by the end of the quarter.

Colm.

On Thu, Jan 30, 2020 at 9:35 PM Peter De Maeyer 
wrote:

> Dear,
>
> In the context of my job, I recently found myself in need to have some
> bugs fixed and features added to santuario-java. Now I want to
> contribute those fixes/features to the community, so I started here:
> https://santuario.apache.org/contributing.html
>
> The information on that page seems a bit outdated - it refers to svn and
> this mailing list, but I also found a GitHub project:
> https://github.com/apache/santuario-java and a bug tracker:
> https://issues.apache.org/jira/browse/SANTUARIO
>
> Is it enough if I create bugs and pull requests on GitHub, and discuss
> everything in there, or should I still use this mailing list too?
>
> What expectations may I have regarding the timeframe in which my
> contributions will be considered for inclusion in the next release?
>
> This is partially a test to check how active this mailing list is :-)
>
> Kind regards,
>
> Peter
>
>

Moving to GIT

[Colm O hEigeartaigh]

Hi all,

I want to switch the Apache Santuario XML Security for Java codebase to git
at Apache (http://svn.apache.org/repos/asf/santuario/xml-security-java/).
The website will stay on svn. I think Santuario is the last project at
Apache I'm involved with that still uses svn.

@Scott Cantor   would you like to also move
xml-security-cpp to git, or do you just want to leave it in svn?

Colm.

Re: CRLF change in Java 8 patch

[Colm O hEigeartaigh]

Hi Scott,

Are you referring to the fix that was made for 2.1.2?
https://issues.apache.org/jira/browse/SANTUARIO-482

As in, the latest Oracle patch, does not have this fix above?

Colm.

On Thu, Oct 17, 2019 at 3:16 PM Cantor, Scott  wrote:

> 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 ideal situation, needless to say. Our opinion is that
> change was a huge mistake, but be that as it may, to start seeing things
> fork in such a potentially sensitive area is a pretty big red flag. We
> suspected it might happen, but being right doesn't make it any more fun.
>
> -- Scott
>
>
>

Re: [PATCH] RSASSA-PSS with Parameters

[Colm O hEigeartaigh]

Hi,

Thanks for the patches - could you create a JIRA (
https://issues.apache.org/jira/projects/SANTUARIO) + attach the patches
there?

Colm.

On Wed, Sep 11, 2019 at 9:04 AM Kunnar Klauks  wrote:

> Hello,
>
> Here is patch for supporting 'RSASSA-PSS with Parameters' as described in
> https://tools.ietf.org/html/rfc6931#section-2.3.9
>
> We have patches for
> http://svn.apache.org/viewvc/santuario/xml-security-java/branches/2.0.x-fixes/
>  and
> for http://svn.apache.org/viewvc/santuario/xml-security-java/trunk/.
>
> Disclaimer: we developed and tested against 2.0.x-fixes branch and later
> merged to trunk branch. We ran tests on trunk locally, but did not use this
> branch for anything else.
>
> Regards,
> Kunnar
>
>
>

Re: [CVE-2019-12400] Apache Santuario potentially loads XML parsing code from an untrusted source

[Colm O hEigeartaigh]

Hi,

Yes, Scott's interpretation is correct - I'm sorry if the wording of the
CVE was not sufficiently clear. Let me see if there's a way to query the
CVSSv3 score that was assigned to the CVE...

Colm.

On Fri, Sep 6, 2019 at 3:03 PM Cantor, Scott  wrote:

> On 9/6/19, 5:44 AM, "RvG"  wrote:
>
> > I was going for a reading like this as well, but there's a little too
> much
> > ambiguity in the original wording for me to feel comfortable reading it
> like
> > that. I say that considering that the CVSSv3 score assigned to this
> > vulnerability (7.5) is rather high if the bug requires you to load
> untrusted
> > XML parsers to be effective.
>
> I think quantitiative scoring like that is ridiculous and will never be
> meaningful, nor do I know who scored it.
>
> I think it's entirely fair to expect the upstream project to be clear
> about the issue if it can be without disclosing information that would put
> people at risk, but it's not my advisory, so it's not my place to clarify
> it beyond what I've already said. If my understanding is incorrect, then
> I'm sure I'll be corrected.
>
> -- Scott
>
>
>

[CVE-2019-12400] Apache Santuario potentially loads XML parsing code from an untrusted source

[Colm O hEigeartaigh]

The following security advisory is announced for the Apache Santuario - XML
Security for Java project, which is fixed in the recent 2.1.4 release.

[CVEID]:CVE-2019-12400
[PRODUCT]:Apache Santuario - XML Security for Java
[VERSION]:All 2.0.x releases from 2.0.3, all 2.1.x releases before 2.1.4.
[PROBLEMTYPE]:Process Control
[REFERENCES]:
http://santuario.apache.org/secadv.data/CVE-2019-12400.asc?version=1=1566573083000=v2
[DESCRIPTION]:In version 2.0.3 of Apache Santuario XML Security for Java, a
caching mechanism
  was introduced to speed up creating new XML documents using a
static pool of
  DocumentBuilders.

  However, if some untrusted code can register a malicious
implementation with
  the thread context class loader first, then this
implementation might be
  cached and re-used by Apache Santuario - XML Security for
Java, leading to
  potential security flaws when validating signed documents,
etc.

For more information, please see the security advisories page of Apache
Santuario: http://santuario.apache.org/secadv.html

-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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

[Colm O hEigeartaigh]

With 5 +1 votes, including 3 binding +1 votes, this vote passes - I'll do
the release.

Colm.

On Fri, Jul 19, 2019 at 12:59 PM Daniel Kulp  wrote:

>
> +1
>
> Dan
>
>
> On 2019/07/16 15:59:03, Colm O hEigeartaigh  wrote:
> > This is a vote to release Apache Santuario - XML Security for Java 2.1.4.
> >
> > Issues fixed:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12345224
> > Maven artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachesantuario-1025/
> > SVN tag:
> >
> https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-2.1.4/
> >
> > +1 from me.
> >
> > Colm.
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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

[Colm O hEigeartaigh]

Hi Scott,

On Tue, Jul 16, 2019 at 5:19 PM Cantor, Scott  wrote:

>
> 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:
>
> - decrypting XML
> - particular Transform sequences that go from octet stream to DOM
> mid-transform
> ?
>

Yes and in canonicalization.


>
> My project is particular sensitive to the security considerations of ever
> allowing any other library to do XML parsing for obvious reasons. I wonder
> if there's a way we could inject our own via some kind of interface in a
> future version? Or would a patch for that be welcome?
>

Yes I was thinking along those lines for 2.3.0. Patches definitely welcome!

Colm.


>
> -- Scott
>
>
>

-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java 2.1.4.

Issues fixed:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12345224
Maven artifacts:
https://repository.apache.org/content/repositories/orgapachesantuario-1025/
SVN tag:
https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-2.1.4/

+1 from me.

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java 2.1.3.

Issues fixed:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12343431
SVN tag:
http://svn.apache.org/viewvc/santuario/xml-security-java/tags/xmlsec-2.1.3/
Maven artifacts:
https://repository.apache.org/content/repositories/orgapachesantuario-1023/

+1 from me.

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Java 2.1.3 release

[Colm O hEigeartaigh]

Thanks, this one should be viewable:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12343431

Colm.

On Mon, Mar 25, 2019 at 4:07 PM Cantor, Scott  wrote:

> On 3/22/19, 11:16 AM, "Colm O hEigeartaigh"  wrote:
>
> > I'd like to get the Java 2.1.3 release out soon. We have seven issues
> fixed for it so far:
>
> Just FYI, the filter there isn't publically viewable, if you meant it to
> be.
>
> > https://issues.apache.org/jira/projects/SANTUARIO/versions/12343431
>
> -- Scott
>
>
>

-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Java 2.1.3 release

[Colm O hEigeartaigh]

Hi all,

I'd like to get the Java 2.1.3 release out soon. We have seven issues fixed
for it so far:

https://issues.apache.org/jira/projects/SANTUARIO/versions/12343431

Anything else anyone wants to see in it?

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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

[Colm O hEigeartaigh]

+1.

Colm.

On Tue, Oct 30, 2018 at 8:30 PM Cantor, Scott  wrote:

> 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 built from svn revision 1843566 at [2].
>
> I'd like to get this out by next week latest if possible.
>
> This is my +1
>
> Thanks,
> -- Scott
>
> [1] https://issues.apache.org/jira/browse/SANTUARIO-496
> [2] https://dist.apache.org/repos/dist/dev/santuario/c-library/
>
>

-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Digest Mismatch Exceptions and Enveloped Signatures

[Colm O hEigeartaigh]

Hi,

Those examples are from my personal github repo and have nothing to do
really with the Apache Santuario project.

I'm not sure what you mean by "seem to produce invalid XML signatures by
default"? The examples produce valid (detached) XML Signatures and verify
just fine. For example, this test uses both those methods in SignatureUtils:

https://github.com/coheigea/testcases/blob/master/apache/santuario/santuario-xml-signature/src/test/java/org/apache/coheigea/santuario/xmlsignature/SignatureStAXTest.java

> Used as is you will get XML Signatures that do not include the
EnvelopedSignature Transform

This is not a requirement for XML Signatures - the test code in
SignatureUtils does not use it.

Colm.

On Fri, Jul 27, 2018 at 2:53 AM, buko  wrote:

>
>
> Not sure if others have encountered this but I thought I’d report this
> since I ran into this issue and spent quite a while trying to figure out
> what’s going on. The issue:
>
>
>
> The signUsingStax and verifyUsingStax methods from the Example Code (see
> https://github.com/coheigea/testcases/blob/master/apache/
> santuario/santuario-xml-signature/src/test/java/org/
> apache/coheigea/santuario/xmlsignature/SignatureUtils.java#L162 and
> https://github.com/coheigea/testcases/blob/master/apache/
> santuario/santuario-xml-signature/src/test/java/org/
> apache/coheigea/santuario/xmlsignature/SignatureUtils.java#L203) seem to
> produce invalid XML signatures by default. Used as is you will get XML
> Signatures that do not include the EnvelopedSignature Transform (
> http://www.w3.org/2000/09/xmldsig#enveloped-signature).
>
>
>
> The code will sign documents but when you verify the signed documents
> you’ll get invalid digest errors like:
>
>
>
> org.apache.xml.security.exceptions.XMLSecurityException: Invalid digest
> of reference #Ge7a73177-7aad-4fe8-bed8-d26ef9cfaeed
>
>
>
> To make the code work you’ll need to add the EnvelopedSignature Transform
> like:
>
>private static final String[] ENVELOPED_SIGNATURE_TRANSFORMS =
>
>   { "http://www.w3.org/2000/09/
> xmldsig#enveloped-signature",  "http://www.w3.org/2001/10/xml-exc-c14n#"};
>
>signatureSpec.getElementsToSign().forEach(
>
> qname -> {
>
>final SecurePart
> securePart = new SecurePart(qname, SecurePart.Modifier.Content);
>
>
> securePart.setTransforms(ENVELOPED_SIGNATURE_TRANSFORMS);
>
>
> securityProperties.addSignaturePart(securePart);
> });
>
>
>
>
>
> Perhaps it would be helpful to include two separate examples, one using
> stax signature verification with an enveloped signature and another one
> with an enveloping signature?
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Recovering XML Signature via JAXB

[Colm O hEigeartaigh]

According to the schema, the Signature Element is a SignatureType:



and the SignatureType is available in the bindings directory:

https://github.com/apache/santuario-java/blob/trunk/src/main/java/org/apache/xml/security/binding/xmldsig/SignatureType.java

The JAXB bindings are used by the streaming XML Security implementation,
and are not designed to be used in a standalone way. You might be able to
re-use the streaming code for your purpose though. Take a look at some of
the tests, for example:

https://github.com/apache/santuario-java/blob/trunk/src/test/java/org/apache/xml/security/test/stax/signature/SignatureVerificationTest.java

Colm.

On Tue, Jul 17, 2018 at 10:49 AM, buko  wrote:

>
>
> We’d like to start with a JAXB object (Document) and then serialize and
> sign it into a new JAXB object (SignedDocument). Then we’d like to embed
> the SignedDocument into another object (Message) and sign that to produce a
> new JAXB object (SignedMessage).
>
>
>
> We can create the secure XMLStreamWriter easily enough and sign the
> document easily enough but it’s not clear how we actually read the
> generated signature back using JAXB.
>
>
>
> What’s interesting is Santuario appears to contain JAXB bindings for the
> XML Signature Schema in https://github.com/apache/
> santuario-java/tree/trunk/src/main/java/org/apache/xml/
> security/binding/xmldsig. But there’s no binding for the ‘Signature’
> element.
>
>
>
> Any ideas here? Is this possible? Is there a test that shows how to use
> the JAXB bindings?
>
>
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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

[Colm O hEigeartaigh]

I updated the website manually - the automatic build is a bit flaky.

Colm.

On Wed, Jun 27, 2018 at 5:36 PM, Cantor, Scott  wrote:

> 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
>
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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

[Colm O hEigeartaigh]

On Fri, Jun 22, 2018 at 5:17 PM, Cantor, Scott  wrote:

>
> 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 supported ones is fairly narrow, but I'll do what I can. It isn't a
> general bug on at least RH5+, SUSE 11+, Debian, Mac, and Windows.
>

Ubuntu 18.04 bionic.
g++ (Ubuntu 7.3.0-16ubuntu3) 7.3.0
GNU Make 4.1

It's not a big deal though if it works on other platforms. If you want I
can create a JIRA for it?


>
> > * Could you create an official SVN Tag for the release as well?
>
> Not until it's released. I believe it is wrong to ever touch a tag after
> it's produced, so by definition I can't tag something that hasn't been
> released. The tag would be a copy of the noted revision, pending me making
> the change to the change log or fixing something else.
>

It's more normal at Apache to create a tag and call a vote referencing the
tag. That way no changes are allowed afterwards to the artifacts we are
voting on. But it's fine here so long as you do it after.


>
> > * The CHANGELOG is not updated for 2.0.0.
>
> I thought I had gutted that to not contain anything needing update but
> I'll correct if not. I don't want to have to touch files like that when new
> versions come out.
>

Yes my mistake, I missed the first sentence in it.

Colm.


>
> -- Scott
>
>
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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

[Colm O hEigeartaigh]

Hi Scott,

When trying to build the source distribution with "make" I get an error:

g++ -DHAVE_CONFIG_H   -I.. -I.. -DXSEC_BUILDING_TOOLS -Wall  -O2
-DNDEBUG -pthread -MT tools/templatesign/xsec_templatesign-templatesign.o
-MD -MP -MF tools/templatesign/.deps/xsec_templatesign-templatesign.Tpo -c
-o tools/templatesign/xsec_templatesign-templatesign.o `test -f
'tools/templatesign/templatesign.cpp' || echo
'./'`tools/templatesign/templatesign.cpp
tools/templatesign/templatesign.cpp: In function ‘int main(int, char**)’:
tools/templatesign/templatesign.cpp:786:13: error: ‘hmacKey’ was not
declared in this scope
 hmacKey->setKey((unsigned char *) argv[paramCount + 1],
(unsigned int) strlen(argv[paramCount + 1]));
 ^~~

A few other points (none of them blocking):

 * Could you create an official SVN Tag for the release as well?
 * Also don't forget to include digests
 * The CHANGELOG is not updated for 2.0.0.

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

On Wed, Jun 20, 2018 at 5:54 PM, Cantor, Scott  wrote:

> I'd like to ask for a vote to release RC3, posted at [1], as the final
> release of V2.0.0 of the C++ Santuario library. It was built from svn
> revision 1833740 of the trunk.
>
> There are no features removed from this release, though some APIs have
> been removed to hide unrelated details and to eliminate a lot of
> enumerations in the library and replace them with the full
> XML-Signature/Encryption standard URIs for better extensibility.
> Applications using the older version will require generally minor changes
> to use this version. The old version will not be maintained by me beyond
> the end of 2018 at the latest, and likely sooner, it depends on my
> project's timelines.
>
> This release formally deprecates the XKMS support and the NSS and WinCAPI
> security library support pending the appearance of a maintainer for those
> sections of code (and the XKMS support can now be compiled out as an
> option). I would note that both the NSS and WinCAPI support are lacking in
> capability, in some cases not offering any "considered-secure" algorithms
> for particular functions, so this is more of a mercy killing than an act of
> hostile intent.
>
> This is my +1.
>
> -- Scott
>
> [1] https://dist.apache.org/repos/dist/dev/santuario/c-library/
>
>
>

[VOTE] - Release Apache Santuario - XML Security for Java 2.1.2 (take III)

[Colm O hEigeartaigh]

This is a vote (take III) to release Apache Santuario - XML Security for
Java 2.1.2.

Issues fixed:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12342674

SVN tag:

http://svn.apache.org/viewvc/santuario/xml-security-java/tags/xmlsec-2.1.2/

Artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-1022/

+1 from me.

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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

[Colm O hEigeartaigh]

This vote is cancelled due to the issues raised by Scott.

Colm.

On Fri, Jun 8, 2018 at 2:45 PM, Cantor, Scott  wrote:

> 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: [VOTE] - Release Apache Santuario - XML Security for Java
> 2.0.11
> > (take II)
> >
> > > This is a vote to release Apache Santuario - XML Security for Java
> 2.0.11.
> >
> > +1
>
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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

[Colm O hEigeartaigh]

This is a vote to release Apache Santuario - XML Security for Java 2.0.11.

Issues fixed:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12342673

SVN tag:

https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-2.0.11/

Artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-1021/

+1 from me.

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

[VOTE] - Release Apache Santuario - XML Security for Java 2.1.2 (take II)

[Colm O hEigeartaigh]

This is a vote (take II) to release Apache Santuario - XML Security for
Java 2.1.2.

Issues fixed:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12342674

SVN tag:

http://svn.apache.org/viewvc/santuario/xml-security-java/tags/xmlsec-2.1.2/

Artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-1020/

+1 from me.

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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

[Colm O hEigeartaigh]

Sean has pointed out a minor issue, so I will fix this and call another
vote tomorrow.

Colm.

On Mon, Jun 4, 2018 at 3:25 PM, Alessio Soldano  wrote:

> +1
>
> On Mon, Jun 4, 2018 at 3:54 PM, Cantor, Scott  wrote:
>
>> > This is a vote to release Apache Santuario - XML Security for Java
>> 2.0.11.
>>
>> +1
>>
>> -- Scott
>>
>>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com