On Sun, Jul 6, 2014 at 5:29 AM, Karanbir Singh mail-lists@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?