On 11-Dec-2008, at 07:39, Bowie Bailey wrote:
LuKreme wrote:
On 10-Dec-2008, at 20:36, SM wrote:
it's a hexadecimal number which identifies the key.
And the source of that number is, evidently, a complete mystery.
That's my point. I've seen lots of instructions like this:
# wget http://somesite.tld/somepath/GPG.KEY
# sudo sa-update --import GPG.KEY
# sudo sa-update --gpgkey 0E28B3DC --channel uber.rule.somesite.tld
where the '0E28B3DC' has just magically appeared as if created from
the ether.
Do you see that there is a crucial step missing there? Where did
that
gpgkey value come from? If it wasn't provided in these instructions
(like say you were looking for a ruleset at foo.bar.tld/GPG.KEY but
hadn't yet discovered the page that had the magic hex code), how do
you find it? Can you generate it. Is is simply a hash of the gpg
keyfile, or something else?
It's a bit of "hey, now just fill in this number we hopefully have
given you. Don't worry about what it means, or how it works, or
where
it came from. Just copy&paste and you'll be fine."
Strangely enough, that does not fill me with the highest degree of
confidence. Not much more so that --nogpg.
It's almost like "Just download this key file and you'll be fine.
Don't
worry about where it came from, just put it in your keyring."
Not at all, I KNOW where the gpg.key came from, because I downloaded
it. And it came from the same server as the rules are coming.
The point is that at some point you have to trust the source to give
you
the correct information. (Which, in the case of an encryption key or
key id, will look like a bunch of random numbers)
The KeyID is coming from who knows where.
Because sa-update is designed to provide updates in a secure way.
If you want the simplest way, you can ignore these steps and face
the consequences when something goes wrong.
Oddly enough, I am able to encrypt emails, sign emails, verify signed
mails, login to ssh ports on remote servers and do a whole host of
secure things without ever having encountered anything like this
gpgkey. I've added the key to the keychain as a trusted key, that is
enough to make it secure. How is this 8 digit hex code making
anything any more secure?
Because it specifies WHICH key in your keyring is allowed to sign the
updates.
So the concern is that someone who produces RULES1 for SA would hijack
RULES2's server and then create a new RULES2 set, sign it with their
RULES1 key, and wait for people to sync up with it? Because it would
require all of that, right?
Probability seems low.
Or is it that checking multiple keys is so expensive that you are
trying to save the server massive processing by telling it which key
to check with? That at least might make some sense, but I've not
noticed key checking taking a lot of processing.
On 11-Dec-2008, at 08:31, Kai Schaetzl wrote:
Karsten Bräckelmann wrote on Thu, 11 Dec 2008 12:48:34 +0100:
A quick glimpsing of the man page tells me to use this:
gpg --list-keys --no-default-keyring --keyring sa-update-keys/
pubring.gpg
For me, too. Either cd to /etc/mail/spamassassin or add it to the
path, though ;-)
The gpg installed on my FreeBSD does not have a man page (installed by
ports for SA3.2.5, IIRC), just a --help which says the syntax is:
syntax: gpg [options] [files]
sign, check, encrypt or decrypt
It does, further down, say:
--list-keys [names] show keys
but there is no indication of what is meant by [names]
I'm just saying the current state of the documentation on this is
poor, requires a level of implicit trust of the -gpgkey value that
should not be necessary with gpg keys, and it down-right confusing to
anyone looking at it for the first time who is not willing to simply
plug-n-play with someone else's config.
--
How do you feel? I'm lonely
What do you think? Cant take it all
Whatcha gonna do? Gonna live my life
