Re: [OT] Benedikt's availability

[Gary Gregory]

Perfect. Enjoy!

Gary

On Tue, May 10, 2016 at 8:25 PM, Benedikt Ritter  wrote:

> Hello,
>
> I'm on vacation for one week. I will not have internet access, so I will
> not respond to any mails.
>
> Regards,
> Benedikt
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [RESULT] [VOTE] Apache Commons VFS 2.1 rc1

[Gary Gregory]

Don't despair, I plan on being +1 for the next RC :-)

Gary

On Tue, May 10, 2016 at 7:38 PM, Josh Elser  wrote:

> Well, this seems to have officially been stalled after 2 binding votes
> (which is super disheartening).
>
> 1, +1
> 1, -1
> 1, non-binding +1.
>
> Thank you Gary, Stian, and Benedikt for finding the time to vote!
>
> I guess I'll pull in Gary's changes and hope we can get the minimum
> binding votes for the next RC. Will try to get rc2 out in the next day or
> two.
>
> Josh Elser wrote:
>
>> All,
>>
>> Please consider the following for Apache Commons VFS2 version 2.1 (rc1).
>>
>> Maven repository:
>> https://repository.apache.org/content/repositories/orgapachecommons-1163
>> Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511
>>
>> MD5 commons-vfs-distribution-2.1-bin.tar.gz
>> 1192914d1ba6f8ca3a2a688feeff602c
>> SHA1 commons-vfs-distribution-2.1-bin.tar.gz
>> 285097f1db6cbc9d76ae5bb3adf66a315344a864
>> MD5 commons-vfs-distribution-2.1-src.tar.gz
>> 0646187562302a7dcfbddb93204fc9eb
>> SHA1 commons-vfs-distribution-2.1-src.tar.gz
>> 24bab87fd4049b9389acd1b6e272f405630aeb25
>> MD5 commons-vfs-distribution-2.1-bin.zip 3785874aa0cda64d68acbb8fb7db8bea
>> SHA1 commons-vfs-distribution-2.1-bin.zip
>> 942a23fb202b89b1a8432beeb0a66469959e661d
>> MD5 commons-vfs-distribution-2.1-src.zip c8ef43d308bed1b3ffcb363c15285176
>> SHA1 commons-vfs-distribution-2.1-src.zip
>> 1ddf0d218f659766f136894eab0beca504ab9f8c
>>
>> Signed with 4677D66C from
>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>
>> SVN tag is available at
>>
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/
>> r1742212
>>
>> Staged Maven website:
>> http://home.apache.org/~elserj/commons/commons-vfs-2.1/
>>
>> All reports are available in the provided staged Maven site (see
>> "Project Reports" at the root-level as well as under each sub-module).
>> JIRA-generated release notes are available in the dist.a.o "Artifacts"
>> repository. Unit tests pass and the RC was built util JDK6.
>>
>> (For Sebb) A direct Clirr link
>>
>> http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>>
>>
>> Changes since rc0:
>>
>> * Improved release notes and website for compatibility
>> * Fixes to pom.xml for building website
>>
>> This vote will be open for 72-hours, 2016/05/06 0400 UTC.
>>
>> [ ] +1 Release these artifacts as version 2.1
>> [ ] 0 OK, but...
>> [ ] -1 I oppose these artifacts as version 2.1 because..
>>
>> - Josh
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[OT] Benedikt's availability

[Benedikt Ritter]

Hello,

I'm on vacation for one week. I will not have internet access, so I will
not respond to any mails.

Regards,
Benedikt

[RESULT] [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

Well, this seems to have officially been stalled after 2 binding votes 
(which is super disheartening).


1, +1
1, -1
1, non-binding +1.

Thank you Gary, Stian, and Benedikt for finding the time to vote!

I guess I'll pull in Gary's changes and hope we can get the minimum 
binding votes for the next RC. Will try to get rc2 out in the next day 
or two.


Josh Elser wrote:

All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc1).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1163
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511

MD5 commons-vfs-distribution-2.1-bin.tar.gz
1192914d1ba6f8ca3a2a688feeff602c
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
285097f1db6cbc9d76ae5bb3adf66a315344a864
MD5 commons-vfs-distribution-2.1-src.tar.gz
0646187562302a7dcfbddb93204fc9eb
SHA1 commons-vfs-distribution-2.1-src.tar.gz
24bab87fd4049b9389acd1b6e272f405630aeb25
MD5 commons-vfs-distribution-2.1-bin.zip 3785874aa0cda64d68acbb8fb7db8bea
SHA1 commons-vfs-distribution-2.1-bin.zip
942a23fb202b89b1a8432beeb0a66469959e661d
MD5 commons-vfs-distribution-2.1-src.zip c8ef43d308bed1b3ffcb363c15285176
SHA1 commons-vfs-distribution-2.1-src.zip
1ddf0d218f659766f136894eab0beca504ab9f8c

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/
r1742212

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see
"Project Reports" at the root-level as well as under each sub-module).
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link
http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html


Changes since rc0:

* Improved release notes and website for compatibility
* Fixes to pom.xml for building website

This vote will be open for 72-hours, 2016/05/06 0400 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0 OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)

[ecki]

Hello,

Fully agree for checksum files no stronger hashes are needed. For the pgp 
signatures we should however avoid md5/sha1. The advantage isnthat this is 
pretty transparent (alg encoded in .asc file). It only breaks for some very old 
invoked pgp binaries. (Theoretically we can add multiple signatures using 
sha1+sha2 but that might break even more pgp implementations anf the 
maven/gnupg-plugin does not support it afaik).

Gruss
Bernd
-- 
http://bernd.eckenfels.net

-Original Message-
From: sebb 
To: Commons Developers List 
Sent: Di., 10 Mai 2016 11:53
Subject: Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer 
provide MD5 and SHA1 checksums for Neon (but still SHA512)

Why bother changing?

Checksums/hashes are only intended for checking that a download has
completed OK.

They don't provide any authentication as anyone can generate them.
AFAICT the strength of the hash has no bearing on its utility.

People should use the sigs instead.

Switching to a stronger hash might give the impression that the hash
is intended for authentication.

Note that any change ought to be run past Infra, because the release
distribution policy might need to be updated.

On 10 May 2016 at 10:30, Benedikt Ritter  wrote:
> Hi Gary,
>
> What changes are required for this? Is this just a setting in
> commons-parent?
>
> Benedikt
>
> Gary Gregory  schrieb am Di., 10. Mai 2016 um
> 02:51 Uhr:
>
>> Should we follow suit?
>>
>> Gary
>>
>> -- Forwarded message --
>> From: David M Williams 
>> Date: Mon, May 9, 2016 at 5:37 PM
>> Subject: [eclipse-dev] Notice that Eclipse Platform plans to no longer
>> provide MD5 and SHA1 checksums for Neon (but still SHA512)
>> To: eclipse-...@eclipse.org, equinox-...@eclipse.org,
>> cross-project-issues-...@eclipse.org
>>
>>
>> The topic of this note is about the downloads and checksums obtained
>> directly from the the Eclipse Project. It does not involve the checksums
>> from the "select a mirror" page -- that is controlled by the Eclipse
>> Foundation -- nor any of the packages downloaded from
>> http://www.eclipse.org/downloads-- also controlled by the Eclipse
>> Foundation.  My intuition is that few "casual users" use our checksums but
>> some adopters or committers might use them in automated scripts or builds.
>>
>> If any of you do get checksums directly from
>> .../eclipse/downloads/drops4//checksum/... then this note is for
>> you.
>>
>> We announced in Luna we would "stop producing MD5 and SHA1 checksums" after
>> Luna's release (*Bug 423714*
>> )... and I am just
>> now getting around to it. Since it has been a long time since that
>> announcement, and since we are late in this cycle, I am cross-posting to 3
>> lists to be sure those that might be impacted will be notified.
>>
>> We will continue to provide SHA512 checksums and I recently decided to also
>> provide SHA256 checksums since SHA256 seems to be popular "in the
>> industry".
>>
>> This RC1 effort is documented in *Bug 454784*
>> . If the removal of
>> the MD5 and SHA1 checksums would unduly burden anyone, please say so in
>> that *Bug 454784* 
>> and
>> we would be happy to accommodate.
>>
>> I will soon be updating our wiki on *How to verify a download*
>> <
>> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
>> >
>> to contain accurate information for Neon, but wanted to get this notice out
>> now so if you are negatively impacted you would have time to say so.
>>
>> Thank you,
>>
>>
>>
>>
>>
>>
>> ___
>> eclipse-dev mailing list
>> eclipse-...@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)

[Ralph Goers]

I am not even sure how you would do this. Maven does this automatically when 
you deploy.  In Log4j I only do it manually when I zip the web site and archive 
it.

