Russ Allbery wrote...
> I think there's a bit of subtlety here in that if upstream uses a key with
> an expiration that they periodically extend (to provide a time-based
> cut-off if they lose control of the key for whatever reason, for
> instance), and that package is rarely updated because it's stable, it's
> quite likely that the key will have expired but I'm not sure that's a
> problem.
That's indeed a design weakness of d/u/s-k. But the way upstream handles
signing key expiration and renewal is naturally completely out of
Debian's control.
There is actually another issue besides expiration: Upstream might
have more than just one signing key, and that list changes.
In an ideal world, upstream would, at the time of a release, make sure
the signing key will stay valid beyond the time of the prospective next
one (already partially defeating the idea of a time-based cut-off).
Additionally, upstream will have to take care that next release will be
verifyable using the current keys, i.e. don't use a new key to sign the
next release. Sounds optimistic, eh? Then the Debian maintainer has to
updats d/u/s-k accordingly - which seldom happens, hence this thread,
and by the way I've failed on that as well. Then, and only then uscan
can verify a new upstream release.
So while this works in general, it has some potential for failure, and
this happens. My suggested MBF however would just address maintainer's
negligence, I'm not sure whether it's sufficient and hence worth it.
> I'm not all that familiar with the intended semantics of OpenPGP key
> expirations, but intuitively I think a signature made before the
> expiration should be considered valid, even if the key has now expired and
> thus shouldn't be used to make new signatures.
Agreed for that case here where content and signature have been
published at a some time in the past so falsifying ex post is quite
difficult.
The idea of d/u/s-k however is to validate a future release, assuming
the signing key stays the same and does not need a renweal otherwise.
Repeating myself: I like the idea uscan can verify a new upstream
release and would really like to keep that. But the longer I look at it
the more I think it was better find find a solution that overcomes the
deficiencies of the current concept. I have some ideas but I doubt they
could work out.
> I'm curious how your numbers would change if you only counted as expired
> keys that were expired at the time that the upstream tarball signature was
> made.
Upstream shouldn't be able to create such signatures at all.
A quick check however revealed it's very common the key(s) in d/u/s-k
had expired by the time the last upload to Debian was made. In in ideal
world, upstream would already have refreshed the key, and the Debian
maintainer updated d/u/s-k accordingly - which is the reason why I'd
like to see a lintian check for expired keys.
Christoph
Attachment:
signature.asc
Description: PGP signature