Re: Fwd: New Feathercast mailing list
👌 Pada 26 Jan 2017 4:47 PG, "Rich Bowen" menulis: > To anyone who has at any time expressed interest in helping out with > Feathercast, please see below. (Some of you have already received this, > but sending it to comdev just in case I missed someone!) > > Thanks! > > --Rich > > > Forwarded Message > Subject: New Feathercast mailing list > Date: Wed, 25 Jan 2017 15:46:18 -0500 > From: Rich Bowen > To: featherc...@apache.org > > Hi, > > I'm BCC'ing you because at some point you have expressed some interest > in helping out with Feathercast. Infra has been kind enough as to create > a featherc...@apache.org mailing list (because the world needs Yet > Another Mailing List!!) for coordinating work on Feathercast, as well as > announcing new episodes, events, and so on. > > I was on the verge of losing track of who had responded to my various > calls for help, so this seemed more efficient. It also lets you join and > drop off at will, rather than getting my emails when you no longer want > them. > > To subscribe to the mailing list, send blank email to > feathercast-subscr...@apache.org > > To unsubscribe, it's feathercast-unsubscr...@apache.org > > The list archives are at > https://lists.apache.org/list.html?featherc...@apache.org and you can, > if you wish, read and post via that interface instead. > > So, thanks again for your interest in Feathercast, and I look forward to > working with all of you! > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > > > >
Re: Hello
👌 Pada 22 Jan 2017 8:28 PG, "Andrew Palumbo" menulis: > Hello, > > > I sent an email yesterday regarding swag for Meetups, etc to this list, > thinking that it was an Apache list that was devoted specifically to that > type of thing (i was just going off of a comment automatically sent to me > from the last quarter's board report review).. I've noticed several Emails, > and realized that I was wrong about this just being a place to ask for swag > from. > > > So I just wanted to Introduce myself and say hello. I'm the PMC chair of > Apache Mahout. The Mahout team is a die hard group of all volunteer > committers, devoted to distributed shared nothing machine learning, > centered currently around an abstract Engine neutral set of Distributed > Linear Algebra primitives. We're working currently on a release with GPU > and native multithreaded backed matrix operations, as well as to provide > more caned algorithms. We have no corporate backing, which makes it > challenging at times to keep up; most of us work after our day-jobs. This > also makes us flexible and able to answer to no one but our own PMC when > deciding the best direction for the project to go. > > > So I just wanted to Introduce myself, and give you an overview of our > team. The email that I sent yesterday came off more as an order for Apache > swag.. > > > So, Hello, and have a good weekend, all, > > > Andy >
Use of MD5 and SHA1 for download verification
I filed a bug about this already, but I've been directed to email here instead. The bug I filed is: https://issues.apache.org/jira/browse/INFRA-12626 Basically, on download pages we provide obsolete hashes for our downloads (MD5 and SHA1). These are meant, as I understand it, to serve two purposes. First, they allow you to make sure that your download succeeded. Second, they allow you to ensure that your download wasn't tampered with. For the first purpose: Great. They work. For the second purpose, however, we need to move away from MD5 and SHA1 hashes, both of which can now be attacked with relatively modest hardware. Browsers are moving away from SHA1 at a very fast pace. See: https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html And: https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ I don't know who's responsible for this, but my bug was closed because it's not the infrastructure team, and so I'm trying here. I suggest we move to SHA2 hashes for all verification purposes. Thanks, Mike
Re: Use of MD5 and SHA1 for download verification
On 26 January 2017 at 18:20, Mike Lissner wrote: > I filed a bug about this already, but I've been directed to email here > instead. The bug I filed is: > https://issues.apache.org/jira/browse/INFRA-12626 > > Basically, on download pages we provide obsolete hashes for our downloads > (MD5 and SHA1). These are meant, as I understand it, to serve two purposes. > First, they allow you to make sure that your download succeeded. Agreed > Second, they allow you to ensure that your download wasn't tampered with. They aren't intended for that purpose. > For the first purpose: Great. They work. For the second purpose, however, > we need to move away from MD5 and SHA1 hashes, both of which can now be > attacked with relatively modest hardware. > > Browsers are moving away from SHA1 at a very fast pace. See: > > https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html > > And: > > https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ Those hashes serve a different purpose. > I don't know who's responsible for this, but my bug was closed because it's > not the infrastructure team, and so I'm trying here. > > I suggest we move to SHA2 hashes for all verification purposes. And how do you verify that the SHA2 hash has not been tampered with? With PGP signatures one can check the WoT (web of trust). And the PGP public keys are published in the KEYS files which are derived from a source code repo to which only ASF committers have write access. I think it would be a mistake to give the impression that hashes are of use for anything other than a sophisticated download checksum. > Thanks, > > Mike - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Use of MD5 and SHA1 for download verification
SHA1 and MD5 have been individually compromised, but a combined hash has not been. Regardless, Sebb's comment that hashes are worthless for authentication and tamper-detection is spot-on. You have to look to trusted signatures for that. On Thu, Jan 26, 2017 at 10:20 AM, Mike Lissner < mliss...@michaeljaylissner.com> wrote: > I filed a bug about this already, but I've been directed to email here > instead. The bug I filed is: > https://issues.apache.org/jira/browse/INFRA-12626 > > Basically, on download pages we provide obsolete hashes for our downloads > (MD5 and SHA1). These are meant, as I understand it, to serve two purposes. > First, they allow you to make sure that your download succeeded. Second, > they allow you to ensure that your download wasn't tampered with. > > For the first purpose: Great. They work. For the second purpose, however, > we need to move away from MD5 and SHA1 hashes, both of which can now be > attacked with relatively modest hardware. > > Browsers are moving away from SHA1 at a very fast pace. See: > > https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html > > And: > > https://blog.mozilla.org/security/2014/09/23/phasing- > out-certificates-with-sha-1-based-signature-algorithms/ > > I don't know who's responsible for this, but my bug was closed because it's > not the infrastructure team, and so I'm trying here. > > I suggest we move to SHA2 hashes for all verification purposes. > > Thanks, > > Mike >
Re: Use of MD5 and SHA1 for download verification
To be clear, those "trusted signatures" should be using strong hash algorithms themselves. (As well as sufficiently long keys.) I raised the issue of weak hashes in GPG signatures for Maven projects at ASF with https://issues.apache.org/jira/browse/MPOM-118 , but non-Maven projects which manually sign releases should probably take care to ensure their signatures are adequate. I consider this a release-voting quality assurance step, and encourage projects to examine the signatures attached to their release candidates as part of their release process. On Thu, Jan 26, 2017 at 2:27 PM Ted Dunning wrote: > SHA1 and MD5 have been individually compromised, but a combined hash has > not been. > > Regardless, Sebb's comment that hashes are worthless for authentication and > tamper-detection is spot-on. You have to look to trusted signatures for > that. > > > > On Thu, Jan 26, 2017 at 10:20 AM, Mike Lissner < > mliss...@michaeljaylissner.com> wrote: > > > I filed a bug about this already, but I've been directed to email here > > instead. The bug I filed is: > > https://issues.apache.org/jira/browse/INFRA-12626 > > > > Basically, on download pages we provide obsolete hashes for our downloads > > (MD5 and SHA1). These are meant, as I understand it, to serve two > purposes. > > First, they allow you to make sure that your download succeeded. Second, > > they allow you to ensure that your download wasn't tampered with. > > > > For the first purpose: Great. They work. For the second purpose, however, > > we need to move away from MD5 and SHA1 hashes, both of which can now be > > attacked with relatively modest hardware. > > > > Browsers are moving away from SHA1 at a very fast pace. See: > > > > https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html > > > > And: > > > > https://blog.mozilla.org/security/2014/09/23/phasing- > > out-certificates-with-sha-1-based-signature-algorithms/ > > > > I don't know who's responsible for this, but my bug was closed because > it's > > not the infrastructure team, and so I'm trying here. > > > > I suggest we move to SHA2 hashes for all verification purposes. > > > > Thanks, > > > > Mike > > > -- Christopher
Re: Use of MD5 and SHA1 for download verification
Infra does filter filenames that match (*.sha256) from the mirror replication, so it is possible to use such names and have matching behavior: Compare mirror: http://apache.cs.utah.edu/orc/orc-1.2.3/ Apache version: http://www-eu.apache.org/dist/orc/orc-1.2.3/ and you can see the sha256 files are dropped just like the *.asc files. .. Owen On Thu, Jan 26, 2017 at 12:01 PM, Christopher wrote: > To be clear, those "trusted signatures" should be using strong hash > algorithms themselves. (As well as sufficiently long keys.) > I raised the issue of weak hashes in GPG signatures for Maven projects at > ASF with https://issues.apache.org/jira/browse/MPOM-118 , but non-Maven > projects which manually sign releases should probably take care to ensure > their signatures are adequate. I consider this a release-voting quality > assurance step, and encourage projects to examine the signatures attached > to their release candidates as part of their release process. > > On Thu, Jan 26, 2017 at 2:27 PM Ted Dunning wrote: > > > SHA1 and MD5 have been individually compromised, but a combined hash has > > not been. > > > > Regardless, Sebb's comment that hashes are worthless for authentication > and > > tamper-detection is spot-on. You have to look to trusted signatures for > > that. > > > > > > > > On Thu, Jan 26, 2017 at 10:20 AM, Mike Lissner < > > mliss...@michaeljaylissner.com> wrote: > > > > > I filed a bug about this already, but I've been directed to email here > > > instead. The bug I filed is: > > > https://issues.apache.org/jira/browse/INFRA-12626 > > > > > > Basically, on download pages we provide obsolete hashes for our > downloads > > > (MD5 and SHA1). These are meant, as I understand it, to serve two > > purposes. > > > First, they allow you to make sure that your download succeeded. > Second, > > > they allow you to ensure that your download wasn't tampered with. > > > > > > For the first purpose: Great. They work. For the second purpose, > however, > > > we need to move away from MD5 and SHA1 hashes, both of which can now be > > > attacked with relatively modest hardware. > > > > > > Browsers are moving away from SHA1 at a very fast pace. See: > > > > > > https://security.googleblog.com/2014/09/gradually- > sunsetting-sha-1.html > > > > > > And: > > > > > > https://blog.mozilla.org/security/2014/09/23/phasing- > > > out-certificates-with-sha-1-based-signature-algorithms/ > > > > > > I don't know who's responsible for this, but my bug was closed because > > it's > > > not the infrastructure team, and so I'm trying here. > > > > > > I suggest we move to SHA2 hashes for all verification purposes. > > > > > > Thanks, > > > > > > Mike > > > > > > -- > Christopher >
Re: Use of MD5 and SHA1 for download verification
Yes, hashes etc are not replicated to mirrors; I think this is partly to encourage people to download them from the ASF hardware. However a rogue mirror could still provide its own hashes. But hashes from ASF hardware still only provide a basic download check; they don't provide authentication, because anyone can create a hash for any file. Of course, if you sign a hash with a GPG key, that would allow the user to authenticate the hash if they trust the key. AIUI that's basically what sigs are. On 26 January 2017 at 21:26, Owen O'Malley wrote: > Infra does filter filenames that match (*.sha256) from the mirror > replication, so it is possible > to use such names and have matching behavior: > > Compare mirror: http://apache.cs.utah.edu/orc/orc-1.2.3/ > Apache version: http://www-eu.apache.org/dist/orc/orc-1.2.3/ > > and you can see the sha256 files are dropped just like the *.asc files. > > .. Owen > > On Thu, Jan 26, 2017 at 12:01 PM, Christopher wrote: > >> To be clear, those "trusted signatures" should be using strong hash >> algorithms themselves. (As well as sufficiently long keys.) >> I raised the issue of weak hashes in GPG signatures for Maven projects at >> ASF with https://issues.apache.org/jira/browse/MPOM-118 , but non-Maven >> projects which manually sign releases should probably take care to ensure >> their signatures are adequate. I consider this a release-voting quality >> assurance step, and encourage projects to examine the signatures attached >> to their release candidates as part of their release process. >> >> On Thu, Jan 26, 2017 at 2:27 PM Ted Dunning wrote: >> >> > SHA1 and MD5 have been individually compromised, but a combined hash has >> > not been. >> > >> > Regardless, Sebb's comment that hashes are worthless for authentication >> and >> > tamper-detection is spot-on. You have to look to trusted signatures for >> > that. >> > >> > >> > >> > On Thu, Jan 26, 2017 at 10:20 AM, Mike Lissner < >> > mliss...@michaeljaylissner.com> wrote: >> > >> > > I filed a bug about this already, but I've been directed to email here >> > > instead. The bug I filed is: >> > > https://issues.apache.org/jira/browse/INFRA-12626 >> > > >> > > Basically, on download pages we provide obsolete hashes for our >> downloads >> > > (MD5 and SHA1). These are meant, as I understand it, to serve two >> > purposes. >> > > First, they allow you to make sure that your download succeeded. >> Second, >> > > they allow you to ensure that your download wasn't tampered with. >> > > >> > > For the first purpose: Great. They work. For the second purpose, >> however, >> > > we need to move away from MD5 and SHA1 hashes, both of which can now be >> > > attacked with relatively modest hardware. >> > > >> > > Browsers are moving away from SHA1 at a very fast pace. See: >> > > >> > > https://security.googleblog.com/2014/09/gradually- >> sunsetting-sha-1.html >> > > >> > > And: >> > > >> > > https://blog.mozilla.org/security/2014/09/23/phasing- >> > > out-certificates-with-sha-1-based-signature-algorithms/ >> > > >> > > I don't know who's responsible for this, but my bug was closed because >> > it's >> > > not the infrastructure team, and so I'm trying here. >> > > >> > > I suggest we move to SHA2 hashes for all verification purposes. >> > > >> > > Thanks, >> > > >> > > Mike >> > > >> > >> -- >> Christopher >> - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