Ralph

> On May 9, 2016, at 5:51 PM, Gary Gregory  wrote:
> 
> Should we follow suit?
> 
> Gary
> 
> -- Forwarded message --
> From: David M Williams 
> Date: Mon, May 9, 2016 at 5:37 PM
> Subject: [eclipse-dev] Notice that Eclipse Platform plans to no longer
> provide MD5 and SHA1 checksums for Neon (but still SHA512)
> To: eclipse-...@eclipse.org, equinox-...@eclipse.org,
> cross-project-issues-...@eclipse.org
> 
> 
> The topic of this note is about the downloads and checksums obtained
> directly from the the Eclipse Project. It does not involve the checksums
> from the "select a mirror" page -- that is controlled by the Eclipse
> Foundation -- nor any of the packages downloaded from
> http://www.eclipse.org/downloads-- also controlled by the Eclipse
> Foundation.  My intuition is that few "casual users" use our checksums but
> some adopters or committers might use them in automated scripts or builds.
> 
> If any of you do get checksums directly from
> .../eclipse/downloads/drops4//checksum/... then this note is for
> you.
> 
> We announced in Luna we would "stop producing MD5 and SHA1 checksums" after
> Luna's release (*Bug 423714*
> )... and I am just
> now getting around to it. Since it has been a long time since that
> announcement, and since we are late in this cycle, I am cross-posting to 3
> lists to be sure those that might be impacted will be notified.
> 
> We will continue to provide SHA512 checksums and I recently decided to also
> provide SHA256 checksums since SHA256 seems to be popular "in the
> industry".
> 
> This RC1 effort is documented in *Bug 454784*
> . If the removal of
> the MD5 and SHA1 checksums would unduly burden anyone, please say so in
> that *Bug 454784*  and
> we would be happy to accommodate.
> 
> I will soon be updating our wiki on *How to verify a download*
> 
> to contain accurate information for Neon, but wanted to get this notice out
> now so if you are negatively impacted you would have time to say so.
> 
> Thank you,
> 
> 
> 
> 
> 
> 
> ___
> eclipse-dev mailing list
> eclipse-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)

[Matt Sicker]

As long as all the required PGP keys are in the KEYS file, falling back to
only .asc signatures would be ok with me. However, if the required public
keys are missing from KEYS, that makes it very hard to automate
verification of artifacts.

On 10 May 2016 at 05:42, Gary Gregory  wrote:

> I've not looked into it...
> On May 10, 2016 2:30 AM, "Benedikt Ritter"  wrote:
>
> > Hi Gary,
> >
> > What changes are required for this? Is this just a setting in
> > commons-parent?
> >
> > Benedikt
> >
> > Gary Gregory  schrieb am Di., 10. Mai 2016 um
> > 02:51 Uhr:
> >
> > > Should we follow suit?
> > >
> > > Gary
> > >
> > > -- Forwarded message --
> > > From: David M Williams 
> > > Date: Mon, May 9, 2016 at 5:37 PM
> > > Subject: [eclipse-dev] Notice that Eclipse Platform plans to no longer
> > > provide MD5 and SHA1 checksums for Neon (but still SHA512)
> > > To: eclipse-...@eclipse.org, equinox-...@eclipse.org,
> > > cross-project-issues-...@eclipse.org
> > >
> > >
> > > The topic of this note is about the downloads and checksums obtained
> > > directly from the the Eclipse Project. It does not involve the
> checksums
> > > from the "select a mirror" page -- that is controlled by the Eclipse
> > > Foundation -- nor any of the packages downloaded from
> > > http://www.eclipse.org/downloads-- also controlled by the Eclipse
> > > Foundation.  My intuition is that few "casual users" use our checksums
> > but
> > > some adopters or committers might use them in automated scripts or
> > builds.
> > >
> > > If any of you do get checksums directly from
> > > .../eclipse/downloads/drops4//checksum/... then this note is
> for
> > > you.
> > >
> > > We announced in Luna we would "stop producing MD5 and SHA1 checksums"
> > after
> > > Luna's release (*Bug 423714*
> > > )... and I am
> just
> > > now getting around to it. Since it has been a long time since that
> > > announcement, and since we are late in this cycle, I am cross-posting
> to
> > 3
> > > lists to be sure those that might be impacted will be notified.
> > >
> > > We will continue to provide SHA512 checksums and I recently decided to
> > also
> > > provide SHA256 checksums since SHA256 seems to be popular "in the
> > > industry".
> > >
> > > This RC1 effort is documented in *Bug 454784*
> > > . If the removal
> > of
> > > the MD5 and SHA1 checksums would unduly burden anyone, please say so in
> > > that *Bug 454784* <
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>
> > > and
> > > we would be happy to accommodate.
> > >
> > > I will soon be updating our wiki on *How to verify a download*
> > > <
> > >
> >
> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
> > > >
> > > to contain accurate information for Neon, but wanted to get this notice
> > out
> > > now so if you are negatively impacted you would have time to say so.
> > >
> > > Thank you,
> > >
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > eclipse-dev mailing list
> > > eclipse-...@eclipse.org
> > > To change your delivery options, retrieve your password, or unsubscribe
> > > from this list, visit
> > > https://dev.eclipse.org/mailman/listinfo/eclipse-dev
> > >
> > >
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > > 
> > > JUnit in Action, Second Edition 
> > > Spring Batch in Action 
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>



