I might be misunderstanding this thread... but if package signing and/or message digest are not being applied to SRPM, I also agree this is a problem.

On Sat, Jul 5, 2014 at 10:58 AM, Nico Kadel-Garcia <nkadel@gmail.com> wrote:

On Sat, Jul 5, 2014 at 8:23 AM, Karanbir Singh <mail-lists@karan.org> wrote:
> On 07/05/2014 05:08 AM, Nico Kadel-Garcia wrote:
>> 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.

Yes. SSL and SSH *can* provide privacy in transit and authentication of the source and destination (often only the destination). But it doesn't protect the content at the source or the target or at transit points, and authentication of the destination host isn't as useful or as well scrutinized as many people believe.

In the case of SSL... the recent "Heartbleed" exploit clearly demonstrates that SSL is not as invulnerable as people have been lead to believe. But, SSL has long had known issues and been circumvented. Edward Snowden changed our suspicions to beliefs that the US government was dabbling in this practice including potentially intercepting the SSL traffic directed towards large companies that I won't name here.

In the case of SSH... how many of you actually look up the SSH public key through a secondary channel (not SSH to the server!), before you accept the SSH public key as valid into your ~/.ssh/known_hosts file? I know I'm as guilty as probably all of you, and I generally do not.

More on this:

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!!!!

Our company is looking into exactly these technologies. Both HTTPS and SSH transparent proxies. Once deployed, I won't be able to SSH from work out to a machine on the Internet without my session being "in the clear" and under the complete control of the proxy machine. The intent of this is supposedly to prevent data exfiltration but what it amounts to is that the company wants the ability to monitor all traffic in and out, and to be able to do a sort of "deep packet inspection" or even manipulation that would allow them to better filter the content and in the case of SSH, the ability to disable the use of port forwarding over SSH as a tunnel. They are real. Yes, a person worried about such a thing could check the signature of the server and the signature would probably not match... but for SSH, do you check the signature? And for SSL, what happens if they also intercept or manipulate the certificate lookups?

The point here is that HTTPS and SSH provide an amount of privacy and security. It does not make *any* guarantee about the authenticity of the content. It is sort of like having a rare painting be transported in a security truck, and presuming that because the painting arrives in a security truck, the painting must still be the original. The only way to determine if the painting is the original is to actually check the painting itself. How it arrives is irrelevant.

In a less extreme case, it just needs somebody to "hack into" one of the CentOS distribution points and replace the source and the .metadata with something of their own. Or it could just be a disgruntled or financially-rewarded volunteer who quietly replaces a server package. Without signatures, it can be difficult to detect this sort of thing.

Now, Git itself provides some of these protections... I'm only learning about CentOS 7 and git.centos.org, but I suspect a capability availability here is to use the Git SHA-1 commit identifiers as a means of authenticating content... but this wouldn't be good enough for files produced or distributed outside of Git...

Anyways... I just wanted to add support to the argument that signatures of some sort are desirable and that SSH and SSL are not on their own sufficient.

--
Mark Mielke <mark.mielke@gmail.com>