Re: [PLUG] SourceForge has Malware?

[Rich Freeman <r-plug@thefreemanclan.net>]

On Mon, Jun 1, 2015 at 11:15 AM, Thomas Delrue <delrue.thomas@gmail.com> wrote:
>
> I'm a heavy Mercurial user which has a 'sign' feature: you can
> crypto-sign a commit - and therefore it plus all of it's ancestors - I
> think this enables a higher level of trustworthiness. This feature is
> used in the mercurial source code itself.
> While it does put the onus on the user to perform the validation, it is
> things like that may increase trustworthiness in source-based software
> distribution.
>
> I don't know if git (what all the 'cool' kids are using these days) has
> a similar feature. I'd be surprised if it doesn't but am looking at this
> community to inform me.
> If git has this feature, how extensively is it used for mainstream
> projects (I haven't seen anything like this in for instance the Linux
> Kernel repo) ?
>

On git all objects but tags are content-hashed, including commits.
This is only hashed using sha1, so it is potentially vulnerable, but
in practice I don't believe there are any known attacks against sha1
that don't involve chosen plaintext, which means the authors would
have to participate in any collision attack.  Of course, with ANY
source-management system you could do an MITM and accept commits from
the devs but present entirely different data to the average downloader
(changing the commit numbers, resigning with your own keys, etc), but
this would be pretty obvious if any of the developers looked at the
distributed code.  When they start getting bug reports referencing
commit IDs that don't exist in their own git repositories it would
become obvious that somebody is playing games with their distribution.

With git there has always been the ability to gpg-sign tags, which are
typically used to mark releases.  This is in fairly common use.  A
more recent feature is the ability to sign commits, and this is not in
such common use from what I've seen, but I do try to personally make
use of it.  Obviously any use of signatures is vulnerable to attacks
on the key distribution system.

I think the bottom line is that all the content hashing makes it
fairly difficult to tamper with sources stored in git.  Depending on
the level of vigilance of the project, it might be possible with great
difficulty.  If the project does use commit signing and decent PKI,
then tampering would be very difficult, though again with
collaboration with the authors it might be possible to abuse SHA1
collisions (since only an SHA1 hash joins the signature to the content
being signed).  Also, you lose some traceability to authors if
rebasing is used, since then you don't get a clear history from the
original author's commit to the rebase commit (rebasing changes
history, and thus requires re-signing of commits, likely not using the
original author's key).

--
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug