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

On Sun, Jul 6, 2014 at 5:29 AM, Karanbir Singh <mail-lists at karan.org> wrote:
> On 07/06/2014 05:25 AM, Nico Kadel-Garcia wrote:
>> Some of that is in the '[packagename].medatada' file. Problem is, it's
>> inside the repository itself. The more common approach, built into git
>> directly for *exactly* this sort of use, is to use GPG signed tags.
>> It's possible to remove and replace a tag, but the GPG signature helps
>> assure that if that occurs, at least it was *intentional* by the owner
>> of the GPG tag.
>
> if you can MITM the content, nothing signed or otherwise is assured to
> be in any sate.

First note: in many environments, MITM is how things work normally. In
others, the routers and proxies and DNS are *not* secured or easily
re-implemented to be secure, for many, many different reasons. No
matter how careful you are with git.centos.org itself, it's going to
be vulnerable to trojaned intermediate repositories being substituted
because no one at CentOS or Red Hat has enough control over the
Internet to fix these.

For folks unfamiliar with the technology, one can *reduce* the risk,
and provide a much more robust content verification, by GPG signing
tags. The GPG signature is applied to the commit checksums embedded in
the tag, and normally have multiple, very separate means of
propagation, They're been effectively used for RPM and SRPM
verificiation for many years, and  in my opinion form a much more
verifiable chain of trust. They're also distinct from the transmission
protocol, so they still apply if the site is HTTP accessed or SSH
accessed or even local filesystem accessed or even if someone walks a
tarball of the git repo from one desk to another. They don't solve
everything, but Lord, they help verify that the tag in the *local* git
clone has content signed by the upstream repository owners. I
certainly know of, and have built, local high security build systems
that have a carefully built internal mirror of CentOS or RHEL or
Scientific Linux, locked down content, and no Internet access: not
having to verify that content against the centralized
https://git.centos.org/, and being able to apply GPG verification to
the SRPM's from upsteam, has been useful.

If CentOS is going to GPG sign the SRPM's when published, great,
that's helpful. But if you expect developers to be going straight to
the git repo, instead of the SRPM's for their development
environments, it has to be considered an independent channel and its
security concerns considered separately.

Is there any place where a trojaned site can cause real damage?
Absolutely. Any site  that does serious development with locally
modified kernels or applications on top of CentOS (*cough* Cisco
*cough*) could have the source for its customized components corrupted
by such an attack. It's *difficult* to code review entire repositories
of upsteam software. The result can be widespread commercial software
and hardware with embedded vulnerabilities.  (*cough* Cisco ASA
firewall *cough*).

Is it happening right now? Good question. I don't know. Who would
*admit* that it had happened, or even notice at first?