[
https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973358#comment-16973358
]
Michael Semb Wever edited comment on CASSANDRA-14970 at 11/13/19 1:56 PM:
--------------------------------------------------------------------------
This is work in progress, but I've pushed the following branches to
[cassandra|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_14970]
and
[cassandra-builds|https://github.com/apache/cassandra-builds/compare/master...thelastpickle:mck/14970_sha512-checksums].
The changes involve…
- remove the source and binary artefacts from being uploaded to nexus (nexus
is meant for maven artefacts)
- removes the use of people.apache.org for staging test artefacts (this
practice was deprecated, with a deadline of 31st December 2012)
- uses svnpubsub staging of all non-maven artefacts (ie
https://dist.apache.org/repos/dist/dev/cassandra/ )
- adds the rpm docker stuff into the script
- removes the copy of the source artefact in the debian binary's folder
- adds a "test announcement" email template (it is encouraged to be announcing
test builds a few days in advance of starting the vote)
Still to do is…
- generate the sha512 and gnupg asc signatures on the non-maven artefacts
- remove the `only_deb` flag (is it really needed?)
- make corresponding changes to {{finish_release.sh}} and
{{upload_bintray.sh}} scripts
- test rpm docker stuff inside script
- make patches for 2.2, 3.0, 3.11
[~mshuler], if you agree , shall i continue with this approach?
was (Author: michaelsembwever):
This is work in progress, but I've pushed the following branches to
[cassandra|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_14970]
and
[cassandra-builds|https://github.com/apache/cassandra-builds/compare/master...thelastpickle:mck/14970_sha512-checksums].
The changes involve…
- remove the source and binary artefacts from being uploaded to nexus (nexus
is meant for maven artefacts)
- removes the use of people.apache.org for staging test artefacts (this
practice was deprecated, with a deadline of 31st December 2012)
- uses svnpubsub staging of all non-maven artefacts (ie
https://dist.apache.org/repos/dist/dev/cassandra/ )
- adds the rpm docker stuff into the script
- removes the copy of the source artefact in the debian binary's folder
- adds a "test announcement" email template (it is encouraged to be announcing
test builds a few days in advance of starting the vote)
Still to do is…
- generate the sha512 and gnupg asc signatures on the non-maven artefacts
- remove the `only_deb` flag (is it really needed?)
- make corresponding changes to {{finish_release.sh}} and
{{upload_bintray.sh}} scripts
- make patches for 2.2, 3.0, 3.11
[~mshuler], if you agree , shall i continue with this approach?
> New releases must supply SHA-256 and/or SHA-512 checksums
> ---------------------------------------------------------
>
> Key: CASSANDRA-14970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14970
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
> Reporter: Michael Shuler
> Assignee: Michael Shuler
> Priority: Urgent
> Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0
>
> Attachments:
> 0001-Update-downloads-for-sha256-sha512-checksum-files.patch,
> 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch,
> ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png
>
>
> Release policy was updated around 9/2018 to state:
> "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT
> supply MD5 or SHA-1. Existing releases do not need to be changed."
> build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both.
> cassandra-builds/cassandra-release scripts need to be updated to work with
> the new checksum files.
> http://www.apache.org/dev/release-distribution#sigs-and-sums
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
