[VOTE] Release Apache Commons Net 3.9.0 based on RC1

[Gary Gregory]

We have fixed quite a few bugs and added some enhancements since Apache
Commons Net 3.8.0 was released, so I would like to release Apache Commons
Net 3.9.0.

Apache Commons Net 3.9.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1 (svn
revision 58255)

The Git tag commons-net-3.9.0-RC1 commit for this RC is
1595ad2cbb5b7d7e055613c1a76a3a4c82318aee which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-net.git;a=commit;h=1595ad2cbb5b7d7e055613c1a76a3a4c82318aee
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-net.git --branch
commons-net-3.9.0-RC1 commons-net-3.9.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1607/commons-net/commons-net/3.9.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Sat Nov 26 16:08:42 EST 2022
Apache\ Commons\
Net-3.9.0.spdx.rdf.xml=86bd182d31b6cfbfbb9402a77bc17f1bcfc7e9a4de0ce3c42f651cf9db6705360f9cc0973b2720a5df5a9c2d142c947ffd196edec7c54d46328a83a8e1218304
commons-net-3.9.0-bin.tar.gz=98b5ed975d07a825577e240ab463c58b32874e30225755051f5f66ba008ad6c21cbebb50ca15665835c7189bf222baea16e94bc4ddf7c301da2742f16071718a
commons-net-3.9.0-bin.zip=129a1382e33f5b9aad9001a98c7fd17d1033eff97f2f1cf805d3190ece2aa7860f425000e4f3d79171144fe8d591f36d35210da323ecb124ab7d01023d981341
commons-net-3.9.0-bom.json=19ab24fab9f3dcee2d430bf43a89725ab3477056e2a11f6a19f5e134e6a39d9f9613c1314924889af1d09bddef2014fe328c74036a6d665474b33c11c3e92003
commons-net-3.9.0-bom.xml=5992a52897a6db29e84ef9cd25dc2eb67b4f1f48937e001215903a4788fef455355b7fef6d556bba46a89a7286c402b281e58dd1078dd0fe52738ec2bf08c798
commons-net-3.9.0-javadoc.jar=607a103b623d24872654f864eb5d803c5fd2bb177b229c6c1f791ff040fb6c1ca8d141fac0362f1f5716e7784db38de078ecd530d3dfbb94c472b06f749547a9
commons-net-3.9.0-sources.jar=2fa5e645b5913394ab240443d73957c18173272c2004355bdcd0936ef40be73d7577e6c3167c49b5649f0899465c9c17de12dfba1e3dd179c7924f10f96ceac0
commons-net-3.9.0-src.tar.gz=a2d4ef4937701f28304fdb9a39a0d4a8fdd5fd7ae84c6d647a6b9e05eee68cb4fde8ae9eedd94f45fdc0194d160dd9f64b3c1cfbdd8bcea2214e9826ace32877
commons-net-3.9.0-src.zip=553a105ca2b624e13f9e7713084680477af87cb2d6d365f1075f6daa06ee1cda17f945ebf7983e3fd3ee04ed5ab9524365ed115f54cfeb730661cd9ec9832a9b
commons-net-3.9.0-test-sources.jar=689220026210f434ef9bc53647a0567ba55e15cd9583229fc4187f8252c3766a3c943fe3f20c438bb8e1e06182d509c90c01013de4cebaa767f59b733475fd7a
commons-net-3.9.0-tests.jar=5fea125ba37a40f7da1a0ad27191cad36e3892bf8c7820b998cf8780ef63e09ac75bb5a3fc3a177e4ac4467cd69c1e862572dbcf7778b4f930bf8df91c96f684
commons-net-examples-3.9.0.jar=4620fed9f7296f2e840edaa79fcf773a401f0153935ff30bb591f6acc8ee3f6765dca9ba697b07b395ede07039f237ebfeda532f558620ecb4323b223f26ffd4
commons-net-ftp-3.9.0.jar=1e477c00ac5f404f701cbd2b6cb4bf6971283621dd0561aa21232c3f8bcd3195a6a5d99723a73db0bec0d66fa2e79361bc5330540ddce8c1d45bc887c8c05962