-- 
Matt Sicker 

Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)

[Gary Gregory]

I've not looked into it...
On May 10, 2016 2:30 AM, "Benedikt Ritter"  wrote:

> Hi Gary,
>
> What changes are required for this? Is this just a setting in
> commons-parent?
>
> Benedikt
>
> Gary Gregory  schrieb am Di., 10. Mai 2016 um
> 02:51 Uhr:
>
> > Should we follow suit?
> >
> > Gary
> >
> > -- Forwarded message --
> > From: David M Williams 
> > Date: Mon, May 9, 2016 at 5:37 PM
> > Subject: [eclipse-dev] Notice that Eclipse Platform plans to no longer
> > provide MD5 and SHA1 checksums for Neon (but still SHA512)
> > To: eclipse-...@eclipse.org, equinox-...@eclipse.org,
> > cross-project-issues-...@eclipse.org
> >
> >
> > The topic of this note is about the downloads and checksums obtained
> > directly from the the Eclipse Project. It does not involve the checksums
> > from the "select a mirror" page -- that is controlled by the Eclipse
> > Foundation -- nor any of the packages downloaded from
> > http://www.eclipse.org/downloads-- also controlled by the Eclipse
> > Foundation.  My intuition is that few "casual users" use our checksums
> but
> > some adopters or committers might use them in automated scripts or
> builds.
> >
> > If any of you do get checksums directly from
> > .../eclipse/downloads/drops4//checksum/... then this note is for
> > you.
> >
> > We announced in Luna we would "stop producing MD5 and SHA1 checksums"
> after
> > Luna's release (*Bug 423714*
> > )... and I am just
> > now getting around to it. Since it has been a long time since that
> > announcement, and since we are late in this cycle, I am cross-posting to
> 3
> > lists to be sure those that might be impacted will be notified.
> >
> > We will continue to provide SHA512 checksums and I recently decided to
> also
> > provide SHA256 checksums since SHA256 seems to be popular "in the
> > industry".
> >
> > This RC1 effort is documented in *Bug 454784*
> > . If the removal
> of
> > the MD5 and SHA1 checksums would unduly burden anyone, please say so in
> > that *Bug 454784* 
> > and
> > we would be happy to accommodate.
> >
> > I will soon be updating our wiki on *How to verify a download*
> > <
> >
> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
> > >
> > to contain accurate information for Neon, but wanted to get this notice
> out
> > now so if you are negatively impacted you would have time to say so.
> >
> > Thank you,
> >
> >
> >
> >
> >
> >
> > ___
> > eclipse-dev mailing list
> > eclipse-...@eclipse.org
> > To change your delivery options, retrieve your password, or unsubscribe
> > from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/eclipse-dev
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>

Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)

[sebb]

Why bother changing?

Checksums/hashes are only intended for checking that a download has
completed OK.

They don't provide any authentication as anyone can generate them.
AFAICT the strength of the hash has no bearing on its utility.

People should use the sigs instead.

Switching to a stronger hash might give the impression that the hash
is intended for authentication.

Note that any change ought to be run past Infra, because the release
distribution policy might need to be updated.

