Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

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