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

Sun Jul 6 04:25:29 UTC 2014
Nico Kadel-Garcia <nkadel at gmail.com>

On Sat, Jul 5, 2014 at 2:11 PM, Mark Mielke <mark.mielke at gmail.com> wrote:
> 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.

You got most of it. I'm strongly urging the sue of GPG signed 'git
tags' for particular SRPM bundles in the git.centos.org repositories,
rather than relying on analyzing "git log" to mark particular SRPM's.

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

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

Amen. There are long threads about this, including some analyses by
Bruce Schneier. at
he writes:

      The most interesting entry in that table is the "CA compromise"
one, because those are incidents that could affect any or every secure
web or email server on the Internet. In at least 248 cases, a CA chose
to indicate that it had been compromised as a reason for revoking a
cert. Such statements have been issued by 15 distinct CA

That was 2011.  There's no reason to think it's gotten better. Coupled
with the interposition of deliberately compromised proxies, either as
a matter of internal policy or due to cracking, and SSL cannot be
considered sufficient for software repository authentication.

> 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

Ahh. Are you using 'NetIntercept'? Nice hardware, very powerful, does
both man-in-the-middle monitoring and recording it do local disk for
meta-analysis. Scary, scary, scary stuff..

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

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.

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

Thanks! I do think it will help assuage some concerns.