On 10 May 2016 at 10:30, Benedikt Ritter  wrote:
> Hi Gary,
>
> What changes are required for this? Is this just a setting in
> commons-parent?
>
> Benedikt
>
> Gary Gregory  schrieb am Di., 10. Mai 2016 um
> 02:51 Uhr:
>
>> Should we follow suit?
>>
>> Gary
>>
>> -- Forwarded message --
>> From: David M Williams 
>> Date: Mon, May 9, 2016 at 5:37 PM
>> Subject: [eclipse-dev] Notice that Eclipse Platform plans to no longer
>> provide MD5 and SHA1 checksums for Neon (but still SHA512)
>> To: eclipse-...@eclipse.org, equinox-...@eclipse.org,
>> cross-project-issues-...@eclipse.org
>>
>>
>> The topic of this note is about the downloads and checksums obtained
>> directly from the the Eclipse Project. It does not involve the checksums
>> from the "select a mirror" page -- that is controlled by the Eclipse
>> Foundation -- nor any of the packages downloaded from
>> http://www.eclipse.org/downloads-- also controlled by the Eclipse
>> Foundation.  My intuition is that few "casual users" use our checksums but
>> some adopters or committers might use them in automated scripts or builds.
>>
>> If any of you do get checksums directly from
>> .../eclipse/downloads/drops4//checksum/... then this note is for
>> you.
>>
>> We announced in Luna we would "stop producing MD5 and SHA1 checksums" after
>> Luna's release (*Bug 423714*
>> )... and I am just
>> now getting around to it. Since it has been a long time since that
>> announcement, and since we are late in this cycle, I am cross-posting to 3
>> lists to be sure those that might be impacted will be notified.
>>
>> We will continue to provide SHA512 checksums and I recently decided to also
>> provide SHA256 checksums since SHA256 seems to be popular "in the
>> industry".
>>
>> This RC1 effort is documented in *Bug 454784*
>> . If the removal of
>> the MD5 and SHA1 checksums would unduly burden anyone, please say so in
>> that *Bug 454784* 
>> and
>> we would be happy to accommodate.
>>
>> I will soon be updating our wiki on *How to verify a download*
>> <
>> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
>> >
>> to contain accurate information for Neon, but wanted to get this notice out
>> now so if you are negatively impacted you would have time to say so.
>>
>> Thank you,
>>
>>
>>
>>
>>
>>
>> ___
>> eclipse-dev mailing list
>> eclipse-...@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)

[Benedikt Ritter]

Hi Gary,

What changes are required for this? Is this just a setting in
commons-parent?

Benedikt

Gary Gregory  schrieb am Di., 10. Mai 2016 um
02:51 Uhr:

> Should we follow suit?
>
> Gary
>
> -- Forwarded message --
> From: David M Williams 
> Date: Mon, May 9, 2016 at 5:37 PM
> Subject: [eclipse-dev] Notice that Eclipse Platform plans to no longer
> provide MD5 and SHA1 checksums for Neon (but still SHA512)
> To: eclipse-...@eclipse.org, equinox-...@eclipse.org,
> cross-project-issues-...@eclipse.org
>
>
> The topic of this note is about the downloads and checksums obtained
> directly from the the Eclipse Project. It does not involve the checksums
> from the "select a mirror" page -- that is controlled by the Eclipse
> Foundation -- nor any of the packages downloaded from
> http://www.eclipse.org/downloads-- also controlled by the Eclipse
> Foundation.  My intuition is that few "casual users" use our checksums but
> some adopters or committers might use them in automated scripts or builds.
>
> If any of you do get checksums directly from
> .../eclipse/downloads/drops4//checksum/... then this note is for
> you.
>
> We announced in Luna we would "stop producing MD5 and SHA1 checksums" after
> Luna's release (*Bug 423714*
> )... and I am just
> now getting around to it. Since it has been a long time since that
> announcement, and since we are late in this cycle, I am cross-posting to 3
> lists to be sure those that might be impacted will be notified.
>
> We will continue to provide SHA512 checksums and I recently decided to also
> provide SHA256 checksums since SHA256 seems to be popular "in the
> industry".
>
> This RC1 effort is documented in *Bug 454784*
> . If the removal of
> the MD5 and SHA1 checksums would unduly burden anyone, please say so in
> that *Bug 454784* 
> and
> we would be happy to accommodate.
>
> I will soon be updating our wiki on *How to verify a download*
> <
> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
> >
> to contain accurate information for Neon, but wanted to get this notice out
> now so if you are negatively impacted you would have time to say so.
>
> Thank you,
>
>
>
>
>
>
> ___
> eclipse-dev mailing list
> eclipse-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>