Fwd: New release distribution checksum policy

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: New release distribution checksum policy

Thomas Vandahl
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 <[hidden email]>
Reply-To: [hidden email]
To: [hidden email]

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 [hidden email]:
> >
> > 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" <[hidden email]>
> > À: [hidden email]
> > 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 <[hidden email]>
> >> To: [hidden email]
> >> 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 [hidden email]     \_/
> >
> >>> Am 15.08.2018 um 10:19 schrieb Henk P. Penning <[hidden email]>:
> >>>
> >>> On Tue, 14 Aug 2018, Shane Curcuru wrote:
> >>>> Date: Tue, 14 Aug 2018 15:18:34 +0200
> >>>> From: Shane Curcuru <[hidden email]>
> >>>> To: [hidden email]
> >>>> 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 [hidden email].
> >>> 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 [hidden email]     \_/
> >>> ------------------------------------------------------------   _
> >>>
> >>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New release distribution checksum policy

Benedikt Ritter-4
Am Do., 23. Aug. 2018 um 09:16 Uhr schrieb Thomas Vandahl <[hidden email]>:

> 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 <[hidden email]>
> Reply-To: [hidden email]
> To: [hidden email]
>
> 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 [hidden email]:
> > >
> > > 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" <[hidden email]>
> > > À: [hidden email]
> > > 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 <[hidden email]>
> > >> To: [hidden email]
> > >> 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 [hidden email]     \_/
> > >
> > >>> Am 15.08.2018 um 10:19 schrieb Henk P. Penning <[hidden email]>:
> > >>>
> > >>> On Tue, 14 Aug 2018, Shane Curcuru wrote:
> > >>>> Date: Tue, 14 Aug 2018 15:18:34 +0200
> > >>>> From: Shane Curcuru <[hidden email]>
> > >>>> To: [hidden email]
> > >>>> 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 [hidden email].
> > >>> 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 [hidden email]     \_/
> > >>> ------------------------------------------------------------   _
> > >>>
> > >>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: New release distribution checksum policy

Thomas Vandahl
Hi Benedikt,

On 23.08.18 18:25, Benedikt Ritter wrote:
> Am Do., 23. Aug. 2018 um 09:16 Uhr schrieb Thomas Vandahl <[hidden email]>:
>
>> Shall we use this for commons-parent?
>>
>
> Sounds reasonable to me.

If I'm not mistaken, the requirement for SHA-512 checksums only exists
for the source distribution, not the binaries. At least this is what I
derive from Hervés implementation in Apache Parent 21. However, the
plugin configuration only kicks in, if the source release artifact name
ends with "-source-release.[zip|tar*]" From what I see in the latest
votes, Apache Commons uses another naming scheme (I do, too). Shall we
adapt?

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New release distribution checksum policy

Benedikt Ritter-4
Hi Thomas,

Am Fr., 24. Aug. 2018 um 13:13 Uhr schrieb Thomas Vandahl <[hidden email]>:

> Hi Benedikt,
>
> On 23.08.18 18:25, Benedikt Ritter wrote:
> > Am Do., 23. Aug. 2018 um 09:16 Uhr schrieb Thomas Vandahl <[hidden email]
> >:
> >
> >> Shall we use this for commons-parent?
> >>
> >
> > Sounds reasonable to me.
>
> If I'm not mistaken, the requirement for SHA-512 checksums only exists
> for the source distribution, not the binaries. At least this is what I
> derive from Hervés implementation in Apache Parent 21. However, the
> plugin configuration only kicks in, if the source release artifact name
> ends with "-source-release.[zip|tar*]" From what I see in the latest
> votes, Apache Commons uses another naming scheme (I do, too). Shall we
> adapt?
>

What do you mean? Adapt our artifact naming scheme or adapt what Apache
Parent 21 does? Since SHA-512 checksums are required now, we need to find a
way to implement this :-) I'm not sure what's the best way for that right
now. What do others think?

Benedikt


>
> Bye, Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: New release distribution checksum policy

Gilles Sadowski
On Fri, 24 Aug 2018 15:13:22 +0200, Benedikt Ritter wrote:

> Hi Thomas,
>
> Am Fr., 24. Aug. 2018 um 13:13 Uhr schrieb Thomas Vandahl
> <[hidden email]>:
>
>> Hi Benedikt,
>>
>> On 23.08.18 18:25, Benedikt Ritter wrote:
>> > Am Do., 23. Aug. 2018 um 09:16 Uhr schrieb Thomas Vandahl
>> <[hidden email]
>> >:
>> >
>> >> Shall we use this for commons-parent?
>> >>
>> >
>> > Sounds reasonable to me.
>>
>> If I'm not mistaken, the requirement for SHA-512 checksums only
>> exists
>> for the source distribution, not the binaries. At least this is what
>> I
>> derive from Hervés implementation in Apache Parent 21. However, the
>> plugin configuration only kicks in, if the source release artifact
>> name
>> ends with "-source-release.[zip|tar*]" From what I see in the latest
>> votes, Apache Commons uses another naming scheme (I do, too). Shall
>> we
>> adapt?
>>
>
> What do you mean? Adapt our artifact naming scheme or adapt what
> Apache
> Parent 21 does? Since SHA-512 checksums are required now,

sha-256 is fine too.

> we need to find a
> way to implement this :-) I'm not sure what's the best way for that
> right
> now. What do others think?

IIUC, Rob has implemented it in the release plugin.
For example, the "Commons RNG" release has the required checksums:
   http://commons.apache.org/proper/commons-rng/download_rng.cgi

Regards,
Gilles

>
> Benedikt
>
>
>>
>> Bye, Thomas


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New release distribution checksum policy

sebb-2-2
In reply to this post by Benedikt Ritter-4
On 24 August 2018 at 14:13, Benedikt Ritter <[hidden email]> wrote:

> Hi Thomas,
>
> Am Fr., 24. Aug. 2018 um 13:13 Uhr schrieb Thomas Vandahl <[hidden email]>:
>
>> Hi Benedikt,
>>
>> On 23.08.18 18:25, Benedikt Ritter wrote:
>> > Am Do., 23. Aug. 2018 um 09:16 Uhr schrieb Thomas Vandahl <[hidden email]
>> >:
>> >
>> >> Shall we use this for commons-parent?
>> >>
>> >
>> > Sounds reasonable to me.
>>
>> If I'm not mistaken, the requirement for SHA-512 checksums only exists
>> for the source distribution, not the binaries. At least this is what I
>> derive from Hervés implementation in Apache Parent 21. However, the
>> plugin configuration only kicks in, if the source release artifact name
>> ends with "-source-release.[zip|tar*]" From what I see in the latest
>> votes, Apache Commons uses another naming scheme (I do, too). Shall we
>> adapt?
>>
>
> What do you mean? Adapt our artifact naming scheme or adapt what Apache
> Parent 21 does? Since SHA-512 checksums are required now, we need to find a
> way to implement this :-) I'm not sure what's the best way for that right
> now. What do others think?

If it really is the case that the Apache Parent POM only creates the
checksums for artifacts with a specific name, then IMO it is badly
broken and needs a bug report.

All artifacts that linked from the page must have sigs and hashes, and
these must not be MD5 or SHA1.

See:
https://www.apache.org/dev/release-distribution#sigs-and-sums

Note that it says:
"For every artifact distributed to the public through Apache channels,
the PMC..."

Since we distribute the binaries, they must have SHA256+

> Benedikt
>
>
>>
>> Bye, Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New release distribution checksum policy

Thomas Vandahl
On 24.08.18 15:42, sebb wrote:
> If it really is the case that the Apache Parent POM only creates the
> checksums for artifacts with a specific name, then IMO it is badly
> broken and needs a bug report.

Feel free. Lines 425 to 454.

> Note that it says:
> "For every artifact distributed to the public through Apache channels,
> the PMC..."
>
> Since we distribute the binaries, they must have SHA256+

I see. Does Maven Central qualify as "Apache channel"? Because I have no
idea how to achieve this. Tried multiple configurations - PITA.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New release distribution checksum policy

Gilles Sadowski
On Fri, 24 Aug 2018 19:51:04 +0200, Thomas Vandahl wrote:

> On 24.08.18 15:42, sebb wrote:
>> If it really is the case that the Apache Parent POM only creates the
>> checksums for artifacts with a specific name, then IMO it is badly
>> broken and needs a bug report.
>
> Feel free. Lines 425 to 454.
>
>> Note that it says:
>> "For every artifact distributed to the public through Apache
>> channels,
>> the PMC..."
>>
>> Since we distribute the binaries, they must have SHA256+
>
> I see. Does Maven Central qualify as "Apache channel"? Because I have
> no
> idea how to achieve this. Tried multiple configurations - PITA.

 From http://www.apache.org/dev/release-publishing.html#valid
---CUT---
don't try to publish .sha256, .sha512 files yet; Nexus doesn't handle
them (as of March 2018)
---CUT---

Gilles

>
> Bye, Thomas
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New release distribution checksum policy

sebb-2-2
In reply to this post by Thomas Vandahl
On 24 August 2018 at 18:51, Thomas Vandahl <[hidden email]> wrote:

> On 24.08.18 15:42, sebb wrote:
>> If it really is the case that the Apache Parent POM only creates the
>> checksums for artifacts with a specific name, then IMO it is badly
>> broken and needs a bug report.
>
> Feel free. Lines 425 to 454.
>
>> Note that it says:
>> "For every artifact distributed to the public through Apache channels,
>> the PMC..."
>>
>> Since we distribute the binaries, they must have SHA256+
>
> I see. Does Maven Central qualify as "Apache channel"? Because I have no
> idea how to achieve this. Tried multiple configurations - PITA.

I don't know if Maven Central counts; I expect it needs changes to Nexus.

However www.apache.org/dist does count, and that's the one that Maven
needs to fix.

> Bye, Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New release distribution checksum policy

sebb-2-2
On 24 August 2018 at 19:42, sebb <[hidden email]> wrote:

> On 24 August 2018 at 18:51, Thomas Vandahl <[hidden email]> wrote:
>> On 24.08.18 15:42, sebb wrote:
>>> If it really is the case that the Apache Parent POM only creates the
>>> checksums for artifacts with a specific name, then IMO it is badly
>>> broken and needs a bug report.
>>
>> Feel free. Lines 425 to 454.
>>
>>> Note that it says:
>>> "For every artifact distributed to the public through Apache channels,
>>> the PMC..."
>>>
>>> Since we distribute the binaries, they must have SHA256+
>>
>> I see. Does Maven Central qualify as "Apache channel"? Because I have no
>> idea how to achieve this. Tried multiple configurations - PITA.
>
> I don't know if Maven Central counts; I expect it needs changes to Nexus.
>
> However www.apache.org/dist does count, and that's the one that Maven
> needs to fix.

I've just remembered - we don't use the apache-release profile, which
is where the new checksum has been added.

So the new Apache pom won't help.

I think the apache-release profile only handles source artifacts for dist.
See
http://maven.apache.org/pom/asf/

It also uses a different naming convention, and there are a few other
differences from our release profile.

However it may be possible to use the checksum-maven-plugin in our POM
to create the additional hashes.

>> Bye, Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]