Am Do., 23. Aug. 2018 um 09:16 Uhr schrieb Thomas Vandahl <t...@apache.org>:
> Shall we use this for commons-parent? > Sounds reasonable to me. Benedikt > > 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 > >
