All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: linux-audit@redhat.com
Subject: Re: signed tarballs
Date: Fri, 14 Apr 2017 09:38:51 -0400	[thread overview]
Message-ID: <6911467.0fbbL1krjI@x2> (raw)
In-Reply-To: <CAHC9VhSFaw4knZQqJfds8ci06n6CUmiXjW87KiA-9YnLc5To9Q@mail.gmail.com>

On Friday, April 14, 2017 9:06:53 AM EDT Paul Moore wrote:
> On Thu, Apr 13, 2017 at 6:25 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Thursday, April 13, 2017 5:05:36 PM EDT Paul Moore wrote:
> >> On Thu, Apr 13, 2017 at 5:00 PM, William Roberts
> >> 
> >> <bill.c.roberts@gmail.com> wrote:
> >> > Isn't the hash on the https people's page?
> > 
> > No, its on the mail list. The mail list is moderated. Only a handful of
> > people could post a spoofed message.
> > 
> >> > Which last time I looked wasnt throwing cert errors in chrome.
> >> 
> >> 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>)
> > 
> > Nope.
> > 
> >> 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.
> > 
> > They would have to go tamper with the mail list where all the hashes are
> > publicly disclosed, too. There are multiple mail list archives. Then they
> > would have to post the tampered tarball to the Fedora Build System which
> > also publicly discloses hashs. And the Fedora Build System requires
> > several identity checks to check it in and it maintains a log.
> 
> No.  Since there is no authentication to post to this public email
> list all they would have to do is spoof bogus a release announcement
> email from you; yes there are some measures in place to combat things
> like this, but it isn't that hard.  Granted, you might notice this
> attack relatively quickly, but if the attack was timed to happen while
> you were away from your email for an extended period of time (travel,
> etc.) the window could be non-trivial, and even then, how many
> installs could have already been put at risk?
> 
> Steve, it's pretty apparent at this point that you don't want to, and
> aren't likely to, provide any form of signed checksum for the audit
> userspace release.  That's your prerogative, and to some like William,
> they may be content with that level of risk.  However, please don't
> pretend that signing releases doesn't provide an additional layer of
> protection.

As I said in a subsequent email, "we'll go with hashes now and 
work up to signing another day." But I really am serious that the biggest 
threat to the project is not some wild eyed MITM attack targeting a whole 
distribution. Its me. I doubt few people truly understand the impact of the 
bug that Laurent reported and why it moved me to change plans and do a quick 
release. (It was not because ausearch was segfaulting.) Again, I call for more 
testing and bug reports. I know they are in the code. I find a couple every 
day or two.

-Steve

  reply	other threads:[~2017-04-14 13:38 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
2017-04-13 22:25                 ` Steve Grubb
2017-04-14 13:06                   ` Paul Moore
2017-04-14 13:38                     ` Steve Grubb [this message]
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=6911467.0fbbL1krjI@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=paul@paul-moore.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.