subject:"\[all\] release validation"

Re: [all] release validation (was: Re: [VOTE] Release Apache Commons Lang 3.11 based on RC2)

2020-07-13 Thread sebb

On Mon, 13 Jul 2020 at 15:15, Matt Sicker  wrote:
>
> I'm still of the opinion that verifying the GPG signature is logically
> sufficient since they include the message digest by nature of how they
> work. It is particularly useful because .asc files can be safely
> mirrored unlike checksum files which can be maliciously modified.

Any checksums we publish must be correct, so we need to check them.

Asc files are not mirrored.

> On Sun, 12 Jul 2020 at 16:19, Rob Tompkins  wrote:
> >
> > given the consistency of the signatures from the plugins…do we need to 
> > check them for releases anymore? I have been using shell scripts to 
> > validate all of the md5’s, sha1’s, sha512’s, and gpg signatures that come 
> > out of the process.
> >
> > @sebb or @markt do you have an opinion here?
> >
> > -Rob
> >
> > > On Jul 12, 2020, at 9:42 AM, Gary Gregory  wrote:
> > >
> > > We have fixed quite a few bugs and added some significant enhancements
> > > since Apache Commons Lang 3.10 was released, so I would like to release
> > > Apache Commons Lang 3.11.
> > >
> > > Apache Commons Lang 3.11 RC2 is available for review here:
> > >https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2 (svn
> > > revision 40434)
> > >
> > > The Git tag commons-lang-3.11-RC2 commit for this RC is
> > > f62f0f59a33d2c42bd4236ea7122735de30d91fc which you can browse here:
> > >
> > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=f62f0f59a33d2c42bd4236ea7122735de30d91fc
> > > You may checkout this tag using:
> > >git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch
> > > commons-lang-3.11-RC2 commons-lang-3.11-RC2
> > >
> > > Maven artifacts are here:
> > >
> > > https://repository.apache.org/content/repositories/orgapachecommons-1506/org/apache/commons/commons-lang3/3.11/
> > >
> > > These are the artifacts and their hashes:
> > >
> > > #Release SHA-512s
> > > #Sun Jul 12 09:31:57 EDT 2020
> > > commons-lang3-3.11-bin.tar.gz=314ed5b2a0af658a008b0c6dbba0c79c8e465a413fa483b68eaa7d60ef6731ca12bd04fc5a1e7c4faab4eedfca48b1ebc51228dc4bbcc44287aac6805e41d8a1
> > > commons-lang3-3.11-bin.zip=e2406057b664b2c2230f8804ed442c72e28ab93e01cca1d46d4dbbd5b179f0fbc1f02218654b459718f483210cb5e3f8621d4f3c31f0b3bb3ff05f8913e18f6c
> > > commons-lang3-3.11-javadoc.jar=ccba8259d8eb75c721145d0da24e04ccc20af485f010db424eae33e5b2563f878e03b498b5a8bb3db637ac1db5e14868f7356412f8679f6ce6ed82d9a0a62f4d
> > > commons-lang3-3.11-sources.jar=b9c210c4c78823b5eb50f420791a0d6515bc8413bfff029d678aeea78331bba1c127557c0f67667c467a1f66b79806cc5ca18668e3ca55048eb50aaeccaea3e3
> > > commons-lang3-3.11-src.tar.gz=ebcb13e47c24e6984835d9d6904fe33077aa3ba781cd61db109fa7005517e4e74cf086c4789a1d65cf3d6c4924b32337c98827a75f91aab908d8e8b9d3b92087
> > > commons-lang3-3.11-src.zip=2c7f44f9a5c8d597595bdcd54905e08cf10260f265e194cb62c5142cd2573c2a59660f01760ff39442febf90e0c75aa377f91fc071fb1ab7bbc55c1476a9c363
> > > commons-lang3-3.11-test-sources.jar=93345fb5a4c148eaad3d814973520640fae5fde8e4c72eafade846dc557301b1569f07ad1cd4a6bf81e8893846388208cf36addec40a2d2d1fa8fd18ad112b49
> > > commons-lang3-3.11-tests.jar=a168e088e9993dcad96fe689d2a13d384b36b8dc93f19a92a34c93add3ce14388e8031d75bb378c0ebb30ec625d1a27e106c28a1a3f9001d5bf5b7c5cebde123
> > >
> > > I have tested this with:
> > >
> > > mvn -V -Duser.name=%my_apache_id%
> > > -Dcommons.release-plugin.version=%commons.release-plugin.version% 
> > > -Prelease
> > > -Ptest-deploy -P jacoco -P japicmp clean package site deploy
> > >
> > > using:
> > >
> > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> > > Maven home: C:\Java\apache-maven-3.6.3\bin\..
> > > Java version: 1.8.0_251, vendor: Oracle Corporation, runtime: C:\Program
> > > Files\Java\jdk1.8.0_251\jre
> > > Default locale: en_US, platform encoding: Cp1252
> > > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> > >
> > > Details of changes since 3.10 are in the release notes:
> > >
> > > https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/RELEASE-NOTES.txt
> > >
> > > https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/changes-report.html
> > >
> > > Site:
> > >
> > > https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/index.html
> > >(note some *relative* links are broken and the 3.11 directories are not
> > > yet created - these will be OK once the site is deployed.)
> > >
> > > JApiCmp Report (compared to 3.10):
> > >
> > > https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/japicmp.html
> > >
> > > RAT Report:
> > >
> > > https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/rat-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

