Hi all, Since the vault for 7.3.1611 has been cleared out last sunday (20170207) - why is that? - I'm using git to download a "SRPM", or more accurately, its contents. However, using git has one major drawback: It is missing checksums for the files. Are there any plans to provide checksums for the files in git so I can be sure that what I download is actually not tampered with? SRPMS are signed so we can be sure there content is what you provided. Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research
On 02/09/2017 06:30 AM, Leonard den Ottolander wrote:> Hi all, > > Since the vault for 7.3.1611 has been cleared out last sunday (20170207) > - why is that? - I'm using git to download a "SRPM", or more accurately, > its contents. > > However, using git has one major drawback: It is missing checksums for > the files. > > Are there any plans to provide checksums for the files in git so I can > be sure that what I download is actually not tampered with? SRPMS are > signed so we can be sure there content is what you provided. > > Regards, > Leonard. >Yes .. that content will be republished. It was an accident. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20170209/fef0fe59/attachment-0001.sig>
Hello Johnny, On Thu, 2017-02-09 at 09:07 -0600, Johnny Hughes wrote:> Yes .. that content will be republished. It was an accident.How about my request for checksums in the git repo? Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research
On 02/09/2017 03:12 PM, Johnny Hughes wrote:> The patch files are in git as text files, right? Why would you need > checksums of those? That is the purpose of git, right? >Not to stir up a hornets' nest, but how does Google's announcement at https://shattered.it affect this now? (Executive summary: Google has successfully produced two different PDF files that hash to the same SHA-1.) There is a whole paragraph on 'How is GIT affected?'
On 23 February 2017 at 19:55, Lamar Owen <lowen at pari.edu> wrote:> On 02/09/2017 03:12 PM, Johnny Hughes wrote: >> >> The patch files are in git as text files, right? Why would you need >> checksums of those? That is the purpose of git, right? >> > Not to stir up a hornets' nest, but how does Google's announcement at > https://shattered.it affect this now? (Executive summary: Google has > successfully produced two different PDF files that hash to the same SHA-1.) > There is a whole paragraph on 'How is GIT affected?' > > >To stave off another ridiculous thread - short version is simply "it isn't"
On 02/23/2017 03:32 PM, James Hogarth wrote:> On 23 February 2017 at 19:55, Lamar Owen <lowen at pari.edu> wrote: >> Not to stir up a hornets' nest, but how does Google's announcement at >> https://shattered.it affect this now? (Executive summary: Google has >> successfully produced two different PDF files that hash to the same SHA-1.) >> There is a whole paragraph on 'How is GIT affected?' > To stave off another ridiculous thread - short version is simply "it isn't" >Ridiculous? Seriously? I don't think it's time to be in panic mode, but it is time to prepare for the generation-after-next of GPUs which will be able to produce SHA-1 collisions quickly enough to be able to keep up with a git repo. Dan Goodin disagrees that it's not a problem for git in the long run. See: https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/ (not a bit of hyperbole in that headline, right? ) Maybe it's a bit premature to call it 'dead' but it is definitely in its death rattles. Google is scheduled to release the source code to produce arbitrary "identical-prefix" collisions of SHA-1 hashes in three months. You need about $110,000 worth of compute time to pull off the attack, and that number will go down. We're basically at the same place now with SHA-1 as we were in 2010 with MD5. The full paper can be read at https://shattered.io/static/shattered.pdf And an interesting discussion on git's potential handling of a SHA-1 collision on a blob is at https://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob It may not be urgent, but it's not ridiculous.
On 02/23/2017 01:03 PM, Lamar Owen wrote:> On 02/23/2017 03:32 PM, James Hogarth wrote: >> On 23 February 2017 at 19:55, Lamar Owen <lowen at pari.edu> wrote: >>> Not to stir up a hornets' nest, but how does Google's announcement at >>> https://shattered.it affect this now? (Executive summary: Google has >>> successfully produced two different PDF files that hash to the same >>> SHA-1.) >>> There is a whole paragraph on 'How is GIT affected?' >> To stave off another ridiculous thread - short version is simply "it >> isn't" >> > Ridiculous? Seriously? I don't think it's time to be in panic mode, > but it is time to prepare for the generation-after-next of GPUs which > will be able to produce SHA-1 collisions quickly enough to be able to > keep up with a git repo. > > Dan Goodin disagrees that it's not a problem for git in the long run. > See: > https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/ > (not a bit of hyperbole in that headline, right? ) Maybe it's a bit > premature to call it 'dead' but it is definitely in its death rattles. > > Google is scheduled to release the source code to produce arbitrary > "identical-prefix" collisions of SHA-1 hashes in three months. You need > about $110,000 worth of compute time to pull off the attack, and that > number will go down. We're basically at the same place now with SHA-1 > as we were in 2010 with MD5. > > The full paper can be read at https://shattered.io/static/shattered.pdf > > And an interesting discussion on git's potential handling of a SHA-1 > collision on a blob is at > https://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob > > > It may not be urgent, but it's not ridiculous. >I think the issue is that you not only have to create a trojan file that matches the same hash, but you have to create a trojan file that matches the same hash and doesn't break compiling. Maybe you could do that by padding the file in a comment, but I suspect it would be extremely difficult to pull off. Bottom line is git needs to move to sha256 but I do not believe there is any present danger. I'd be more worried about fraudulently issued TLS certs combined with a DNS cache attack when doing a git checkout. That would be easier to easier to pull off.
On Feb 23, 2017, at 12:55 PM, Lamar Owen <lowen at pari.edu> wrote:> > On 02/09/2017 03:12 PM, Johnny Hughes wrote: >> The patch files are in git as text files, right? Why would you need >> checksums of those? That is the purpose of git, right? >> > Not to stir up a hornets' nest, but how does Google's announcement at https://shattered.it affect this now?To replace pre-existing checkins in place, you have to execute what?s called a second-preimage attack, which is much, much harder than the collision attack presented by Google. The collision attack gives you the freedom to change both files until they match, whereas fixing one of the artifacts ahead of time requires you to pull off a second-preimage attack. Since the fear up-thread is about whether we can trust what?s already in the CentOS Git repos, only a second-preimage attack will do. There is a way to use a collision attack against Git or similar systems: https://news.ycombinator.com/item?id=13715887 However, realize that in this context, it means you?d have to: 1. Get the Red Hat or CentOS folks to accept the good version of your patch. (i.e. The benign version of the evil patch you want to get into RHEL and CentOS.) 2. Hope that the committer doesn?t modify your patch before committing it, thus breaking the match to the evil version you spent $100k and a month of time creating. 3. MITM the Git sync protocol between git.centos.org and the target site to inject your evil version into the sync stream. Since git.centos.org redirects to HTTPS by default and issues HTTPS URLs for you to clone from, this means you also have to break TLS, since unbroken TLS prevents MITM attacks. That, or someone has to *aim* while shooting themselves in the foot, going out of their way to remove the ?s? from the URL. 4. Since git.centos.org is apparently not mirrored, you have to execute this attack between git.centos.org and all end users of their service that you wish to attack, rather than poison one or more of the mirrors by MITMing the mirror?s connection back to git.centos.org. So yeah, it?s still Difficult.? All of this is not to say that Git doesn?t have a problem. They do. It?s just that the problem in question doesn?t affect the integrity of git.centos.org, as far as I can see.
On 02/23/2017 07:31 PM, Warren Young wrote:> All of this is not to say that Git doesn?t have a problem. They do. > It?s just that the problem in question doesn?t affect the integrity of > git.centos.org, as far as I can see.Thanks for the good answer, Warren. Since last posting on this, I've been watching traffic on NANOG about it, and then Linus weighed in on the issue at https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL which, in a nutshell, says: 1.) The sky isn't falling even though there is an actual issue with this; 2.) There are a couple of patches mitigating the primary modes of this attack; 3.)GIT will be upgrading to another hash, and that upgrade won't break existing repos. So even in Linus' words it's not a ridiculous conversation, but it's not super urgent, either. Which is the kind of statement I was after, and the type of information I was looking for.