[ANNOUNCEMENT] Commons Daemon 1.4.0 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Daemon 1.4.0

The Apache Commons Daemon software library provides a generic Daemon
(unix) or Service (Windows) wrapper for Java code.

Version 1.4.0 raises the minimum supported version of Java to Java 8 and 
Windows to Windows 10 / Windows Server 2012. Version 1.4.0 also 
addresses a number of bugs.


A full list of changes can be found at
https://commons.apache.org/proper/commons-daemon/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-daemon/download_daemon.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Daemon, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Daemon website:

https://commons.apache.org/proper/commons-daemon/

Mark
on behalf of the Apache Commons community

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE][RESULT] Release Apache Commons Daemon 1.4.0 based on RC1

[Mark Thomas]

All,

My apologies for the delay in closing this vote. I missed some of the 
the votes so I didn't realize there were sufficient votes for this to pass.


The following votes were cast:

Binding:
+1: ggregory, markt, chtompki

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


On 17/05/2024 19:05, Mark Thomas wrote:
We have fixed a few bugs, added enhancements and updated the minimum 
Java and Windows version since Apache Commons Daemon 1.3.4 was released, 
so I would like to release Apache Commons Daemon 1.4.0.


Apache Commons Daemon 1.4.0 RC1 is available for review here:
     https://dist.apache.org/repos/dist/dev/commons/daemon/1.4.0-RC1 
(svn revision 69267)


The Git tag commons-daemon-1.4.0-RC1 commit for this RC is 
6b911598b815a4a7b8ab2b8a8a2157593effc6bc which you can browse here:


https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=6b911598b815a4a7b8ab2b8a8a2157593effc6bc
You may checkout this tag using:
     git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.4.0-RC1 commons-daemon-1.4.0-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1729/commons-daemon/commons-daemon/1.4.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Fri May 17 16:28:36 BST 2024
commons-daemon-1.4.0-bin-windows.zip=5974d638994cbf821c17d0fc6b69bace08b0314ea5614c1a57175a02cda7c57a6b8ee49f8892206061f9d3385da5841db31d9ce9b3ce74cf4afc10ad8e68
commons-daemon-1.4.0-bin.tar.gz=15fccd35a711f91e5b4466d56f50585c7ae3a787a39c16e006617c86b9e9feee9fbf902582b08c2e896ca6a655500d805fdbb9c97f04f70321631168b8d42c81
commons-daemon-1.4.0-bin.zip=3652ed9ed9cf6fcb0d4b5067570c322b0b3c9ae0a81dee1d7b0992bb7ff5654a7c4dc89c0c2d966c9962778288c6ad60bd8ac10f62898c9e10261bec6e61d3ea
commons-daemon-1.4.0-bom.json=0de219d72a63d8154f42ef5bd6c348936e14d65efec3e54a55ebfb9bc757e4ceac7aabd8c8b85d94657ed76f44069ac56b2bb231aba5419733f00a3dc85f6601
commons-daemon-1.4.0-bom.xml=bc0dba27a50ca6c5d30015f97bd258325452e6fabefd1cf38b94d0ce5699233a18b456fd701761a5f8cedf847cbd152879e0dec9add548611d5593b910c90244
commons-daemon-1.4.0-javadoc.jar=8fd299a3d228c4ab4ea8455b81319d80b3e27cac1c31bed1e03cc7a3391d59f18e037adcb72e68202511a45ef5bc49274d6e9cf38c860b55bb9b874a92044d2e
commons-daemon-1.4.0-native-src.tar.gz=8a54200d547ef7ee647e8d4910fd3cb55bf7d8fc75de8f0e01bc701ef0b386ddc3843e6c9189e34d2afd62060fb6299ea83c421cf60c7d105d04cb45904500d3
commons-daemon-1.4.0-native-src.zip=cb6b12bbd775eba7d012744cf908f42fc6d39e421c1f41546f230b431c1d239cc3e2d9c09520165b5db7a95701b651a6738a5d1915d39a4520b1ff07ce4f65a5
commons-daemon-1.4.0-sources.jar=701b3646ea29de5ea69d72c8741a2dc56a44a57168c0e7d1afab87f89d9cab75c413f1fe3d09f5765e4dbe2b2af0951125ee0f6a0a4d5b4fafcf49bfd0b03cbf
commons-daemon-1.4.0-src.tar.gz=285f33ce36e2591f49b6067da16612ec1b49b23a8637d077618aefaae4452993dc2a31660665551ea761857390d940100e162e205fe7c0fad9c72374f2d15bb8
commons-daemon-1.4.0-src.zip=190d6b8b65d71594ff02bade3fbcd6b09d5b2e68413a2a23ef2cbf945d2e19655c1d480484ec198f7e140eaa3744c970770cea17498c12f9bfe284f5bd28a51d
commons-daemon-1.4.0-test-sources.jar=e889d8b5bda1e0a89d33741e9308739b732e938ef13b552acf7dc0ba52845766e6a49f3fbb6c821655d295e18b9accbfeac1c26b8afacc088084511cea301bcd
commons-daemon-1.4.0-tests.jar=b392bdaa59e3d75e7aa023f65514385edfc44bc1bc088826b643186bfeaf47215375a814af3637e585bde201dd6ee5ef3669f2b4a3cf2e275da4fc6ccd91dfda
commons-daemon_commons-daemon-1.4.0.spdx.json=47c669c16aca4588d4940a4dcec162a619587f8fc8d6a74a5abbe8562296f0eb08f271db531e678a939355a9b7f669cb9ade864d953c77402b60e8c183f1faed



Details of changes since 1.3.4 are in the change log:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.4.0-RC1/RELEASE-NOTES.txt

https://github.com/apache/commons-daemon/blob/master/src/changes/changes.xml

KEYS:
   https://downloads.apache.org/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1a) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.4.0-RC1 commons-daemon-1.4.0-RC1

cd commons-daemon-1.4.0-RC1

1b) Download and unpack the source archive from:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.4.0-RC1/source

2) Check Apache licenses

This step is not required if the site includes a RAT report page which 
you then must check.


mvn apache-rat:check

3) Check binary compatibility

Re: [VOTE] Release Apache Commons Daemon 1.4.0 based on RC1

[Mark Thomas]

On 17/05/2024 19:05, Mark Thomas wrote:


   [X] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...


Signatures confirmed for Windows binaries.
Tested successfully with Tomcat 11.0.x build.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.4.0 based on RC1

[Mark Thomas]

Hi Gary,

Looks like I missed adding them before I committed the changes. I've 
just done that.


Mark


On 18/05/2024 15:28, Gary Gregory wrote:

Hi Mark,

Thank you for preparing this release candidate.

There are no SHA512 files in:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.4.0-RC1/source/
https://dist.apache.org/repos/dist/dev/commons/daemon/1.4.0-RC1/binaries/

Gary

On Fri, May 17, 2024 at 2:06 PM Mark Thomas  wrote:


We have fixed a few bugs, added enhancements and updated the minimum
Java and Windows version since Apache Commons Daemon 1.3.4 was released,
so I would like to release Apache Commons Daemon 1.4.0.

Apache Commons Daemon 1.4.0 RC1 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/daemon/1.4.0-RC1
(svn revision 69267)

The Git tag commons-daemon-1.4.0-RC1 commit for this RC is
6b911598b815a4a7b8ab2b8a8a2157593effc6bc which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=6b911598b815a4a7b8ab2b8a8a2157593effc6bc
You may checkout this tag using:
  git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
--branch commons-daemon-1.4.0-RC1 commons-daemon-1.4.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1729/commons-daemon/commons-daemon/1.4.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Fri May 17 16:28:36 BST 2024
commons-daemon-1.4.0-bin-windows.zip=5974d638994cbf821c17d0fc6b69bace08b0314ea5614c1a57175a02cda7c57a6b8ee49f8892206061f9d3385da5841db31d9ce9b3ce74cf4afc10ad8e68
commons-daemon-1.4.0-bin.tar.gz=15fccd35a711f91e5b4466d56f50585c7ae3a787a39c16e006617c86b9e9feee9fbf902582b08c2e896ca6a655500d805fdbb9c97f04f70321631168b8d42c81
commons-daemon-1.4.0-bin.zip=3652ed9ed9cf6fcb0d4b5067570c322b0b3c9ae0a81dee1d7b0992bb7ff5654a7c4dc89c0c2d966c9962778288c6ad60bd8ac10f62898c9e10261bec6e61d3ea
commons-daemon-1.4.0-bom.json=0de219d72a63d8154f42ef5bd6c348936e14d65efec3e54a55ebfb9bc757e4ceac7aabd8c8b85d94657ed76f44069ac56b2bb231aba5419733f00a3dc85f6601
commons-daemon-1.4.0-bom.xml=bc0dba27a50ca6c5d30015f97bd258325452e6fabefd1cf38b94d0ce5699233a18b456fd701761a5f8cedf847cbd152879e0dec9add548611d5593b910c90244
commons-daemon-1.4.0-javadoc.jar=8fd299a3d228c4ab4ea8455b81319d80b3e27cac1c31bed1e03cc7a3391d59f18e037adcb72e68202511a45ef5bc49274d6e9cf38c860b55bb9b874a92044d2e
commons-daemon-1.4.0-native-src.tar.gz=8a54200d547ef7ee647e8d4910fd3cb55bf7d8fc75de8f0e01bc701ef0b386ddc3843e6c9189e34d2afd62060fb6299ea83c421cf60c7d105d04cb45904500d3
commons-daemon-1.4.0-native-src.zip=cb6b12bbd775eba7d012744cf908f42fc6d39e421c1f41546f230b431c1d239cc3e2d9c09520165b5db7a95701b651a6738a5d1915d39a4520b1ff07ce4f65a5
commons-daemon-1.4.0-sources.jar=701b3646ea29de5ea69d72c8741a2dc56a44a57168c0e7d1afab87f89d9cab75c413f1fe3d09f5765e4dbe2b2af0951125ee0f6a0a4d5b4fafcf49bfd0b03cbf
commons-daemon-1.4.0-src.tar.gz=285f33ce36e2591f49b6067da16612ec1b49b23a8637d077618aefaae4452993dc2a31660665551ea761857390d940100e162e205fe7c0fad9c72374f2d15bb8
commons-daemon-1.4.0-src.zip=190d6b8b65d71594ff02bade3fbcd6b09d5b2e68413a2a23ef2cbf945d2e19655c1d480484ec198f7e140eaa3744c970770cea17498c12f9bfe284f5bd28a51d
commons-daemon-1.4.0-test-sources.jar=e889d8b5bda1e0a89d33741e9308739b732e938ef13b552acf7dc0ba52845766e6a49f3fbb6c821655d295e18b9accbfeac1c26b8afacc088084511cea301bcd
commons-daemon-1.4.0-tests.jar=b392bdaa59e3d75e7aa023f65514385edfc44bc1bc088826b643186bfeaf47215375a814af3637e585bde201dd6ee5ef3669f2b4a3cf2e275da4fc6ccd91dfda
commons-daemon_commons-daemon-1.4.0.spdx.json=47c669c16aca4588d4940a4dcec162a619587f8fc8d6a74a5abbe8562296f0eb08f271db531e678a939355a9b7f669cb9ade864d953c77402b60e8c183f1faed



Details of changes since 1.3.4 are in the change log:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.4.0-RC1/RELEASE-NOTES.txt

https://github.com/apache/commons-daemon/blob/master/src/changes/changes.xml

KEYS:
https://downloads.apache.org/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1a) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
--branch commons-daemon-1.4.0-RC1 commons-daemon-1.4.0-RC1
cd commons-daemon-1.4.0-RC1

1b) Download and unpack the source archive from:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.4.0-RC1/source

2) Check Apache licenses

This step is not required if the site includes a RAT report page which
you then must check

[VOTE] Release Apache Commons Daemon 1.4.0 based on RC1

[Mark Thomas]

We have fixed a few bugs, added enhancements and updated the minimum 
Java and Windows version since Apache Commons Daemon 1.3.4 was released, 
so I would like to release Apache Commons Daemon 1.4.0.


Apache Commons Daemon 1.4.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/daemon/1.4.0-RC1 
(svn revision 69267)


The Git tag commons-daemon-1.4.0-RC1 commit for this RC is 
6b911598b815a4a7b8ab2b8a8a2157593effc6bc which you can browse here:


https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=6b911598b815a4a7b8ab2b8a8a2157593effc6bc
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.4.0-RC1 commons-daemon-1.4.0-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1729/commons-daemon/commons-daemon/1.4.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Fri May 17 16:28:36 BST 2024
commons-daemon-1.4.0-bin-windows.zip=5974d638994cbf821c17d0fc6b69bace08b0314ea5614c1a57175a02cda7c57a6b8ee49f8892206061f9d3385da5841db31d9ce9b3ce74cf4afc10ad8e68
commons-daemon-1.4.0-bin.tar.gz=15fccd35a711f91e5b4466d56f50585c7ae3a787a39c16e006617c86b9e9feee9fbf902582b08c2e896ca6a655500d805fdbb9c97f04f70321631168b8d42c81
commons-daemon-1.4.0-bin.zip=3652ed9ed9cf6fcb0d4b5067570c322b0b3c9ae0a81dee1d7b0992bb7ff5654a7c4dc89c0c2d966c9962778288c6ad60bd8ac10f62898c9e10261bec6e61d3ea
commons-daemon-1.4.0-bom.json=0de219d72a63d8154f42ef5bd6c348936e14d65efec3e54a55ebfb9bc757e4ceac7aabd8c8b85d94657ed76f44069ac56b2bb231aba5419733f00a3dc85f6601
commons-daemon-1.4.0-bom.xml=bc0dba27a50ca6c5d30015f97bd258325452e6fabefd1cf38b94d0ce5699233a18b456fd701761a5f8cedf847cbd152879e0dec9add548611d5593b910c90244
commons-daemon-1.4.0-javadoc.jar=8fd299a3d228c4ab4ea8455b81319d80b3e27cac1c31bed1e03cc7a3391d59f18e037adcb72e68202511a45ef5bc49274d6e9cf38c860b55bb9b874a92044d2e
commons-daemon-1.4.0-native-src.tar.gz=8a54200d547ef7ee647e8d4910fd3cb55bf7d8fc75de8f0e01bc701ef0b386ddc3843e6c9189e34d2afd62060fb6299ea83c421cf60c7d105d04cb45904500d3
commons-daemon-1.4.0-native-src.zip=cb6b12bbd775eba7d012744cf908f42fc6d39e421c1f41546f230b431c1d239cc3e2d9c09520165b5db7a95701b651a6738a5d1915d39a4520b1ff07ce4f65a5
commons-daemon-1.4.0-sources.jar=701b3646ea29de5ea69d72c8741a2dc56a44a57168c0e7d1afab87f89d9cab75c413f1fe3d09f5765e4dbe2b2af0951125ee0f6a0a4d5b4fafcf49bfd0b03cbf
commons-daemon-1.4.0-src.tar.gz=285f33ce36e2591f49b6067da16612ec1b49b23a8637d077618aefaae4452993dc2a31660665551ea761857390d940100e162e205fe7c0fad9c72374f2d15bb8
commons-daemon-1.4.0-src.zip=190d6b8b65d71594ff02bade3fbcd6b09d5b2e68413a2a23ef2cbf945d2e19655c1d480484ec198f7e140eaa3744c970770cea17498c12f9bfe284f5bd28a51d
commons-daemon-1.4.0-test-sources.jar=e889d8b5bda1e0a89d33741e9308739b732e938ef13b552acf7dc0ba52845766e6a49f3fbb6c821655d295e18b9accbfeac1c26b8afacc088084511cea301bcd
commons-daemon-1.4.0-tests.jar=b392bdaa59e3d75e7aa023f65514385edfc44bc1bc088826b643186bfeaf47215375a814af3637e585bde201dd6ee5ef3669f2b4a3cf2e275da4fc6ccd91dfda
commons-daemon_commons-daemon-1.4.0.spdx.json=47c669c16aca4588d4940a4dcec162a619587f8fc8d6a74a5abbe8562296f0eb08f271db531e678a939355a9b7f669cb9ade864d953c77402b60e8c183f1faed



Details of changes since 1.3.4 are in the change log:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.4.0-RC1/RELEASE-NOTES.txt

https://github.com/apache/commons-daemon/blob/master/src/changes/changes.xml

KEYS:
  https://downloads.apache.org/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1a) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.4.0-RC1 commons-daemon-1.4.0-RC1

cd commons-daemon-1.4.0-RC1

1b) Download and unpack the source archive from:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.4.0-RC1/source

2) Check Apache licenses

This step is not required if the site includes a RAT report page which 
you then must check.


mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page which 
you then must check.


mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page 
which you then must check.


mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V

Re: [Daemon] Anything to appease "Wrong type of arguments to formatting function"

[Mark Thomas]

Set them as false positives or just ignore them.

Mark


On 17/05/2024 15:09, Gary Gregory wrote:

Mark and all:

Is there anything smile to do to appease the warnings "Wrong type of
arguments to formatting function" in see
https://github.com/apache/commons-daemon/security/code-scanning ?

TY
Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Meta] gitlab error responses to mailing list

[Mark Thomas]

Got them.

The idiot concerned has won themselves a lifetime subscription to the 
deny list for commons-dev and the handful of other ASF lists they are 
subscribed to.


Sorry it took a while to sort this out.

Some of you won't yet have received the test message yet due to my mail 
server being rate limited. You should received it in the next few hours.


Mark


On 10/08/2023 09:48, Mark Thomas wrote:

Hi all,

In an effort to trace the idiot that set up whatever process is 
triggering these messages directly to anyone who posts to the dev list I 
will be sending out some test messages later today. Each subscriber to 
this list should only receive one test message. Apologies in advance for 
the noise.


Mark


On 07/08/2023 15:40, Gilles Sadowski wrote:
Le lun. 7 août 2023 à 16:38, Gilles Sadowski  a 
écrit :


Le lun. 7 août 2023 à 10:46, Mark Thomas  a écrit :


Got the error message. To help me play hunt the subscriber, can anyone
provide information on when this behaviour started?


I got one on Saturday at 11:17, in a thread with
    [commons-math] Three Concerns
as subject line.  Content was:
---CUT---
Unfortunately, your email message to GitLab could not be processed.

We couldn't figure out what the email is for. Please create your issue
or comment through the web interface.
---CUT---


And again, just now, in reply to the above message...



Regards,
Gilles


[...]


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Meta] gitlab error responses to mailing list

[Mark Thomas]

Hi all,

In an effort to trace the idiot that set up whatever process is 
triggering these messages directly to anyone who posts to the dev list I 
will be sending out some test messages later today. Each subscriber to 
this list should only receive one test message. Apologies in advance for 
the noise.


Mark


On 07/08/2023 15:40, Gilles Sadowski wrote:

Le lun. 7 août 2023 à 16:38, Gilles Sadowski  a écrit :


Le lun. 7 août 2023 à 10:46, Mark Thomas  a écrit :


Got the error message. To help me play hunt the subscriber, can anyone
provide information on when this behaviour started?


I got one on Saturday at 11:17, in a thread with
[commons-math] Three Concerns
as subject line.  Content was:
---CUT---
Unfortunately, your email message to GitLab could not be processed.

We couldn't figure out what the email is for. Please create your issue
or comment through the web interface.
---CUT---


And again, just now, in reply to the above message...



Regards,
Gilles


[...]


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Codec] clearing input byte array vs not

[Mark Thomas]

Reject it. And document the existing behavior.

Mark


On 09/08/2023 19:52, Gary Gregory wrote:

Hi all,

Any thoughts on https://github.com/apache/commons-codec/pull/197

Gary



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Meta] gitlab error responses to mailing list

[Mark Thomas]

Got the error message. To help me play hunt the subscriber, can anyone 
provide information on when this behaviour started?


Thanks,

Mark


On 07/08/2023 09:44, Mark Thomas wrote:

".invalid" is something that the ASF adds to addresses.

See https://infra.apache.org/blog/dmarc_filtering_on_lists_that.html

Hopefully I'll get a similar error message from gitlab in response to 
this. I'll see if I can track down which mailing list subscriber is 
triggering it.


Mark

On 06/08/2023 15:05, Gary Gregory wrote:
Ah, right, you're post here... I'm guessing that address is no longer 
valid

or is one of those ".invalid" addresses services like Proton Mail uses...

Gary

On Sun, Aug 6, 2023, 10:04 AM Gary Gregory  
wrote:



I commons dev mailing list gets those.

Gary

On Sun, Aug 6, 2023, 9:29 AM Daniel Watson  wrote:

Does anyone else get gitlab error messages in response to emails 
sent to

this list (coming from supp...@cons3rt.com) ? The messages have no
information as to the cause or resolution. Can't find any documentation
about it on mailing list page.







-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Meta] gitlab error responses to mailing list

[Mark Thomas]

".invalid" is something that the ASF adds to addresses.

See https://infra.apache.org/blog/dmarc_filtering_on_lists_that.html

Hopefully I'll get a similar error message from gitlab in response to 
this. I'll see if I can track down which mailing list subscriber is 
triggering it.


Mark

On 06/08/2023 15:05, Gary Gregory wrote:

Ah, right, you're post here... I'm guessing that address is no longer valid
or is one of those ".invalid" addresses services like Proton Mail uses...

Gary

On Sun, Aug 6, 2023, 10:04 AM Gary Gregory  wrote:


I commons dev mailing list gets those.

Gary

On Sun, Aug 6, 2023, 9:29 AM Daniel Watson  wrote:


Does anyone else get gitlab error messages in response to emails sent to
this list (coming from supp...@cons3rt.com) ? The messages have no
information as to the cause or resolution. Can't find any documentation
about it on mailing list page.







-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [FileUpload] Major version 2

[Mark Thomas]

On 21/07/2023 16:18, Gary Gregory wrote:

Now that 2.0.0-M1 is out the door, let's talk about Java platform requirements.

I propose that for 2.0.0, FileUpload be bumped from Java 8 to 11, if not 17.


+1 for Java 17

Mark