Re: [all] release validation (was: Re: [VOTE] Release Apache Commons Lang 3.11 based on RC2)

2020-07-13 Thread Matt Sicker

I'm still of the opinion that verifying the GPG signature is logically
sufficient since they include the message digest by nature of how they
work. It is particularly useful because .asc files can be safely
mirrored unlike checksum files which can be maliciously modified.

On Sun, 12 Jul 2020 at 16:19, Rob Tompkins  wrote:
>
> given the consistency of the signatures from the plugins…do we need to check 
> them for releases anymore? I have been using shell scripts to validate all of 
> the md5’s, sha1’s, sha512’s, and gpg signatures that come out of the process.
>
> @sebb or @markt do you have an opinion here?
>
> -Rob
>
> > On Jul 12, 2020, at 9:42 AM, Gary Gregory  wrote:
> >
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons Lang 3.10 was released, so I would like to release
> > Apache Commons Lang 3.11.
> >
> > Apache Commons Lang 3.11 RC2 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2 (svn
> > revision 40434)
> >
> > The Git tag commons-lang-3.11-RC2 commit for this RC is
> > f62f0f59a33d2c42bd4236ea7122735de30d91fc which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=f62f0f59a33d2c42bd4236ea7122735de30d91fc
> > You may checkout this tag using:
> >git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch
> > commons-lang-3.11-RC2 commons-lang-3.11-RC2
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1506/org/apache/commons/commons-lang3/3.11/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Sun Jul 12 09:31:57 EDT 2020
> > commons-lang3-3.11-bin.tar.gz=314ed5b2a0af658a008b0c6dbba0c79c8e465a413fa483b68eaa7d60ef6731ca12bd04fc5a1e7c4faab4eedfca48b1ebc51228dc4bbcc44287aac6805e41d8a1
> > commons-lang3-3.11-bin.zip=e2406057b664b2c2230f8804ed442c72e28ab93e01cca1d46d4dbbd5b179f0fbc1f02218654b459718f483210cb5e3f8621d4f3c31f0b3bb3ff05f8913e18f6c
> > commons-lang3-3.11-javadoc.jar=ccba8259d8eb75c721145d0da24e04ccc20af485f010db424eae33e5b2563f878e03b498b5a8bb3db637ac1db5e14868f7356412f8679f6ce6ed82d9a0a62f4d
> > commons-lang3-3.11-sources.jar=b9c210c4c78823b5eb50f420791a0d6515bc8413bfff029d678aeea78331bba1c127557c0f67667c467a1f66b79806cc5ca18668e3ca55048eb50aaeccaea3e3
> > commons-lang3-3.11-src.tar.gz=ebcb13e47c24e6984835d9d6904fe33077aa3ba781cd61db109fa7005517e4e74cf086c4789a1d65cf3d6c4924b32337c98827a75f91aab908d8e8b9d3b92087
> > commons-lang3-3.11-src.zip=2c7f44f9a5c8d597595bdcd54905e08cf10260f265e194cb62c5142cd2573c2a59660f01760ff39442febf90e0c75aa377f91fc071fb1ab7bbc55c1476a9c363
> > commons-lang3-3.11-test-sources.jar=93345fb5a4c148eaad3d814973520640fae5fde8e4c72eafade846dc557301b1569f07ad1cd4a6bf81e8893846388208cf36addec40a2d2d1fa8fd18ad112b49
> > commons-lang3-3.11-tests.jar=a168e088e9993dcad96fe689d2a13d384b36b8dc93f19a92a34c93add3ce14388e8031d75bb378c0ebb30ec625d1a27e106c28a1a3f9001d5bf5b7c5cebde123
> >
> > I have tested this with:
> >
> > mvn -V -Duser.name=%my_apache_id%
> > -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease
> > -Ptest-deploy -P jacoco -P japicmp clean package site deploy
> >
> > using:
> >
> > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> > Maven home: C:\Java\apache-maven-3.6.3\bin\..
> > Java version: 1.8.0_251, vendor: Oracle Corporation, runtime: C:\Program
> > Files\Java\jdk1.8.0_251\jre
> > Default locale: en_US, platform encoding: Cp1252
> > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> >
> > Details of changes since 3.10 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/index.html
> >(note some *relative* links are broken and the 3.11 directories are not
> > yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report (compared to 3.10):
> >
> > https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/japicmp.html
> >
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/rat-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,
> >
> > 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

Re: [all] release validation

2020-07-13 Thread sebb

On Mon, 13 Jul 2020 at 13:53, Rob Tompkins  wrote:
>
>
>
> > On Jul 13, 2020, at 8:51 AM, Gary Gregory  wrote:
> >
> > On Mon, Jul 13, 2020 at 8:48 AM Rob Tompkins  > > wrote:
> >
> >>
> >>
> >>> On Jul 13, 2020, at 8:46 AM, Gary Gregory 
> >> wrote:
> >>>
> >>> Is there still room for corruption after a vote passes when the files are
> >>> moved in SVN from the dev to dist folder?
> >>
> >> Good question….but I would think we would notice that after the fact with
> >> an alert like the ones that we’ve gotten about signatures not matching. So
> >> I would think that we wouldn’t worry about it?
> >>
> >
> > I hope not! ;-)
>
> I think this is another case where we need @markt to weigh in.

