Dear Maintainer,

I noticed yesterday that the current source package of
zsh-syntax-highlighting contains a debian/upstream/signing-key.asc file
which contains an expired snapshot of upstream's signing key: the
snapshot gives the key's expiration date as 2018-06-28.¹

I then generated and built that package on a then-current sid chroot and
observed that no lintian warnings were logged about the expired key.
I invoked lintian as «lintian --display-info --display-experimental
--pedantic --color=always --no-tag-display-limit /build/*.changes
/build/*.dsc /build/*.deb».

I was wondering whether it would be a good idea for Lintian to add
a check for expired keys in debian/upstream/signing-key.asc.

Despite the name being in singular, signing-key.asc may contain multiple
keys, just like upstream tar.gz.asc files may contain multiple people's
signatures.

I am not sure what the semantics of the check should be when that file
contains multiple keys, only some of which are expired.  When upstream's
release manager (RM)'s identity changes, it can be useful to keep
carrying the outgoing RM's public key, in order to make it easier to
verify past and potential future upstream releases signed with that key.
However, someone who had stepped down from being RM might let their key
expire and not renew it until and unless they resume being the RM.

An alternative point of view is that signing-key.asc should contain only
keys that are currently in use, and older keys should be removed
(they'll still be available in archived sourced packages).  Under this
point of view, there might be room for an additional check that the keys
in signing-key.asc are indeed those keys used to sign the upstream
tarball.

Cheers,

Daniel

¹ In this particular case, upstream's key is my key, and that key has
been regularly extended (to 2020-07-01 and to 2021-12-31).  After
extending the key I re-pushed it to keyservers, but did not regenerate
the d/u/signing-key.asc export.  (I'd like to automate that regeneration,
since my key appears in multiple packages' signing-key.asc files, but
that's a question for another thread.)

Hi,

Daniel Shahaf wrote:

That might be something for lintian-brush once a lintian check is
there. Cc'ing Jelmer, the author of lintian-brush.

		Regards, Axel

Axel Beckert wrote...

What's the status of that story? I hacked a few lines together that work at
least for the case where I encountered the problem. But it's fairly
fragile since parsing in a textual output is bad. It was way better to
*omit* --list-packets in the gpg invocation since then the output is by
definition machine-readable (and there is an "Expired!" alert on stderr
for free). Also upstream warns the output of --list-packets "may change
with new releases."

    Christoph

Hi Daniel,

Did uscan give you any trouble when trying to validate upstream's
release signature?

Kind regards
Felix Lechner

Felix Lechner wrote...

Try libgpg-error before #985793 gets fixed:

    uscan: Newest version of libgpg-error on remote site is 1.42, local version is 1.38
    uscan:  => Newer package available from:
            => https://gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.42.tar.bz2
    gpgv: Signature made Mon 22 Mar 2021 11:50:29 AM CET
    gpgv:                using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA
    gpgv: Can't check signature: No public key
    uscan die: OpenPGP signature did not verify. at /usr/share/perl5/Devscripts/Uscan/Output.pm line 60.

Exit code 2

    Christoph

Hi Christoph,

That makes sense. I had a similar issue with wolfssl. Version 4.6.0-3
in unstable still contains the expired public key, but the validation
worked previously. As this open issue [1] suggests, it was probably
because the signature was made before the key expired. For version
4.7.0, it fails:

    uscan die: OpenPGP signature did not verify. at
/usr/share/perl5/Devscripts/Uscan/Output.pm line 60.

By the way, the suggestion behind this bug may not be implemented
anytime soon. It would cause Lintian's output to change over time
(same Lintian version on same package). Such tags are hard to test in
Lintian's test suite. I just got rid of the last known tag like it:

https://salsa.debian.org/lintian/lintian/-/commit/53ead395a217a8a7969f7f96e3882d2da402c96d

It would be more appropriate to flag expired keys on tracker.d.o.  The
need to update or replace a public key can, generally, only be
detected when trying to validate the most recent release signature. In
Debian's current setup that happens in UDD (via uscan). You can find a
quick note about here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985633#40

Expired keys also do not affect package quality in the archive. They
still validate old release signatures. I believe a maintainer would
have to sidestep uscan intentionally in order to upload a source
package with an upstream public key that turns out to be useless.
Since uscan happens earlier in the workflow, a Lintian tag is not the
right place to detect such key failures.

Kind regards
Felix Lechner

[1] https://dev.gnupg.org/T1537

Felix Lechner wrote...
they are difficult to test. By the way, to test behaviour over time,
faketime(1) serves me good enough. But that's your design decision.

Another place might be DDPO - problem with both is visibility. If such a
check was implemented in Lintian, package maintainers get any issues
right in their face when building the package (which usually includes
running lintian). Tracker or DDPO, I these those only occasionally.
Other people's workflow might be different, though.

Also, in lintian the change was rather small and therefore easy to
implement.

How do the other signing key checks do that? Where's the difference?

Assuming upstream already updated the signing key, it would still avoid
breaking uscan in the future.

It would alert if the key already has expired, something I reckon about
libgpg-error (key expiry December 2019, new upstream release uploads in
March and June 2020).

It could (after an extension of the check) warn about an upcoming
expiration so the maintainer can update accordingly before breaking the
validation chain. And yes, that's time-based behaviour.

    Christoph

Hi Christoph,

No, it's an indicator that another QA tool might be a better place for
the warning.

Everyone with a key uses 'uscan', and that is the right place to warn
about expired keys. It is not necessary to upload new Debian revisions
because a key is expired.

The resulting tag is not useful for a package at rest. Think about it
this way: Many old packages may trigger the tag in the archive, but
there is no need to fix anything. Dead upstream sources also
illustrate that point.

Keys that are not minimal, for example, take up space. We have keys
with over a thousand third-party signatures in the archive. [1] Keys
with weak hashes are a security risk. So are known compromised keys.
Expired keys, on the other hand, are not a package quality issue. They
will get updated in the course of time.

[1] https://lintian.debian.org/sources/xandikos/0.2.2-1.html

Uscan uses the network, but Lintian does not. In a similar vein,
Lintian can also not fix broken download URLs—which are arguably a
much bigger problem. (For an extended discussion, please see
Bug#985633 about recent changes at Github.) Errors that arise when
trying to access and validate new sources will be flagged right then
and there.

Without a new release, there is no need to update the key. From my
experience, that is also the attitude of upstream personnel, who may
only extend or distribute new keys at release time.

As I reasoned here, that is not valuable information for a package at
rest. Lintian is a static analysis tool.

The maintainer cannot download new versions without a validation
chain. The issue is always solved before Lintian runs. Lintian is the
wrong place to point it out. It is too late in the workflow, and
cannot arise naturally unless the maintainer intentionally works with
unvalidated sources.

Kind regards
Felix Lechner

Good morning Felix,

Felix Lechner wrote on Tue, Mar 23, 2021 at 14:16:26 -0700:

In zsh-syntax-highlighting's packaging I don't use uscan(1).  I just
git-merge(1) the new upstream tag, and use git-archive(1) to fake
a .orig tarball.

According to comments in zsh-syntax-highlighting's debian/README.source
and debian/source/lintian-overrides, uscan(1) was avoided because
upstream produces signed tags but not signed tarballs, and no way was
identified to have uscan(1) verify them.  Thus, the automation that
calls git-archive(1) also handles verification manually.

In my specific case, I don't actually need the verification at all
because I happen to upstream's release manager and sign the tags myself
in that capacity, but the workflow doesn't depend on this.

Cheers,

Daniel

Hello,

Just to make this suggestion more obvious as I got (and needed) this
hint:

A sensible date to fake (or compare to) would probably be the changelog
date. Then the output doesn't vary over time and we also don't get bad
positives for old packages.

Best regards
Uwe