If you are going to ask why, see my reply in the [pool] thread
(https://lists.apache.org/thread/ngyrssxndklltzkoqfqx4n780h4b5vwk)

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1

[Mark Thomas]

On 28/06/2023 14:16, Gary Gregory wrote:

Hi All and Phil.


I haven't been that involved in Pool recently but Pool remains a key 
dependency for Tomcat (via DBCP).



The main driver here was two combine keeping binary compatibility
_and_ benefit call sites of the API by _not_ having to catch Exception
or throw Exception, which clearly is an anti-pattern. Instead, call
sites should deal with domain exceptions, which they can in turn
handle. IOW, when I am using IO resources or JDBC resources, I should
expect to handle IOException and JDBCException, not Exception, so by
extension (more on this below), I would expect to handle the same
kinds of exceptions when I am pooling those kinds of resources.


I understand the aim and I am generally in favour of simplification.

However, Pool still throws unchecked exceptions (NoSuchElementException 
and IllegalStateException, possibly others) during normal operations and 
I think that significantly undermines what this change is trying to achieve.





Question: If we were to design Pool from scratch today, would we
create APIs with checked or unchecked exceptions?


For Pool I have a slight preference for using checked exceptions 
throughout but I agree that is a larger design change that needs a wider 
discussion.





I did not get the points Phil is trying to make in his examples, I'm
not sure they are valid. OTOH, the unit tests do show using the APIs
typed with different types of exceptions. Sure, there might be
adjustments to make, but I don't see the flaws you seem to think are
there. WRT to source changes, I welcome cleaning up my call sites! The
debate is valid and I hope we have interesting replies to this thread.


My main concern is not whether Pool should make this change (I think the 
change makes sense) but when Pool should make this change and alongside 
what other changes.


At this point I'm not convinced the cost / benefit of the change in a 
minor release stacks up.


I suspect very few users are simply going to replace the old JAR with 
the new one and take advantage of binary compatibility. They are going 
to update their build dependencies and then compilation is going to 
fail. I don't think users will appreciate that in a minor release 
however much we tell them they are binary compatible.


To fix the compilation issues and retain existing behaviour (without 
worrying about the unchecked exceptions the Pool does throw during 
normal operations) they are going to have to modify their code so that E 
== Exception. That is going to look like a make-work task as they will 
get zero benefit from it.


I think the majority of the benefit of this changes comes if Pool also 
stops throwing unchecked exceptions - as a minimum during normal pooling 
operations.


I'd prefer to see this change deferred to a Pool 3.0 release preceded by 
a wider discussion of the benefits of unchecked vs checked that has 
started in this thread.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Project

[Mark Thomas]

Harvey,

Where did you find the task below? It looks like data from the old "help 
wanted" system and I thought that had been disabled some time ago.


The task was created ~7 years ago so is somewhat out of date. Commons 
Daemon has since moved to git


https://github.com/apache/commons-daemon/

and the build process has been documented in

https://github.com/apache/commons-daemon/blob/master/HOWTO-RELEASE.txt
and
https://github.com/apache/commons-daemon/blob/master/src/native/windows/README.txt

That said, I am sure there is room for improvement. If this is still a 
task that interests you then I suggest you try using the instructions to 
build the Windows binaries yourself, ask any questions where things are 
unclear and then submit one or more PRs to improve the existing 
instructions.


Keep in mind that the release builds use a specific build process to 
ensure the resulting binaries will run on a clean install any current 
Windows OS without any additional libraries.


Mark


On 09/06/2023 02:56, Harvey Pullen Jr. wrote:

*Hi,*

*I would like to complete the task below.  I am sending this email as
instructed below.*



*Project: *commons
*Created by:* ma...@apache.org
*Task added: *Thu Aug 18 2016
*Difficulty: * Beginner - This is an easy task that anyone can get started
on
*Task type:* Programming and Development

The build process for the Commons Daemon Windows binary is currently
undocumented. It is believed to be similar to the Tomcat Native build
process documented here:
https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+Tomcat+Native+Connector+binaries+for+Windows

This task is to create an equivalent set of instructions for building the
Commons Daemon Windows binary.

The deliverable is a patch to this file:
http://svn.apache.org/viewvc/commons/proper/daemon/trunk/HOWTO-RELEASE.txt

to provide detailed step-by-step instructions for the Windows binary build

How to help:

If you want to help with this task, please get in touch with the project
at: dev@commons.apache.org

!
You should also check out the additional information URL (if such is
provided above) for more information.


Best,
Harvey



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[ANNOUNCEMENT] Commons Daemon 1.3.4 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Daemon 1.3.4.

The Apache Commons Daemon software library provides a generic Daemon
(unix) or Service (Windows) wrapper for Java code.

Version 1.3.4 is a bugfix release.

A full list of changes can be found at
https://commons.apache.org/proper/commons-daemon/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-daemon/download_daemon.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Daemon, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Daemon website:

https://commons.apache.org/proper/commons-daemon/

Mark
on behalf of the Apache Commons community

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE][RESULT] Release Apache Commons Daemon 1.3.4 based on RC1

[Mark Thomas]

The following votes were cast:

Binding:
+1: ggregory, markt, kinow

No other votes were cast. The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.3.4 based on RC1

[Mark Thomas]

On 05/05/2023 11:27, Mark Thomas wrote:

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

   [X] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.3.4 based on RC1

[Mark Thomas]

On 06/05/2023 16:15, Gary D. Gregory wrote:

FYI I seem to be building fine for me using "Microsoft (R) C/C++ Optimizing Compiler 
Version 19.35.32217.1 for x64" but maybe there is a gotcha I am missing?


See the "Release Builds" section of the README.txt file in 
src/native/windows


Mark




Gary

On 2023/05/06 15:12:56 "Gary D. Gregory" wrote:

Note a blocker but I imagine not true for this release: In the README.txt for 
the Windows native apps:

"Release builds are build with Mladen Turk's (mturk) Custom Microsoft Compiler
Toolkit Compilation. This can be obtained from:
https://github.com/mturk/cmsc
Version: 15.0.44"

Is this true for this release?

Gary


On 2023/05/05 10:27:23 Mark Thomas wrote:

We have fixed a few bugs since Apache Commons Daemon 1.3.3 was released,
so I would like to release Apache Commons Daemon 1.3.4.

Apache Commons Daemon 1.3.4 RC1 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.4-RC1
(svn revision 61662)

The Git tag commons-daemon-1.3.4-RC1 commit for this RC is
f7c21ce501eee288c488edd416f0ddccdd365966 which you can browse here:

https://github.com/apache/commons-daemon/commit/f7c21ce501eee288c488edd416f0ddccdd365966

(gitbox browsing is currently disabled)

You may checkout this tag using:
  git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
--branch commons-daemon-1.3.4-RC1 commons-daemon-1.3.4-RC1

Maven artifacts are here:
  
https://repository.apache.org/content/repositories/orgapachecommons-1634/commons-daemon/commons-daemon/1.3.4/


These are the artifacts and their hashes:

commons-daemon-1.3.4.jar=31e723efc879fb1a45001bcb1577c02defe38b0a7e02fc4efd2800f85a4dbe583eba2e67323145aa5c2c5cf9dd09c457961557898a9923e85b0375c73c639498
commons-daemon-1.3.4-bin.tar.gz=adc301fe9c7e50c5ed71c6775c8c41c33a369a05c30785ccb81209089603ae66563e958b466c99fc5cd27c12625bb7def68d7d91933aa8739eb645af37f3d03e
commons-daemon-1.3.4-bin.zip=857da3217d9186b034ffecf36b8d0df84b3b4de8b06a81338df97dbabafeff9b84034d49173623f5b03786d48d85d406af8e602ea644c95552f2df68f98d5ddc
commons-daemon-1.3.4-bin-windows.zip=57a59d402dd0a1c99ed5da062b4616d54679e4208abec8b25742f5bf3ec1ee6b5187bc830edeaa218766215371b5519ce0a7186325c929c86b567a3078aa7555
commons-daemon-1.3.4-native-src.tar.gz=3c10ca72fc0eb7f755c0b5452bb6d5e8b42d8f363767ffcd9a6f0883026e688ea7dff50ea05e2675a7cdf9f413cb8012ee6b79e16dfc1cd4d83bd775ea10216c
commons-daemon-1.3.4-native-src.zip=2e2db21b142b40427c43f4802ec94fb6212d1c79cb6aa02325b71017e20384a8d6123148603eda03f309aeae5a6f88f9a014deb978af0fac2f62b576d73ae1b8
commons-daemon-1.3.4-src.tar.gz=bb36d88bc21a5777245012b2a73ee0e764b85715731f54cc4ff09343e95ccb18fc6c68b3ae9c680fb45a60c7ef5ed0f9e40991c2c03246dd7f8dd65031eddf24
commons-daemon-1.3.4-src.zip=2f77720724069655828cecb639a3c9a8411e97ed4c9923340f521cf7078ce85e5d223f20431040411a592b4d38208144ffc56da8b70091f75028a1aad9c51891


KEYS:
https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.3.4 based on RC1

[Mark Thomas]

On 06/05/2023 16:12, Gary D. Gregory wrote:

Note a blocker but I imagine not true for this release: In the README.txt for 
the Windows native apps:

"Release builds are build with Mladen Turk's (mturk) Custom Microsoft Compiler
Toolkit Compilation. This can be obtained from:
https://github.com/mturk/cmsc
Version: 15.0.44"

Is this true for this release?


Yes.

Mark




Gary


On 2023/05/05 10:27:23 Mark Thomas wrote:

We have fixed a few bugs since Apache Commons Daemon 1.3.3 was released,
so I would like to release Apache Commons Daemon 1.3.4.

Apache Commons Daemon 1.3.4 RC1 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.4-RC1
(svn revision 61662)

The Git tag commons-daemon-1.3.4-RC1 commit for this RC is
f7c21ce501eee288c488edd416f0ddccdd365966 which you can browse here:

https://github.com/apache/commons-daemon/commit/f7c21ce501eee288c488edd416f0ddccdd365966

(gitbox browsing is currently disabled)

You may checkout this tag using:
  git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
--branch commons-daemon-1.3.4-RC1 commons-daemon-1.3.4-RC1

Maven artifacts are here:
  
https://repository.apache.org/content/repositories/orgapachecommons-1634/commons-daemon/commons-daemon/1.3.4/


These are the artifacts and their hashes:

commons-daemon-1.3.4.jar=31e723efc879fb1a45001bcb1577c02defe38b0a7e02fc4efd2800f85a4dbe583eba2e67323145aa5c2c5cf9dd09c457961557898a9923e85b0375c73c639498
commons-daemon-1.3.4-bin.tar.gz=adc301fe9c7e50c5ed71c6775c8c41c33a369a05c30785ccb81209089603ae66563e958b466c99fc5cd27c12625bb7def68d7d91933aa8739eb645af37f3d03e
commons-daemon-1.3.4-bin.zip=857da3217d9186b034ffecf36b8d0df84b3b4de8b06a81338df97dbabafeff9b84034d49173623f5b03786d48d85d406af8e602ea644c95552f2df68f98d5ddc
commons-daemon-1.3.4-bin-windows.zip=57a59d402dd0a1c99ed5da062b4616d54679e4208abec8b25742f5bf3ec1ee6b5187bc830edeaa218766215371b5519ce0a7186325c929c86b567a3078aa7555
commons-daemon-1.3.4-native-src.tar.gz=3c10ca72fc0eb7f755c0b5452bb6d5e8b42d8f363767ffcd9a6f0883026e688ea7dff50ea05e2675a7cdf9f413cb8012ee6b79e16dfc1cd4d83bd775ea10216c
commons-daemon-1.3.4-native-src.zip=2e2db21b142b40427c43f4802ec94fb6212d1c79cb6aa02325b71017e20384a8d6123148603eda03f309aeae5a6f88f9a014deb978af0fac2f62b576d73ae1b8
commons-daemon-1.3.4-src.tar.gz=bb36d88bc21a5777245012b2a73ee0e764b85715731f54cc4ff09343e95ccb18fc6c68b3ae9c680fb45a60c7ef5ed0f9e40991c2c03246dd7f8dd65031eddf24
commons-daemon-1.3.4-src.zip=2f77720724069655828cecb639a3c9a8411e97ed4c9923340f521cf7078ce85e5d223f20431040411a592b4d38208144ffc56da8b70091f75028a1aad9c51891


KEYS:
https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.3.4 based on RC1

[Mark Thomas]

On 05/05/2023 11:32, Gary Gregory wrote:

Empty the sense that I can't tell what's been fixed.


That is what the change log is for (which the release notes reference). 
Since the public site still shows 1.3.3, you'll want:


https://github.com/apache/commons-daemon/blob/master/src/changes/changes.xml#L43

Mark




Gary

On Fri, May 5, 2023, 06:31 Gary Gregory  wrote:


The release notes are empty.

Gary

On Fri, May 5, 2023, 06:27 Mark Thomas  wrote:


We have fixed a few bugs since Apache Commons Daemon 1.3.3 was released,
so I would like to release Apache Commons Daemon 1.3.4.

Apache Commons Daemon 1.3.4 RC1 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.4-RC1
(svn revision 61662)

The Git tag commons-daemon-1.3.4-RC1 commit for this RC is
f7c21ce501eee288c488edd416f0ddccdd365966 which you can browse here:


https://github.com/apache/commons-daemon/commit/f7c21ce501eee288c488edd416f0ddccdd365966

(gitbox browsing is currently disabled)

You may checkout this tag using:
  git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
--branch commons-daemon-1.3.4-RC1 commons-daemon-1.3.4-RC1

Maven artifacts are here:


https://repository.apache.org/content/repositories/orgapachecommons-1634/commons-daemon/commons-daemon/1.3.4/

These are the artifacts and their hashes:


commons-daemon-1.3.4.jar=31e723efc879fb1a45001bcb1577c02defe38b0a7e02fc4efd2800f85a4dbe583eba2e67323145aa5c2c5cf9dd09c457961557898a9923e85b0375c73c639498

commons-daemon-1.3.4-bin.tar.gz=adc301fe9c7e50c5ed71c6775c8c41c33a369a05c30785ccb81209089603ae66563e958b466c99fc5cd27c12625bb7def68d7d91933aa8739eb645af37f3d03e

commons-daemon-1.3.4-bin.zip=857da3217d9186b034ffecf36b8d0df84b3b4de8b06a81338df97dbabafeff9b84034d49173623f5b03786d48d85d406af8e602ea644c95552f2df68f98d5ddc

commons-daemon-1.3.4-bin-windows.zip=57a59d402dd0a1c99ed5da062b4616d54679e4208abec8b25742f5bf3ec1ee6b5187bc830edeaa218766215371b5519ce0a7186325c929c86b567a3078aa7555

commons-daemon-1.3.4-native-src.tar.gz=3c10ca72fc0eb7f755c0b5452bb6d5e8b42d8f363767ffcd9a6f0883026e688ea7dff50ea05e2675a7cdf9f413cb8012ee6b79e16dfc1cd4d83bd775ea10216c

commons-daemon-1.3.4-native-src.zip=2e2db21b142b40427c43f4802ec94fb6212d1c79cb6aa02325b71017e20384a8d6123148603eda03f309aeae5a6f88f9a014deb978af0fac2f62b576d73ae1b8

commons-daemon-1.3.4-src.tar.gz=bb36d88bc21a5777245012b2a73ee0e764b85715731f54cc4ff09343e95ccb18fc6c68b3ae9c680fb45a60c7ef5ed0f9e40991c2c03246dd7f8dd65031eddf24

commons-daemon-1.3.4-src.zip=2f77720724069655828cecb639a3c9a8411e97ed4c9923340f521cf7078ce85e5d223f20431040411a592b4d38208144ffc56da8b70091f75028a1aad9c51891


KEYS:
https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Apache Commons Daemon 1.3.4 based on RC1

[Mark Thomas]

We have fixed a few bugs since Apache Commons Daemon 1.3.3 was released, 
so I would like to release Apache Commons Daemon 1.3.4.


Apache Commons Daemon 1.3.4 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.4-RC1 
(svn revision 61662)


The Git tag commons-daemon-1.3.4-RC1 commit for this RC is 
f7c21ce501eee288c488edd416f0ddccdd365966 which you can browse here:


https://github.com/apache/commons-daemon/commit/f7c21ce501eee288c488edd416f0ddccdd365966

(gitbox browsing is currently disabled)

You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.4-RC1 commons-daemon-1.3.4-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1634/commons-daemon/commons-daemon/1.3.4/

These are the artifacts and their hashes:

commons-daemon-1.3.4.jar=31e723efc879fb1a45001bcb1577c02defe38b0a7e02fc4efd2800f85a4dbe583eba2e67323145aa5c2c5cf9dd09c457961557898a9923e85b0375c73c639498
commons-daemon-1.3.4-bin.tar.gz=adc301fe9c7e50c5ed71c6775c8c41c33a369a05c30785ccb81209089603ae66563e958b466c99fc5cd27c12625bb7def68d7d91933aa8739eb645af37f3d03e
commons-daemon-1.3.4-bin.zip=857da3217d9186b034ffecf36b8d0df84b3b4de8b06a81338df97dbabafeff9b84034d49173623f5b03786d48d85d406af8e602ea644c95552f2df68f98d5ddc
commons-daemon-1.3.4-bin-windows.zip=57a59d402dd0a1c99ed5da062b4616d54679e4208abec8b25742f5bf3ec1ee6b5187bc830edeaa218766215371b5519ce0a7186325c929c86b567a3078aa7555
commons-daemon-1.3.4-native-src.tar.gz=3c10ca72fc0eb7f755c0b5452bb6d5e8b42d8f363767ffcd9a6f0883026e688ea7dff50ea05e2675a7cdf9f413cb8012ee6b79e16dfc1cd4d83bd775ea10216c
commons-daemon-1.3.4-native-src.zip=2e2db21b142b40427c43f4802ec94fb6212d1c79cb6aa02325b71017e20384a8d6123148603eda03f309aeae5a6f88f9a014deb978af0fac2f62b576d73ae1b8
commons-daemon-1.3.4-src.tar.gz=bb36d88bc21a5777245012b2a73ee0e764b85715731f54cc4ff09343e95ccb18fc6c68b3ae9c680fb45a60c7ef5ed0f9e40991c2c03246dd7f8dd65031eddf24
commons-daemon-1.3.4-src.zip=2f77720724069655828cecb639a3c9a8411e97ed4c9923340f521cf7078ce85e5d223f20431040411a592b4d38208144ffc56da8b70091f75028a1aad9c51891


KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Request for Information: Commons Text

[Mark Thomas]

On 04/05/2023 16:44, Zhang, Cynthia X. (GSFC-710.0)[BOOZ ALLEN HAMILTON] 
wrote:

Hello, my name is Cynthia Zhang and I am a Supply Chain Risk Management Analyst 
at NASA. NASA is currently conducting a supply chain assessment of Commons 
Text. We are interested in confirming the following information:

   1.  Is there an organization which sponsors/publishes the project, or a 
primary developer who audits the code for potential vulnerabilities, errors, or 
malicious code? Y/N


Yes (Apache Software Foundation)


   2.  Please list the country or list of countries where most contributions 
originate from.


That information is not available. The ASF does not track contributions 
by country.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [BCEL] https://github.com/apache/commons-bcel/pull/177

[Mark Thomas]

Looks plausible to me (or did you mean a different Mark?).

Mark


On 10/04/2023 15:13, Gary D. Gregory wrote:

Mark and all,

Any thoughts on https://github.com/apache/commons-bcel/pull/177 ?

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Nexus: Staging Repository Dropped

[Mark Thomas]

I typed "mvn site deploy" rather than "mvn site-deploy". Sorry for the 
noise.


Mark

On 20/02/2023 15:53, Nexus Repository Manager wrote:

Message from: https://repository.apache.org <https://repository.apache.org>



*Deployer properties:*

  * "userAgent" = "Apache-Maven/3.8.4 (Java 1.8.0_362; Linux
5.19.0-32-generic)"
  * "userId" = "markt"
  * "ip" = "81.159.69.115"


*Details:*

The orgapachecommons-1621 staging repository has been dropped.
Action performed by Mark Thomas (markt)


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[SECURITY] CVE-2023-24998 Apache Commons FileUpload - DoS with excessive parts

[Mark Thomas]

CVE-2023-24998 Apache Commons FileUpload - DoS with excessive parts

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Commons FileUpload 1.0-beta-1 to 1.4

Description:
Apache Commons FileUpload before 1.5 does not limit the number of 
request parts to be processed resulting in the possibility of an 
attacker triggering a DoS with a malicious upload or series of uploads.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Commons FileUpload 1.5 or later

Credit:
This issue was identified by Jakob Ackermann and reported responsibly to 
the Apache Commons Security Team.


History:
2023-02-20 Original advisory

References:
[1] 
https://commons.apache.org/proper/commons-fileupload/security-reports.html



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[ANNOUNCE] Apache Commons FIleUpload 1.5 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the release of
Apache Commons FileUpload 1.5.


The Commons FileUpload software library makes it easy to add
robust, high-performance, file upload capability to your servlets
and web applications.


Source and binary distributions are available for download from the Apache
Commons FileUpload download site:
https://commons.apache.org/proper/commons-fileupload/download_fileupload.cgi


When downloading, please verify signatures using the KEYS file available 
at the above location when downloading the release.



Alternatively the release can be pulled via maven:
  commons-fileupload
  commons-fileupload
  1.5


The release notes can be reviewed at:
https://www.apache.org/dist/commons/fileupload/RELEASE-NOTES.txt


For complete information on Commons FileUpload, including instructions 
on how to

submit bug reports, patches, or suggestions for improvement, see the Apache
Commons FileUpload website:


https://commons.apache.org/proper/commons-fileupload/


Best regards,
Mark
on behalf of the Apache Commons community

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE][RESULT] Release Apache Commons FileUpload 1.5 based on RC1

[Mark Thomas]

The following votes were cast:

Binding:
+1: kinow, markt, ggregory

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons FileUpload 1.5 based on RC1

[Mark Thomas]

Ping. One more PMC member vote required.

Mark

On 01/02/2023 12:57, Mark Thomas wrote:
We have fixed a few bugs and added some small enhancements since 
FileUpload 1.4 was released, so I would like to release FileUpload 1.5.


FileUpload 1.5 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1
(svn revision 59794)

The tag is here:
https://gitbox.apache.org/repos/asf?p=commons-fileupload.git;a=tag;h=7a932af807778ffd11ed5e86cc69b405855c11fb

Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1618/

These are the artifacts and their hashes:

#Release SHA-512s
commons-fileupload-1.5-bin.tar.gz=185699b43afcf1494378ed7efae25fb3630346323c6abadaef2dfce3a01c533341a51e2c14f081f4b90d02dd9364c4a565966bf4358e9a11b71aa3a19adb3097
commons-fileupload-1.5-bin.zip=4e99e8ee135d0f331a0f5ffeb3a15d94f31469c57c9ca79a65608665165604be7e20d4571571fdfaf37938db90744dc318ed634c19dd6f31c7d4815b0084c9b1
commons-fileupload-1.5-bom.json=864690cd2f9e962dab4a58661a356acc29aebe5958dea1c2161541160d36b3a86f582b8fd9be6502465e7d68480aad9c1777e0b1646ef9ad8c02aa541f78f964
commons-fileupload-1.5-bom.xml=ab82f4581eb9056dd2c28ea8656016d02729c3648f140d5b270b470e91df2baa3b0e1d2111b445093fc826834d86a2525d7421dc47ffd4afab8690ce5e865512
commons-fileupload-1.5-javadoc.jar=f1c1dbb054e4b1a4ed1616c78b3e00b97b4eb8b05b89971ec87d80a09aef680451d98762fd490b7618b00fe2c33e1e50e153676bb92a3941fb82c21cf5c7ec0a
commons-fileupload-1.5-sources.jar=4a62eae065a0f7063c7377e06e499582acfcb2cd3f0a35e2b6893d7bc04406da49b9e60e1b1ec7fb53b9fcfc028e335c4ce812a3085302853a62584e663c0f2c
commons-fileupload-1.5-src.tar.gz=6cf4a1deeb8511d29e1543af4b6d3d984f0f2991e6f4550d84e7fb5d1a6df6df71c1fad6d2607d4b5d062c8fff498d30da7bd1a5bfc09f9cabdb0a57dc5c1a16
commons-fileupload-1.5-src.zip=b0b6f54e6de2d472033f1bca70b587c99f1b8d649147469e4f315848ed284a9db6b4f200046cb36e99613a4029b5f5b86316bbe26494ce34ca36a670e69492e5
commons-fileupload-1.5-test-sources.jar=428d35784b99543d304fc44eb26da9fb76bd5844843bf7f0b027cc511a56a08ea5891c8aacc14099bf2fce0ef9cc90cc3bca01255bdf57d6015b232ecefa7f4c
commons-fileupload-1.5-tests.jar=b3b06fe319cbc4b679b8a0ada40772bb943151bc26828c6c4d98a102c5aafab94dcffa6f61570830339d7b0f86c834413660240c6692811d22e1cfc0e051d330
commons-fileupload_commons-fileupload-1.5.spdx.json=add8592cb24014c3e732b1eb13f9780904ef28a4439091431b1070a735993ff83c3fdaae60de2be146b4f816c9dee123ff06515cbbd8127d99d13c93d03220fc
commons-xyz-1.2-test-sources.jar