I don't think it's possible for an SVN rename to corrupt files, but of
course the names might be mangled or some files may be overlooked.

Another reason for checking hashes is that sometimes artifacts have to
be fixed and uploaded anew.
The hash can be overlooked (I think that has happened in the past).

We need to be checking what the consumers will see.

> -Rob
>
> >
> > Gary
> >
> >
> >>
> >> -Rob
> >>
> >>>
> >>> Gary
> >>>
> >>> On Mon, Jul 13, 2020 at 8:29 AM Rob Tompkins  wrote:
> >>>
>  I’ll take the shell scripts that I’ve been using and enrich them a
> >> little,
>  and then I’ll share them with folks.I think we can likely put them in
> >> one
>  of the plugins so that folks can simply run the script to move and
> >> download
>  all the artifacts in their checkout of the svn directory.
> 
>  Cheers,
>  -Rob
> 
> > On Jul 13, 2020, at 8:12 AM, Rob Tompkins  wrote:
> >
> > Yes…I agree with that need. I was wondering if the release plugin was
>  doing that or nexus itself was doing that. But, I definitely understand
>  that they show up in nexus when using the plugin.
> >
> > Cheers,
> > -Rob
> >
> >> On Jul 13, 2020, at 8:10 AM, Gary Gregory 
>  wrote:
> >>
> >> Rob, if you plan on working on the release plugin, can you see if
> >> there
>  is
> >> a way to have the VOTE not generate checksum lines for ASC files? IIRC
>  we
> >> do not need checksums for ASC files.
> >>
> >> Speaking for corrupted uploads, does the Maven deploy goal check that
>  its
> >> uploads are sane?
> >>
> >> Gary
> >>
> >> Gary
> >>
> >> On Mon, Jul 13, 2020, 08:04 Rob Tompkins  wrote:
> >>
> >>> This all makes sense to me. Many thanks for the feedback here.
> >>>
> >>> Cheers,
> >>> -Rob
> >>>
>  On Jul 13, 2020, at 5:12 AM, Mark Thomas  wrote:
> 
>  On 13/07/2020 06:43, Stefan Bodewig wrote:
> > On 2020-07-12, Rob Tompkins wrote:
> >
> >> given the consistency of the signatures from the plugins…do we
> >> need
>  to
> >> check them for releases anymore?
> >
> > Yes, please. Not everybody uses the plugins and even if everybody
>  did a
> > misconfiguration could be pulling in the wrong key or a key not
> > available from the expected download location.
> 
>  +1, for several reasons
> 
>  It also catches corrupted uploads.
> 
>  It is simpler to fix during a release vote than after a release
> >> where
>  we'd have to at least consider the possibility of malicious activity
>  and
>  respond accordingly until we could prove it wasn't.
> 
>  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 
> >> 

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

Re: [all] release validation

2020-07-13 Thread Rob Tompkins



> On Jul 13, 2020, at 8:51 AM, Gary Gregory  wrote:
> 
> On Mon, Jul 13, 2020 at 8:48 AM Rob Tompkins  > wrote:
> 
>> 
>> 
>>> On Jul 13, 2020, at 8:46 AM, Gary Gregory 
>> wrote:
>>> 
>>> Is there still room for corruption after a vote passes when the files are
>>> moved in SVN from the dev to dist folder?
>> 
>> Good question….but I would think we would notice that after the fact with
>> an alert like the ones that we’ve gotten about signatures not matching. So
>> I would think that we wouldn’t worry about it?
>> 
> 
> I hope not! ;-)

I think this is another case where we need @markt to weigh in.

-Rob

> 
> Gary
> 
> 
>> 
>> -Rob
>> 
>>> 
>>> Gary
>>> 
>>> On Mon, Jul 13, 2020 at 8:29 AM Rob Tompkins  wrote:
>>> 
 I’ll take the shell scripts that I’ve been using and enrich them a
>> little,
 and then I’ll share them with folks.I think we can likely put them in
>> one
 of the plugins so that folks can simply run the script to move and
>> download
 all the artifacts in their checkout of the svn directory.
 
 Cheers,
 -Rob
 
> On Jul 13, 2020, at 8:12 AM, Rob Tompkins  wrote:
> 
> Yes…I agree with that need. I was wondering if the release plugin was
 doing that or nexus itself was doing that. But, I definitely understand
 that they show up in nexus when using the plugin.
> 
> Cheers,
> -Rob
> 
>> On Jul 13, 2020, at 8:10 AM, Gary Gregory 
 wrote:
>> 
>> Rob, if you plan on working on the release plugin, can you see if
>> there
 is
>> a way to have the VOTE not generate checksum lines for ASC files? IIRC
 we
>> do not need checksums for ASC files.
>> 
>> Speaking for corrupted uploads, does the Maven deploy goal check that
 its
>> uploads are sane?
>> 
>> Gary
>> 
>> Gary
>> 
>> On Mon, Jul 13, 2020, 08:04 Rob Tompkins  wrote:
>> 
>>> This all makes sense to me. Many thanks for the feedback here.
>>> 
>>> Cheers,
>>> -Rob
>>> 
 On Jul 13, 2020, at 5:12 AM, Mark Thomas  wrote:
 
 On 13/07/2020 06:43, Stefan Bodewig wrote:
> On 2020-07-12, Rob Tompkins wrote:
> 
>> given the consistency of the signatures from the plugins…do we
>> need
 to
>> check them for releases anymore?
> 
> Yes, please. Not everybody uses the plugins and even if everybody
 did a
> misconfiguration could be pulling in the wrong key or a key not
> available from the expected download location.
 
 +1, for several reasons
 
 It also catches corrupted uploads.
 
 It is simpler to fix during a release vote than after a release
>> where
 we'd have to at least consider the possibility of malicious activity
 and
 respond accordingly until we could prove it wasn't.
 
 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: [all] release validation

2020-07-13 Thread Gary Gregory

On Mon, Jul 13, 2020 at 8:48 AM Rob Tompkins  wrote:

>
>
> > On Jul 13, 2020, at 8:46 AM, Gary Gregory 
> wrote:
> >
> > Is there still room for corruption after a vote passes when the files are
> > moved in SVN from the dev to dist folder?
>
> Good question….but I would think we would notice that after the fact with
> an alert like the ones that we’ve gotten about signatures not matching. So
> I would think that we wouldn’t worry about it?
>

I hope not! ;-)

Gary


>
> -Rob
>
> >
> > Gary
> >
> > On Mon, Jul 13, 2020 at 8:29 AM Rob Tompkins  wrote:
> >
> >> I’ll take the shell scripts that I’ve been using and enrich them a
> little,
> >> and then I’ll share them with folks.I think we can likely put them in
> one
> >> of the plugins so that folks can simply run the script to move and
> download
> >> all the artifacts in their checkout of the svn directory.
> >>
> >> Cheers,
> >> -Rob
> >>
> >>> On Jul 13, 2020, at 8:12 AM, Rob Tompkins  wrote:
> >>>
> >>> Yes…I agree with that need. I was wondering if the release plugin was
> >> doing that or nexus itself was doing that. But, I definitely understand
> >> that they show up in nexus when using the plugin.
> >>>
> >>> Cheers,
> >>> -Rob
> >>>
>  On Jul 13, 2020, at 8:10 AM, Gary Gregory 
> >> wrote:
> 
>  Rob, if you plan on working on the release plugin, can you see if
> there
> >> is
>  a way to have the VOTE not generate checksum lines for ASC files? IIRC
> >> we
>  do not need checksums for ASC files.
> 
>  Speaking for corrupted uploads, does the Maven deploy goal check that
> >> its
>  uploads are sane?
> 
>  Gary
> 
>  Gary
> 
>  On Mon, Jul 13, 2020, 08:04 Rob Tompkins  wrote:
> 
> > This all makes sense to me. Many thanks for the feedback here.
> >
> > Cheers,
> > -Rob
> >
> >> On Jul 13, 2020, at 5:12 AM, Mark Thomas  wrote:
> >>
> >> On 13/07/2020 06:43, Stefan Bodewig wrote:
> >>> On 2020-07-12, Rob Tompkins wrote:
> >>>
>  given the consistency of the signatures from the plugins…do we
> need
> >> to
>  check them for releases anymore?
> >>>
> >>> Yes, please. Not everybody uses the plugins and even if everybody
> >> did a
> >>> misconfiguration could be pulling in the wrong key or a key not
> >>> available from the expected download location.
> >>
> >> +1, for several reasons
> >>
> >> It also catches corrupted uploads.
> >>
> >> It is simpler to fix during a release vote than after a release
> where
> >> we'd have to at least consider the possibility of malicious activity
> >> and
> >> respond accordingly until we could prove it wasn't.
> >>
> >> 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: [all] release validation

