[prev in list] [next in list] [prev in thread] [next in thread] 

List:       suse-security
Subject:    [opensuse-security] Re: [review-team] Submission with changed .keyring
From:       Marcus Meissner <meissner () suse ! de>
Date:       2013-12-18 14:37:20
Message-ID: 20131218143720.GJ20751 () suse ! de
[Download RAW message or body]

On Wed, Nov 13, 2013 at 02:32:29PM +0100, Sascha Peilicke wrote:
> On Wednesday 13 November 2013 13:39:24 Dominique Leuenberger a.k.a. Dimstar 
> wrote:
> > Quoting Sascha Peilicke <speilicke@suse.com>:
> > >> Replacing the .keyring MUST be a sensible topic for the review team
> > >> (if not: we can as well remove the logic: if injecting a random
> > >> keyring into the package does not result in the verification of the
> > >> keyring, it's wasted space).
> > > 
> > > I fail to see why this pops up now when a .keyring was changed. Did
> > > somebody verify how those .keyring files where created in the first
> > > place? As long as we
> > > don't have an automated way to trust keyring files, we have zero security
> > > gained.
> > 
> > I sure hope they were verified.. otherwise you can just remove them
> > again and consider it wasted time. We DID originally agree on a
> > process on how to do this task.
> > 
> > And we also mentioned that we'd want a big red banned to warn about
> > changes in this file.
> > 
> > AUTOMATED way of trusting a keyring is just plain useless... and
> > cannot be done.. EVER! This goes against the whole web-of-trust stuff
> > ('somewhere the trust chain has to start.. this you have to establish
> > manually')
> > 
> > > Others have state that the keyring files shouldn't be part of the package
> > > they're supposed to validate. Maybe only a very small set of trusted users
> > > would be allowed to change that.
> > 
> > That's just Jan.. and is not what was agreed on how we follow it for now.
> > Users trust our packages... it is up to the package to establish the
> > trust to upstream.
> > 
> > the .keyring file is there for the maintainer/us to be able to trust
> > 'unknown' contributors
> > 
> > > We only need a package with openSUSE's blessed keyring and require that
> > > for
> > > gpg-offline verification during build. Put that package into Base:System
> > > or
> > > openSUSE:Tools or wherever it's save enough and have the security team be
> > > the only maintainers. As a Factory reviewer, you would normally trust
> > > SUSE's security team and wave through changes to the keyring package.
> > 
> > yes, that was also discussed: but rejected due to overhead and
> > complexity (in how to get a signed package into the dist)
> 
> Do you honestly expect external contributors to use the mechanism? For 
> externals, the usual motivation for packaging something is to scratch some 
> itch. I wonder if there are people out there itched by upstream tarball 
> verification issues. If they are, they're most likely working for a consultancy 
> or other company which is concerned about OS-level security. These guys 
> definitely can manage to send a mail to opensuse-security@opensuse.org.
> 
> As an example, take polkit rules. They're in the hands of the sec team for 
> good reason and are handles exactly as I proposed. So far people where able to 
> manage that.
> 
> Do you have the ML thread ready where this was discussed?
>  
> > >> I did not yet have time to actually do the KR validation.. but from a
> > >> .changes entry, I think it's just right.
> > > 
> > > As said, I can certainly live with mentioning it. Maybe it's even a
> > > good idea.
> > > It's just not helping anybody ATM.
> > 
> > It helps us, the review team, to make sure that there was thought put
> > into the change. It helps us in establishing 'trust' to the packager
> > submitting it..
> 
> More or less, yes. Of course it's more obvious that the packager changed the 
> keyring on purpose if he documented it. On the other hand he could have just 
> faked the changes entry too. By mandating this, we just added process without 
> solving the underlying issue.
> 
> So far, I'm inclined to keep my attitude, as long as the feature didn't get 
> it's extra tuning round in the garage, I'm not gonna spend any review time on 
> it.

In general, if the change is documented and does not look fishy, let it through.

If it looks fishy, mark for review security-team

This whole thing is hard to do right and we should see how this can be improved
later.

Ciao, Marcus
-- 
To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-security+owner@opensuse.org

[prev in list] [next in list] [prev in thread] [next in thread]