[Pkg-zsh-devel] Expired keys in d/upstream/signing-key.asc

[Axel Beckert]

Hi Daniel,

Daniel Shahaf wrote:
> > I like your usage of ë in a non-French language. :-)
> 
> Thanks ☺
> 
> > I usually do this with "Koffeïn" (the German word for "caffeine" as it is
> > otherwise ambiguous since "ei" usually has a special pronounciation in
> > German.
> 
> *nod* I'm familiar with German pronunciation rules, but I didn't know
> diaereses were used in German.

They're not(*). That's my point. :-)

(*) Except when maybe talking about Citroën cars. Citroën even had a
    marketing event a year ago or so claiming that they will rebrand
    to Zitrön in Germany to accomodate the most common pronounciation
    of their name by Germans. ;-)

> What does one do when an umlauted letter needs to be diaeresis'd? I
> don't see a way to add a diaeresis to an ä/ö/ü in Unicode.

I'll skip that here on the list now as we're completely offtopic with
this. I think there is an answer, but I'd need to experiment a bit
first. ;-)

> > > Should I update those exports manually? It seems weird to have to do
> > > this manually when it's fully automatable (particularly so when the
> > > public key in question is on keyring.d.o anyway).
> > 
> > Good question.
> 
> Thanks.  Any thoughts on the answer?  It's not hard to write
> .
>     cd "$(mktemp -d)"
>     GNUPGHOME=$PWD gpg --import < /path/to/signing-key.asc
>     GNUPGHOME=$PWD gpg --refresh-keys
>     GNUPGHOME=$PWD gpg --armor --export > /path/to/signing-key.asc
> .

Indeed. In consider the usage of a temporary directory with $GNUPGHOME
as very important for privacy reasons (with --refresh-keys), not only
for not modifying your personal keyring.

We likely also should use something like "--export-options
export-minimal". Otherwise lintian will complain about that :-)

> ; the question what kind of automation to wrap it in.  I'd propose to
> have it run by a headless task, but I don't see how to make the
> resulting diffs reviewable.

Can we get external diff tools to be used with git? If so, diffoscope
might be able to show such a difference.

> > > There doesn't seem to be a lintian check for expired keys in that file,
> 
> [There is https://lintian.debian.org/tags/public-upstream-key-unusable.html,
> but it didn't fire when I built z-sy-h with today's sid.]

>From the description, I'd expect this warning mostly when lintian
can't parse the key.

Please also note that https://lintian.debian.org/tags.html is known to
be currently not uptodate. At least new tags since 2.81.0 (23th of
June) are missing. (I always look for the tag breakout-link in there.)

> > > nor a wishlist bug for such a check.
> > 
> > But I think there should be one, especially if that's not yet
> > automated (or automatable) yet.
> 
> Okay.  If I don't hear otherwise, I'll file a wishlist bug.
> Should I Cc some person/group as maintainers of the d/u/signing-key.asc
> spec?  -qa@?  devscripts at packages.d.o (maintainers of uscan(1))?

Good question. Not sure if such a Cc is needed for the bug report in
general, but this topic might indeed interest other people as well. My
gut feeling says -qa is a good choice, but I don't know if all uscan
authors read this. (Some do for sure. :-)

> > > I'm not sure whether one should be added, though; that would depend
> > > on whether upstream keys that have been retired should or shouldn't
> > > be retained in that file.
> > 
> > Nope, I think expired keys in debian/upstream/signing-key.asc
> > generally should cause a warning — independent of if the key
> > expiration date has been extended elsewhere or not.
> 
> What would a maintainer do when the warning fires for their package?

Update the key primarily, either add a different one or update the
current one with the according signature which extended that date.

> Add an override?

I can't imagine any reason to do that in case of an expired upstream
key. But then again, it's good to be able to override lintian warnings
as there's always some exception you don't think of as check author.
(Saying this as someone who has written a bunch of lintian checks
himself and nearly 150 commits in lintian — which is not in the top
ten, you'd need nearly 500 commits to get in there. :-)

> Naturally, if the expired key belongs to the then-current upstream RM
> then the warning is correct and that person should be asked to extend
> their key's validity.  However, what if the expired key belongs to
> a past RM who is no longer active?  Such a person may or may not be
> reachable, and may or may not come back and RM some future releases.

For me it's kinda obvious that in this case the key needs to be
replaced with the current release manager's public key.

BTW: In Debian context "RM", especially in caps-lock seems seldomly
used for release managers, but a lot for package removal, the so
called RM bugs:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ftp.debian.org#_0_0_4

This especially counts for phrases like this:

> > > (For example, I didn't RM zsh 5.8, but my public key was in
> > > signing-key.asc in 5.8.)

First I read it as "I didn't remove zsh 5.8 from Debian". ;-)

> > Good point. We probably should add dana's public key, too.
> 
> I already did, in debian/5.7-2-1-g14d262602.  (See workers/46229 for
> additional context for that commit.)

Ah, right. Already forgot about this. I uploaded it myself with
5.7.1-1. :-)

> (We might want to continue this discussion on the lintian bug, once it's
> created.  I'll X-D-Cc you.)

Ack.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE