On 09/15/2017 03:59 PM, Clebert Suconic wrote:
Just for my education. Why you Decided to drop downloading the .sha1 and
are creating a new one?
All the other downloads we have are using the .sha1?
As Robbie stated in the original message the Apache recommendation for
signatures on the official release artifacts is a sha512 based
signature, not the older sha1 that is used in the unofficial maven
release artifacts.
Refer here:
http://www.apache.org/dev/release-distribution.html#sigs-and-sums
On Fri, Sep 15, 2017 at 11:56 AM Robbie Gemmell <[email protected]>
wrote:
I tweaked the helper script to verify the downloaded tar/zip files
using their downloaded signature, then update the downloaded .md5 file
with filename info so it can verify easily with CLI tools, dropped
downloading the .sha1 and generated a new .sha512, and then at the end
verifies all the checksums as a sanity check (somewhat superfluous for
the SHA512, but doesn't hurt).
https://github.com/apache/activemq-artemis/commit/b7b2960e1f1870246f0c113f56d22cfc0f7a4269
If folks are happy with this I can update the instructions at
https://github.com/apache/activemq-artemis/blob/master/RELEASING.md to
reflect the slight process changes needed.
Robbie
On 14 September 2017 at 15:32, Clebert Suconic
<[email protected]> wrote:
I thought about checking the sum. Didn't have time.
I would check the files created by nexus Instead of creating new ones
thought.
Feel free to tweak the script. I will be out for a week. I will just
finish the release and I will be away for a week.
On Thu, Sep 14, 2017 at 5:48 AM Robbie Gemmell <[email protected]
wrote:
Script looks good, though I'd tweak it a little to cover the eased
checksum verification and supplying a SHA512 one (more below).
I agree that similar changes would be good for the ActiveMQ 5 releases
also, thats the main reason I didn't just detail things on the Artemis
2.3.0 vote thread.
Back to the script, I'd suggest tweaking it to add a check that the
signature verifies to ensure the downloaded files are ok, then rather
than download the .sha1 I'd have it generate a .sha512 file instead,
and would similarly update/regenerate the .md5 file to embed filename
info so it verifies easily with the CLI tooling. E.g:
gpg --verify $theFile.asc
md5sum $theFile > $theFile.md5
sha512sum $theFile > $theFile.sha512
Then testers and end users downloading the checksum files can just
verify them with the -c flags on the CLI tools, e.g you can check all
the checksums with just:
md5sum -c *.md5
sha512sum -c *.sha512
On 13 September 2017 at 23:36, Clebert Suconic
<[email protected]> wrote:
Ok, fair enough... I can see this as a process improvement.
I wasn't just understanding what you were proposing clearly enough.
I just added this script here:
https://github.com/apache/activemq-artemis/blob/master/scripts/download-release.sh
I didn't update the RELEASE.md yet...
I would add that during the release, you use the download-release from
the staged mvn repo using that script into the dev area.
The vote would have the staged download on dev, and we just make a
simple copy from one place to the other.. and remove the previous
thing.
But I think this should be also done on ActiveMQ 5 releases.
The thing that threw me of was when you mentioned extra work.. there's
no extra work here :)
It's actually saving me from screwing up eventually, so I take it as
an improvement.
On Wed, Sep 13, 2017 at 1:19 PM, Robbie Gemmell
<[email protected]> wrote:
Yes, thats essentially what I mean and do, I have a txt file I keep
some comments in as notes, and can source as a script to download the
various tars and signatures from nexus (though it could equally pull
them from the maven local repo, verifying the Nexus ones is good I
think), verify the signature, and generate new MD5+SHA512 checksum
files that include the filename details (it could instead manipualte
the MD5 one rather than create new). I execute that in a directory
within a checkout of the dist dev, then commit the files after a
little validation and open the vote.
The process of putting the files in the dist dev area is mostly the
same as what will be getting done now for the final release, it just
uses a different subtree of the same parent dist svn repo, so for
example you would use a subdir of
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/
before the vote rather than of
https://dist.apache.org/repos/dist/release/activemq/activemq-artemis/
after the vote.
To complete the example, had the files for the recent Artemis 2.3.0
vote been in the dist dev area already you would just do something
like this to complete the release once the vote had passed:
svn cp -m "add files for activemq-artemis-2.3.0"
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.3.0-rc1
https://dist.apache.org/repos/dist/release/activemq/activemq-artemis/2.3.0
Robbie
On 13 September 2017 at 17:52, Clebert Suconic
<[email protected]> wrote:
I actually see how to make the copy into dev... let me play with it
a
little bit....
On Wed, Sep 13, 2017 at 12:44 PM, Clebert Suconic
<[email protected]> wrote:
what about this:
Currently mvn release and mvn upload will always send the release
to
nexus,
So what about:
- we provide an script to artemis to download the correct bits of
the
release, the release manager would use that script to perform such
download.
- The release manager would place it on the dev repository Robbie
is
mentioning... (that means.. we wouldn't really have an extra step).
On thing I'm not sure how to do is... how to upload it to the dev
dist
at https://dist.apache.org/repos/dist/dev/activemq/
and how we would make the final move? just a regular copy?
On Wed, Sep 13, 2017 at 9:49 AM, Robbie Gemmell
<[email protected]> wrote:
On 13 September 2017 at 14:35, Clebert Suconic
<[email protected]> wrote:
On Wed, Sep 13, 2017 at 9:21 AM Robbie Gemmell <
[email protected]>
wrote:
This was less about time, though there is some benefit in that
regard,
with how much depending on how particular people actually verify
the
checksums I guess.
Actually this is kind of moot. nexus does that check for you.
You
cannot
upload a release with a checksum broken. It won't let you close.
Like. Last week I had to restart the release once because MVN
upload broke
the checksum somewhere.
--
Clebert Suconic
Whether the files in Nexus are ok isn't sufficient. The archives
and
checksum files in the dist repo are the mirrorer official release
artifacts (and strictly only the source ones at that), and Nexus
cant
check those. There could be a problem deploying those bits for a
variety of reasons, so we check they are ok. Users downloading the
release archives also tend to grab the checksums from the dist
repo
because that is their official source, in order to verify
downloads
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
