Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] GPG keyring storage ?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: sm-discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] GPG keyring storage ?
  • Date: Thu, 18 Aug 2005 10:15:09 -0700

On Thu, Aug 18, 2005 at 09:21:53AM -0700, Andrew wrote:
> On Thu, Aug 18, 2005 at 09:18:22AM -0700, Seth Alan Woolley wrote:
> > On Thu, Aug 18, 2005 at 07:54:26AM -0700, Andrew wrote:
> > > On Thu, Aug 18, 2005 at 04:46:42PM +0200, Flavien Bridault wrote:
> > > > Hi all,
> > > >
> > > > Now that I become to understand the GPG checking process for spells, I
> > > > noticed, if I understood well ;-), that you have to include a keyring
> > > > in
> > > > the spell when using a vendor key. That means, referring to a real
> > > > example, that there is a kernel.gpg keyring in the udev spell and the
> > > > same kernel.gpg keyring in the linux spell.
> > > > Is it not a big problem in the design ? For me, anything redundant is
> > > > bad, and as I heard on IRC "Yes we should resolve that later", I
> > > > rather
> > > > like to point out this now, in order to avoid later mass changes of
> > > > spells using GPG checking.
> > > >
> > > > If I'm right (that's finally the question), I will obviously post a
> > > > bug. ;-)
> > > >
> > >
> > > You can keep the key in the spell directory, parent section, or the base
> > > grimoire directory. The code will look in each location in that order
> > > for the file listed in $SOURCE_GPG.
> > >
> > > Guru signed spells, for example, use the common gurus.gpg file at the
> > > base of the grimoire. No extra work is needed for the code to find
> > > it there.
> > >
> > > In the kernel.gpg case, since the udev spell is in the disk section, and
> > > the linux spell is in the kernel section, we'd just have the kernel.gpg
> > > key in the grimoire base (or move the udev spell, and put the key in
> > > the kernel section).
> >
> > As an aside, in case anybody gets the fancy idea of doing
> > ../../kernels/linux/kernel.gpg or using an absolute path, yeah, it will
> > work except it's not compatible with tablet or scribbler, both of which
> > are only aware of the parent (section) and grandparent (grimoire)
> > directories from the spell directory. So we won't be doing any fancy
> > relative file locations like that.
> >
>
> Good point. Its also (potentially) a security risk, since if the key
> was described as ../../kernels/linux/foo.gpg, if the key wasnt found
> there (say it was renamed or moved) the code would look in the grimoire
> directory with that path appended to it. In that case it would look
> outside the grimoire into a possibly unsecured directory, the spell would
> use an incorrect gpg key and validate a possibly compromised source/sig.
> Unlikely, but worth mentioning.

Good point.

In addition to the spell->section->grimoire cascade, I just wanted to
mention:

The search path for keys doesn't cascade to SOURCE_CACHE (which contains
untrustworthy things)

The search path for sigs always cascades to SOURCE_CACHE (sigs are by
their nature common in untrustworthy environments -- their goal is to
establish trust within a hostile transport medium).

Unless an absolute path is specified, which is not for spells of general
circulation.

It does check the CWD as a near last resort if a relative path is given
(absolute path otherwise), though (which in PRE_BUILD would be /usr/src
if I'm not mistaken). With that you can use a validated SOURCE tarball
to unpack a set of keys and/or signatures for later SOURCEn files.
Almost a bit too flexible. Or you can change directories before calling
unpack_file, as well. I just didn't want people to claim it was too
limiting.

Seth

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454 E082 99F0 69DC FDCE E733

Attachment: pgpN4ph2cztBE.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page