[debexpo-devel] parsing gpg key ids
Serafeim Zanikolas
serzan at hellug.gr
Sun Feb 1 22:38:26 CET 2009
Hi Jonny,
On Sun, Feb 01, 2009 at 05:08:17PM +0000, Jonny Lamb wrote [edited]:
> * Please hard-code the path to the GPG executable in the configuration
> file. The default should of course be "/usr/bin/gpg2".
Will do.
> * I'm merely a user of GPG, but I'd recommend using gnupg instead of
> gnupg2 as the former is "Priority: important" and the latter is
> "Priority: optional". As a result, it will be installed on more
> machines. Please do point out the advantage of using gnupg2 to me
> though.
I haven't thought about it at the time, and having looked it up, I agree that
we should stick to gpg (and it really doesn't matter that much as the
executable will be a parameter in the configuration file).
> * The reason I didn't implement the key checking like this in the first
> place is that it feels like a duplication of data. But the cost of
> storing a little string in the database clearly is better than
> calling out to an executable every time, unless there's another way
> to get it?
I'm not aware of another way. I did think about the duplication issue, but
given the current code, I'd be hard pressed to find a case where the key gets
out of sync with the fingerprint. If we're really paranoid about it, we could
easily add a script, to be ran as a cronjob, that performs this and other
kinds of sanity checks.
> * I tried to make debexpo rather pythonic. It would be nicer if debexpo
> used some kind of Python GPG binding, as opposed to calling out to
> /usr/bin/gnupg directly and mangling the string. For example, I see
> the python-gnupginterface package.
I appreciate the emphasis on modularity and reuse but I think that as of now,
gpg is used very little to justify use of python-gnupginterface (perhaps, we
might reconsider if and when gpg is used more extensively?)
> > The patch also has a couple of other minor changes:
> >
> > - allow non @debian.org emails in debug mode
> > - add a bit of padding in the HTML table that lists uploaded packages
> > (previously some cells looked crammed together)
>
> These are both great ideas. Could you split the patch for each change
> though please?
Will follow up on this.
Cheers,
Serafeim
More information about the debexpo-devel
mailing list