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: Karsten Behrmann <BearPerson AT gmx.net>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] GPG keyring storage ?
  • Date: Thu, 18 Aug 2005 16:29:38 -0700

On Fri, Aug 19, 2005 at 01:08:01AM +0200, Karsten Behrmann wrote:
> On Thu, 18 Aug 2005 09:21:53 -0700, Andrew wrote:
> > 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.
>
> Apropos security risks in gpg signing:
> Just a thought, I'm almost sure it has to be resolved, but I thought
> I'd mention it: Do we specify a keyring as well as a signer's
> fingerprint or at least ID? Otherwise, couldn't the new gnu dev that
> just got into gnu.gpg sign off a compromised binutils? The basic point
> here is that maybe we should keep the keyrings as collections to be
> referenced, but not as authorities on their own.

They have access to our source code repository, too.

We have to trust our own gurus, but think for a minute -- they'd have to
place a trojanned app on the SOURCE_URL too. For binutils, this would
be unlikely -- we'd notice. For other random spells, maybe we wouldn't
notice it right away, but at least, they've laid out what the url is
publicly and we can all double-check. This is the same risk we have
with a trojanned "md5" signature, too.

gurus.gpg is probably better broken up, but with tools like pgpdump
(that lace just submitted) it's easy to see what's in it, instead of
having to run:

gpg --no-default-keyring --keyring /var/lib/sorcery/codex/stable/gurus.gpg
--fingerprint

The main reason why keyrings were supported is because projects can have
more than one release maintainer, and changing it for every release can
be a problem. I would prefer four or five people who had their public
keys in a keyring instead of one commonly shared key everybody has
access to -- then we can trace guilt ;).

Seth

>
> Feel free to send "we're doing that already"
> so far,
> Karsten

--
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: pgpzwoP4s_TTy.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page