Details of changes since 1.4 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/RELEASE-NOTES.txt
https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/site/changes-report.html

Site:
https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/site/index.html


KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now,
i.e. sometime after 13:00 UTC 4 Feb 2023

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

Thanks!

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons FileUpload 1.5 based on RC1

[Mark Thomas]

On 01/02/2023 12:57, Mark Thomas wrote:


Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now,
i.e. sometime after 13:00 UTC 4 Feb 2023

   [X] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Apache Commons FileUpload 1.5 based on RC1

[Mark Thomas]

We have fixed a few bugs and added some small enhancements since 
FileUpload 1.4 was released, so I would like to release FileUpload 1.5.


FileUpload 1.5 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1
(svn revision 59794)

The tag is here:
https://gitbox.apache.org/repos/asf?p=commons-fileupload.git;a=tag;h=7a932af807778ffd11ed5e86cc69b405855c11fb

Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1618/

These are the artifacts and their hashes:

#Release SHA-512s
commons-fileupload-1.5-bin.tar.gz=185699b43afcf1494378ed7efae25fb3630346323c6abadaef2dfce3a01c533341a51e2c14f081f4b90d02dd9364c4a565966bf4358e9a11b71aa3a19adb3097
commons-fileupload-1.5-bin.zip=4e99e8ee135d0f331a0f5ffeb3a15d94f31469c57c9ca79a65608665165604be7e20d4571571fdfaf37938db90744dc318ed634c19dd6f31c7d4815b0084c9b1
commons-fileupload-1.5-bom.json=864690cd2f9e962dab4a58661a356acc29aebe5958dea1c2161541160d36b3a86f582b8fd9be6502465e7d68480aad9c1777e0b1646ef9ad8c02aa541f78f964
commons-fileupload-1.5-bom.xml=ab82f4581eb9056dd2c28ea8656016d02729c3648f140d5b270b470e91df2baa3b0e1d2111b445093fc826834d86a2525d7421dc47ffd4afab8690ce5e865512
commons-fileupload-1.5-javadoc.jar=f1c1dbb054e4b1a4ed1616c78b3e00b97b4eb8b05b89971ec87d80a09aef680451d98762fd490b7618b00fe2c33e1e50e153676bb92a3941fb82c21cf5c7ec0a
commons-fileupload-1.5-sources.jar=4a62eae065a0f7063c7377e06e499582acfcb2cd3f0a35e2b6893d7bc04406da49b9e60e1b1ec7fb53b9fcfc028e335c4ce812a3085302853a62584e663c0f2c
commons-fileupload-1.5-src.tar.gz=6cf4a1deeb8511d29e1543af4b6d3d984f0f2991e6f4550d84e7fb5d1a6df6df71c1fad6d2607d4b5d062c8fff498d30da7bd1a5bfc09f9cabdb0a57dc5c1a16
commons-fileupload-1.5-src.zip=b0b6f54e6de2d472033f1bca70b587c99f1b8d649147469e4f315848ed284a9db6b4f200046cb36e99613a4029b5f5b86316bbe26494ce34ca36a670e69492e5
commons-fileupload-1.5-test-sources.jar=428d35784b99543d304fc44eb26da9fb76bd5844843bf7f0b027cc511a56a08ea5891c8aacc14099bf2fce0ef9cc90cc3bca01255bdf57d6015b232ecefa7f4c
commons-fileupload-1.5-tests.jar=b3b06fe319cbc4b679b8a0ada40772bb943151bc26828c6c4d98a102c5aafab94dcffa6f61570830339d7b0f86c834413660240c6692811d22e1cfc0e051d330
commons-fileupload_commons-fileupload-1.5.spdx.json=add8592cb24014c3e732b1eb13f9780904ef28a4439091431b1070a735993ff83c3fdaae60de2be146b4f816c9dee123ff06515cbbd8127d99d13c93d03220fc
commons-xyz-1.2-test-sources.jar

Details of changes since 1.4 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/RELEASE-NOTES.txt
https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/site/changes-report.html

Site:
https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/site/index.html


KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now,
i.e. sometime after 13:00 UTC 4 Feb 2023

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thanks!

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [FILEUPLOAD] State of the 1.6 branch

[Mark Thomas]

On 03/01/2023 09:52, Mark Thomas wrote:

On 15/12/2022 18:54, Jochen Wiedmann wrote:

On Wed, Dec 14, 2022 at 12:20 PM Mark Thomas  wrote:


- Delete the b2_0 branch
- Move the head of the b1_4 branch to the 1.4 tag
- Update the b1_4 branch for development of 1.4.1
    (or should that be 1.5 and start a new branch?)
- Back-port my recent file count limit change


If you can do that: Please, do!


Thanks all for the feedback.

I have made the following changes:

The b2_0 branch has been deleted. It was never used.

The b1_4 branch has been deleted. It was never used. 1.x replaces it.

I have created a 1.x branch from the 1.4 tag.

b1_3 remains unchanged. It could be renamed 1.3.x but since no further 
development is expected on 1.3.x, I opted to leave it as is. The same 
applies to b1_2 and b1_2_1.


I will update the 1.x branch to 1.5 (for consistency with previous 1.x 
versions) and then back-port my recent (ish) file count limit change.


I will also review the changes between 1.4 and HEAD on the master branch 
for possible back ports for 1.x/1.5. I only intend to back-port bug fixes.


All done.

The 1.x branch needs some work before it is ready for a release but it 
should have all the code changes now.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [FILEUPLOAD] State of the 1.6 branch

[Mark Thomas]

On 15/12/2022 18:54, Jochen Wiedmann wrote:

On Wed, Dec 14, 2022 at 12:20 PM Mark Thomas  wrote:


- Delete the b2_0 branch
- Move the head of the b1_4 branch to the 1.4 tag
- Update the b1_4 branch for development of 1.4.1
(or should that be 1.5 and start a new branch?)
- Back-port my recent file count limit change


If you can do that: Please, do!


Thanks all for the feedback.

I have made the following changes:

The b2_0 branch has been deleted. It was never used.

The b1_4 branch has been deleted. It was never used. 1.x replaces it.

I have created a 1.x branch from the 1.4 tag.

b1_3 remains unchanged. It could be renamed 1.3.x but since no further 
development is expected on 1.3.x, I opted to leave it as is. The same 
applies to b1_2 and b1_2_1.


I will update the 1.x branch to 1.5 (for consistency with previous 1.x 
versions) and then back-port my recent (ish) file count limit change.


I will also review the changes between 1.4 and HEAD on the master branch 
for possible back ports for 1.x/1.5. I only intend to back-port bug fixes.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Mark Thomas]

On 16/12/2022 13:24, Gary Gregory wrote:

Thank you Richard for starting this thread.

My view is simpler perhaps: I would not make this about the javax vs
Jakarta namespaces.

I don't want to double the numbers of jars we produce from the same branch
for affected components as one of the scheme proposed. It feels like a
burden to maintenance moving forward and a very brittle process with some
unforeseen side effects.

This is just a code change IMO. For a given component, either it is binary
compatible, or it is not. You don't know until you try it and see if public
and protected elements break, using our existing configuration of Maven and
japicmp (or revapi).

If it is binary compatible, then let's consider making the change. If not,
then do it in a major version, where the previous major version is
maintained as we do now, as need be.

A new major version also benefits from the usual dropping of deprecated
elements and making any other changes with seem reasonable.


+1. I don't see this as any different to increasing the minimum version 
of Java and supported new JDBC methods.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [FILEUPLOAD] State of the 1.6 branch

[Mark Thomas]

On 14/12/2022 12:12, Gilles Sadowski wrote:

Hi.

Le mer. 14 déc. 2022 à 12:25, Gary Gregory  a écrit :


I would create a branch called "1.x" instead and bump the version in the
POM to 1.5.0.

FYI, I've been using the x.y.z version format in most of not all components
I work on, I find that it sets expectations better, for me anyway.


IIRC, the convention is to use "x.y" if "z" is "0".


I have a very strong perference for always including the z component 
even if it is zero. That said, for consistency I intend to follow 
whatever pattern (I haven't looked yet) file upload used for the 
previous 1.x releases.



If a third number refers to "patch" or "bug fix", and there hasn't
been any, it is rather more confusing.


I disagree. I see greater confusion between 1.y referring to the 
specific 1.y(.0) release or the series of 1.y releases. If the .z 
component is always present, there is no opporutnity for confusion.



IMO, this is the kind of thing that should be consistent across all
releases within a project; so departing from the common (and
Commons') practice should not occur without a vote.


If the process wasn't established with a VOTE there there is no need for 
a VOTE to deviate from it.


It seems reasonable that there should be a consistent versioning format 
but it isn't clear if we'd be able to reach consensus on what that 
should be.



Perhaps the same remark about naming (git) "tags".


Ditto.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[FILEUPLOAD] State of the 1.6 branch

[Mark Thomas]

Hi all,

I was looking into the possibility of back-porting my recent file count 
limit change to 1.4 and I think the Github branch is rather out of sync.


Using gitk to explore the history, the last commit on the b1_4 branch 
was eed3e5 on 2017-06-03


But the 1.4 tag is at 047f315 on 2018-12-28

It looks like 1.4 development proceeded on master after the b1_4 tag and 
then master switched to 2.0 after the 1.4 tag.


There is also a b2_0 branch that was created and abandoned.

My proposal for a way forward as follows:

- Delete the b2_0 branch
- Move the head of the b1_4 branch to the 1.4 tag
- Update the b1_4 branch for development of 1.4.1
  (or should that be 1.5 and start a new branch?)
- Back-port my recent file count limit change

Thoughts?

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE][RESULT] Release Apache Commons Daemon 1.3.3 based on RC1

[Mark Thomas]

The following votes were cast:

Binding:
+1: ggregory, markt, kinow

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


On 23/11/2022 20:45, Mark Thomas wrote:
We have fixed a few bugssince Apache Commons Daemon 1.3.2 was released, 
so I would like to release Apache Commons Daemon 1.3.3.


Apache Commons Daemon 1.3.3 RC1 is available for review here:
     https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.3-RC1 
(svn revision svn: 58217


The Git tag commons-daemon-1.3.3-RC1 commit for this RC is 
5ead75b56ce0e171931de808bf0529666c1c4cbb which you can browse here:


https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=5ead75b56ce0e171931de808bf0529666c1c4cbb
You may checkout this tag using:
     git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.3-RC1 commons-daemon-1.3.3-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1606/commons-daemon/commons-daemon/1.3.3/

These are the artifacts and their hashes:

#Release SHA-512s
commons-daemon-1.3.3.jar=ee877434645400193ef5578f52e1314e90604c28224a77d03176c1370e7bcdae393d62238bce371b4cbb1495b867c06d2bf6a33ea1ab3aea56c2b872ea2b0b6c
Apache Commons 
Daemon-1.3.3.spdx.rdf.xml=c7c4416afbe3b14d62c94d5b1da413794ac0db8732c51453a1bb39677a0e564af245a6ab8bc4f2d66ac95b6b594faa208ec2da12ac66241c47db6e853d141a5f

commons-daemon-1.3.3-bin-windows.zip=f291b142dadb179fee6845b4d26a52e7961bd39e57680ce2398505efe8c04de00271ed35bc39392c82d1e2d0f60b868cc5a1e80a7b8af8de923554877e0003ba
commons-daemon-1.3.3-bin.tar.gz=6600f3c182a46005928a77ade2a7f7e32ba29ebdfdc2255275cbd07445c4d278a96de4d8555031fa90eef29c4f50325b3b79eec0e4e09308d152583807189578
commons-daemon-1.3.3-bin.zip=ef89d6cac12b7f90575ccfeca0d58ed96f8d2dca702946882d54fa10df5f770ba9c08097951589f8704419a8e14b205cd95135c5bc12a59107ef5ee84db17fa9
commons-daemon-1.3.3-bom.json=d199cc4ac629f0b7cde86ab4084251dbb57b20a8d94d3086d5d6e0533e77a0f07d01b4326059e645d4eec2f460f144b79376cae95e1ba619fc96a4caaa0465e3
commons-daemon-1.3.3-bom.xml=e299fd88c34c9eb4ecd431f83f43a4aa978d6d123ffc5d14ffc718826832ff1972dc3b3fb944ceca4c608185d2edcb32e91ea3d2aab10e2a4e3812a4ba872887
commons-daemon-1.3.3-javadoc.jar=64423f84f26633748c61d7c2e34c6e6283d35ec95ccc162c5dcdd28bc5fa73222181fe429304a93b1de32b63385f14301f52fa44c02f710cc6a9a62b6fef6730
commons-daemon-1.3.3-native-src.tar.gz=a3d200e5c35c4f2d397164fbaee52f235d954ba8fe342bf136fb2a7da3ca2df472af31c7f68d71b114ab3632ac712f6c7b7a3d3043f8e754c58c402658e1
commons-daemon-1.3.3-native-src.zip=bbd9ea0b6b8438c305a537dd30d3754fe8cda33af7cd416b039548f4a33a1afbde295590e98801f75ad73a0aefb512aa91f8c0b1dd716c332facd6ace0cce646
commons-daemon-1.3.3-sources.jar=a7179691a4c7fabdd379d8b6ca9b221bd792382439ebff7dc618d1c6f287a77defe2e5a85d594da618ecb14c8b5062560c9e09c9ccebab0d0527cda42d618159
commons-daemon-1.3.3-src.tar.gz=ec246e2c05d66408374ba56b3715b13f8f24f89af11fa00c2381dc19c188f1b6228f19351c97d5774808a804b83fdbdfb8f537d099db062c39ffd281c142ee77
commons-daemon-1.3.3-src.zip=d622db66ea21ac6c1b096506173d1e66c7c2e5db49cefaeac818fe6f106c32c2daef946a9c6faf8c664716fc8acb7501d5e5e0c6faf66ab02d7c94849b21df19



KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.3-RC1 commons-daemon-1.3.3-RC1

cd commons-daemon-1.3.3-RC1

2) Check Apache licenses

This step is not required if the site includes a RAT report page which 
you then must check.


mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page which 
you then must check.


mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page 
which you then must check.


mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V clean package

You can record the Maven and Java version produced by -V in your VOTE 
reply.

To gather OS information from a command line:
Windows: ver
Linux: uname -a

5) Build the site for a single module project

Note: Some plugins require the components to be installed instead of 
packaged.


mvn site
Check the site reports in:
- Windows: target\site\index.html
- Linux

Re: [VOTE] Release Apache Commons Daemon 1.3.3 based on RC1

[Mark Thomas]

On 23/11/2022 20:45, Mark Thomas wrote:


Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

   [X] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...


Tested with Tomcat 10.1.x

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Apache Commons Daemon 1.3.3 based on RC1

[Mark Thomas]

We have fixed a few bugssince Apache Commons Daemon 1.3.2 was released, 
so I would like to release Apache Commons Daemon 1.3.3.


Apache Commons Daemon 1.3.3 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.3-RC1 
(svn revision svn: 58217


The Git tag commons-daemon-1.3.3-RC1 commit for this RC is 
5ead75b56ce0e171931de808bf0529666c1c4cbb which you can browse here:


https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=5ead75b56ce0e171931de808bf0529666c1c4cbb
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.3-RC1 commons-daemon-1.3.3-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1606/commons-daemon/commons-daemon/1.3.3/

These are the artifacts and their hashes:

#Release SHA-512s
commons-daemon-1.3.3.jar=ee877434645400193ef5578f52e1314e90604c28224a77d03176c1370e7bcdae393d62238bce371b4cbb1495b867c06d2bf6a33ea1ab3aea56c2b872ea2b0b6c
Apache Commons 
Daemon-1.3.3.spdx.rdf.xml=c7c4416afbe3b14d62c94d5b1da413794ac0db8732c51453a1bb39677a0e564af245a6ab8bc4f2d66ac95b6b594faa208ec2da12ac66241c47db6e853d141a5f

commons-daemon-1.3.3-bin-windows.zip=f291b142dadb179fee6845b4d26a52e7961bd39e57680ce2398505efe8c04de00271ed35bc39392c82d1e2d0f60b868cc5a1e80a7b8af8de923554877e0003ba
commons-daemon-1.3.3-bin.tar.gz=6600f3c182a46005928a77ade2a7f7e32ba29ebdfdc2255275cbd07445c4d278a96de4d8555031fa90eef29c4f50325b3b79eec0e4e09308d152583807189578
commons-daemon-1.3.3-bin.zip=ef89d6cac12b7f90575ccfeca0d58ed96f8d2dca702946882d54fa10df5f770ba9c08097951589f8704419a8e14b205cd95135c5bc12a59107ef5ee84db17fa9
commons-daemon-1.3.3-bom.json=d199cc4ac629f0b7cde86ab4084251dbb57b20a8d94d3086d5d6e0533e77a0f07d01b4326059e645d4eec2f460f144b79376cae95e1ba619fc96a4caaa0465e3
commons-daemon-1.3.3-bom.xml=e299fd88c34c9eb4ecd431f83f43a4aa978d6d123ffc5d14ffc718826832ff1972dc3b3fb944ceca4c608185d2edcb32e91ea3d2aab10e2a4e3812a4ba872887
commons-daemon-1.3.3-javadoc.jar=64423f84f26633748c61d7c2e34c6e6283d35ec95ccc162c5dcdd28bc5fa73222181fe429304a93b1de32b63385f14301f52fa44c02f710cc6a9a62b6fef6730
commons-daemon-1.3.3-native-src.tar.gz=a3d200e5c35c4f2d397164fbaee52f235d954ba8fe342bf136fb2a7da3ca2df472af31c7f68d71b114ab3632ac712f6c7b7a3d3043f8e754c58c402658e1
commons-daemon-1.3.3-native-src.zip=bbd9ea0b6b8438c305a537dd30d3754fe8cda33af7cd416b039548f4a33a1afbde295590e98801f75ad73a0aefb512aa91f8c0b1dd716c332facd6ace0cce646
commons-daemon-1.3.3-sources.jar=a7179691a4c7fabdd379d8b6ca9b221bd792382439ebff7dc618d1c6f287a77defe2e5a85d594da618ecb14c8b5062560c9e09c9ccebab0d0527cda42d618159
commons-daemon-1.3.3-src.tar.gz=ec246e2c05d66408374ba56b3715b13f8f24f89af11fa00c2381dc19c188f1b6228f19351c97d5774808a804b83fdbdfb8f537d099db062c39ffd281c142ee77
commons-daemon-1.3.3-src.zip=d622db66ea21ac6c1b096506173d1e66c7c2e5db49cefaeac818fe6f106c32c2daef946a9c6faf8c664716fc8acb7501d5e5e0c6faf66ab02d7c94849b21df19



KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.3-RC1 commons-daemon-1.3.3-RC1

cd commons-daemon-1.3.3-RC1

2) Check Apache licenses

This step is not required if the site includes a RAT report page which 
you then must check.


mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page which 
you then must check.


mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page 
which you then must check.


mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V clean package

You can record the Maven and Java version produced by -V in your VOTE reply.
To gather OS information from a command line:
Windows: ver
Linux: uname -a

5) Build the site for a single module project

Note: Some plugins require the components to be installed instead of 
packaged.


mvn site
Check the site reports in:
- Windows: target\site\index.html
- Linux: target/site/index.html

6) Build the site for a multi-module project

mvn site
mvn site:stage
Check the site reports in:
- Windows: target\site\index.html
- Linux: target/site/index.html

-the end

Re: [commons-daemon] tag commons-daemon-1.3.2 created (now 4189f27)

[Mark Thomas]

No. We only had the RC1 tag for 1.3.2. This just creates a duplicate tag 
for that version without the RC1 suffix.


But I did spot the need for it while preparing for 1.3.3-RC1.

Mark

On 23/11/2022 19:34, Gary Gregory wrote:

Don't you mean 1.3.3?

Gary

On Wed, Nov 23, 2022, 14:32  wrote:


This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to tag commons-daemon-1.3.2
in repository https://gitbox.apache.org/repos/asf/commons-daemon.git


   at 4189f27  (commit)
No new revisions were added by this update.






-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Correctly configuring Apache Commons components for oss-fuzz

[Mark Thomas]

On 21/11/2022 04:22, Oliver Chang wrote:

Hi Mark,

Thanks for the early feedback.

Re a), unfortunately I'm not aware of an easy way to do this with our
current bug tracking system (Monorail). If it's an important feature to
have, one way to achieve this may be to set up a separate "
security-oss-fuzz-not...@commons.apache.org" group or something similar to
be CCed on all issues, which just forwards any notifications to the main "
secur...@commons.apache.org" list. The main list can then filter out emails
based on the recipient to avoid duplication. Would that work?


Given that Monorail is a Google owned / controlled project I'd hope that 
such a feature addition would be possible.



Re b), thank you for the feedback. We will be working on making our bug
reports contain more actionable context in the notifications themselves.


Thank you.


I have just finished reviewing approximately 50 oss-fuzz reports for 
Commons. Give the excessive noise to signal ratio, the Apache Commons 
project has disabled all email notifications from monorail to our 
security team unless we explicitly mark the issue of interest.


That gets us to a position where our security mailing list isn't swamped.

We will continue to receive notifications for all issues at 
fuzz-test...@commons.apache.org


If you could ensure that fuzz-test...@commons.apache.org is on the CC 
for all Apache Commons components that would ensure we don't miss anything.


On reflection, it would probably be better if 
fuzz-test...@commons.apache.org was the primary contact for all Commons 
components and secur...@commons.apache.org was on the CC list.



The remaining major point is triage of discovered issues. We are still 
putting together our thoughts on that given the high number of issues 
and high false positive rate.


Mark




Best,
Oliver

On Sun, 20 Nov 2022 at 21:24, Mark Thomas  wrote:


Hi Oliver,

The following are a couple of (hopefully) low hanging fruit that will
smooth a couple of rough edges. These aren't the biggest issues - just
something to get started with.

a) It would be very helpful if there was an option to enable sending of
 notifications for your own comments.

b) It would be helpful if more (actually all) of the issue detail was
 included in the notification emails.

Mark


On 18/11/2022 00:02, Oliver Chang wrote:

Thanks Mark.

Please let us know how we can help make this fuzzing experience better
for you. We're also happy to jump on a call to walk through your
concerns and reach a good outcome.

Best regards,
--
Oliver


On Thu, 17 Nov 2022 at 06:56, Mark Thomas mailto:ma...@apache.org>> wrote:

 I haven't forgotten about this. I am currently working through the