2020-07-13 Thread Rob Tompkins




> On Jul 13, 2020, at 8:46 AM, Gary Gregory  wrote:
> 
> Is there still room for corruption after a vote passes when the files are
> moved in SVN from the dev to dist folder?

Good question….but I would think we would notice that after the fact with an 
alert like the ones that we’ve gotten about signatures not matching. So I would 
think that we wouldn’t worry about it?

-Rob

> 
> Gary
> 
> On Mon, Jul 13, 2020 at 8:29 AM Rob Tompkins  wrote:
> 
>> I’ll take the shell scripts that I’ve been using and enrich them a little,
>> and then I’ll share them with folks.I think we can likely put them in one
>> of the plugins so that folks can simply run the script to move and download
>> all the artifacts in their checkout of the svn directory.
>> 
>> Cheers,
>> -Rob
>> 
>>> On Jul 13, 2020, at 8:12 AM, Rob Tompkins  wrote:
>>> 
>>> Yes…I agree with that need. I was wondering if the release plugin was
>> doing that or nexus itself was doing that. But, I definitely understand
>> that they show up in nexus when using the plugin.
>>> 
>>> Cheers,
>>> -Rob
>>> 
 On Jul 13, 2020, at 8:10 AM, Gary Gregory 
>> wrote:
 
 Rob, if you plan on working on the release plugin, can you see if there
>> is
 a way to have the VOTE not generate checksum lines for ASC files? IIRC
>> we
 do not need checksums for ASC files.
 
 Speaking for corrupted uploads, does the Maven deploy goal check that
>> its
 uploads are sane?
 
 Gary
 
 Gary
 
 On Mon, Jul 13, 2020, 08:04 Rob Tompkins  wrote:
 
> This all makes sense to me. Many thanks for the feedback here.
> 
> Cheers,
> -Rob
> 
>> On Jul 13, 2020, at 5:12 AM, Mark Thomas  wrote:
>> 
>> On 13/07/2020 06:43, Stefan Bodewig wrote:
>>> On 2020-07-12, Rob Tompkins wrote:
>>> 
 given the consistency of the signatures from the plugins…do we need
>> to
 check them for releases anymore?
>>> 
>>> Yes, please. Not everybody uses the plugins and even if everybody
>> did a
>>> misconfiguration could be pulling in the wrong key or a key not
>>> available from the expected download location.
>> 
>> +1, for several reasons
>> 
>> It also catches corrupted uploads.
>> 
>> It is simpler to fix during a release vote than after a release where
>> we'd have to at least consider the possibility of malicious activity
>> and
>> respond accordingly until we could prove it wasn't.
>> 
>> 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: [all] release validation

2020-07-13 Thread Gary Gregory

Is there still room for corruption after a vote passes when the files are
moved in SVN from the dev to dist folder?

Gary

On Mon, Jul 13, 2020 at 8:29 AM Rob Tompkins  wrote:

> I’ll take the shell scripts that I’ve been using and enrich them a little,
> and then I’ll share them with folks.I think we can likely put them in one
> of the plugins so that folks can simply run the script to move and download
> all the artifacts in their checkout of the svn directory.
>
> Cheers,
> -Rob
>
> > On Jul 13, 2020, at 8:12 AM, Rob Tompkins  wrote:
> >
> > Yes…I agree with that need. I was wondering if the release plugin was
> doing that or nexus itself was doing that. But, I definitely understand
> that they show up in nexus when using the plugin.
> >
> > Cheers,
> > -Rob
> >
> >> On Jul 13, 2020, at 8:10 AM, Gary Gregory 
> wrote:
> >>
> >> Rob, if you plan on working on the release plugin, can you see if there
> is
> >> a way to have the VOTE not generate checksum lines for ASC files? IIRC
> we
> >> do not need checksums for ASC files.
> >>
> >> Speaking for corrupted uploads, does the Maven deploy goal check that
> its
> >> uploads are sane?
> >>
> >> Gary
> >>
> >> Gary
> >>
> >> On Mon, Jul 13, 2020, 08:04 Rob Tompkins  wrote:
> >>
> >>> This all makes sense to me. Many thanks for the feedback here.
> >>>
> >>> Cheers,
> >>> -Rob
> >>>
>  On Jul 13, 2020, at 5:12 AM, Mark Thomas  wrote:
> 
>  On 13/07/2020 06:43, Stefan Bodewig wrote:
> > On 2020-07-12, Rob Tompkins wrote:
> >
> >> given the consistency of the signatures from the plugins…do we need
> to
> >> check them for releases anymore?
> >
> > Yes, please. Not everybody uses the plugins and even if everybody
> did a
> > misconfiguration could be pulling in the wrong key or a key not
> > available from the expected download location.
> 
>  +1, for several reasons
> 
>  It also catches corrupted uploads.
> 
>  It is simpler to fix during a release vote than after a release where
>  we'd have to at least consider the possibility of malicious activity
> and
>  respond accordingly until we could prove it wasn't.
> 
>  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: [all] release validation