I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease
-Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:

Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /usr/local/Cellar/maven/3.8.6/libexec
Java version: 1.8.0_352, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@8/1.8.0+352/libexec/openjdk.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "13.0.1", arch: "x86_64", family: "mac"
Darwin .local 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:54
PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64 x86_64

Details of changes since 3.8.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1/RELEASE-NOTES.txt

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

Site:

https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1/site/index.html
(note some *relative* links are broken and the 3.9.0 directories are
not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 3.8.0):
Binary compatibility can be confirmed by running 'mvn' or 'mvn
japicmp:cmp'

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1/site/rat-report.html

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,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

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-net.git --branch

Re: [ALL][COMPRESS] POM version

[Gary Gregory]

This is not something to automate IMO, it is just part of the release steps
the RM needs to take, which only happens when you wrap up releasing. Unless
I am misunderstanding something.

Gary

On Sat, Nov 26, 2022, 16:50 Xeno Amess  wrote:

> or would you mind if I make one？
> 
> From: Xeno Amess 
> Sent: Sunday, November 27, 2022 2:29:53 AM
> To: Commons Developers List 
> Subject: Re: [ALL][COMPRESS] POM version
>
> good and could we add a ci checker for this？
> 
> From: Gary Gregory 
> Sent: Saturday, November 26, 2022 8:36:10 PM
> To: Commons Developers List 
> Subject: [ALL][COMPRESS] POM version
>
> Hi all and release managers,
>
> A reminder that a POM version should never be a non-snapshot version in a
> git master branch as I've just found in Compress with 1.22 in the POM. It's
> now 1.23-SNAPSHOT.
>
> Also remember to update the date and description in changes.xml, which I've
> also fixed.
>
> Happy Thanksgiving to folks in the US,
> Gary
>

Re: [ALL][COMPRESS] POM version

[Xeno Amess]

or would you mind if I make one？

From: Xeno Amess 
Sent: Sunday, November 27, 2022 2:29:53 AM
To: Commons Developers List 
Subject: Re: [ALL][COMPRESS] POM version

good and could we add a ci checker for this？

From: Gary Gregory 
Sent: Saturday, November 26, 2022 8:36:10 PM
To: Commons Developers List 
Subject: [ALL][COMPRESS] POM version

Hi all and release managers,

A reminder that a POM version should never be a non-snapshot version in a
git master branch as I've just found in Compress with 1.22 in the POM. It's
now 1.23-SNAPSHOT.

Also remember to update the date and description in changes.xml, which I've
also fixed.

Happy Thanksgiving to folks in the US,
Gary

Re: Correctly configuring Apache Commons components for oss-fuzz

[Matt Sicker]

Yes, please use the existing fuzz-testing list. It’s basically a notifications 
list at this point due to differences in memory safety between Java and the C 
family making fuzzing a little trickier to reproduce security issues.
—
Matt Sicker

> On Nov 23, 2022, at 08:58, Mark Thomas  wrote:
> 
> 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 >>> > 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
 .
  > Let us extend  this 

Re: [ALL][COMPRESS] POM version

[Xeno Amess]

good and could we add a ci checker for this？

From: Gary Gregory 
Sent: Saturday, November 26, 2022 8:36:10 PM
To: Commons Developers List 
Subject: [ALL][COMPRESS] POM version

Hi all and release managers,

A reminder that a POM version should never be a non-snapshot version in a
git master branch as I've just found in Compress with 1.22 in the POM. It's
now 1.23-SNAPSHOT.

Also remember to update the date and description in changes.xml, which I've
also fixed.

Happy Thanksgiving to folks in the US,
Gary

[ALL][COMPRESS] POM version

[Gary Gregory]

Hi all and release managers,

A reminder that a POM version should never be a non-snapshot version in a
git master branch as I've just found in Compress with 1.22 in the POM. It's
now 1.23-SNAPSHOT.

Also remember to update the date and description in changes.xml, which I've
also fixed.

Happy Thanksgiving to folks in the US,
Gary