open

 issues. I want to complete first that so feedback isn't skewed by a
 single project.

 Mark


 On 11/11/2022 14:45, Roman Wagner wrote:
  > Hi Mark,
  >
  > I think the best way forward is to collaborate and have a short
 feedback
  > loop.
  >
  > Did you mean build failures by “Invalid due to broken test”? If
 yes, I am
  > not sure what we can do about the broken tests since those are
 already
  > executed and tested by check build scripts locally and in a CI/CD
 pipeline.
  > Build and Coverage failures are sometimes supposed to happen if
 there are
  > changes in the target repository itself or if there are
 infrastructure
  > issues in OSS-Fuzz. We will investigate those issues in more
 detail. Maybe
  > some filter in the apache mailing list is helpful for you in the
 short
  > term, Fuzzing and Coverage build issues have a "build failure"
 string in
  > the subject. That would enable you to focus on the reports only.
  >
  > In order to make sure that we get high-quality tests and results,
  > maintainer feedback from apache will be very valuable and
 welcome. You have
  > the best domain knowledge about your code base and can give
 valuable hints
  > on which APIs to tackle best. There was already some valuable
 feedback for
  > Apache Tomcat in
 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53153
 <https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53153>.
  > Let us extend  this collaboration. We can discuss and agree on
 the attack
  > vectors in apache-commons components.
  >
  > Best regards
  > Roman
  >
  > On Thu, Nov 10, 2022 at 10:29 AM Mark Thomas mailto:ma...@apache.org>> wrote:
  >
  >> Oliver,
  >>
  >> My requirements regarding configuration are:
  >>
  >> - secur...@commons.apache.org
 <mailto:secur...@commons.apache.org> MUST be notified of all

security

  >> vulnerability reports for all Apache Commons components

[DAEMON] Expecting to tag tomorrow

[Mark Thomas]

Hi all,

This is just a heads up.

I've just fixed a bug in DAEMON so I am expecting to tag 1.3.3 tomorrow 
so the next round of Tomcat releases can pick up a version of Daemon 
with the fix.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-bcel] branch master updated: Validate the u4 length of all attributes

[Mark Thomas]

On 22/11/2022 13:10, Gary D. Gregory wrote:

I am concerned that the recent fixes we've made through OSS fuzz and code 
inspection to validate input are semantically incorrect: The verifier should 
catch these errors, not the construction of Java objects. This could be a case 
where fuzzing and low-level code inspections only appear to find issues but are 
ignorant of the usage context.

Thoughts?


My understanding of the Javadocs was that these changes are consistent 
with the documented behaviour.


ClassParser.parse() throws ClassFormatException if the class file is 
malformed. I think all the recent changes come under this heading.


Verification is (mostly) concerned with the byte code in Code 
attributes. Those are opaue to the parser.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Correctly configuring Apache Commons components for oss-fuzz

[Mark Thomas]

Hi Oliver,

The following are a couple of (hopefully) low hanging fruit that will 
smooth a couple of rough edges. These aren't the biggest issues - just 
something to get started with.


a) It would be very helpful if there was an option to enable sending of
   notifications for your own comments.

b) It would be helpful if more (actually all) of the issue detail was
   included in the notification emails.

Mark


On 18/11/2022 00:02, Oliver Chang wrote:

Thanks Mark.

Please let us know how we can help make this fuzzing experience better 
for you. We're also happy to jump on a call to walk through your 
concerns and reach a good outcome.


Best regards,
--
Oliver


On Thu, 17 Nov 2022 at 06:56, Mark Thomas <mailto:ma...@apache.org>> wrote:


I haven't forgotten about this. I am currently working through the open
issues. I want to complete first that so feedback isn't skewed by a
single project.

Mark


On 11/11/2022 14:45, Roman Wagner wrote:
 > Hi Mark,
 >
 > I think the best way forward is to collaborate and have a short
feedback
 > loop.
 >
 > Did you mean build failures by “Invalid due to broken test”? If
yes, I am
 > not sure what we can do about the broken tests since those are
already
 > executed and tested by check build scripts locally and in a CI/CD
pipeline.
 > Build and Coverage failures are sometimes supposed to happen if
there are
 > changes in the target repository itself or if there are
infrastructure
 > issues in OSS-Fuzz. We will investigate those issues in more
detail. Maybe
 > some filter in the apache mailing list is helpful for you in the
short
 > term, Fuzzing and Coverage build issues have a "build failure"
string in
 > the subject. That would enable you to focus on the reports only.
 >
 > In order to make sure that we get high-quality tests and results,
 > maintainer feedback from apache will be very valuable and
welcome. You have
 > the best domain knowledge about your code base and can give
valuable hints
 > on which APIs to tackle best. There was already some valuable
feedback for
 > Apache Tomcat in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53153
<https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53153>.
 > Let us extend  this collaboration. We can discuss and agree on
the attack
 > vectors in apache-commons components.
 >
 > Best regards
 > Roman
 >
 > On Thu, Nov 10, 2022 at 10:29 AM Mark Thomas mailto:ma...@apache.org>> wrote:
 >
 >> Oliver,
 >>
 >> My requirements regarding configuration are:
 >>
 >> - secur...@commons.apache.org
<mailto:secur...@commons.apache.org> MUST be notified of all security
 >>     vulnerability reports for all Apache Commons components
 >>
 >> - a mechanism MUST be provided for the
secur...@commons.apache.org <mailto:secur...@commons.apache.org>
 >>     Google user to view all historical reports that were not
previously
 >>     notified to that address
 >>
 >> - if any further Apache Commons components get added to oss-fuzz
 >>     then secur...@commons.apache.org
<mailto:secur...@commons.apache.org> MUST receive notification of any
 >>     issues as they are found
 >>
 >> - more generally, if *any* Apache Software Foundation project is
added
 >>     to oss-fuzz then the notifications for that project MUST
include the
 >>     relevant security team for that project
 >>
 >> If you can achieve the above with the current structure then great.
 >>
 >>
 >> Separately, there is a concern regarding the false positive
rate. With
 >> the oss-fuzz integration provided by Code Intelligence we have
seen the
 >> following with Apache Tomcat in a little under 3 months.
 >>
 >> Total "vulnerability" reports: 39
 >>
 >> Invalid due to broken test: 31%
 >> False positive:             52%
 >> Bugs:                       18%
 >> Valid security issues:       0%
 >>
 >> To add some commentary:
 >> - the bugs were minor / extreme edge cases users were unlikely
to hit
 >> - false positives were all due to the tests being based on invalid
 >>     assumptions regarding whether input was expected to be
trusted or not
 >>
 >>
 >> If those statistics were repeated across multiple Apache Commons
 >> components, the volume of invalid reports would be more than the
 >> volunte

Re: Correctly configuring Apache Commons components for oss-fuzz

[Mark Thomas]

I haven't forgotten about this. I am currently working through the open 
issues. I want to complete first that so feedback isn't skewed by a 
single project.


Mark


On 11/11/2022 14:45, Roman Wagner wrote:

Hi Mark,

I think the best way forward is to collaborate and have a short feedback
loop.

Did you mean build failures by “Invalid due to broken test”? If yes, I am
not sure what we can do about the broken tests since those are already
executed and tested by check build scripts locally and in a CI/CD pipeline.
Build and Coverage failures are sometimes supposed to happen if there are
changes in the target repository itself or if there are infrastructure
issues in OSS-Fuzz. We will investigate those issues in more detail. Maybe
some filter in the apache mailing list is helpful for you in the short
term, Fuzzing and Coverage build issues have a "build failure" string in
the subject. That would enable you to focus on the reports only.

In order to make sure that we get high-quality tests and results,
maintainer feedback from apache will be very valuable and welcome. You have
the best domain knowledge about your code base and can give valuable hints
on which APIs to tackle best. There was already some valuable feedback for
Apache Tomcat in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53153.
Let us extend  this collaboration. We can discuss and agree on the attack
vectors in apache-commons components.

Best regards
Roman

On Thu, Nov 10, 2022 at 10:29 AM Mark Thomas  wrote:


Oliver,

My requirements regarding configuration are:

- secur...@commons.apache.org MUST be notified of all security
vulnerability reports for all Apache Commons components

- a mechanism MUST be provided for the secur...@commons.apache.org
Google user to view all historical reports that were not previously
notified to that address

- if any further Apache Commons components get added to oss-fuzz
then secur...@commons.apache.org MUST receive notification of any
issues as they are found

- more generally, if *any* Apache Software Foundation project is added
to oss-fuzz then the notifications for that project MUST include the
relevant security team for that project

If you can achieve the above with the current structure then great.


Separately, there is a concern regarding the false positive rate. With
the oss-fuzz integration provided by Code Intelligence we have seen the
following with Apache Tomcat in a little under 3 months.

Total "vulnerability" reports: 39

Invalid due to broken test: 31%
False positive: 52%
Bugs:   18%
Valid security issues:   0%

To add some commentary:
- the bugs were minor / extreme edge cases users were unlikely to hit
- false positives were all due to the tests being based on invalid
assumptions regarding whether input was expected to be trusted or not


If those statistics were repeated across multiple Apache Commons
components, the volume of invalid reports would be more than the
volunteers of the Apache Commons security team could handle.

I have no objection to being overwhelmed with valid security
vulnerability reports. If that ever happened, we would find a way to
deal with it.

I do have very strong objections to being overwhelmed with invalid
security vulnerability reports. If we see the same false positive rate
repeated across the Apache Commons components that has been observed
with Apache Tomcat then I don't see that Apache Commons would have any
choice but to request the removal of all Apache Commons Components from
oss-fuzz.

Mark





On 10/11/2022 04:19, Oliver Chang wrote:

Hi Mark,

In addition to the reasons Roman listed, the current structure also
allows us to allocate more compute resources to all of these Apache
packages, rather than all of them sharing the CPUs allocated for a
single OSS-Fuzz "project".

We can definitely ensure that secur...@commons.apache.org
<mailto:secur...@commons.apache.org> is included on all relevant Apache
projects going forward, and other than that I believe there's not much
other difference in terms of the end result (i.e. bug reports) that end
up getting filed.

Does that sound OK to you? Or did you have other concerns around the
current directory structure?

Best regards,
--
Oliver


On Wed, 9 Nov 2022 at 21:31, Roman Wagner mailto:wag...@code-intelligence.com>> wrote:

 Hi Mark,

 I have added @Oliver Chang <mailto:och...@google.com> from the
 Google OSS-Fuzz to the thread.

 I had a short discussion with Oliver. There could be different
 issues in OSS-Fuzz by design If all apache-commons components will
 move under apache-commons directory:

   * it is not scalable and will slow down both fuzzing and triage
 (e.g. automated bisections, fix verification)
   * changing the structure this way will invalidate all existing
 open testcases, and cause new ones to be filed, which will

Re: Correctly configuring Apache Commons components for oss-fuzz

[Mark Thomas]

Oliver,

My requirements regarding configuration are:

- secur...@commons.apache.org MUST be notified of all security
  vulnerability reports for all Apache Commons components

- a mechanism MUST be provided for the secur...@commons.apache.org
  Google user to view all historical reports that were not previously
  notified to that address

- if any further Apache Commons components get added to oss-fuzz
  then secur...@commons.apache.org MUST receive notification of any
  issues as they are found

- more generally, if *any* Apache Software Foundation project is added
  to oss-fuzz then the notifications for that project MUST include the
  relevant security team for that project

If you can achieve the above with the current structure then great.


Separately, there is a concern regarding the false positive rate. With 
the oss-fuzz integration provided by Code Intelligence we have seen the 
following with Apache Tomcat in a little under 3 months.


Total "vulnerability" reports: 39

Invalid due to broken test: 31%
False positive: 52%
Bugs:   18%
Valid security issues:   0%

To add some commentary:
- the bugs were minor / extreme edge cases users were unlikely to hit
- false positives were all due to the tests being based on invalid
  assumptions regarding whether input was expected to be trusted or not


If those statistics were repeated across multiple Apache Commons 
components, the volume of invalid reports would be more than the 
volunteers of the Apache Commons security team could handle.


I have no objection to being overwhelmed with valid security 
vulnerability reports. If that ever happened, we would find a way to 
deal with it.


I do have very strong objections to being overwhelmed with invalid 
security vulnerability reports. If we see the same false positive rate 
repeated across the Apache Commons components that has been observed 
with Apache Tomcat then I don't see that Apache Commons would have any 
choice but to request the removal of all Apache Commons Components from 
oss-fuzz.


Mark





On 10/11/2022 04:19, Oliver Chang wrote:

Hi Mark,

In addition to the reasons Roman listed, the current structure also 
allows us to allocate more compute resources to all of these Apache 
packages, rather than all of them sharing the CPUs allocated for a 
single OSS-Fuzz "project".


We can definitely ensure that secur...@commons.apache.org 
<mailto:secur...@commons.apache.org> is included on all relevant Apache 
projects going forward, and other than that I believe there's not much 
other difference in terms of the end result (i.e. bug reports) that end 
up getting filed.


Does that sound OK to you? Or did you have other concerns around the 
current directory structure?


Best regards,
--
Oliver


On Wed, 9 Nov 2022 at 21:31, Roman Wagner <mailto:wag...@code-intelligence.com>> wrote:


Hi Mark,

I have added @Oliver Chang <mailto:och...@google.com> from the
Google OSS-Fuzz to the thread.

I had a short discussion with Oliver. There could be different
issues in OSS-Fuzz by design If all apache-commons components will
move under apache-commons directory:

  * it is not scalable and will slow down both fuzzing and triage
(e.g. automated bisections, fix verification)
  * changing the structure this way will invalidate all existing
open testcases, and cause new ones to be filed, which will
result in a fair bit of spam.

My proposal would be that "secur...@commons.apache.org
<mailto:secur...@commons.apache.org>" is added to all individual
apache-commons components.
I am not sure how it is possible to ensure that future onboardings
of apache-commons components will automatically have
"secur...@commons.apache.org <mailto:secur...@commons.apache.org>"
as primary contact. OSS-Fuzz could have some additional
documentation for that. @Oliver Chang <mailto:och...@google.com> do
you have any ideas here?

Best regards
Roman

On Tue, Nov 8, 2022 at 5:56 PM Mark Thomas mailto:ma...@apache.org>> wrote:

Thanks for the update.

I'll wait for that PR to be resolved before taking any further
action.

Mark


On 08/11/2022 16:42, Roman Wagner wrote:
 > Hi Mark,
 >
 > there is a PR open in oss-fuzz
https://github.com/google/oss-fuzz/pull/8933
<https://github.com/google/oss-fuzz/pull/8933>
 > .
 >
 > Best regards
 > Roman
 >
 > On Tue, Nov 8, 2022 at 4:15 PM Gary Gregory
mailto:garydgreg...@gmail.com>> wrote:
     >
 >> Sounds good.
 >>
 >> Gary
 >>
 >> On Tue, Nov 8, 2022, 10:07 Mark Thomas mailto:ma...@apache.org>> wrote:
 >>
   

Re: Correctly configuring Apache Commons components for oss-fuzz

[Mark Thomas]

Thanks for the update.

I'll wait for that PR to be resolved before taking any further action.

Mark


On 08/11/2022 16:42, Roman Wagner wrote:

Hi Mark,

there is a PR open in oss-fuzz https://github.com/google/oss-fuzz/pull/8933
.

Best regards
Roman

On Tue, Nov 8, 2022 at 4:15 PM Gary Gregory  wrote:


Sounds good.

Gary

On Tue, Nov 8, 2022, 10:07 Mark Thomas  wrote:


There has been no response to this email from anyone from Code
Intelligence.

Unless there are objections from the Apache Commons Community my next
step will be to submit a PR to have the following modules removed from
oss-fuzz:

apache-commons-bcel
apache-commons-beanutils
apache-commons-cli
apache-commons-codec
apache-commons-collections
apache-commons-configuration
apache-commons-io
apache-commons-jxpath
apache-commons-lang
apache-commons-logging

Code Intelligence (or anyone else) will remain free to add them back in
the right place - under apache-commons should they wish to do so.

Mark



On 19/10/2022 10:56, Mark Thomas wrote:

Hi,

You are receiving this email as you are currently configured as the
recipients for oss-fuzz reports for Apache Commons JXPath.

As per the discussion on the Apache Commons dev list[1], please make

the

following configuration changes to the oss-fuzz integrations with
immediate effect:

- Move all oss-fuzz integrations added for *ALL* Apache Commons
components to the oss-fuzz module for Apache-Commons:



https://github.com/google/oss-fuzz/tree/master/projects/apache-commons


There should *NOT* be separate oss-fuzz modules for each component


- Add the Google account for "secur...@commons.apache.org" to
- the notifications for these issues
- the ACL to enable this account to access the details for each

report



Please notify dev@commons.apache.org and secur...@commons.apache.org
when these changes have been completed.

Thanks,

Mark



[1]  https://lists.apache.org/thread/53vwy3g8w3f8nydz7jvxm8snrqx7msln

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Correctly configuring Apache Commons components for oss-fuzz

[Mark Thomas]

There has been no response to this email from anyone from Code Intelligence.

Unless there are objections from the Apache Commons Community my next 
step will be to submit a PR to have the following modules removed from 
oss-fuzz:


apache-commons-bcel
apache-commons-beanutils
apache-commons-cli
apache-commons-codec
apache-commons-collections
apache-commons-configuration
apache-commons-io
apache-commons-jxpath
apache-commons-lang
apache-commons-logging

Code Intelligence (or anyone else) will remain free to add them back in 
the right place - under apache-commons should they wish to do so.


Mark



On 19/10/2022 10:56, Mark Thomas wrote:

Hi,

You are receiving this email as you are currently configured as the 
recipients for oss-fuzz reports for Apache Commons JXPath.


As per the discussion on the Apache Commons dev list[1], please make the 
following configuration changes to the oss-fuzz integrations with 
immediate effect:


- Move all oss-fuzz integrations added for *ALL* Apache Commons
   components to the oss-fuzz module for Apache-Commons:

   https://github.com/google/oss-fuzz/tree/master/projects/apache-commons

   There should *NOT* be separate oss-fuzz modules for each component


- Add the Google account for "secur...@commons.apache.org" to
   - the notifications for these issues
   - the ACL to enable this account to access the details for each report


Please notify dev@commons.apache.org and secur...@commons.apache.org 
when these changes have been completed.


Thanks,

Mark



[1]  https://lists.apache.org/thread/53vwy3g8w3f8nydz7jvxm8snrqx7msln

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: JEXL Security

[Mark Thomas]

On 31/10/2022 14:03, Henri Biestro wrote:

Let's restrict this discussion to the case of 'authenticated and authorised 
users' of an 'enterprise platform'.

When we talk about 'unsafe input' vs 'safe input', I'm still confused about 
what this actually entails. Let's assume we want those users to enter a (JEXL) 
expression to express their functional need (think of an enterprise spreadsheet 
of some kind with some built-in constraints). Is this considered an 'unsafe 
input' by essence ? If so, we need to 'sanitise' it to ensure it is 'harmless' 
- that being a broad definition.


If the users that can edit the JEXL are authenticated and authorised 
then then that is pretty much the definition of trusted input.



So, what does it mean to 'sanitise' such an input ? You can not do it by an 
external mean (external to JEXL); well, you could, but then there is almost no 
point in using JEXL then since you'd already done most of the hardwork of 
syntactic and semantic checks.
Assuming then that the only practical way to control what a script can do is 
through JEXL itself; splitting the platform scripting feature using different 
classes/modules/jars still requires configuring these environments properly. 
And we cannot do this through JEXL jars since we can't know those environment 
constraints before hand.

My proposal of enforcing a default configuration with a very narrow 
permeability is meant to ensure the platform developers at least realise they 
have to think about what they expose to whom.


Quoting from the project's home page:

"Its goal is to expose scripting features usable by technical operatives 
or consultants working with enterprise platforms."


I read that as the typical/expected usage scenario is with trusted 
input. I don't think we should break the typical usage to benefit an 
atypical one.



Isn't this the resolution strategy we used for the latest log4j2 and text CVEs 
- Avoid defauit configurations that are too permissive ?


Too permissive for what?

You have to consider the software in the context it is intended to be 
used. We don't consider Java to have an RCE because System.exec() 
exists. If an application developer was daft enough to expose 
System.exec() functionality to untrusted users, it would be treated as 
an application vulnerability, not as a Java issue.


The same consideration applies when considering JEXL. How is it intended 
to be used? / How is it typically used? Everything I have seen suggests 
that the intended / typical usage is with trusted input.


Mark



The primary driver for my thinking is observation of projects that have
tried to separate safe and unsafe functions via configuration and the
steady stream CVEs raised against those projects as security researchers
find ways to bypass the filtering. If there is a requirement to support
unsafe input then I think a stronger separation is required.

One solution would be different scripting engines for the two use cases
(trusted and untrusted) but that is likely to result in duplicate code
of some form - something else that I don't like.

Not knowing JEXL at all, would it be possible to have a "safe" JAR that
only provided features for untrusted input and an "extension" JAR you
could add to enable all the "dangerous" features for use with trusted input?

Mark






This sort of functionality is only required if an application is passing
untrusted / unsanitised input to JEXL. That seems an extremely dangerous
thing to do to me. Do we have any indications that any real world users
are doing this?

If the project starts down the road of being "secure by default for
untrusted input" then rather than the project avoiding future CVEs, it
opens itself up to a long stream of future CVEs as researchers find ways
to bypass the restrictions put in place.

My recommended approach for projects like JEXL would to be clearly
document that all input is expected to be trusted and then reject any
vulnerability reports based on processing untrused input.

If there are users that need to process untrusted input then I'd suggest
starting with asking how they are currently validating / sanitising that
input.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: JEXL Security

[Mark Thomas]

On 26/10/2022 08:58, Henri Biestro wrote:

Fair points, thank you. They seem to lead into the point of view that JEXL (or 
any scripting solution?) should not expose any feature that could be considered 
security-related avoiding the CVE potential turmoils alltogether. Trusted 
sanitised input is expected and required so this is a moot discussion.

In the EPM field at least, there are real world users who would like to have 
ways to express a computation, a formula, a label, - anything from a one line 
expression, snippet to script -through the platform/application they use daily 
- rather than depend and wait for IT/consultants/software-vendors to implement 
it. I'm not saying it is reasonable or achievable but is desired. The latest 
low-code hype is probably fuelled by the same functional needs.

Anyhow, it seems reasonable - at least useful - to help control the danger of 
allowing 'scripting' in a platform. It seems we reduce little of that issue if 
our stance on security is 'the only scripts you should run are scripts that are 
trusted'. Even a 'trusted user' can have a nefarious intent...
A 'sanitised input' can only be enforced by configuring precisely the (JEXL) 
engine (JexlPermissions, JexlFeatures, JexlOptions). Even if we rightfully 
reject any CVE due to a poorly configured engine, we can probably avoid the 
obvious ones in the first place.

Wether security should be addressed by some features seems to be the underlying 
chasm... Interesting conundrum :-)


Indeed.

The primary driver for my thinking is observation of projects that have 
tried to separate safe and unsafe functions via configuration and the 
steady stream CVEs raised against those projects as security researchers 
find ways to bypass the filtering. If there is a requirement to support 
unsafe input then I think a stronger separation is required.


One solution would be different scripting engines for the two use cases 
(trusted and untrusted) but that is likely to result in duplicate code 
of some form - something else that I don't like.


Not knowing JEXL at all, would it be possible to have a "safe" JAR that 
only provided features for untrusted input and an "extension" JAR you 
could add to enable all the "dangerous" features for use with trusted input?


Mark






This sort of functionality is only required if an application is passing
untrusted / unsanitised input to JEXL. That seems an extremely dangerous
thing to do to me. Do we have any indications that any real world users
are doing this?

