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

[Daniel Shahaf]

Good morning Axel,

Thanks for the quick answer.

Axel Beckert wrote on Sun, Jul 12, 2020 at 22:45:48 +0200:
> Hi Daniel,
> 
> Daniel Shahaf wrote:
> > My key hasn't expired; just the snapshots.  I periodically extend my
> > key's validity — currently it's valid through next December, published
> > in the usual places — but I haven't reëxported it to those files since I
> > last extended it.
> 
> 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.  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.

> > 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
.
; 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.

> I assume that at least the latter is not a (that) common case, so it's
> probably not taken into account so far.

*nod*

> > 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.]

> > 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))?

> > 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?
Remove the expired upstream key?  Add an override?  Something else?

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.

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

> > (For example, I didn't RM zsh 5.8, but my
> > public key was in signing-key.asc in 5.8.)
> 
> 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.)

Cheers,

Daniel