osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New release distribution checksum policy


Am Do., 23. Aug. 2018 um 09:16 Uhr schrieb Thomas Vandahl <tv@xxxxxxxxxx>:

> 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.boutemy@xxxxxxx>
> Reply-To: members@xxxxxxxxxx
> To: members@xxxxxxxxxx
>
> 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.boutemy@xxxxxxx:
> > >
> > > 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" <penning@xxxxx>
> > > À: members@xxxxxxxxxx
> > > 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 <struberg@xxxxxxxx>
> > >> To: members@xxxxxxxxxx
> > >> 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 penning@xxxxx     \_/
> > >
> > >>> Am 15.08.2018 um 10:19 schrieb Henk P. Penning <penning@xxxxx>:
> > >>>
> > >>> On Tue, 14 Aug 2018, Shane Curcuru wrote:
> > >>>> Date: Tue, 14 Aug 2018 15:18:34 +0200
> > >>>> From: Shane Curcuru <asf@xxxxxxxxxxxxxxxx>
> > >>>> To: members@xxxxxxxxxx
> > >>>> 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 penning@xxxxx     \_/
> > >>> ------------------------------------------------------------   _
> > >>>
> > >>> 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-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>
>