If the project starts down the road of being "secure by default for
untrusted input" then rather than the project avoiding future CVEs, it
opens itself up to a long stream of future CVEs as researchers find ways
to bypass the restrictions put in place.

My recommended approach for projects like JEXL would to be clearly
document that all input is expected to be trusted and then reject any
vulnerability reports based on processing untrused input.

If there are users that need to process untrusted input then I'd suggest
starting with asking how they are currently validating / sanitising that
input.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Publish statement on Commons Text CVE

[Mark Thomas]

On 24/10/2022 19:54, Gary Gregory wrote:

The problem is that you sent your message from what I assume is a bogus
email reply address: p...@wolfgang-jung.net.invalid


No, the ".invalid" was added by the ASF mail servers.

See: https://blogs.apache.org/infra/entry/dmarc_filtering_on_lists_that

We can ask infra to change this behaviour but it requires disbaling all 
forms of message munging. For Commons, I think this is limited to the 
help message added as a footer.



To reply to this email I had to hand edit the reply to and am guessing that
maybe p...@wolfgang-jung.net will reach you, but, who knows... I usually
don't bother fiddling with this type of email address hassle.


That is the price we (the ASF) have to pay for avoiding DMARC issues. Or 
we change the list configuration.


Mark



WRT to the CVE, the issue was originally reported in Commons Configuration
where the code is basically the same (in a different package obviously). It
was decided that Commons Configuration warranted a CVE and we pushed a
release out. Since Text and Configuration are pretty much the same in this
area, it seemed consistent to issue a CVE and a new version for Text as
well.

Gary

On Mon, Oct 24, 2022, 11:45 Wolfgang Jung 
wrote:


Dear Gary,

I’ve sent this exact problem on Dec. 11 2021 to the mail-address mentioned
on the above changed security page: secur...@commons.apache.org
But never received a response… Therefore my question: Is this mail-address
still correct?

Best regards (and glad, that the default behaviour will be changed as
suggested),
  Wolfgang Jung

On 2022/10/19 21:28:59 Gary Gregory wrote:

Fixed! The Apache Commons Configuration Security page is now live:
https://commons.apache.org/proper/commons-configuration/security.html

Gary

On Wed, Oct 19, 2022 at 4:45 PM Gary Gregory  wrote:


Thank you for the brilliant detective work Bruno!

Gary

On Wed, Oct 19, 2022, 16:16 Bruno Kinoshita  wrote:


I had a look at the browser network tab, and saw an HTTP 302 location
redirect from Varnish. These redirects normally need to be configured

in

Varnish with some sort of rule.

I went back to your email, grabbed the SVN URL, stepped up a few
directories and saw an .htaccess at a parent level, that has a

redirect

rule for some commons components (it has for [configuration], not for
[text]). I think we just need to remove the configuration entry.



https://svn.apache.org/repos/infra/websites/production/commons/content/.htaccess


HTH,
Bruno

On Thu, 20 Oct 2022 at 08:22, Gary Gregory  wrote:


Well, I published the Configuration site to the usual svn:




https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-configuration/


which should be end up at:

https://commons.apache.org/proper/commons-configuration/index.html

but for me clicking on the "Security" (in the top left menu) does

not

take me to


https://commons.apache.org/proper/commons-configuration/security.html,

instead it redirects magically to
https://commons.apache.org/security.html

Commons Text is fine in this area. What gives?

Gary

On Wed, Oct 19, 2022 at 12:48 PM Gary Gregory 
wrote:


TY and merged. I'll publish later today.

Gary

On Wed, Oct 19, 2022 at 11:13 AM Arnout Engelen 


wrote:


On Wed, Oct 19, 2022 at 12:23 PM Gary Gregory 

wrote:


Would you be available to update the Commons Configuration page




https://github.com/apache/commons-configuration/blob/master/src/site/xdoc/security.xml

in the same way you did for Commons Text? The CVE is basically

the

same: https://nvd.nist.gov/vuln/detail/CVE-2022-33980



Happy to! Proposed

https://github.com/apache/commons-configuration/pull/230



Kind regards,

Arnout


On Tue, Oct 18, 2022 at 11:20 PM Gary Gregory 


wrote:


FYI: I updated the security page
https://commons.apache.org/proper/commons-text/security.html

Gary

On Tue, Oct 18, 2022 at 4:25 PM Gary Gregory <

garydgreg...@gmail.com> wrote:


I have an unpublished security page in the repo already.

Let's

not duplicate information like this PR does please. Publishing a
non-snapshot site is a pain and I don't want to do more than I have

to.

There is no need to buy in and promote the FUD on the front page

IMO. This

component will soon publish a security page and you can PR that

page (



https://github.com/apache/commons-text/blob/master/src/site/xdoc/security.xml
)

if you want to update the details.


TY!

On Tue, Oct 18, 2022, 09:52 Arnout Engelen <

en...@apache.org>

wrote:


Hello Commons,

As you might know Commons Text recently published a CVE.

It

seems there is

a fair bit of confusion about its severity online, so it

seems

like a good

idea to publish a statement around that on the website.

I've proposed one at

https://github.com/apache/commons-text/pull/374 and

I'd like to ask for your review & help publishing. Given

the

issue is

getting some attention it might be nice to publish

something

soon and maybe

refine it later ;). I'll also publish it at

Re: JEXL Security

[Mark Thomas]

On 24/10/2022 17:02, Henri Biestro (Apache) wrote:

Hello Commons;

JEXL-381 is an attempt at making JEXL's default more secure or at least
less 'permeable' wrt to the application/platform/JVM/file-system/host that
runs it. Based on JexlPermissions - a crude security visibility manager -,
this restricts the *default* behavior of what is visible to JEXL scripts to
the basics (lang, math, text, collection,...).
This does prevent a future crude test of some kind leading to a CVE stating
that JEXL poses a security risk since it can create processes or read the
whole file-system (cf JEXL-223).

I'd like opinions on this idea - assuming it is not a bad one - and how to
best expose it. Although JEXL 3.3 is compatible with JEXL 3.2, the runtime
behavior might break due to these new default security restrictions.
The net-cost is that current users (people actually using JEXL for its
intended purpose) will have to actively decide how much permeability they
need if they want to upgrade to JEXL 3.3 and retain functionality.  They
will probably gain at least some insight about their platform/product
security. Note that the basic mitigation - being as permeable as JEXL 3.2 -
costs only a line of code..

Ideas on how to best warn/expose/explain this to users and any element
pertaining to this subject is welcome. :-)


This sort of functionality is only required if an application is passing 
untrusted / unsanitised input to JEXL. That seems an extremely dangerous 
thing to do to me. Do we have any indications that any real world users 
are doing this?


If the project starts down the road of being "secure by default for 
untrusted input" then rather than the project avoiding future CVEs, it 
opens itself up to a long stream of future CVEs as researchers find ways 
to bypass the restrictions put in place.


My recommended approach for projects like JEXL would to be clearly 
document that all input is expected to be trusted and then reject any 
vulnerability reports based on processing untrused input.


If there are users that need to process untrusted input then I'd suggest 
starting with asking how they are currently validating / sanitising that 
input.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Correctly configuring Apache Commons components for oss-fuzz

[Mark Thomas]

Hi,

You are receiving this email as you are currently configured as the 
recipients for oss-fuzz reports for Apache Commons JXPath.


As per the discussion on the Apache Commons dev list[1], please make the 
following configuration changes to the oss-fuzz integrations with 
immediate effect:


- Move all oss-fuzz integrations added for *ALL* Apache Commons
  components to the oss-fuzz module for Apache-Commons:

  https://github.com/google/oss-fuzz/tree/master/projects/apache-commons

  There should *NOT* be separate oss-fuzz modules for each component


- Add the Google account for "secur...@commons.apache.org" to
  - the notifications for these issues
  - the ACL to enable this account to access the details for each report


Please notify dev@commons.apache.org and secur...@commons.apache.org 
when these changes have been completed.


Thanks,

Mark



[1]  https://lists.apache.org/thread/53vwy3g8w3f8nydz7jvxm8snrqx7msln

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [jxpath] reported CVE and path forward

[Mark Thomas]

On 15/10/2022 17:12, Mark Thomas wrote:

On 11/10/2022 16:25, Mike Drob wrote:

Thanks for this outline, Mark. Some questions in line.

Mike

On Tue, Oct 11, 2022 at 6:13 AM Mark Thomas  wrote:


Roman - don't do anything yet.

Commons folk, I suggest the following which is based on how we have
oss-fuzz setup on Tomcat.

1. Create a Google account for fuzz-testing@c.a.o
2. Put the password for the account in the PMC private shared repo so
any PMC member can access these reports.



If the dashboard doesn't support groups then maybe this is the only way.
Otherwise I think it would be very nice if we could use ASF committer 
info

or possibly github info since that often has mirrored groups of our
internal organizational structure.


Yes this would be ideal, but isn't currently possible.


3. Get Roman to add this account to the JXPath oss-fuzz project and the
projects for any other Commons components they have set up



Maybe it makes sense to group all of the apache-commons-* projects under
the general apache-commons module at
https://github.com/google/oss-fuzz/tree/master/projects/
That module is the one that was initially set up, including compress and
imaging as mentioned by Matt S upthread.


+1.


4. Review the reports once we have access via fuzz-testing@c.a.o (I'll
volunteer to help with this as I have some experience from Tomcat which
should speed things up)



I would be happy to volunteer.


Tx


5. Ask the ASF security to get all CVEs allocated by Google to Apache
Commons components transferred to the ASF (we can edit them once we have
ownership)
6. Ask the ASF security team to contact Google to make sure that Google
follows the CNA rules and stops allocating CVEs for projects outside of
its scope.

If there is agreement to this approach, I'll volunteer to get the things
on the list above done. Depending on the number of issues, I may be
asking for help with 4.

Given this is all public, I don't see any need to use the security@c.a.o
list unless we come across a valid, non-public issue.


Based on the feedback I'm amending my proposal to replace the original 
step 3) with:


3a) Get the new shared account added to the existing apache-commons module
3b) Request that Code Intelligence move these individual modules under 
the existing apache-commons module.


I'm going to go ahead and start this process with one further small 
amendment after double-checking how Tomcat is set up.


The Google account will be for secur...@commons.apache.org so that 
reports are delivered directly to the security@c.a.o list.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [jxpath] reported CVE and path forward

[Mark Thomas]

On 11/10/2022 16:25, Mike Drob wrote:

Thanks for this outline, Mark. Some questions in line.

Mike

On Tue, Oct 11, 2022 at 6:13 AM Mark Thomas  wrote:


Roman - don't do anything yet.

Commons folk, I suggest the following which is based on how we have
oss-fuzz setup on Tomcat.

1. Create a Google account for fuzz-testing@c.a.o
2. Put the password for the account in the PMC private shared repo so
any PMC member can access these reports.



If the dashboard doesn't support groups then maybe this is the only way.
Otherwise I think it would be very nice if we could use ASF committer info
or possibly github info since that often has mirrored groups of our
internal organizational structure.


Yes this would be ideal, but isn't currently possible.


3. Get Roman to add this account to the JXPath oss-fuzz project and the
projects for any other Commons components they have set up



Maybe it makes sense to group all of the apache-commons-* projects under
the general apache-commons module at
https://github.com/google/oss-fuzz/tree/master/projects/
That module is the one that was initially set up, including compress and
imaging as mentioned by Matt S upthread.


+1.


4. Review the reports once we have access via fuzz-testing@c.a.o (I'll
volunteer to help with this as I have some experience from Tomcat which
should speed things up)



I would be happy to volunteer.


Tx


5. Ask the ASF security to get all CVEs allocated by Google to Apache
Commons components transferred to the ASF (we can edit them once we have
ownership)
6. Ask the ASF security team to contact Google to make sure that Google
follows the CNA rules and stops allocating CVEs for projects outside of
its scope.

If there is agreement to this approach, I'll volunteer to get the things
on the list above done. Depending on the number of issues, I may be
asking for help with 4.

Given this is all public, I don't see any need to use the security@c.a.o
list unless we come across a valid, non-public issue.


Based on the feedback I'm amending my proposal to replace the original 
step 3) with:


3a) Get the new shared account added to the existing apache-commons module
3b) Request that Code Intelligence move these individual modules under 
the existing apache-commons module.



Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [jxpath] reported CVE and path forward

[Mark Thomas]

there

are

now other projects in oss-fuzz for other Commons components.

The apache-commons project (that contains Imaging, Compress, and

Geometry)

had a custom policy, agreed in the mailing list and later with

someone

that

maintained oss-fuzz, where ASF issues were not disclosed in 90

days, but

instead gave us more time to align the issues with our ASF

process.


I am not sure if these other projects follow similar policy, nor

if

the

ASF

developers are aware of the integration (I only keep an eye on
compress/imaging/geometry notifications from the apache-commons

project).

Also not sure whether it's better to have everything in a single

project in

oss-fuzz or in separate projects. I'm happy with Imaging being a

single

oss-fuzz project if needed, but I prefer to keep the policy of

giving a

longer time to review the issues. I try to review important issues

quickly,

but the ones that I know are very low priority or won't be fixed

(e.g.

OOM)

I leave for later.

Cheers
Bruno

On Tue, 11 Oct 2022 at 09:01, Matt Sicker 

wrote:



I get emails about some of the Commons fuzzing things, but I was

only

aware of it being enabled for compress and imaging.

On Mon, Oct 10, 2022 at 1:37 PM Roman Wagner
 wrote:


Hi all,

I am working for Code Intelligence we did our best to find a

maintainer

for

the oss-fuzz project. Unfortunately we've got no feedback

until

now,

but

It

seems to be an unmaintained project except for some typo fixes

since

some

years. I am not sure yet to which mailing list the bug report

was

send

to,

but I will check that information with the team.

However, I am really happy that there is some interest in

fixing the

RCE. I

have verified the vulnerability and for me it seems to be a

valid

RCE. @Mark Thomas should we continue to discuss further

details

via

secur...@apache.org?

Best regards
Roman




-

To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org










-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org









-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [jxpath] reported CVE and path forward

[Mark Thomas]

Hmm.

There are various red flags here that suggest to me that this issue is 
likely not valid.


1. The source is oss-fuzz. I have been dealing with oss-fuzz issues for 
Apache Tomcat and so far out of the 30+ issues raised (the majority 
marked as security relevant) not one of the issues was a vulnerability.


2. The CNA is Google. Google is not authorised to issue CVEs for ASF 
projects accept in strictly limited circumstances that do not apply here.


3. There is no record of CVE-2022-41852 on *ANY* ASF security list.

The next steps are:

- Identify the current JXPath maintainers (or some volunteers to clean
  up this mess)

- Gain access to the details of the reports

- Assess the reports

- Invalidate / update the CVEs as required

I don't see meaningful commits to the repo after 2015 so I suspect we'll 
be looking for volunteers.


Mark



On 10/10/2022 16:19, Mike Drob wrote:

Howdy folks,

I recently saw that there was a reported CVE[1] for Apache JXPath that became 
public due to no response to the reporter over 90 days. I am uncertain if the 
reporter had tried reaching out to the appropriate security lists before-hand 
and was ignored, or failed to follow our established procedures. Regardless, 
the issue is now public.

I have not personally verified the vulnerability, nor assessed the impact. NIST 
thinks it is a Big Deal, though, scoring it 9.8/10 [2]

It is hard to assess impact since the project does not publish artifacts to 
maven central, but I'm also taking that as an indicator of low adoption at this 
point in time. Further, the project has not had a release since 2015. There has 
been very limited mailing list activity, and the last 5 years of commits have 
only been typo/comment fixes.

If there is no community around it, is there a path to retirement? What are the 
next steps?

Thanks,
Mike

[1]: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47133
[2]: https://nvd.nist.gov/vuln/detail/CVE-2022-41852

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[ANNOUNCEMENT] Commons Daemon 1.3.2 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Daemon 1.3.2.

The Apache Commons Daemon software library provides a generic Daemon
(unix) or Service (Windows) wrapper for Java code.

Version 1.3.2 is a bugfix release.

A full list of changes can be found at
https://commons.apache.org/proper/commons-daemon/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-daemon/download_daemon.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Daemon, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Daemon website:

https://commons.apache.org/proper/commons-daemon/

Mark
on behalf of the Apache Commons community

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE][RESULT] Release Apache Commons Daemon 1.3.2 based on RC1

[Mark Thomas]

The following votes were cast:

Binding:
+1: markt, linow, ggregory

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


On 05/10/2022 15:36, Mark Thomas wrote:
We have fixed a few bugs since Apache Commons Daemon 1.3.1 was released, 
so I would like to release Apache Commons Daemon 1.3.2.


Apache Commons Daemon 1.3.2 RC1 is available for review here:
     https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.2-RC1 
(svn revision 57178)


The Git tag commons-daemon-1.3.2-RC1 commit for this RC is 
4189f2798f20180ea9f36c00bb5a05702971ba95 which you can browse here:


https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=4189f2798f20180ea9f36c00bb5a05702971ba95
You may checkout this tag using:
     git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.2-RC1 commons-daemon-1.3.2-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1598/commons-daemon/commons-daemon/1.3.2/

These are the artifacts and their hashes:
commons-dameon-1.3.2-bin-windows.zip=4a4779629b76e5c7fb7885af51f0468c26ca958e6a243b60787c1576529fed48f0ec5b257ef5fcd71e48de8625d384aa27391e74e0ae4b43b0e7b3dbe8ca3d78
commons-daemon-1.3.2-bin.tar.gz=be2677b352cfff99ba4447468757136416a9477eadb61ec8b35e2fb72fadd40e7405f0dfc57e265957a938ff4e37f8814d731b1bf5893191f1104b0101017eb5
commons-daemon-1.3.2-bin.zip=130d658e09cd5a4eb82a175354ae18ad2ddd62e74fc48a661e6ce2fa08c294ae8d0cbc42ae11708284c46feae600e9c10989723035308d4dfa458bd919bfb1ec
commons-daemon-1.3.2-cyclonedx.json=c75beb453a4930367ce29d621bcf16a7e23f8c5f19bd6ff2f6515a0d27650424e03fdd4340a50e1bb4bfd17a2e62b8005367add17a384f2c2a7d282c20695797
commons-daemon-1.3.2-cyclonedx.xml=d407f88a5321297712e5d35554808caba4b9818cb7d22cd5996cc984b22146df02506814d03434e8afafbdc4e4a578c7075257c39d7d97b526811454c6bf0cf7
commons-daemon-1.3.2-javadoc.jar=7921b2bc5bf200c25506c5f57920322c29f7a60b8568dc7ab858cb952f2a21179720a8428d4ee3a752bceb8b9ac5096c6de8953aafac9b01e7c9832e46495861
commons-daemon-1.3.2-native-src.tar.gz=9908858ebe7e08873a0d1a83c88f78ca6eccacab24bf5fd2980f91df128d0c3407fd68351ea0736214f6dc758f8451b0e0b1fa7ccaf593479659c7c1d3acbf95
commons-daemon-1.3.2-native-src.zip=264f0ae6378afb1ec78cd518dde054f26c03a10ac3330c4da8829c5774c521a4ca4b1981e068a98913c73dc8396210062985fdcc55bd8415238afb2d5ab515af
commons-daemon-1.3.2-sources.jar=5f23cec53458818ea55572f83d93ebe1573de3371707090a5ff42e3dda60cd81387fa74d8fbc3999cab8a2394a0d1aadf5023377dffab1e5c1a9fa1b4de78b36
commons-daemon-1.3.2-src.tar.gz=241f3b15ef2a5e11cf802adef8c5e07d417a0c614188123db197b76154ed6ef6fc5dfaa7acff3bfac067b1b7978c3e0674bba2efc776305a2ab28a23be1c7f89
commons-daemon-1.3.2-src.zip=0f15f9277691cc259171ef20139fcfd8d4039da1ddc9a45aed0870d6ed6e3c78aacc10a535cc05c28ac50c9beb1b47280435b0ab339915e28f4aeda5087e5f0a
commons-dameon-1.3.2.spdx.rdf.xml=b80766a716e02d53b1a1a674653280bb4bf516b111ab760819ed5bc240562d66161299bca2533ccfd20ab97560da8f6de55387b5ef94cac9cbf259b1765e3b90




Details of changes since 1.3.1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.2-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.2-RC1/site/changes-report.html


KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)




For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.2-RC1 commons-daemon-1.3.2-RC1

cd commons-daemon-1.3.2-RC1

2) Check Apache licenses

This step is not required if the site includes a RAT report page which 
you then must check.


mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page which 
you then must check.


mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page 
which you then must check.


mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V clean package

You can record the Maven and Java version produced by -V in your VOTE 
reply.

To gather OS information from a command line:
Windows: ver
Linux: uname -a

5) Build the site for a single module project

Note: Some plugins require the components to be installed instead of 
packaged.


mvn site
Check

Re: [VOTE] Release Apache Commons Daemon 1.3.2 based on RC1

[Mark Thomas]

On 05/10/2022 15:36, Mark Thomas wrote:


Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

   [X] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Apache Commons Daemon 1.3.2 based on RC1

[Mark Thomas]

We have fixed a few bugs since Apache Commons Daemon 1.3.1 was released, 
so I would like to release Apache Commons Daemon 1.3.2.


Apache Commons Daemon 1.3.2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.2-RC1 
(svn revision 57178)


The Git tag commons-daemon-1.3.2-RC1 commit for this RC is 
4189f2798f20180ea9f36c00bb5a05702971ba95 which you can browse here:


https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=4189f2798f20180ea9f36c00bb5a05702971ba95
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.2-RC1 commons-daemon-1.3.2-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1598/commons-daemon/commons-daemon/1.3.2/

These are the artifacts and their hashes:
commons-dameon-1.3.2-bin-windows.zip=4a4779629b76e5c7fb7885af51f0468c26ca958e6a243b60787c1576529fed48f0ec5b257ef5fcd71e48de8625d384aa27391e74e0ae4b43b0e7b3dbe8ca3d78
commons-daemon-1.3.2-bin.tar.gz=be2677b352cfff99ba4447468757136416a9477eadb61ec8b35e2fb72fadd40e7405f0dfc57e265957a938ff4e37f8814d731b1bf5893191f1104b0101017eb5
commons-daemon-1.3.2-bin.zip=130d658e09cd5a4eb82a175354ae18ad2ddd62e74fc48a661e6ce2fa08c294ae8d0cbc42ae11708284c46feae600e9c10989723035308d4dfa458bd919bfb1ec
commons-daemon-1.3.2-cyclonedx.json=c75beb453a4930367ce29d621bcf16a7e23f8c5f19bd6ff2f6515a0d27650424e03fdd4340a50e1bb4bfd17a2e62b8005367add17a384f2c2a7d282c20695797
commons-daemon-1.3.2-cyclonedx.xml=d407f88a5321297712e5d35554808caba4b9818cb7d22cd5996cc984b22146df02506814d03434e8afafbdc4e4a578c7075257c39d7d97b526811454c6bf0cf7
commons-daemon-1.3.2-javadoc.jar=7921b2bc5bf200c25506c5f57920322c29f7a60b8568dc7ab858cb952f2a21179720a8428d4ee3a752bceb8b9ac5096c6de8953aafac9b01e7c9832e46495861
commons-daemon-1.3.2-native-src.tar.gz=9908858ebe7e08873a0d1a83c88f78ca6eccacab24bf5fd2980f91df128d0c3407fd68351ea0736214f6dc758f8451b0e0b1fa7ccaf593479659c7c1d3acbf95
commons-daemon-1.3.2-native-src.zip=264f0ae6378afb1ec78cd518dde054f26c03a10ac3330c4da8829c5774c521a4ca4b1981e068a98913c73dc8396210062985fdcc55bd8415238afb2d5ab515af
commons-daemon-1.3.2-sources.jar=5f23cec53458818ea55572f83d93ebe1573de3371707090a5ff42e3dda60cd81387fa74d8fbc3999cab8a2394a0d1aadf5023377dffab1e5c1a9fa1b4de78b36
commons-daemon-1.3.2-src.tar.gz=241f3b15ef2a5e11cf802adef8c5e07d417a0c614188123db197b76154ed6ef6fc5dfaa7acff3bfac067b1b7978c3e0674bba2efc776305a2ab28a23be1c7f89
commons-daemon-1.3.2-src.zip=0f15f9277691cc259171ef20139fcfd8d4039da1ddc9a45aed0870d6ed6e3c78aacc10a535cc05c28ac50c9beb1b47280435b0ab339915e28f4aeda5087e5f0a
commons-dameon-1.3.2.spdx.rdf.xml=b80766a716e02d53b1a1a674653280bb4bf516b111ab760819ed5bc240562d66161299bca2533ccfd20ab97560da8f6de55387b5ef94cac9cbf259b1765e3b90




