Subject: Re: adding gpg to src/gnu/dist
To: None <tech-userlevel@NetBSD.org, tech-security@NetBSD.org>
From: Andrew Brown <firstname.lastname@example.org>
Date: 05/13/2004 23:53:21
On Thu, May 13, 2004 at 11:25:08AM -0400, Thor Lancelot Simon wrote:
>On Thu, May 13, 2004 at 02:41:45PM +0100, Alistair Crooks wrote:
>> However, we need the functionality that gpg provides. I keep being
>I don't agree. We need _a very small part_ of the functionality that
>gpg provides, that of RSA signing and signature checking. The rest
>of it, we don't need; it's either candy, or it's intended for a purpose
>that's not ours.
agreed. for the purpose of verifying the signature on a given pkg,
the user should already *have* the signer's key (it should be in
base.tgz, along with instructions on verifying it or downloading it
again), and openssl would need to shipped with a configuration that
knows how to find and use it.
>For example, in the extensive list of gpg command-line invocations
>for which you asked for equivalents, quite a few of them are
>associated with web-of-trust management. But (for this purpose)
>we don't have a web of trust; we have a trust hierarchy. This
>means that a huge amount of the functionality in GPG is superfluous,
>whatever one thinks of how it's implemented.
the user shouldn't have to download keys, sign keys, or upload keys.
they shouldn't need to sign anything either (or were we considering a
way that people could provide their own "signed" packages?). that
leaves only verification from your list of 8 things.
we can also probably (though i've not checked) coerce the nbwww key
into signing the "NetBSD CA" key, thereby establishing a line (note,
not a web) of trust back to one of the "globally recognized CAs".
>I could give you the openssl command-line syntax for the actual
>signing operations, but it's pretty awful; besides, I'm sure you
>could puzzle it out for yourself. That's not the point. As Dan
>pointed out, users should never have to be exposed to _either_
>of these command-line tools -- and OpenSSL is a *library*, and
>even better it's one that generates and checks signatures in a
>format that many other libraries can handle as well. We can
>integrate OpenSSL support directly into the pkgtools and the
>system installer, and rely on no external utility at all. I'd
>be glad to help you do that, if you like.
i've mucked about with openssl too much as well, so i'm willing to
throw in some time here, too. having a native tool that does exactly
what we want is, imho, better than a large generic tool that does too
many things no one needs.
|-----< "CODE WARRIOR" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."