libreboot
[Top][All Lists]
Advanced

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

Re: [Libreboot] Git clone authentication


From: Duncan Guthrie
Subject: Re: [Libreboot] Git clone authentication
Date: Mon, 22 Aug 2016 01:15:56 +0100
User-agent: K-9 Mail for Android

I did some more investigation into these issues.

More worrying is the build process of crossgcc. It downloads source tarballs 
for its dependencies over regular http, and doesn't even verify the checksums, 
let alone cryptographic signatures. I asked about this on #coreboot IRC, and 
luckily, there is a patch on Coreboot's code review website, and this will 
probably end up being put in upstream: http://review.coreboot.org/#/c/15170/. 
This is, of course, incredibly bad form, but it is good that Coreboot 
developers are willing to fix the problem. 

With the cached packages being included in Libreboot source distribution, can 
someone confirm to me whether these had signatures verified, or at least 
checksums (manually, I presume)? Because otherwise, if some malicious group 
wanted to target a whole group of users (read: juicy targets) with an interest 
in preservation of privacy, one could target the Libreboot project developers. 
I doubt it would be especially difficult. I really hope you verified them...

Either way, fixing the build process, obviously starting with applying the 
patch to Coreboot is absolutely essential. I can't really believe nobody here 
ever inquired into security of the buildgcc script.

Thanks for all your responses,
D.

On 22 August 2016 00:53:04 BST, koanhead <address@hidden> wrote:
>On 08/20/2016 02:11 AM, Leah Rowe wrote:
>> Hi,
>> 
>> Op 20/08/16 om 01:41 schreef koanhead:
>...
>> 
>>> Other than that, if you clone the repository in a manner vulnerable
>>> to MITM, you should still be able to verify its checksum against
>>> the one that's published. As far as I can tell from perusing 
>>> http://git.savannah.gnu.org/cgit/libreboot.git/, there's no global
>>> sum published for the whole tree. This might not matter, since
>>> after all we're using git, which uses hashes to identify the
>>> objects it tracks. The cgit link above shows some of these hashes.
>>> I'm not sure just now how exactly to convince git to emit enough of
>>> the correct information that you can compare the results with those
>>> shown on the savannah site, so I'm going to send this off as-is and
>>> look into it; if I figure it out I'll post in reply to this.
>>> Hopefully someone else out there already knows how to do this
>>> thing?
>> 
>> 
>> sha1 was broken afaik, I don't remember the link but I was reading
>> about it. Whether it's practical in practise to mitm accesses to the
>> git repository I don't know. 
>
>As to whether that's practical, I don't know either, but Leah is
>definitely right about sha1 having been 'broken' in the sense that it's
>possible to generate sha1 hash collisions in somewhat reasonable time.
>
>According to
>https://en.wikipedia.org/wiki/SHA-1#Cryptanalysis_and_validation it was
>do-able but very expensive in 2005; I expect it's a lot cheaper now.
>
>I had thought that it might be practical to verify the path from the
>root of the git tree to the HEAD of whichever branch you're pulling by
>validating each hash in order; but that's only a linear increase in
>complexity (unless you have lots of branches having lots of branches)
>so
>it doesn't seem like it would be worthwhile to try. If anyone still
>wants to try it they can grep the list of commits from `git log`.
>
>Fortunately it doesn't matter, because https!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]