Details of changes since 1.3.1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.2-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.2-RC1/site/changes-report.html


KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)




For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.2-RC1 commons-daemon-1.3.2-RC1

cd commons-daemon-1.3.2-RC1

2) Check Apache licenses

This step is not required if the site includes a RAT report page which 
you then must check.


mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page which 
you then must check.


mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page 
which you then must check.


mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V clean package

You can record the Maven and Java version produced by -V in your VOTE reply.
To gather OS information from a command line:
Windows: ver
Linux: uname -a

5) Build the site for a single module project

Note: Some plugins require the components to be installed instead of 
packaged.


mvn site
Check the site reports in:
- Windows: target\site\index.html
- Linux: target/site/index.html

6) Build the site for a multi-module project

mvn site
mvn site:stage
Check the site reports in:
- Windows: target\site\index.html
- Linux: target

Re: [Daemon] release soon?

[Mark Thomas]

I'll try and take a look this month.

Mark

On 04/10/2022 12:47, Gary Gregory wrote:

Hi Mark or anyone,

Do you have any time for releasing Daemon to pick up the logging fix?

Thank you,
Gary



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[ANNOUNCEMENT] Commons Daemon 1.3.1 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Daemon 1.3.1.

The Apache Commons Daemon software library provides a generic Daemon
(unix) or Service (Windows) wrapper for Java code.

Version 1.3.1 is a mainly bugfix release.

A full list of changes can be found at
https://commons.apache.org/proper/commons-daemon/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-daemon/download_daemon.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Daemon, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Daemon website:

https://commons.apache.org/proper/commons-daemon/

Mark
on behalf of the Apache Commons community

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.3.1 based on RC1

[Mark Thomas]

On 05/05/2022 14:04, Gary Gregory wrote:


Can't build the site due to https://issues.apache.org/jira/browse/RAT-300


The JDepend plugin has a similar issue.

For the benefit of the archives I built both the RAT plugin and JDepend 
plugin from source and then built the site for the 1.3.1 release with 
the resulting snapshots.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE][RESULT] Release Apache Commons Daemon 1.3.1 based on RC1

[Mark Thomas]

The following votes were cast:

Binding:
+1: kinow, markt, ggregory

The vote therefore passes.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.3.1 based on RC1

[Mark Thomas]

On 03/05/2022 16:43, Mark Thomas wrote:


   [X] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...


Tested with Tomcat 10.1.x

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [daemon] please add support for riscv64 arch

[Mark Thomas]

Done.

Thanks for the patch.

Mark


On 04/05/2022 06:56, Bo YU wrote:

Hi,
Please add support for riscv64 arch.
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1010381;filename=riscv64.diff;msg=5


If you need me to do more tests on real riscv64 hardware, please let me
know,
Thank you.

BR,
Bo



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Apache Commons Daemon 1.3.1 based on RC1

[Mark Thomas]

We have fixed a few bugs since Apache Commons Daemon 1.3.0 was released, 
so I would like to release Apache Commons Daemon 1.3.1.


Apache Commons Daemon 1.3.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.1-RC1 
(svn revision 54240)


The Git tag commons-daemon-1.3.1-RC1 commit for this RC is 
466cc9a2442412dbb25dc5dad803982a7f864264 which you can browse here:


https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=466cc9a2442412dbb25dc5dad803982a7f864264
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.1-RC1 commons-daemon-1.3.1-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1584/commons-daemon/commons-daemon/1.3.1/

These are the artifacts and their hashes:

#Release SHA-512s
#Tue May 03 15:19:45 BST 2022
commons-daemon-1.3.1-bin-windows.zip=1219e746c0dbc6d077d89f6c1140112e95f80b0c761f38fc3effd4008ab1051ae30a2f40ab74f7671212b565365dba45f1a6f3e2a8d703078faac260d33382c3
commons-daemon-1.3.1-bin.tar.gz=101fa25c723694ed7b1475a178aec40b5c94c6e8bdcfb17411841606148db25dc46825539a5afca02413fefa2566002d69310203f132edfb4e49f3018f158504
commons-daemon-1.3.1-bin.zip=c64eafbe8447a32ec6cc7a2bc94241420b9fb64a43bf2c9e5da116f7b3306706b06c02ee1b71e98c47b2151dd2e8968eee7b7bf8230d86bb1d43095f1521ca80
commons-daemon-1.3.1-javadoc.jar=a2824eda38bad3342644d8a22b67e6ac970c4aa44674eb8951f6e7c18f97fd3941b04b48ab1ece08866b0da01edb8d77f0931c9af5b037d46e6ae501dad20396
commons-daemon-1.3.1-native-src.tar.gz=de1c5352e4f17a717f06ac95cf9f2734ebb29ad85051779829ac67d83b330951947940616d4c1cc87d1cbb8a2415d674a3e4b2d7e2b33a5d34c9fae2fb9c1f16
commons-daemon-1.3.1-native-src.zip=cb046fc4fe0a2e15e793aa2420b632a27acfb716464091d6dea50ce12e04c6f6ca741590e2e9f351b3f1e0cd58747199aaa85b423c688df9b0dcf2775fba52c7
commons-daemon-1.3.1-sources.jar=32b6a04fc01a4fca5af9a437d6f54d5b0980665f4badb3c3d2e4bed11d201bc2ac2cbfbfbba0d5fe47492fe26ef2ea6b6fb6e6c5559a0c645872a10b017baa01
commons-daemon-1.3.1-src.tar.gz=b810ac152f8296d980a4fb3786eff9d147b234dc2377df5fe1bded0824c694c9e82a7ef50b0a63c3e6432dfc4684a3aa2ce8d583aacb740bd4664c3dfb8b8f16
commons-daemon-1.3.1-src.zip=c4a8829a89965c31d250f632380e15ef4494d0c6017119e023d1e48889974a0a76694768182ca36b82101da404e0b4cd0c9769973d15602df248967ea7166f11


KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)


For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.1-RC1 commons-daemon-1.3.1-RC1

cd commons-daemon-1.3.1-RC1

2) Check Apache licenses

This step is not required if the site includes a RAT report page which 
you then must check.


mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page which 
you then must check.


mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page 
which you then must check.


mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V clean package

You can record the Maven and Java version produced by -V in your VOTE reply.
To gather OS information from a command line:
Windows: ver
Linux: uname -a

5) Build the site for a single module project

Note: Some plugins require the components to be installed instead of 
packaged.


mvn site
Check the site reports in:
- Windows: target\site\index.html
- Linux: target/site/index.html

6) Build the site for a multi-module project

mvn site
mvn site:stage
Check the site reports in:
- Windows: target\site\index.html
- Linux: target/site/index.html

-the end-

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[DAEMON] Releasing 1.3.1 soon

[Mark Thomas]

Hi all,

This is a heads up I'm planning a Daemon 1.3.1 release soon. I want to 
finish off the work on the log messages and then tag. I expect that will 
be either later today or early next week.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] consider moving to a directory per release, rather than binaries and source

[Mark Thomas]

On 16/03/2022 17:53, sebb wrote:

As the subject says.

We currently use separate directories for binaries and source, each of
which may contain multiple versions.

This is a bit awkward to maintain compared with a directory per
release which would contain both binaries and source.

I think we should consider moving to individual release directories.

This would mean changes to various scripts etc, so would not be trivial.

If we do decide to do so, it would make sense to try this on a
component that normally only has one current version on release.

WDYT?


I like the idea in general. It makes managing releases a little easier.

However, there would be an impact is on users that have scripted 
downloads. The change in the location will require changes to all of 
those scripts. Does the benefit (primarily for us) justify the cost of 
those changes (primarily for users)? This might be something to thing 
about when we have a new major version.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [POOL] Archive pre-Java 7 versions?

[Mark Thomas]

On 16/03/2022 15:48, sebb wrote:

As for DBCP, I wonder if there are likely to be any updates to the
earlier versions of Pool?


Seems unlikely.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[ANNOUNCEMENT] Commons Daemon 1.3.0 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Daemon 1.3.0.

The Apache Commons Daemon software library provides a generic Daemon
(unix) or Service (Windows) wrapper for Java code.

Version 1.3.0 is a mainly bugfix release but also increases the minimum 
Java version to Java 7.


A full list of changes can be found at
https://commons.apache.org/proper/commons-daemon/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-daemon/download_daemon.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Daemon, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Daemon website:

https://commons.apache.org/proper/commons-daemon/

Mark
on behalf of the Apache Commons community

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE][RESULT] Release Apache Commons Daemon 1.3.0 based on RC1

[Mark Thomas]

The following votes were cast:

Binding:
+1: ggregory, markt, kinow

No other votes were cast. The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


On 11/03/2022 13:32, Mark Thomas wrote:
Since the 1.2.4 release, the minimum Java version has been updated to 
Java 7 and a handful of bugs have been fixed so I would like to release 
Apache Commons Daemon 1.3.0.


Apache Commons Daemon 1.3.0 RC1 is available for review here:
     https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1 
(svn revision 52984)


The Git tag commons-daemon-1.3.0-RC1 commit for this RC is 
73708a0d774304cd4e02eb675fc599f42bc5e150 which you can browse here:


https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=73708a0d774304cd4e02eb675fc599f42bc5e150 


You may checkout this tag using:
     git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.0-RC1 commons-daemon-1.3.0-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1579/commons-daemon/commons-daemon/1.3.0/ 



These are the artifacts and their hashes:

#Release SHA-512s
commons-daemon-1.3.0.jar=748f3ac828feb9284b192e9c3f7d50cbe3c3bc101ba477a269070b296b9a3a69f626cd546bab45e7a24ac9b9503c01a56d7774192c16765b5995a96f8fc3c3e0 

commons-daemon-1.3.0-bin.tar.gz=53c1fee9bb14ae84034ec06e45693b86927493124fb050a598928884a985c54878710f63063e45b095469ffe45050ed87663de320df2140e0678642e21938592 

commons-daemon-1.3.0-bin.zip=cacc6d59b5baa9bd4c94da2ae1818d08d32cb25ddab6a21aa9e44e735b274cc78599c6342a3af34337152c3915e84055b28e4081e18b6c29e8cb73a604af4e70 

commons-daemon-1.3.0-bin-windows.zip=ff545f4b1c8a5f10b471e579e0b4c739e6e1f393f74f36ff35cfe62cced3febef20451b15b418e534c9e3640a9502e4c9da47a59e7ff3c772b439f8b8929f223 

commons-daemon-1.3.0-native-src.tar.gz=86588c1ce9e26a365235d8629137a6fea8b7bd1f4920063d620f7bf713e17bafc2fd152f46a52edd420d8090122dac4250a531e683b435948ae12462175807b4 

commons-daemon-1.3.0-native-src.zip=2732e26dd0e98867d01155bbcec8dc01810a4c573bc4eeb1ab398071428bafc698588238365e1436cc8ba9838735769637f43a899f51440b3112d7b42283bfb1 

commons-daemon-1.3.0-src.tar.gz=392ae1a4f36294c31f8f549c61bdf0a9fcd59a1e4eee3c54ceba30473066184271636b11ee6073526640c245d3f3a94d1d4d34413787c5b3323e6eedc7026816 

commons-daemon-1.3.0-src.zip=932d907ae51d59818f67d083fcd8f769b71644ac2d7af7131550b1abe729299a25bbada617cb418af4159006f2a3fc2cc44f8292e058ab6e1aa5b1072c1ffad1 



Note the Windows binaries are also signed using the Digicert ONE code 
signing service with the Commons PMC key.



Details of changes since 1.2.4 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/RELEASE-NOTES.txt 



https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/site/changes-report.html 



KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.3.0 based on RC1

[Mark Thomas]

On 11/03/2022 13:32, Mark Thomas wrote:

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

   [X] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...


Tested with Apache Tomcat 10.1.0-M12 on Windows 2022 server.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.3.0 based on RC1

[Mark Thomas]

On 11/03/2022 13:37, Gary Gregory wrote:

Hi Mark,

Thank you for rolling a release candidate.

The release notes should contain the changes not a link to part of a web
site,


The release notes have been this way since 2017.


and the link is broken too
https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/site/changes-report.html


That is because the web site is not part of the release and not part of 
the release vote so it hasn't been uploaded to dist.a.o



If I download the zip or tar i should have the release notes right there.
I'm not sure how you created the RC, but we normally generate the release
notes from the changes.xml file through a Maven plugin.


That isn't how Daemon has been set up. If you want to change this feel 
free and we can pick up the change in the next RC (if there is one) or 
the next release.


I will note that:

mvn deploy -Dcommons.release.isDistModule=true -Prelease

didn't complete cleanly but didn't appear to affect the release 
artifacts. I've now figured out that was due to MNG-7316 and I'll add an 
note to HOW-TO-RELEASE.txt for future reference.


Mark



Gary

On Fri, Mar 11, 2022, 08:32 Mark Thomas  wrote:


Since the 1.2.4 release, the minimum Java version has been updated to
Java 7 and a handful of bugs have been fixed so I would like to release
Apache Commons Daemon 1.3.0.

Apache Commons Daemon 1.3.0 RC1 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1
(svn revision 52984)

The Git tag commons-daemon-1.3.0-RC1 commit for this RC is
73708a0d774304cd4e02eb675fc599f42bc5e150 which you can browse here:


https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=73708a0d774304cd4e02eb675fc599f42bc5e150
You may checkout this tag using:
  git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
--branch commons-daemon-1.3.0-RC1 commons-daemon-1.3.0-RC1

Maven artifacts are here:


https://repository.apache.org/content/repositories/orgapachecommons-1579/commons-daemon/commons-daemon/1.3.0/

These are the artifacts and their hashes:

#Release SHA-512s

commons-daemon-1.3.0.jar=748f3ac828feb9284b192e9c3f7d50cbe3c3bc101ba477a269070b296b9a3a69f626cd546bab45e7a24ac9b9503c01a56d7774192c16765b5995a96f8fc3c3e0

commons-daemon-1.3.0-bin.tar.gz=53c1fee9bb14ae84034ec06e45693b86927493124fb050a598928884a985c54878710f63063e45b095469ffe45050ed87663de320df2140e0678642e21938592

commons-daemon-1.3.0-bin.zip=cacc6d59b5baa9bd4c94da2ae1818d08d32cb25ddab6a21aa9e44e735b274cc78599c6342a3af34337152c3915e84055b28e4081e18b6c29e8cb73a604af4e70

commons-daemon-1.3.0-bin-windows.zip=ff545f4b1c8a5f10b471e579e0b4c739e6e1f393f74f36ff35cfe62cced3febef20451b15b418e534c9e3640a9502e4c9da47a59e7ff3c772b439f8b8929f223

commons-daemon-1.3.0-native-src.tar.gz=86588c1ce9e26a365235d8629137a6fea8b7bd1f4920063d620f7bf713e17bafc2fd152f46a52edd420d8090122dac4250a531e683b435948ae12462175807b4

commons-daemon-1.3.0-native-src.zip=2732e26dd0e98867d01155bbcec8dc01810a4c573bc4eeb1ab398071428bafc698588238365e1436cc8ba9838735769637f43a899f51440b3112d7b42283bfb1

commons-daemon-1.3.0-src.tar.gz=392ae1a4f36294c31f8f549c61bdf0a9fcd59a1e4eee3c54ceba30473066184271636b11ee6073526640c245d3f3a94d1d4d34413787c5b3323e6eedc7026816

commons-daemon-1.3.0-src.zip=932d907ae51d59818f67d083fcd8f769b71644ac2d7af7131550b1abe729299a25bbada617cb418af4159006f2a3fc2cc44f8292e058ab6e1aa5b1072c1ffad1

Note the Windows binaries are also signed using the Digicert ONE code
signing service with the Commons PMC key.


Details of changes since 1.2.4 are in the release notes:


https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/RELEASE-NOTES.txt


https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/site/changes-report.html

KEYS:
https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Apache Commons Daemon 1.3.0 based on RC1

[Mark Thomas]

Since the 1.2.4 release, the minimum Java version has been updated to 
Java 7 and a handful of bugs have been fixed so I would like to release 
Apache Commons Daemon 1.3.0.


Apache Commons Daemon 1.3.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1 
(svn revision 52984)


The Git tag commons-daemon-1.3.0-RC1 commit for this RC is 
73708a0d774304cd4e02eb675fc599f42bc5e150 which you can browse here:


https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=73708a0d774304cd4e02eb675fc599f42bc5e150
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.0-RC1 commons-daemon-1.3.0-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1579/commons-daemon/commons-daemon/1.3.0/

These are the artifacts and their hashes:

#Release SHA-512s
commons-daemon-1.3.0.jar=748f3ac828feb9284b192e9c3f7d50cbe3c3bc101ba477a269070b296b9a3a69f626cd546bab45e7a24ac9b9503c01a56d7774192c16765b5995a96f8fc3c3e0
commons-daemon-1.3.0-bin.tar.gz=53c1fee9bb14ae84034ec06e45693b86927493124fb050a598928884a985c54878710f63063e45b095469ffe45050ed87663de320df2140e0678642e21938592
commons-daemon-1.3.0-bin.zip=cacc6d59b5baa9bd4c94da2ae1818d08d32cb25ddab6a21aa9e44e735b274cc78599c6342a3af34337152c3915e84055b28e4081e18b6c29e8cb73a604af4e70
commons-daemon-1.3.0-bin-windows.zip=ff545f4b1c8a5f10b471e579e0b4c739e6e1f393f74f36ff35cfe62cced3febef20451b15b418e534c9e3640a9502e4c9da47a59e7ff3c772b439f8b8929f223
commons-daemon-1.3.0-native-src.tar.gz=86588c1ce9e26a365235d8629137a6fea8b7bd1f4920063d620f7bf713e17bafc2fd152f46a52edd420d8090122dac4250a531e683b435948ae12462175807b4
commons-daemon-1.3.0-native-src.zip=2732e26dd0e98867d01155bbcec8dc01810a4c573bc4eeb1ab398071428bafc698588238365e1436cc8ba9838735769637f43a899f51440b3112d7b42283bfb1
commons-daemon-1.3.0-src.tar.gz=392ae1a4f36294c31f8f549c61bdf0a9fcd59a1e4eee3c54ceba30473066184271636b11ee6073526640c245d3f3a94d1d4d34413787c5b3323e6eedc7026816
commons-daemon-1.3.0-src.zip=932d907ae51d59818f67d083fcd8f769b71644ac2d7af7131550b1abe729299a25bbada617cb418af4159006f2a3fc2cc44f8292e058ab6e1aa5b1072c1ffad1

Note the Windows binaries are also signed using the Digicert ONE code 
signing service with the Commons PMC key.



Details of changes since 1.2.4 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/site/changes-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[DAEMON] Tagging 1.3.0

[Mark Thomas]

Hi all,

Just a heads up that I'm planning on tagging Daemon 1.3.0 soon - 
probably tomorrow.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-daemon] 02/02: Copyright year update to 2022

[Mark Thomas]

On 24/02/2022 18:30, Gary Gregory wrote:

Should the end year be a constant string?


In a perfect world - yes.

But https://xkcd.com/1205/

Given my (lack of) C skills, search and replace in the IDE is my plan 
for the foreseeable future.


Mark




Gary

On Thu, Feb 24, 2022, 13:10  wrote:


This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-daemon.git

commit af00cbc3095e1798b3122a48ffe0d0c9d43d035d
Author: Mark Thomas 
AuthorDate: Thu Feb 24 18:09:33 2022 +

 Copyright year update to 2022
---
  src/native/unix/native/help.c  | 2 +-
  src/native/unix/native/jsvc-unix.c | 2 +-
  src/native/windows/apps/prunmgr/prunmgr.rc | 6 +++---
  src/native/windows/apps/prunsrv/prunsrv.c  | 2 +-
  src/native/windows/apps/prunsrv/prunsrv.rc | 2 +-
  src/native/windows/resources/license.rtf   | 2 +-
  6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/native/unix/native/help.c b/src/native/unix/native/help.c
index ea92d29..d79aeea 100644
--- a/src/native/unix/native/help.c
+++ b/src/native/unix/native/help.c
@@ -124,7 +124,7 @@ void help(home_data *data)
  printf("--enable-preview\n");
  printf("Java 11 --enable-preview option. Passed as it is to
JVM\n");
  printf("\njsvc (Apache Commons Daemon) " JSVC_VERSION_STRING "\n");
-printf("Copyright (c) 1999-2021 Apache Software Foundation.\n");
+printf("Copyright (c) 1999-2022 Apache Software Foundation.\n");

  printf("\n");
  }