2020-07-13 Thread Rob Tompkins

I’ll take the shell scripts that I’ve been using and enrich them a little, and 
then I’ll share them with folks.I think we can likely put them in one of the 
plugins so that folks can simply run the script to move and download all the 
artifacts in their checkout of the svn directory.

Cheers,
-Rob

> On Jul 13, 2020, at 8:12 AM, Rob Tompkins  wrote:
> 
> Yes…I agree with that need. I was wondering if the release plugin was doing 
> that or nexus itself was doing that. But, I definitely understand that they 
> show up in nexus when using the plugin.
> 
> Cheers,
> -Rob
> 
>> On Jul 13, 2020, at 8:10 AM, Gary Gregory  wrote:
>> 
>> Rob, if you plan on working on the release plugin, can you see if there is
>> a way to have the VOTE not generate checksum lines for ASC files? IIRC we
>> do not need checksums for ASC files.
>> 
>> Speaking for corrupted uploads, does the Maven deploy goal check that its
>> uploads are sane?
>> 
>> Gary
>> 
>> Gary
>> 
>> On Mon, Jul 13, 2020, 08:04 Rob Tompkins  wrote:
>> 
>>> This all makes sense to me. Many thanks for the feedback here.
>>> 
>>> Cheers,
>>> -Rob
>>> 
 On Jul 13, 2020, at 5:12 AM, Mark Thomas  wrote:
 
 On 13/07/2020 06:43, Stefan Bodewig wrote:
> On 2020-07-12, Rob Tompkins wrote:
> 
>> given the consistency of the signatures from the plugins…do we need to
>> check them for releases anymore?
> 
> Yes, please. Not everybody uses the plugins and even if everybody did a
> misconfiguration could be pulling in the wrong key or a key not
> available from the expected download location.
 
 +1, for several reasons
 
 It also catches corrupted uploads.
 
 It is simpler to fix during a release vote than after a release where
 we'd have to at least consider the possibility of malicious activity and
 respond accordingly until we could prove it wasn't.
 
 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: [all] release validation

2020-07-13 Thread Rob Tompkins

Yes…I agree with that need. I was wondering if the release plugin was doing 
that or nexus itself was doing that. But, I definitely understand that they 
show up in nexus when using the plugin.

Cheers,
-Rob

> On Jul 13, 2020, at 8:10 AM, Gary Gregory  wrote:
> 
> Rob, if you plan on working on the release plugin, can you see if there is
> a way to have the VOTE not generate checksum lines for ASC files? IIRC we
> do not need checksums for ASC files.
> 
> Speaking for corrupted uploads, does the Maven deploy goal check that its
> uploads are sane?
> 
> Gary
> 
> Gary
> 
> On Mon, Jul 13, 2020, 08:04 Rob Tompkins  wrote:
> 
>> This all makes sense to me. Many thanks for the feedback here.
>> 
>> Cheers,
>> -Rob
>> 
>>> On Jul 13, 2020, at 5:12 AM, Mark Thomas  wrote:
>>> 
>>> On 13/07/2020 06:43, Stefan Bodewig wrote:
 On 2020-07-12, Rob Tompkins wrote:
 
> given the consistency of the signatures from the plugins…do we need to
> check them for releases anymore?
 
 Yes, please. Not everybody uses the plugins and even if everybody did a
 misconfiguration could be pulling in the wrong key or a key not
 available from the expected download location.
>>> 
>>> +1, for several reasons
>>> 
>>> It also catches corrupted uploads.
>>> 
>>> It is simpler to fix during a release vote than after a release where
>>> we'd have to at least consider the possibility of malicious activity and
>>> respond accordingly until we could prove it wasn't.
>>> 
>>> 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: [all] release validation

2020-07-13 Thread Gary Gregory

Rob, if you plan on working on the release plugin, can you see if there is
a way to have the VOTE not generate checksum lines for ASC files? IIRC we
do not need checksums for ASC files.

