On Sat, Jul 5, 2014 at 2:11 PM, Mark Mielke mark.mielke@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@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 https://www.schneier.com/blog/archives/2011/10/the_security_of_4.html, 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 organizations.
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.