All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: signed tarballs
Date: Thu, 13 Apr 2017 19:17:41 -0400	[thread overview]
Message-ID: <3984048.ybg3X6gWBZ@x2> (raw)
In-Reply-To: <CAFftDdqb9zkh=QjMsm4npEqTMXX8PqQ3OnxoUwqE7FYVXS039g@mail.gmail.com>

On Thursday, April 13, 2017 6:45:55 PM EDT William Roberts wrote:
> On Apr 13, 2017 14:22, "Christian Rebischke" <Chris.Rebischke@archlinux.org>
> wrote:
> 
> On Thu, Apr 13, 2017 at 05:05:36PM -0400, Paul Moore wrote:
> > Unless Steve has exclusive administrative access to people.redhat.com
> > (I think it is safe to say he does not, but correct me if I'm wrong
> > Steve <b>) you can't trust an unsigned checksum regardless of how
> > strong the https cert/crypto as the web admin could still tamper with
> > the data.
> 
> We are not only talking about the web admin. We live in times where
> governments can easily tamper such data and the documents from snowden
> and some other whistleblowers prove that they did stuff like this.
> 
> The only way to make sure that the tarball is the original tarball is
> with a signature from Steve grubbs gpg-key. This would ensure that steve
> has checked the content.
> 
> Just imagine the following scenario:
> 
> 1. New audit version
> 2. Steve uploads the new version with new hash to the webserver.
> 
> 3. Let's imagine that hackers would MITM my connection or modify the
> server content. They could deploy a new tarball and generate a new
> checksum for it, because SHA256 is just *one* factor. Everyone who would
> download the new tarball would check against the new malicious hash.
> 
> This is a valid attack scenario.. This scenario could only be prevent by
> using signed tarballs. Because people like me and other distribution
> maintainers would have Steves pubkey. If somebody would modify the
> tarball he would need Steves pubkey. And this is much more difficult
> than just MITM the connection or tampering the data on the webserver.
> 
> With a signed tarball the attacker would have following problems:
> 
> 1. the attacker can't deploy a malicious tarball without signature,
> because this would make clear that the tarball is malicious.
> 2. if the attacker would generate an own signature for the maliciois
> tarball, people who verify the tarball would get a warning because the
> key is unknown and not part of steves keyring.
> 
> I hope this email is clearer...
> 
> 
> You're assuming a lot for an attack to happen, and your assuming a state of
> steves security of his key, his repo, etc at release time. Pki is based on
> trust of confidentiality of the private key. If Steve starts signing the
> tarballs, it would be great (everyone should), but https + hash is better
> then nothing, that's my point. The difference really boils down to trust of
> the key, admin vs Steve. Admin vs Steve is much better than united vs Steve
> ;-).

Indeed. I think the most plausible issue anyone would ever run across is the 
bugs that I may have inadvertently put in the code base rather than a MITM at 
the very second a distro is downloading a new release. How closely is anyone 
checking this code? Any fuzzers? Static analysis? Test suites?  :-) 

I understand the desire for source integrity. We'll go with hashes now and 
work up to signing another day. Meanwhile...how about some bug reports? Trust 
me. They are there.

-Steve

  reply	other threads:[~2017-04-13 23:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-06 23:31 signed tarballs Christian Rebischke
2017-04-07  1:27 ` William Roberts
2017-04-07 23:41   ` Christian Rebischke
2017-04-07 23:52     ` William Roberts
2017-04-08 12:53 ` Paul Moore
2017-04-10 18:51   ` Steve Grubb
2017-04-10 18:35 ` Steve Grubb
2017-04-11 10:44   ` Christian Rebischke
2017-04-11 14:03     ` Steve Grubb
2017-04-13 20:28       ` Christian Rebischke
2017-04-13 20:30         ` William Roberts
2017-04-13 20:43           ` Steve Grubb
2017-04-13 20:56           ` Christian Rebischke
2017-04-13 21:00             ` William Roberts
2017-04-13 21:05               ` Paul Moore
2017-04-13 21:08                 ` William Roberts
2017-04-13 21:17                   ` Paul Moore
2017-04-13 22:39                     ` William Roberts
2017-04-13 21:22                 ` Christian Rebischke
2017-04-13 22:45                   ` William Roberts
2017-04-13 23:17                     ` Steve Grubb [this message]
2017-04-13 22:25                 ` Steve Grubb
2017-04-14 13:06                   ` Paul Moore
2017-04-14 13:38                     ` Steve Grubb
2017-04-14 23:03                       ` Christian Rebischke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3984048.ybg3X6gWBZ@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.