Shall we use this for commons-parent? Bye, Thomas.
-------- Forwarded Message -------- Subject: Re: New release distribution checksum policy Date: Thu, 23 Aug 2018 08:02:45 +0200 From: Hervé BOUTEMY <herve.bout...@free.fr> Reply-To: memb...@apache.org To: memb...@apache.org FYI, Apache parent POM 21 has been released https://s.apache.org/asf-pom-21 it generates .sha512 checksum in target/checkout/target/ during release with Maven Release Plugin, ready to be copied to Apache dist area: I used it during the release (eating my own dog's food), the .sha512 file in this release comes from this tooling notice: nothing goes through any Maven repository (be it local, staging or central), then it does not hurt Apache Nexus nor Maven central controls Regards, Hervé Le vendredi 17 août 2018, 12:32:57 CEST Mark Struberg a écrit : > Thanks Hervé, really appreciated! > > I suggest to only enforce the new rules once all our toolchain is ready. > And again: what to do with older content? Shouldn't we also at least go > through all out dist + archive and add the sha512? > > LieGrue, > strub > > > Am 17.08.2018 um 11:34 schrieb herve.bout...@free.fr: > > > > for people using Maven release plugin as configured by Apache parent POM > > [1], an update for version 21 is in progress tracked as MPOM-205 [2] > > which will provide the .sha512 checksum file with the source release > > archive and its signature in target/checkout/target/ > > > > I'll start the release vote tomorrow > > > > Regards, > > > > Hervé > > > > [1] https://maven.apache.org/pom/asf/ > > > > [2] https://issues.apache.org/jira/browse/MPOM-205 > > > > ----- Mail original ----- > > De: "Henk P. Penning" <penn...@uu.nl> > > À: memb...@apache.org > > Envoyé: Jeudi 16 Août 2018 12:23:36 > > Objet: Re: New release distribution checksum policy > > > > On Thu, 16 Aug 2018, Mark Struberg wrote: > >> Date: Thu, 16 Aug 2018 09:14:57 +0200 > >> From: Mark Struberg <strub...@yahoo.de> > >> To: memb...@apache.org > >> Subject: Re: New release distribution checksum policy > >> > >> What is the date when this should be effective? > >> > > The policy is already 'effective' ; the policy page has been changed. > > In fact, the page was mauled weeks ago ; then slowly converged > > > > to its present state : > > http://www.apache.org/dev/release-distribution#sigs-and-sums > >> > >> Projects will likely need to update their build process, updating > >> maven plugins, etc > >> > > The Maven people assure me that Maven does not support 'deployment' > > into /dist/. Period. > > > > For Maven-based projects, publishing into /dist/ in 'manual labor' ; > > this involves : > > -- removing .md5's > > -- replacing .sha1's by .sha256's or .sha512's > > I think that is unfortunate, but that's the way it is ; > > it seems fixable, but I know almost nothing about Maven. > > > > For other (non-Maven-based) projects, generating a SHA-256, > > instead of a SHA-1, should be easy ... > >> > >> So I suggest to at least give a 3 month buffer period. > >> > > The only new "MUST" is : > > New releases MUST have a SHA-256 and/or SHA-512 checksum file > > > > ... and who/what is checking that ? > > > > https://checker.apache.org/ 'solves' it by classifying > > a resulting policy violation as a 'warning'. > > In a few months that could be changed to 'error'. > >> > >> While it is possible to create collisions in sha1 it is rather > >> unlikely *right now* to create a collision PLUS get a valid binary out > >> of it. We are talking about a multi-month effort in a cloud-scale GPU > >> environment afaik. > >> > > I agree there is no immediate danger ; the change is cosmetic. > > Like other org's, we must be seen to be moving away from SHA-1. > > Hopefully there are fewer "why is SHA-1 deprecated?" than > > "shouldn't we deprecate SHA-1?" threads :-). > >> > >> Another question: is it possible to create sha256 in our Nexus at > >> least for repository.a.o? We could then provide this hash for our old > >> releases as well and later adapt our download pages. > >> > >> txs and LieGrue, > >> strub > >> > > Groeten, > > > > Henk Penning > > > > ------------------------------------------------------------ _ > > Henk P. Penning, ICT-beta R Uithof MG-403 _/ \_ > > Faculty of Science, Utrecht University T +31 30 253 4106 / \_/ \ > > Leuvenlaan 4, 3584CE Utrecht, NL F +31 30 253 4553 \_/ \_/ > > http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/ > > > >>> Am 15.08.2018 um 10:19 schrieb Henk P. Penning <penn...@uu.nl>: > >>> > >>> On Tue, 14 Aug 2018, Shane Curcuru wrote: > >>>> Date: Tue, 14 Aug 2018 15:18:34 +0200 > >>>> From: Shane Curcuru <a...@shanecurcuru.org> > >>>> To: memb...@apache.org > >>>> Subject: Re: New release distribution checksum policy > >>>> > >>>> To be clear: later this week I'll be sending an email to pmcs@ about > >>>> other services. If someone can get me a specific short paragraph and > >>>> link to the appropriate apache.org URL, I will add it to my email. > >>>> > >>>> Knowing who's writing that paragraph and URL and when they'll provide > >>>> them would be helpful (I'm not the person to write about release policy > >>>> myself...) > >>> > >>> See below my signature the proposal I sent to users@infra.a.o. > >>> Perhaps not 'short', but [IMHO] the change deserves a full > >>> explanation ; to avoid confusion. > >>> > >>> Last time we changed policy (abandon MD5, march 2018), > >>> it raised a lot of followup questions ; so I added > >>> a few hints about avoiding "dist area errors" too. > >>> > >>> Perhaps the notification mail should say where > >>> questions, remarks etc should go. > >>> > >>> Regards, > >>> > >>> Henk Penning > >>> > >>> PS :-) visit https://checker.apache.org/ > >>> > >>> ------------------------------------------------------------ _ > >>> Henk P. Penning, ICT-beta R Uithof MG-403 _/ \_ > >>> Faculty of Science, Utrecht University T +31 30 253 4106 / \_/ \ > >>> Leuvenlaan 4, 3584CE Utrecht, NL F +31 30 253 4553 \_/ \_/ > >>> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/ > >>> ------------------------------------------------------------ _ > >>> > >>> Hi PMCs, > >>> > >>> The Release Distribution Policy[1] changed regarding checksum files. > >>> See under "Cryptographic Signatures and Checksums Requirements" [2]. > >>> > >>> Note that "MUST", "SHOULD", "SHOULD NOT" are technical terms ; > >>> not just emphasized words ; for an explanation see RFC-2119 [3]. > >>> > >>> Old policy : > >>> -- SHOULD supply a SHA checksum file > >>> -- SHOULD NOT supply a MD5 checksum file > >>> > >>> New policy : > >>> -- SHOULD supply a SHA-256 and/or SHA-512 checksum file > >>> -- SHOULD NOT supply MD5 or SHA-1 checksum files > >>> > >>> Why this change ? > >>> > >>> -- Like MD5, SHA-1 is too broken ; we should move away from it. > >>> > >>> Impact for PMCs : > >>> -- for new releases : > >>> -- you MUST supply a SHA-256 and/or SHA-512 file > >>> -- you SHOULD NOT supply MD5 or SHA-1 files > >>> > >>> -- for past releases : > >>> -- you are not required to change anything ; > >>> -- it would be nice if you fixed your dist area ; > >>> -- start with : cleanup ; rename .sha's ; remove .md5's > >>> > >>> Cleanup : if your project develops (only) one branch, > >>> your dist area should contain (only) one release. > >>> > >>> The (legal) release policy [4] says that your dist area > >>> > >>> "should contain the latest release in each branch that is currently > >>> under development. When development ceases on a version branch, > >>> releases of that branch should be removed from /dist." > >>> > >>> Many "checksum problems" can be fixed by cleaning up your dist area. > >>> > >>> FYI ; to check the health of your dist area visit : > >>> https://checker.apache.org/ > >>> > >>> [1] http://www.apache.org/dev/release-distribution > >>> [2] http://www.apache.org/dev/release-distribution#sigs-and-sums > >>> [3] https://www.ietf.org/rfc/rfc2119.txt > >>> [4] https://www.apache.org/legal/release-policy.html#when-to-archive --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