diff --git a/src/native/unix/native/jsvc-unix.c
b/src/native/unix/native/jsvc-unix.c
index 73764d4..a98757a 100644
--- a/src/native/unix/native/jsvc-unix.c
+++ b/src/native/unix/native/jsvc-unix.c
@@ -850,7 +850,7 @@ static int child(arg_data *args, home_data *data,
uid_t uid, gid_t gid)
  /* Check wether we need to dump the VM version */
  if (args->vers == true) {
  log_error("jsvc (Apache Commons Daemon) " JSVC_VERSION_STRING);
-log_error("Copyright (c) 1999-2021 Apache Software Foundation.");
+log_error("Copyright (c) 1999-2022 Apache Software Foundation.");
  if (java_version() != true) {
  return -1;
  }
diff --git a/src/native/windows/apps/prunmgr/prunmgr.rc
b/src/native/windows/apps/prunmgr/prunmgr.rc
index dd5efbe..d102f60 100644
--- a/src/native/windows/apps/prunmgr/prunmgr.rc
+++ b/src/native/windows/apps/prunmgr/prunmgr.rc
@@ -38,7 +38,7 @@ BEGIN
  ES_READONLY | WS_BORDER | WS_VSCROLL,0,31,335,115
  CONTROL
  "BMP_COMMONS",IDC_STATIC,"Static",SS_BITMAP|0x0040L,0,0,337,30
  LTEXT   " ",IDC_ABOUTAPP,2,150,270,12
-LTEXT   "Copyright (c) 2000-2021 The Apache Software
Foundation.",IDC_STATIC,2,160,270,12
+LTEXT   "Copyright (c) 2000-2022 The Apache Software
Foundation.",IDC_STATIC,2,160,270,12
  LTEXT   "https://commons.apache.org",IDC_STATIC,2,170,270,12
  PUSHBUTTON  " Info",IAB_SYSINF,285,170,50,14
  END
@@ -230,7 +230,7 @@ BEGIN
  IDS_APPLICATION RSTR_PSM
  IDS_APPVERSION  "Version 1.3.0"
  IDS_APPFULLNAME RSTR_PSM " Version " PRG_VERSION
-IDS_APPCOPYRIGHT"Copyright (c) 2000-2021 The Apache Software
Foundation"
+IDS_APPCOPYRIGHT"Copyright (c) 2000-2022 The Apache Software
Foundation"
  IDS_APPDESCRIPTION  "Apache Commons Daemon Service Management Tool"
  IDS_ALREAY_RUNING   "An instance of '%S' application is already
running"
  IDS_ERRORCMD"Unknown command line option '%s'\nSee the manual
for command line usage."
@@ -280,7 +280,7 @@ BEGIN
VALUE "FileDescription", RSTR_PSM "\0"
VALUE "FileVersion", PRG_VERSION
VALUE "InternalName", RSTR_PSM "\0"
-  VALUE "LegalCopyright", "Copyright (c) 2000-2021 The Apache
Software Foundation.\0"
+  VALUE "LegalCopyright", "Copyright (c) 2000-2022 The Apache
Software Foundation.\0"
VALUE "OriginalFilename", "prunmgr.exe\0"
VALUE "ProductName", RSTR_PSM "\0"
VALUE "ProductVersion", PRG_VERSION
diff --git a/src/native/windows/apps/prunsrv/prunsrv.c
b/src/native/windows/apps/prunsrv/prunsrv.c
index 62acb7e..472ce14 100644
--- a/src/native/windows/apps/prunsrv/prunsrv.c
+++ b/src/native/windows/apps/prunsrv/prunsrv.c
@@ -399,7 +399,7 @@ static void printVersion(void)
  {
  fwprintf(stderr, L"Apache Commons Daemon Service Runner version
%S/Win%d (%S)\n",
  PRG_VERSION, PRG_BITS, __DATE__);
-fwprintf(stderr, L"Copyright (c) 2000-2021 The Apache Softwa

Re: [VOTE][CANCELLED] Release Apache Commons Daemon 1.2.5 based on RC1

[Mark Thomas]

This vote has been cancelled as the consensus is that the next version 
needs to be 1.30 rather than 1.2.5.


Mark


On 27/01/2022 22:29, Mark Thomas wrote:
We have fixed a few bugs and added some enhancements since Apache 
Commons Daemon 1.2.4 was released, so I would like to release Apache 
Commons Daemon 1.2.5.


Apache Commons Daemon 1.2.5 RC1 is available for review here:
     https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.5-RC1
(svn revision 52304)

The Git tag commons-daemon-1.2.5-RC1 commit for this RC is 
6cbcf2368bc91eceae80455613e089a635bfc98b


which you can browse here:
https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=6cbcf2368bc91eceae80455613e089a635bfc98b 



You may checkout this tag using:
     git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.2.5-RC1 commons-daemon-1.2.5-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1578/commons-daemon/commons-daemon/1.2.5/ 



These are the artifacts and their hashes:

#Release SHA-512s
commons-daemon-1.2.5.jar=742cda24782493bc76f8276810a582deaeb622e48f3334bbd0d9e8e08efbfe367ea48a804eb51874a1823e8523fb318ab1f9f6958e71bc37e4b10dc5d01e652c 

commons-daemon-1.2.5-bin.tar.gz=1d41efa490ca201132767c08c8b54207714701851c42195916d3e9d0b1731a69a5bcb41f877e2d35079aafecff9c47cb828637399794339307e0ab66e4bc5589 

commons-daemon-1.2.5-native-src.tar.gz=6f3968f6cdc96cf784c92547123896c32110c932dc293a3b0fc3a093490b0699c3053f8c3137e39eea3d6c20d7332f98b90dc29a3e2737356d3cde1b4b4e0e2e 

commons-daemon-1.2.5-native-src.zip=20ebd8d897dc51828c71162ecd0337158b91b51fc10ba3f65964a68b0c61466b50b42c44f6aee84db7c621a0d420514e533b50d9deebb4a6b50ddb837e765f8f 

commons-daemon-1.2.5-src.zip=1079969d99c2047f8b8216ca820e731c1dc62ca52d1919bf1deb6b04f32b0dc3ea1ef871a251e03558de665fe3633c29fb13ead642936a51ea1d31431d76be8b 

commons-daemon-1.2.5-src.tar.gz=937042d811b9dc6aaefffdf523d8ee52193342120fb39fc50c7607931f712d6ba9ebae6e2409bf089689fea9064f9107f62627ffeca98335750e2431c828a328 

commons-daemon-1.2.5-bin.zip=1760fa09086611acecd65655fcf1e2f20527af3663b3115f3365283dde700871ae467a7834fb77dac1ac2b9aedd90ac4dfff7812dca0f9f668afe93ab4c14b54 

commons-daemon-1.2.5-bin-windows.zip=b860595c1c104c07678fc25e7efe242b29e4dcc9f12cd564a563adcbaa4503317f8437ccb8ed79b318fbea43a43df20d89ac9b0e83a8cd6fd981722fd5da37f4 




KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

Thank you,

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.2.5 based on RC1

[Mark Thomas]

On 27/01/2022 22:29, Mark Thomas wrote:

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [X] -1 I oppose this release because...


The minimum Java version has been changed since 1.2.4 from Java 6 to 
Java 7. This isn't mentioned in the release notes (which explicitly 
state Java 6 as the minimum) or the change log. I think we need at least 
an RC2 to address these.


On the same topic, should we increase the version number to 1.3.0?

On one hand, no-one should even be using Java 6 (or Java 7 but Tomcat 8 
has a mandatory spec requirement to run on Java 7) these days so from 
that point of view 1.2.5 doesn't seem unreasonable. On the other, 
changing the minimum Java version in a point release doesn't seem right. 
I'm leaning towards 1.3.0 but would be happy with 1.2.5 if that is the 
consensus.


Thoughts?

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.2.5 based on RC1

[Mark Thomas]

On 30/01/2022 17:38, Gary Gregory wrote:

There is nothing at this link link:
https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.5-RC1


My mistake.

The correct URL is:
https://dist.apache.org/repos/dist/dev/commons/daemon/

The release process didn't create the structure for dist. I did it 
manually. I forgot that the release vote script expects "1.2.5-RC1" to 
be included. I could move the RC artifacts but that would change the svn 
revision number. I'll document this in the Daemon's HOW-TO-RELEASE file 
in case it happens again.


I'll also see if I can figure out why the release process didn't create 
the structure for dist.


Mark




?

Gary


On Thu, Jan 27, 2022, 17:29 Mark Thomas  wrote:


We have fixed a few bugs and added some enhancements since Apache
Commons Daemon 1.2.4 was released, so I would like to release Apache
Commons Daemon 1.2.5.

Apache Commons Daemon 1.2.5 RC1 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.5-RC1
(svn revision 52304)

The Git tag commons-daemon-1.2.5-RC1 commit for this RC is
6cbcf2368bc91eceae80455613e089a635bfc98b

which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=6cbcf2368bc91eceae80455613e089a635bfc98b

You may checkout this tag using:
  git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
--branch commons-daemon-1.2.5-RC1 commons-daemon-1.2.5-RC1

Maven artifacts are here:


https://repository.apache.org/content/repositories/orgapachecommons-1578/commons-daemon/commons-daemon/1.2.5/

These are the artifacts and their hashes:

#Release SHA-512s

commons-daemon-1.2.5.jar=742cda24782493bc76f8276810a582deaeb622e48f3334bbd0d9e8e08efbfe367ea48a804eb51874a1823e8523fb318ab1f9f6958e71bc37e4b10dc5d01e652c

commons-daemon-1.2.5-bin.tar.gz=1d41efa490ca201132767c08c8b54207714701851c42195916d3e9d0b1731a69a5bcb41f877e2d35079aafecff9c47cb828637399794339307e0ab66e4bc5589

commons-daemon-1.2.5-native-src.tar.gz=6f3968f6cdc96cf784c92547123896c32110c932dc293a3b0fc3a093490b0699c3053f8c3137e39eea3d6c20d7332f98b90dc29a3e2737356d3cde1b4b4e0e2e

commons-daemon-1.2.5-native-src.zip=20ebd8d897dc51828c71162ecd0337158b91b51fc10ba3f65964a68b0c61466b50b42c44f6aee84db7c621a0d420514e533b50d9deebb4a6b50ddb837e765f8f

commons-daemon-1.2.5-src.zip=1079969d99c2047f8b8216ca820e731c1dc62ca52d1919bf1deb6b04f32b0dc3ea1ef871a251e03558de665fe3633c29fb13ead642936a51ea1d31431d76be8b

commons-daemon-1.2.5-src.tar.gz=937042d811b9dc6aaefffdf523d8ee52193342120fb39fc50c7607931f712d6ba9ebae6e2409bf089689fea9064f9107f62627ffeca98335750e2431c828a328

commons-daemon-1.2.5-bin.zip=1760fa09086611acecd65655fcf1e2f20527af3663b3115f3365283dde700871ae467a7834fb77dac1ac2b9aedd90ac4dfff7812dca0f9f668afe93ab4c14b54

commons-daemon-1.2.5-bin-windows.zip=b860595c1c104c07678fc25e7efe242b29e4dcc9f12cd564a563adcbaa4503317f8437ccb8ed79b318fbea43a43df20d89ac9b0e83a8cd6fd981722fd5da37f4


KEYS:
https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thank you,

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Apache Commons Daemon 1.2.5 based on RC1

[Mark Thomas]

We have fixed a few bugs and added some enhancements since Apache 
Commons Daemon 1.2.4 was released, so I would like to release Apache 
Commons Daemon 1.2.5.


Apache Commons Daemon 1.2.5 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.5-RC1
(svn revision 52304)

The Git tag commons-daemon-1.2.5-RC1 commit for this RC is 
6cbcf2368bc91eceae80455613e089a635bfc98b


which you can browse here:
https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=6cbcf2368bc91eceae80455613e089a635bfc98b

You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.2.5-RC1 commons-daemon-1.2.5-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1578/commons-daemon/commons-daemon/1.2.5/

These are the artifacts and their hashes:

#Release SHA-512s
commons-daemon-1.2.5.jar=742cda24782493bc76f8276810a582deaeb622e48f3334bbd0d9e8e08efbfe367ea48a804eb51874a1823e8523fb318ab1f9f6958e71bc37e4b10dc5d01e652c
commons-daemon-1.2.5-bin.tar.gz=1d41efa490ca201132767c08c8b54207714701851c42195916d3e9d0b1731a69a5bcb41f877e2d35079aafecff9c47cb828637399794339307e0ab66e4bc5589
commons-daemon-1.2.5-native-src.tar.gz=6f3968f6cdc96cf784c92547123896c32110c932dc293a3b0fc3a093490b0699c3053f8c3137e39eea3d6c20d7332f98b90dc29a3e2737356d3cde1b4b4e0e2e
commons-daemon-1.2.5-native-src.zip=20ebd8d897dc51828c71162ecd0337158b91b51fc10ba3f65964a68b0c61466b50b42c44f6aee84db7c621a0d420514e533b50d9deebb4a6b50ddb837e765f8f
commons-daemon-1.2.5-src.zip=1079969d99c2047f8b8216ca820e731c1dc62ca52d1919bf1deb6b04f32b0dc3ea1ef871a251e03558de665fe3633c29fb13ead642936a51ea1d31431d76be8b
commons-daemon-1.2.5-src.tar.gz=937042d811b9dc6aaefffdf523d8ee52193342120fb39fc50c7607931f712d6ba9ebae6e2409bf089689fea9064f9107f62627ffeca98335750e2431c828a328
commons-daemon-1.2.5-bin.zip=1760fa09086611acecd65655fcf1e2f20527af3663b3115f3365283dde700871ae467a7834fb77dac1ac2b9aedd90ac4dfff7812dca0f9f668afe93ab4c14b54
commons-daemon-1.2.5-bin-windows.zip=b860595c1c104c07678fc25e7efe242b29e4dcc9f12cd564a563adcbaa4503317f8437ccb8ed79b318fbea43a43df20d89ac9b0e83a8cd6fd981722fd5da37f4


KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-dbcp] branch master updated: Update MXBean for use of Duration with BasicDataSource

[Mark Thomas]

XxxxMXBean interfaces are (arguably) a special case since they exist to 
expose methods via JMX.


I wouldn't expect any users of DBCP to be implementing this interface.

If we think there is a real risk that users have implemented this 
interface (for what use case?) then I can add default implementations 
for those methods.


Mark



On 05/01/2022 19:36, Gary Gregory wrote:

If you add methods to an existing interface, this will break binary
compatibility unless you add them as default methods. Or am i missing
something?

Gary

On Wed, Jan 5, 2022, 14:10  wrote:


This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git


The following commit(s) were added to refs/heads/master by this push:
  new 28eb33b  Update MXBean for use of Duration with BasicDataSource
28eb33b is described below

commit 28eb33b5b3551de2e630a4cb59dc3bc5506f8114
Author: Mark Thomas 
AuthorDate: Wed Jan 5 19:07:51 2022 +

 Update MXBean for use of Duration with BasicDataSource
---
  .../org/apache/commons/dbcp2/BasicDataSource.java  |  7 ++
  .../org/apache/commons/dbcp2/DataSourceMXBean.java | 77
++
  .../commons/dbcp2/TestBasicDataSourceMXBean.java   | 37 +++
  3 files changed, 121 insertions(+)

diff --git a/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
b/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
index 07615d2..bb451cd 100644
--- a/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
+++ b/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
@@ -1064,6 +1064,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * @return the maximum permitted duration of a connection.
   * @since 2.10.0
   */
+@Override
  public Duration getMaxConnDuration() {
  return maxConnDuration;
  }
@@ -1123,6 +1124,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * @return the maxWaitDuration property value.
   * @since 2.10.0
   */
+@Override
  public synchronized Duration getMaxWaitDuration() {
  return this.maxWaitDuration;
  }
@@ -1147,6 +1149,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * @see #setMinEvictableIdle(Duration)
   * @since 2.10.0
   */
+@Override
  public synchronized Duration getMinEvictableIdleDuration() {
  return this.minEvictableIdleDuration;
  }
@@ -1324,6 +1327,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * @return Timeout before an abandoned connection can be removed.
   * @since 2.10.0
   */
+@Override
  public Duration getRemoveAbandonedTimeoutDuration() {
  return abandonedConfig == null ? Duration.ofSeconds(300) :
abandonedConfig.getRemoveAbandonedTimeoutDuration();
  }
@@ -1353,6 +1357,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * there are minIdle idle connections in the pool
   * @since 2.10.0
   */
+@Override
  public synchronized Duration getSoftMinEvictableIdleDuration() {
  return softMinEvictableIdleDuration;
  }
@@ -1429,6 +1434,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * @see #setDurationBetweenEvictionRuns(Duration)
   * @since 2.10.0
   */
+@Override
  public synchronized Duration getDurationBetweenEvictionRuns() {
  return this.durationBetweenEvictionRuns;
  }
@@ -1482,6 +1488,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   *
   * @return the timeout in seconds before connection validation
queries fail.
   */
+@Override
  public Duration getValidationQueryTimeoutDuration() {
  return validationQueryTimeoutDuration;
  }
diff --git a/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
b/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
index 56fb5c8..9922542 100644
--- a/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
+++ b/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
@@ -17,6 +17,7 @@
  package org.apache.commons.dbcp2;

  import java.sql.SQLException;
+import java.time.Duration;

  /**
   * Defines the methods that will be made available via
@@ -138,10 +139,21 @@ public interface DataSourceMXBean {
  boolean getLogExpiredConnections();

  /**
+ * See {@link BasicDataSource#getMaxConnDuration()}.
+ *
+ * @return {@link BasicDataSource#getMaxConnDuration()}.
+ * @since 2.10.0
+ */
+Duration getMaxConnDuration();
+
+/**
   * See {@link BasicDataSource#getMaxConnLifetimeMillis()}.
   *
   * @return {@link BasicDataSource#getMaxConnLifetimeMillis()}.
+ *
+ * @deprecated Use {@link

Re: can we get rid of dependabot?

[Mark Thomas]

On 29/12/2021 15:04, Gary Gregory wrote:

On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins  wrote:


Why not just run dependabot weekly. We move slowly enough that weekly
currently works. Until we can get more hands on the project, slower comms
are indeed reasonable…right?



I would be OK with it once a week.


I think the improvement resulting from moving to once a week will be 
minimal.


I get the desire to keep things up to date but the way dependabot is 
currently working creates a lot of traffic on both issues@ and commits@
That noise makes it much harder to follow any other activity that might 
be happening in the project. I am finding it a lot more effort to keep 
track of the Commons projects I am interested in.


Most commons libraries have very few "real" dependencies. Most of the 
dependencies are there to support testing or building. I would argue 
that updates to test/build libraries are far less critical and low risk 
to update en masse just before a release.


I may look at applying local filters in the short term but that strikes 
me very much as fixing the symptom rather than the cause and I don't 
think it is efficient for every subscriber to have to do this if there 
is an approach available that addresses the root cause.


As an aside, we also need to keep repeatable builds in mind. Simply 
defining a version dependency as "latest" (or anything other than an 
explicit version) is going to be problematic.


So, is there a way we could do something like the following with any 
combination of dependabot and/or Versions Maven plugin and/or something 
else?


- dependabot like behaviour (daily check, separate PR) for dependencies
  that are used (required or optional) at runtime

- a weekly (or even monthly?) check for test libraries, build tools etc.
  (i.e. everything that isn't a runtime dependency) that provides,
  ideally, a single PR with one commit per update

Emphasis on the "something like" the above.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: can we get rid of dependabot?

[Mark Thomas]

+1

And it isn't just the notifications an upgrade is available. The 
associated GitHub emails are just as much of a problem.


The Versions Maven Plugin would be a much better solution to this problem.
- Run it once as part of the pre-release process.
- One commit to apply all pending updates.
- Job done.

Mark


On 28/12/2021 18:29, Romain Manni-Bucau wrote:

+1, a lot of false positives and useless noise so the gain is rather not
positive for me too (and we revew deps before a release anyway...when there
are some important ones)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 28 déc. 2021 à 19:20, Phil Steitz  a écrit :


I can no longer effectively monitor commits@ due to the spam generated
by this tool.  I am afraid my eyeballs aren't the only ones going
missing here and that is a problem much more severe than any value
provided by this tool, IMO.

Phil

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [OGNL] Drop commons-ognl project

[Mark Thomas]

On 25/11/2021 08:21, Lukasz Lenart wrote:

Hi,

I wonder what do you think about dropping commons-ognl project? This
was supposed to be the next major version (4.x) but there was no
activity in the project for a long time. Also migrating all the
changes from the previous Github version is rather an impossible task.
At the same time I want to move the Github project under
Softwaremill's umbrella [1].

I'm eager to hear your opinions :)


Wearing some combination of my Commons PMC, ASF member and VP Brand 
Management hats.


Am I reading the archives correctly when I conclude there has never been 
an ASF release of Commons OGNL of any version? (snapshots don't count)


Why will migrating changes from 3.x be any easier if the code is hosted 
elsewhere?


A cursory review of GitHub stats does show that the old 3.x has been 
more active. It looks like you have been doing most of the work. Why do 
you think 3.x has seen more activity than 4.x?


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-dbcp] branch master updated: Trivial format fix. Use consistent formatting for all classes.

[Mark Thomas]

On 02/09/2021 16:16, Gary Gregory wrote:

The space after the license is on purpose, it is NOT like a Javadoc
comment, so I do not see why the change is needed. I add that space when it
is missing!



The code formatting was inconsistent. I went with what looked to be the 
majority format for DBCP although it wasn't far off a 50/50 split (maybe 
55/45).


I made the same change to Pool where only 1 file had the (arguably 
unnecessary) space.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] OSS Fuzz

[Mark Thomas]

On 13/04/2021 17:49, Stefan Bodewig wrote:




Fabian has offered to set up OSS Fuzz for Compress. Given that the
issues OSS Fuzz detects may or may not be security sensitive, I don't
feel it would be a good idea to have the tool send reports to a public
mailing list. Therefore I propose to create another subscription
moderated list just for these kinds of reports. I'm afraid it could be
too noisy for security@commons.


Following the "split by audience, not by topic" guideline, I'd suggest 
using security@commons.a.o rather than a separate list. Much, much 
bigger projects than Compress use OSS Fuzz and direct traffic to their 
security list where it seems to be manageable.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-daemon] 1.2.5 release?

[Mark Thomas]

On 25/03/2021 13:50, Mladen Turk wrote:



On 25/03/2021 14:46, Mark Thomas wrote:

On 25/03/2021 12:21, Mladen Turk wrote:

I used to do releases couple of years back.
Since 1.2.5 is mostly fixing procrun issues, I'll try to make that 
release.


Is there some doc with new set of rules for creating a release?


HOW-TO-RELEASE.txt located in the root of the repository.

You'll also need to get yourself setup to sign the Windows binaries. I 
can get that started if you wish.




That would be much faster thought :D


Expect an email from DigiCert shortly to set up your account on the code 
signing system.


Instructions on how to set-up for code signing are here:
https://infra.apache.org/digicert-use.html

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-daemon] 1.2.5 release?

[Mark Thomas]

On 25/03/2021 12:21, Mladen Turk wrote:

I used to do releases couple of years back.
Since 1.2.5 is mostly fixing procrun issues, I'll try to make that release.

Is there some doc with new set of rules for creating a release?


HOW-TO-RELEASE.txt located in the root of the repository.

You'll also need to get yourself setup to sign the Windows binaries. I 
can get that started if you wish.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Fwd: [apache/commons-daemon] Fix for https://issues.apache.org/jira/browse/DAEMON-314 (#23)

[Mark Thomas]

On 23/02/2021 12:08, Gary Gregory wrote:
> Hi Mark,
> 
> May you review please?

Nothing jumps out at me as wrong but I am no C coder.

Mark

> 
> -- Forwarded message -
> From: Jean-Frederic Clere 
> Date: Tue, Feb 23, 2021, 04:05
> Subject: Re: [apache/commons-daemon] Fix for
> https://issues.apache.org/jira/browse/DAEMON-314 (#23)
> To: apache/commons-daemon 
> Cc: Gary Gregory , Comment <
> comm...@noreply.github.com>
> 
> 
> Merged #23  into master.
> 
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> , or
> unsubscribe
> 
> .
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[ANNOUNCEMENT] Commons Daemon 1.2.4 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Daemon 1.2.3.

The Apache Commons Daemon software library provides a generic Daemon
(unix) or Service (Windows) wrapper for Java code.

Version 1.2.4 is a bugfix release.

A full list of changes can be found at
https://commons.apache.org/proper/commons-daemon/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-daemon/download_daemon.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Daemon, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Daemon website:

https://commons.apache.org/proper/commons-daemon/

Mark
on behalf of the Apache Commons community

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE][RESULT] Release Apache Commons Daemon 1.2.4 based on RC2

[Mark Thomas]

The following votes were cast:

Binding:
+1: kinow, markt, chtompki, ggregory

No other votes were cast. The vote therefore passes.

Thanks to everyone who contributed toward this release.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.2.4 based on RC2

[Mark Thomas]

On 18/01/2021 17:12, Mark Thomas wrote:
> We have fixed a couple of bugs and a regression in 1.2.3, so I would
> like to release Apache Commons Daemon 1.2.4.



> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
> 
>   [X] +1 Release these artifacts

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.2.4 based on RC2

[Mark Thomas]

On 19/01/2021 03:30, Bruno P. Kinoshita wrote:
>  [x] +1 Release these artifacts
> 
> Building OK from the tag, with Ubuntu LTS + Java 8, Maven 3.5.4.
> 
> Minor notes:
> - "Maven artifacts are here", the URL is 404 for me, I logged in to 
> repository.apache.org, and copied the link:
> OK = 
> https://repository.apache.org/content/repositories/orgapachecommons-1538/commons-daemon/commons-daemon/1.2.4/
> 
> BROKEN = 
> https://repository.apache.org/content/repositories/orgapachecommons-1538/org/apache/commons/commons-daemon/1.2.4/
> 
> I think the groupId is the issue? Checked signatures, they match with the one 
> used for source folder in dist area.
> 
> 
> - "Details of changes since 1.2.3 are in the change log" the change log link 
> is broken, but I generated the site locally, and it looks OK. The dist area 
> site folder has only the apidocs I think? Not a blocker IMO

Thanks for the review.

I'll take a look at the various link issues. The Commons Release plug-in
makes various assumptions that aren't true for Daemon. I've worked
around some of them and edited others out of the generated vote text. I
obviously missed some. I'll add some more detailed notes to
HOW-TO-RELEASE.txt for next time.

Cheers,

Mark


> 
> Cheers
> Bruno
> 
> p.s.: I checked the NOTICE file because the commit message said 2012, but it 
> has the correct years now :)
> 
> 
> On Tuesday, 19 January 2021, 6:12:41 am NZDT, Mark Thomas 
>  wrote:  
>  
>  We have fixed a couple of bugs and a regression in 1.2.3, so I would
> like to release Apache Commons Daemon 1.2.4.
> 
> Apache Commons Daemon 1.2.4 RC2 is available for review here:
>     https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.4-RC2 (svn
> revision 45480)
> 
> The Git tag commons-daemon-1.2.4-RC2 commit for this RC is
> 0373c020f233236ca7acf4fa4ceef31e27b7cb70 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=0373c020f233236ca7acf4fa4ceef31e27b7cb70
> You may checkout this tag using:
>     git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
> --branch commons-daemon-1.2.4-RC2 commons-daemon-1.2.4-RC2
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1538/org/apache/commons/commons-daemon/1.2.4/
> 
> These are the artifacts and their hashes:
> 
> commons-daemon-1.2.4-bin-windows.zip=9c2bc010828826acbde5613aaf2de303471b33f2cb655b0ac91574e27123b8bcbe59e987d9e47d5835c171a5db31922b1458ed2e4fef840fd06c048f61f1e62b
> commons-daemon-1.2.4-bin.tar.gz=66c33091fa51b6845ce45f326708419ef20ecd4a60bc175b94620a708f398843d9d53cfa8bfd2f5ab924c30b7034af602cb65e3e1cf164a5f687353f755919fe
> commons-daemon-1.2.4-bin.zip=a6ced9c772dda60c1cf000a39e189bc3017030a15335d40dcd6283c5953dbaf455c86c3487fca1d672315b767c272983ec3ddc95126e9767a0fb6005ee7426d3
> commons-daemon-1.2.4-javadoc.jar=5b080fa5b01ffd7868ce922c27b5bfe8ca5b30b74f9bfe5b77082c33878b5bfd87fe3e99e9be3f411b23a7136043894fea1731e2e52ea76a302f1468f2e67d09
> commons-daemon-1.2.4-native-src.tar.gz=655f5b106238f6ac7f6e42dd32acfc553b302aa2c248b839528abdc9872bad5c80da3ef15399a7ff8c414427aafea9c4e9656b2887d98be4584f3926ac02ca23
> commons-daemon-1.2.4-native-src.zip=6bbc7ea9ed31c71faae2f72c305ee8637827316728857abca17463d7d80c94ff9e739cbcf3fe632fdaf2ec16cacb15c1d38d5b2a316e9c124f500d620fde5136
> commons-daemon-1.2.4-sources.jar=770eafc27c0a8070749ab9bb1f2c05df3449f98ce25a4e656632963d052eabcb8793f28eeb839249c1fadf8ce852c4a7bb8da8c79510823085d221b95030ed9a
> commons-daemon-1.2.4-src.tar.gz=36e9cb3153ca763bfaaa71575a1584610254f1ce4c0f666ff7bbc628311405430536413525c9c777e4364eea62a247fb084750d837e84a62d9fce92a61909d56
> commons-daemon-1.2.4-src.zip=c19615eeea0e471446c8159d68c708d2468cf2656637355c75d5bcd2b4f588399a6074d9bce8b2e15ba332c9d0c6f047f063f3218f0bd16771c4fdd800d6eac4
> 
> 
> Details of changes since 1.2.3 are in the change log:
> 
> https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.4-RC2/site/changes-report.html
> 
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thank you,
> 
> Mark Thomas,
> Release Manager (using key 10C01C5A2F6059E7)
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
>   
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Apache Commons Daemon 1.2.4 based on RC2

[Mark Thomas]

We have fixed a couple of bugs and a regression in 1.2.3, so I would
like to release Apache Commons Daemon 1.2.4.

Apache Commons Daemon 1.2.4 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.4-RC2 (svn
revision 45480)

The Git tag commons-daemon-1.2.4-RC2 commit for this RC is
0373c020f233236ca7acf4fa4ceef31e27b7cb70 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=0373c020f233236ca7acf4fa4ceef31e27b7cb70
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
--branch commons-daemon-1.2.4-RC2 commons-daemon-1.2.4-RC2

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1538/org/apache/commons/commons-daemon/1.2.4/

These are the artifacts and their hashes:

commons-daemon-1.2.4-bin-windows.zip=9c2bc010828826acbde5613aaf2de303471b33f2cb655b0ac91574e27123b8bcbe59e987d9e47d5835c171a5db31922b1458ed2e4fef840fd06c048f61f1e62b
commons-daemon-1.2.4-bin.tar.gz=66c33091fa51b6845ce45f326708419ef20ecd4a60bc175b94620a708f398843d9d53cfa8bfd2f5ab924c30b7034af602cb65e3e1cf164a5f687353f755919fe
commons-daemon-1.2.4-bin.zip=a6ced9c772dda60c1cf000a39e189bc3017030a15335d40dcd6283c5953dbaf455c86c3487fca1d672315b767c272983ec3ddc95126e9767a0fb6005ee7426d3
commons-daemon-1.2.4-javadoc.jar=5b080fa5b01ffd7868ce922c27b5bfe8ca5b30b74f9bfe5b77082c33878b5bfd87fe3e99e9be3f411b23a7136043894fea1731e2e52ea76a302f1468f2e67d09
commons-daemon-1.2.4-native-src.tar.gz=655f5b106238f6ac7f6e42dd32acfc553b302aa2c248b839528abdc9872bad5c80da3ef15399a7ff8c414427aafea9c4e9656b2887d98be4584f3926ac02ca23
commons-daemon-1.2.4-native-src.zip=6bbc7ea9ed31c71faae2f72c305ee8637827316728857abca17463d7d80c94ff9e739cbcf3fe632fdaf2ec16cacb15c1d38d5b2a316e9c124f500d620fde5136
commons-daemon-1.2.4-sources.jar=770eafc27c0a8070749ab9bb1f2c05df3449f98ce25a4e656632963d052eabcb8793f28eeb839249c1fadf8ce852c4a7bb8da8c79510823085d221b95030ed9a
commons-daemon-1.2.4-src.tar.gz=36e9cb3153ca763bfaaa71575a1584610254f1ce4c0f666ff7bbc628311405430536413525c9c777e4364eea62a247fb084750d837e84a62d9fce92a61909d56
commons-daemon-1.2.4-src.zip=c19615eeea0e471446c8159d68c708d2468cf2656637355c75d5bcd2b4f588399a6074d9bce8b2e15ba332c9d0c6f047f063f3218f0bd16771c4fdd800d6eac4


Details of changes since 1.2.3 are in the change log:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.4-RC2/site/changes-report.html


KEYS:
  https://www.apache.org/dist/commons/KEYS


Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE][RESULT] Apache Commons Daemon 1.2.4 based on RC1

[Mark Thomas]

Primarily because I forgot to sign the Windows binaries, I am cancelling
the VOTE for this RC. I'm aiming to address this and the minor issues
noted in the reviews of RC1 and have RC2 ready in the next day or so.

Thanks,

Mark


On 06/01/2021 17:24, Mark Thomas wrote:
> We have fixed a few bugs including a regression since Apache Commons
> Daemon 1.2.3 was released, so I would like to release Apache Commons
> Daemon 1.2.4.
> 
> Apache Commons Daemon 1.2.4 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.4-RC1
> (svn revision 45203)
> 
> The Git tag commons-daemon-1.2.4-RC1 commit for this RC is
> 7c3bb602cd8d2f92813bd91bf4f7764d70038cd9
> 
> which you can browse here:
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=7c3bb602cd8d2f92813bd91bf4f7764d70038cd9
> 
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
> --branch commons-daemon-1.2.4-RC1 commons-daemon-1.2.4-RC1
> 
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1537/commons-daemon/commons-daemon/1.2.4/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> commons-daemon-1.2.4-bin.tar.gz=ca15c0e8bc75615219216ed68a1c91c0178159cd3d217f9e533732ea5a90e74e6bf8d30d0102e6f88425738d34e8e94f7b01e0483896a5367fb41c9251d18fee
> commons-daemon-1.2.4-native-src.tar.gz=ccc3c750c67dd0a8885b610d1b36ebe670b9f8d2a2e3843b39a6fdcc2774294248eb3df1fb0ba5bafcf56f9eb6cbba1ee37b5e7bdff35b63e57e89c0ffa9a3de
> commons-daemon-1.2.4-native-src.zip=7c6e755dee8ca4690fecb4078747f67e541a2d98eff7a373b683abd6170d31a60ce89558682f633dcca7c4b3a2ddacbce495e1b29ef22723cb40f3517ceed113
> commons-daemon-1.2.4-src.zip=a5b5b52229709106ce2fac227d5199eb34a55dcdf1ffe1079882026e645f3adb5cccd46a6fbb82f69191cadcc881120d679f10029e5d97d8d5012a03970ccab1
> commons-daemon-1.2.4-src.tar.gz=d5cb7eff1889478ff83da5b235a6639532406d008c659ca76532a4c2528cbc2786bb6a2cba1937bbd542a40a974d90dd8f9b9c2067a65095f9b28c15cda067ae
> commons-daemon-1.2.4-bin.zip=0afa7fc4943d7c1be6a8378fb5c24f764178e97e5106dc7f59d0667ed830385f70105c5349f25260d6a58e0296944807291b88d8ddff324a8b586a101e7e0799
> commons-daemon-1.2.4-bin-windows.zip=77acfad45692ddf8260540646ea895a5e28d34866c4ba0f8a5ec89ea97f64e92b98eb3b5596b3521f3a9ed473614b07f05d45314dcf7becf4436ca417feb515d
> 
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thank you,
> 
> Mark
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Apache Commons Daemon 1.2.4 based on RC1

[Mark Thomas]

I'm going to vote -1 on RC1 as I forgot to sign the Windows binaries.
I'll fix the issues Bruno notes below and then roll an RC2.

Mark


On 08/01/2021 03:42, Bruno P. Kinoshita wrote:
>    [x] +1 Release these artifacts
> 
> NB: the NOTICE file needs the yearly update, from 2020 to 2021. Not a blocker 
> I think?

Annoying, but I agree not a blocker on it's own.

> Building OK from tag with `mvn clean test install site` on
> 
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
> 2018-06-18T06:33:14+12:00)
> Maven home: /opt/apache-maven-3.5.4
> Java version: 1.8.0_275, vendor: Private Build, runtime: 
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-59-generic", arch: "amd64", family: "unix"
> 
> Site reports look good too. The changes report is showing the release date as 
> TBD, but that can be fixed after the release.

It can, although I like to put a best guess rather than leave it as TBD.

> Manually inspected a couple files from binary, and another couple files from 
> the dist area. All looking OK. Then looked at the signatures for the Maven 
> repository, also looking OK.

Thanks for reviewing.

Mark


> 
> 
> Thanks!Bruno
> 
> 
> On Thursday, 7 January 2021, 6:24:14 am NZDT, Mark Thomas 
>  wrote:  
>  
>  We have fixed a few bugs including a regression since Apache Commons
> Daemon 1.2.3 was released, so I would like to release Apache Commons
> Daemon 1.2.4.
> 
> Apache Commons Daemon 1.2.4 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.4-RC1
> (svn revision 45203)
> 
> The Git tag commons-daemon-1.2.4-RC1 commit for this RC is
> 7c3bb602cd8d2f92813bd91bf4f7764d70038cd9
> 
> which you can browse here:
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=7c3bb602cd8d2f92813bd91bf4f7764d70038cd9
> 
> You may checkout this tag using:
>     git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
> --branch commons-daemon-1.2.4-RC1 commons-daemon-1.2.4-RC1
> 
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1537/commons-daemon/commons-daemon/1.2.4/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> commons-daemon-1.2.4-bin.tar.gz=ca15c0e8bc75615219216ed68a1c91c0178159cd3d217f9e533732ea5a90e74e6bf8d30d0102e6f88425738d34e8e94f7b01e0483896a5367fb41c9251d18fee
> commons-daemon-1.2.4-native-src.tar.gz=ccc3c750c67dd0a8885b610d1b36ebe670b9f8d2a2e3843b39a6fdcc2774294248eb3df1fb0ba5bafcf56f9eb6cbba1ee37b5e7bdff35b63e57e89c0ffa9a3de
> commons-daemon-1.2.4-native-src.zip=7c6e755dee8ca4690fecb4078747f67e541a2d98eff7a373b683abd6170d31a60ce89558682f633dcca7c4b3a2ddacbce495e1b29ef22723cb40f3517ceed113
> commons-daemon-1.2.4-src.zip=a5b5b52229709106ce2fac227d5199eb34a55dcdf1ffe1079882026e645f3adb5cccd46a6fbb82f69191cadcc881120d679f10029e5d97d8d5012a03970ccab1
> commons-daemon-1.2.4-src.tar.gz=d5cb7eff1889478ff83da5b235a6639532406d008c659ca76532a4c2528cbc2786bb6a2cba1937bbd542a40a974d90dd8f9b9c2067a65095f9b28c15cda067ae
> commons-daemon-1.2.4-bin.zip=0afa7fc4943d7c1be6a8378fb5c24f764178e97e5106dc7f59d0667ed830385f70105c5349f25260d6a58e0296944807291b88d8ddff324a8b586a101e7e0799
> commons-daemon-1.2.4-bin-windows.zip=77acfad45692ddf8260540646ea895a5e28d34866c4ba0f8a5ec89ea97f64e92b98eb3b5596b3521f3a9ed473614b07f05d45314dcf7becf4436ca417feb515d
> 
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thank you,
> 
> Mark
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
>   
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[DAEMON] Using the commons release plugin

[Mark Thomas]

Hi,

I've had a chance to look at the commons release plugin and daemon again
- primarily as a way of generating the text for the VOTE email.

The current Commons Daemon specific release guide is:
https://github.com/apache/commons-daemon/blob/master/HOWTO-RELEASE.txt

If, at the end of the Maven tasks section, one does:
mvn commons-release:vote-txt

(and assuming the tag was created with the correct name) the vote text
is incomplete primarily because the SHA-512 hashes are missing.

This really needs looking at by someone who understands the commons
release plugin. The following are my notes that may, or may not, be useful.

1. The Nexus repo ID does not appear to be picked up. This can be
specified on the command line.

2. The previous version does not appear to be picked up. This can be
specified on the command line.

3. Using
   mvn deploy -Dcommons.release.isDistModule=true -Prelease
   rather than
   mvn deploy -Prelease
   generates the hashes (and the local copy of the tree for dist.a.o)
   but prevents those artifacts from being uploaded to Maven. Daemon
   needs then in both locations


For now I continue to use various manual hacks to get everything lined
up. It may well be that, given the frequency of Daemon releases, that a
couple of documented (better yet scripted) hacks for the release process
will be a more cost effective solution. I'd be fine with that and can
look at that for the next release (candidate).

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Apache Commons Daemon 1.2.4 based on RC1

[Mark Thomas]

We have fixed a few bugs including a regression since Apache Commons
Daemon 1.2.3 was released, so I would like to release Apache Commons
Daemon 1.2.4.

Apache Commons Daemon 1.2.4 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.4-RC1
(svn revision 45203)

The Git tag commons-daemon-1.2.4-RC1 commit for this RC is
7c3bb602cd8d2f92813bd91bf4f7764d70038cd9

which you can browse here:
https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=7c3bb602cd8d2f92813bd91bf4f7764d70038cd9

You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
--branch commons-daemon-1.2.4-RC1 commons-daemon-1.2.4-RC1

Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1537/commons-daemon/commons-daemon/1.2.4/

These are the artifacts and their hashes:

#Release SHA-512s
commons-daemon-1.2.4-bin.tar.gz=ca15c0e8bc75615219216ed68a1c91c0178159cd3d217f9e533732ea5a90e74e6bf8d30d0102e6f88425738d34e8e94f7b01e0483896a5367fb41c9251d18fee
commons-daemon-1.2.4-native-src.tar.gz=ccc3c750c67dd0a8885b610d1b36ebe670b9f8d2a2e3843b39a6fdcc2774294248eb3df1fb0ba5bafcf56f9eb6cbba1ee37b5e7bdff35b63e57e89c0ffa9a3de
commons-daemon-1.2.4-native-src.zip=7c6e755dee8ca4690fecb4078747f67e541a2d98eff7a373b683abd6170d31a60ce89558682f633dcca7c4b3a2ddacbce495e1b29ef22723cb40f3517ceed113
commons-daemon-1.2.4-src.zip=a5b5b52229709106ce2fac227d5199eb34a55dcdf1ffe1079882026e645f3adb5cccd46a6fbb82f69191cadcc881120d679f10029e5d97d8d5012a03970ccab1
commons-daemon-1.2.4-src.tar.gz=d5cb7eff1889478ff83da5b235a6639532406d008c659ca76532a4c2528cbc2786bb6a2cba1937bbd542a40a974d90dd8f9b9c2067a65095f9b28c15cda067ae
commons-daemon-1.2.4-bin.zip=0afa7fc4943d7c1be6a8378fb5c24f764178e97e5106dc7f59d0667ed830385f70105c5349f25260d6a58e0296944807291b88d8ddff324a8b586a101e7e0799
commons-daemon-1.2.4-bin-windows.zip=77acfad45692ddf8260540646ea895a5e28d34866c4ba0f8a5ec89ea97f64e92b98eb3b5596b3521f3a9ed473614b07f05d45314dcf7becf4436ca417feb515d


KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Daemon] release 1.2.4?

[Mark Thomas]

FYI, I'm expecting to tag 1.2.4-RC1 and start the release process later
today.

Mark


On 23/11/2020 12:45, Rob Tompkins wrote:
> I see. Let me give that a whirl
> 
>> On Nov 23, 2020, at 3:58 AM, Mark Thomas  wrote:
>>
>> Rob,
>>
>> You shouldn't need to install any version of Visual Studio. The CMSC
>> uses some freely distributable VS2008 components.
>>
>> You should be able to just use the latest CMSC binary distribution from
>> GitHUb.
>>
>> I think the Tomcat instructions are based on building the CMSC from
>> source. I don't know whether binary distributions weren't being provided
>> when I set up my build environment, whether I missed that they were
>> available of whether I wanted to build it from source for integrity reasons.
>>
>> If you want to go the build your own route, I have tried to expand on
>> the instructions at:
>> https://cwiki.apache.org/confluence/display/TOMCAT/Common+Native+Build+Environment
>>
>> although it is probably simpler just to use a binary distribution of
>> CMSC from github.
>>
>> Mark
>>
>>
>>> On 22/11/2020 17:15, Rob Tompkins wrote:
>>> @Mark - are you using VS2008 on windows 10? I’m trying to piece together 
>>> the build environment from this line:
>>>
>>> https://github.com/apache/commons-daemon/blob/master/src/native/windows/README.txt#L31-L32
>>>
>>> refrencing Mladen Turk's repo
>>>
>>> https://github.com/mturk/cmsc/tree/cb6be932c8c95a46262a64a89e68aae620dfdcee 
>>> <https://github.com/mturk/cmsc/tree/cb6be932c8c95a46262a64a89e68aae620dfdcee>
>>>
>>> suggesting using Visual Studio 2008 with "cl is 15.00.21022.08,” which I 
>>> can’t find a windows 10 installer for. That said, you have
>>> the documentation for buildling the tomcat binaries 
>>> https://cwiki.apache.org/confluence/display/TOMCAT/Common+Native+Build+Environment
>>>  
>>> <https://cwiki.apache.org/confluence/display/TOMCAT/Common+Native+Build+Environment>
>>>  which again references Turk’s repo with a later commit “132baba36” and 
>>> using Windows 10, but Turk still says to use Visual Studio 2008. If I 
>>> install the latest windows visual studio installation and run the nmake I 
>>> do get files generated out of the “nmake” commands, but I’m still 
>>> consistently unable to run Turk’s “setenv.bat /x86”.
>>>
>>> Personally I want to understand what’s going on here, but this is 
>>> definitely a build environmen that is quite foreign to me. I don’t want to 
>>> hold up the release of Daemon 1.2.4 with my lack of aptitude in the “C” 
>>> build departments.
>>>
>>> Thoughts?
>>>
>>> -Rob
>>>
>>>>> On Nov 19, 2020, at 11:00 AM, Rob Tompkins  wrote:
>>>>
>>>> I’m going to have to say that building and releasing daemon isn’t very 
>>>> clear to me as to how to proceed. The documentation that we do have 
>>>> namely: 
>>>> https://github.com/apache/commons-daemon/blob/master/HOWTO-RELEASE.txt 
>>>> <https://github.com/apache/commons-daemon/blob/master/HOWTO-RELEASE.txt>, 
>>>> and 
>>>> https://github.com/apache/commons-daemon/blob/master/src/native/windows/README.txt
>>>>  
>>>> <https://github.com/apache/commons-daemon/blob/master/src/native/windows/README.txt>
>>>>  aren’t enough help for me to get the C portion of the project to build in 
>>>> windows appropriately. 
>>>>
>>>> @Mark - I’m happy to validate the RC, but given my problems building the 
>>>> project generally, I don’t know my +1 is actually of any service because 
>>>> there’s far more here than I originally thought.
>>>>
>>>> All that said, I will continue to play around with the linux build for the 
>>>> time being as to understand it more. But, I don’t think that you guys 
>>>> should wait for me to do the build for this 1.2.4 release because I’m 
>>>> going to be too slow.
>>>>
>>>> Cheers,
>>>> -Rob
>>>>
>>>>> On Nov 17, 2020, at 10:23 AM, Rob Tompkins >>>> <mailto:chtom...@gmail.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Nov 16, 2020, at 7:35 AM, Rob Tompkins >>>>> <mailto:chtom...@gmail.com>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Nov 16, 2020, at 2:53 A