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

[Daniel Shahaf]

Axel Beckert wrote on Mon, 13 Jul 2020 13:14 +0200:
> Daniel Shahaf wrote:
> > > > 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.

Agreed.

However, there are downsides as well: for example, if ~/.gnupg/gpg.conf
specifies a tor/onion default keyserver URL, honouring it would be
reasonable and probably desirable.

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

Yes.

On an _ad hoc_ basis, there's «git difftool --extcmd foo».  For example,
«git difftool --extcmd icdiff» will show side-by-side diffs.  (Requires
the 'icdiff' package.)

On a more permanent basis, I see a relevant section in gitattributes(5):

   Generating diff text
       [...]
           The attribute **diff** affects how Git generates diffs for
           particular files. It can [...] tell Git to use an external
           command to generate the diff, or ask Git to convert binary
           files to a text format before generating the diff.

I don't know whether other tools — for example, push-to-email
notifications, salsa's Web interface, etc — would honour such
gitattributes(5) settings, or be required to be configured separately.

> If so, diffoscope might be able to show such a difference.

Probably.  Or perhaps we could employ the "ask Git to convert binary
files to text format" bit.  I think that would mean «git diff» would
filter signing-key.asc through a command that converts the .asc export
to human-readable text — something along the lines of «pgpdump -i» — and
then textually diff the result in the usual way.

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

*nod*.  It was the most closely related lintian check.

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

Thanks; I didn't know that.

> > > > 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. :-)

*nod*

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

Adding a different key wouldn't resolve the warning unless the expired
key is removed at the same time, won't it?  I was assuming the warning
should fire if _any_ key in signing-key.asc is expired, but maybe it
should only fire if _all_ keys therein are expired, or maybe it should
verify only those keys that are both in signing-key.asc and were used to
sign the upstream artifact (there may be more than one key in the
intersection).

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

Okay.  Personally, I think there's value in keeping other keys there,
just in case someone wants to use them to verify past or future releases
signed with those keys.  The cost of keeping disused keys in signing-key.asc
forever is basically zero.

If we don't keep old keys, people will still be able to get them from
archived source packages.

> BTW: In Debian context "RM", [...] read it as "I didn't remove zsh 5.8
> from Debian". ;-)

Thanks for the heads-up. ☺