[CentOS-devel] Back on CentOS-devel to get some git.centos.org improvements

[Nico Kadel-Garcia]

On Sat, Jul 5, 2014 at 8:23 AM, Karanbir Singh <mail-lists at karan.org> wrote:
> On 07/05/2014 05:08 AM, Nico Kadel-Garcia wrote:
>> On Fri, Jul 4, 2014 at 11:15 AM, Karanbir Singh <mail-lists at karan.org> wrote:
>>> On 07/04/2014 02:46 PM, Nico Kadel-Garcia wrote:
>>>>                Please consider the use of signed GPG tags for actual
>>>> SRPM updates, rather than merely relying on '[package].metadata, to
>>>> help assure provenance for people who may test or rebuild security
>>>> components.
>>>
>>> the content you get is pushed over https, the implementation on
>>> git.centos.org seems fairly secure. the content into the machine is via
>>> ssh, over a guranteed ( in as much as network can be guranteed ) link.
>>>
>>> we are also preventing anyone else from being able to commit with the
>>> source importer username/email and or using the word 'import' as the
>>> first chat in the commit.
>>
>> Thanks. But Karanbir, "commit" is not the problem I'm referring to.
>> It's the ability to substitute a trojaned, fake repository in between
>> you and the client, to commit a "man-in-the-m8iddle" attack Valid SSL
>
> what about git.centos.org's ssl cert looks invalid ? Also, if you are
> doubting SSL as a transport, we've all got bigger problems.

Today? *Nothing*. It's not git.centos.org, itself, that I'm worried
about.  The proper use of private/public key pairs, such as SSH and
SSL private keys, can help protect the central repository from
improper access, and I assume that you folks are also doing code
review before pulls are accepted into the primary repositories.

It's man-in-the-middle attacks for remote software downloaders. They'e
vulnerable to trojaned repositories. placed *in between* their local
client and git.centos.org. And SSL itself is vulnerable to forged keys
using stolen signature authorities, whether local to a remote
environment or such as the stolen "GlobalSign" keys. There are even
environments that put proxies in front of *incoming* traffic, locally,
to slap a new internal and internally signed SSL key on it, and
*deliberately* do man-in-the-middle monitoring at the proxy. There are
others that block most external HTTP/HTTPS and route only a few
allowed external websites through an internal DNS address at the
proxy: they've effectively insisted on being a man-in-the-middle for
their own internal monitoring and traffic control reasons, and they
can wind up using internally signed keys. They certainly can't use
*your* keys for that!!!!

There's also verification of the content in local working
repositories. If I make a fork of https://github.com/rpms/kernel over
to "https://github.com/nkadel/centos-kernel-test-usb/", and someone
else works with me on it and makes their own clone, they have to have
a chain of trust between their work, your work, and my work. I would
find it much safer, and more useful, have  something like a GPG signed
git tag in the repo that cleanly defines your release. It helps
profoundly to ensure that the tag, which can be tied to a specific
SRPM number quite safely and easily, also ensures the full provenance
of the code as being what you folks over at CentOS actually published.
Otherwise, we enter a potentially pretty painful world of having to
manage and verify git commit checksums, and that way lies unstable
hackery scripting madness.

The GPG keys on the SRPM's have been one of the very useful checks of
veracity and provenance on varous projects, I'll save commentary on
how much more useful I think consistent tag naming conventions are
than doing 'grep' on string logs to deduce commits. But the security
benefits of

I realize that it's work, but at least in a technology sense, I do
think that it could be integrated into the git.centos.org repository.
Frankly, I was a more than a bit surprised to see that tags,
especially GPG signed tags, weren't already in use. for defining the
SRPM numbers. I do think that it would be much cleaner than trying to
derive build numbers from "git log" analysis.