Speaking for corrupted uploads, does the Maven deploy goal check that its
uploads are sane?

Gary

Gary

On Mon, Jul 13, 2020, 08:04 Rob Tompkins  wrote:

> This all makes sense to me. Many thanks for the feedback here.
>
> Cheers,
> -Rob
>
> > On Jul 13, 2020, at 5:12 AM, Mark Thomas  wrote:
> >
> > On 13/07/2020 06:43, Stefan Bodewig wrote:
> >> On 2020-07-12, Rob Tompkins wrote:
> >>
> >>> given the consistency of the signatures from the plugins…do we need to
> >>> check them for releases anymore?
> >>
> >> Yes, please. Not everybody uses the plugins and even if everybody did a
> >> misconfiguration could be pulling in the wrong key or a key not
> >> available from the expected download location.
> >
> > +1, for several reasons
> >
> > It also catches corrupted uploads.
> >
> > It is simpler to fix during a release vote than after a release where
> > we'd have to at least consider the possibility of malicious activity and
> > respond accordingly until we could prove it wasn't.
> >
> > 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: [all] release validation

2020-07-13 Thread Rob Tompkins

This all makes sense to me. Many thanks for the feedback here.

Cheers,
-Rob

> On Jul 13, 2020, at 5:12 AM, Mark Thomas  wrote:
> 
> On 13/07/2020 06:43, Stefan Bodewig wrote:
>> On 2020-07-12, Rob Tompkins wrote:
>> 
>>> given the consistency of the signatures from the plugins…do we need to
>>> check them for releases anymore?
>> 
>> Yes, please. Not everybody uses the plugins and even if everybody did a
>> misconfiguration could be pulling in the wrong key or a key not
>> available from the expected download location.
> 
> +1, for several reasons
> 
> It also catches corrupted uploads.
> 
> It is simpler to fix during a release vote than after a release where
> we'd have to at least consider the possibility of malicious activity and
> respond accordingly until we could prove it wasn't.
> 
> 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: [all] release validation

2020-07-13 Thread Gary Gregory

Corrupted uploads I had not considered,  good one. Maybe our VOTE template
in the release plugin could generate a script users can run to download and
verify each checksums. We already generate a list of files and their
checksum.

Gary

On Mon, Jul 13, 2020, 01:43 Stefan Bodewig  wrote:

> On 2020-07-12, Rob Tompkins wrote:
>
> > given the consistency of the signatures from the plugins…do we need to
> > check them for releases anymore?
>
> Yes, please. Not everybody uses the plugins and even if everybody did a
> misconfiguration could be pulling in the wrong key or a key not
> available from the expected download location.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [all] release validation

2020-07-13 Thread Gilles Sadowski

Hi.

Le lun. 13 juil. 2020 à 11:12, Mark Thomas  a écrit :
>
> On 13/07/2020 06:43, Stefan Bodewig wrote:
> > On 2020-07-12, Rob Tompkins wrote:
> >
> >> given the consistency of the signatures from the plugins…do we need to
> >> check them for releases anymore?
> >
> > Yes, please. Not everybody uses the plugins and even if everybody did a
> > misconfiguration could be pulling in the wrong key or a key not
> > available from the expected download location.
>
> +1, for several reasons
>
> It also catches corrupted uploads.
>
> It is simpler to fix during a release vote than after a release where
> we'd have to at least consider the possibility of malicious activity and
> respond accordingly until we could prove it wasn't.
>
> Mark

Perhaps I don't understand the implications of the question asked;
I've been suggesting for more than a couple of years that after the
"upload" part, the same script could download the artefacts: Unless
I'm missing something, this would rule out the scenario which you've
evoked above.

Regards,
Gilles

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

Re: [all] release validation

2020-07-13 Thread Mark Thomas

On 13/07/2020 06:43, Stefan Bodewig wrote:
> On 2020-07-12, Rob Tompkins wrote:
> 
>> given the consistency of the signatures from the plugins…do we need to
>> check them for releases anymore?
> 
> Yes, please. Not everybody uses the plugins and even if everybody did a
> misconfiguration could be pulling in the wrong key or a key not
> available from the expected download location.

+1, for several reasons

It also catches corrupted uploads.

It is simpler to fix during a release vote than after a release where
we'd have to at least consider the possibility of malicious activity and
respond accordingly until we could prove it wasn't.

Mark

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

Re: [all] release validation

2020-07-12 Thread Stefan Bodewig

On 2020-07-12, Rob Tompkins wrote:

> given the consistency of the signatures from the plugins…do we need to
> check them for releases anymore?

Yes, please. Not everybody uses the plugins and even if everybody did a
misconfiguration could be pulling in the wrong key or a key not
available from the expected download location.

Stefan

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

[all] release validation (was: Re: [VOTE] Release Apache Commons Lang 3.11 based on RC2)

2020-07-12 Thread Rob Tompkins

given the consistency of the signatures from the plugins…do we need to check 
them for releases anymore? I have been using shell scripts to validate all of 
the md5’s, sha1’s, sha512’s, and gpg signatures that come out of the process.

@sebb or @markt do you have an opinion here?

-Rob

> On Jul 12, 2020, at 9:42 AM, Gary Gregory  wrote:
> 
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Lang 3.10 was released, so I would like to release
> Apache Commons Lang 3.11.
> 
> Apache Commons Lang 3.11 RC2 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2 (svn
> revision 40434)
> 
> The Git tag commons-lang-3.11-RC2 commit for this RC is
> f62f0f59a33d2c42bd4236ea7122735de30d91fc which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=f62f0f59a33d2c42bd4236ea7122735de30d91fc
> You may checkout this tag using:
>git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch
> commons-lang-3.11-RC2 commons-lang-3.11-RC2
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1506/org/apache/commons/commons-lang3/3.11/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Sun Jul 12 09:31:57 EDT 2020
> commons-lang3-3.11-bin.tar.gz=314ed5b2a0af658a008b0c6dbba0c79c8e465a413fa483b68eaa7d60ef6731ca12bd04fc5a1e7c4faab4eedfca48b1ebc51228dc4bbcc44287aac6805e41d8a1
> commons-lang3-3.11-bin.zip=e2406057b664b2c2230f8804ed442c72e28ab93e01cca1d46d4dbbd5b179f0fbc1f02218654b459718f483210cb5e3f8621d4f3c31f0b3bb3ff05f8913e18f6c
> commons-lang3-3.11-javadoc.jar=ccba8259d8eb75c721145d0da24e04ccc20af485f010db424eae33e5b2563f878e03b498b5a8bb3db637ac1db5e14868f7356412f8679f6ce6ed82d9a0a62f4d
> commons-lang3-3.11-sources.jar=b9c210c4c78823b5eb50f420791a0d6515bc8413bfff029d678aeea78331bba1c127557c0f67667c467a1f66b79806cc5ca18668e3ca55048eb50aaeccaea3e3
> commons-lang3-3.11-src.tar.gz=ebcb13e47c24e6984835d9d6904fe33077aa3ba781cd61db109fa7005517e4e74cf086c4789a1d65cf3d6c4924b32337c98827a75f91aab908d8e8b9d3b92087
> commons-lang3-3.11-src.zip=2c7f44f9a5c8d597595bdcd54905e08cf10260f265e194cb62c5142cd2573c2a59660f01760ff39442febf90e0c75aa377f91fc071fb1ab7bbc55c1476a9c363
> commons-lang3-3.11-test-sources.jar=93345fb5a4c148eaad3d814973520640fae5fde8e4c72eafade846dc557301b1569f07ad1cd4a6bf81e8893846388208cf36addec40a2d2d1fa8fd18ad112b49
> commons-lang3-3.11-tests.jar=a168e088e9993dcad96fe689d2a13d384b36b8dc93f19a92a34c93add3ce14388e8031d75bb378c0ebb30ec625d1a27e106c28a1a3f9001d5bf5b7c5cebde123
> 
> I have tested this with:
> 
> mvn -V -Duser.name=%my_apache_id%
> -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease
> -Ptest-deploy -P jacoco -P japicmp clean package site deploy
> 
> using:
> 
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\Java\apache-maven-3.6.3\bin\..
> Java version: 1.8.0_251, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_251\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Details of changes since 3.10 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/changes-report.html
> 
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/index.html
>(note some *relative* links are broken and the 3.11 directories are not
> yet created - these will be OK once the site is deployed.)
> 
> JApiCmp Report (compared to 3.10):
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/japicmp.html
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.11-RC2/site/rat-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,
> 
> 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-lang.git --branch
> commons-lang-3.11-RC2 commons-lang-3.11-RC2
> cd commons-lang-3.11-RC2
> 
> 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

Re: [all] release validation (was: Re: [VOTE] Release Apache Commons Lang 3.11 based on RC2)

Re: [all] release validation (was: Re: [VOTE] Release Apache Commons Lang 3.11 based on RC2)

Re: [all] release validation

Re: [all] release validation

Re: [all] release validation

Re: [all] release validation

Re: [all] release validation

Re: [all] release validation

Re: [all] release validation

Re: [all] release validation

Re: [all] release validation

Re: [all] release validation

Re: [all] release validation

Re: [all] release validation

Re: [all] release validation

[all] release validation (was: Re: [VOTE] Release Apache Commons Lang 3.11 based on RC2)

16 matches

Site Navigation

Mail list logo

Footer information