SCIENTIFIC-LINUX-USERS Archives

June 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steven Haigh <[log in to unmask]>
Reply To:
Steven Haigh <[log in to unmask]>
Date:
Wed, 11 Jun 2014 19:21:59 +1000
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (2734 bytes) , signature.asc (851 bytes)
On 11/06/14 18:42, Matt Lewandowsky wrote:
> The problem, as I see it, is that the "[log in to unmask]" commits come from a 
> magic place that no one is sure of where it is. The commits are not GPG 
> signed, nor are they at all verifiable as originating with Red Hat.
> 
> We're getting a bit off-topic for this list, but I see the following as a 
> solution to clarifying the current situation as I understand the reality to 
> be:
> 
> 1) Have the commits come from a Red Hat email address (since they're 
> supposedly being pushed to the repo from Red Hat) as the committer.
> 
> 2) Have the commits be GPG signed, with a way to verifiably trust the 
> signature.
> 
> 3) Ensure git.centos.org is able to show signing information.
> 
> This will result in a verifiable chain of the sources originating at Red Hat, 
> and being reasonably sure of lack of tampering. However, it does add some risk 
> to Red Hat as there is a degree of them certifying correctness. The "don't 
> trust" view is that *someone* needs to be able to put their name behind it as 
> opposed to a faceless committer claiming to be the bug tracker.
> 
> Personally, I don't care if [log in to unmask] commits are signed if he doesn't 
> want them to be and I suspect almost every party interested in this 
> conversation would agree. It's his personal name on the line. The problem is 
> the generic bug tracker address committing huge swaths of code of unknown 
> provenance.
> 
> Again, this is just my view of the situation. I'm not trying to say whether 
> "trust" or "don't trust" is the correct answer. But I see both sides and I 
> want to help everyone also see both sides so they can be informed in their 
> replies instead of this rapidly degenerating into a mess of useless 
> speculation which can't be reconciled due to lack of facts.

For what its worth, Matt and I had a discussion with part of the CentOS
developer team in the past few hours raising these concerns. The issues
were well received and will have some consideration. Before anyone gets
the wrong impression, we are not accusing the CentOS team of anything
malicious or wrong doing. We both believe that there needs to be a form
of both validation and verification of the origin of the source on
git.centos.org - be it a procedure, crytosigning or something else that
can prove that things haven't been tampered with - and also externally
verified. (hell, even my emails are signed and will flag tampering etc -
an OS should at least have that!).

I have no doubt that something will come of it - watch this space. When
it does happen, we all win.

-- 
Steven Haigh

Email: [log in to unmask]
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299



ATOM RSS1 RSS2