Re: Questioning debian/upstream/signing-key.asc

[Guillem Jover]

Hi!

On Fri, 2021-04-02 at 13:38:51 +0200, Guillem Jover wrote:
> On Fri, 2021-03-26 at 10:13:25 +0100, Christoph Biedl wrote:
> > However, I uncertain whether is really worth the efforts to maintain
> > d/u/s-k, or more precisely, ping maintainers to do so. Personally, I
> > really like it when uscan also validates signatures. But it seems that
> > enthusiasm isn't quite shared among all contributors.

BTW this was also recently discussed in #982562.

Thanks,
Guillem

Re: Questioning debian/upstream/signing-key.asc

[Guillem Jover]

[ CCing Daniel. ]

On Fri, 2021-03-26 at 17:31:16 +0100, Ansgar wrote:
> On Fri, 2021-03-26 at 09:06 -0700, Russ Allbery wrote:
> > 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.
> 
> How would you know that the signature was made before the key expired?

Ideally, because our tooling would not let such signatures through
into the archive, so we'd be able to tell automatically whether this
would hold at least at upload time.

(If the certificate would have expired at that time, I'd expect the
Debian maintainer to talk with the upstream maintainer about this.)

> Other systems (e.g. signed executables on Windows) have a trusted third
> party sign the timestamp for that, but OpenPGP doesn't do so.

If we are not going to trust the upstream signed signature timestamp,
then that seems it should be the least of our worries then? I don't
see why we'd trust the code upstream has provided?

Thanks,
Guillem

Re: Questioning debian/upstream/signing-key.asc

[Guillem Jover]

Hi!

[ Ccing Daniel, as he proposed the shipping of upstream signatures, so
  leaving full context. ]

On Fri, 2021-03-26 at 10:13:25 +0100, Christoph Biedl wrote:
> a few days ago, I ran uscan on a package where I knew there was a new
> upstream version - just to encounter an validation error since the
> keys in debian/upstream/signing-key.asc had expired.
> 
> After that, things escalated a little, and eventually I wrote a script
> that downloads d/u/s-k for each source package and examines the
> expiration status. And I ended up with:
> 
> 
>   maincontrib
> 
> Total number of   32761161
> source packages
> 
> Source packages that   2157  8
> ship d/u/s-k
> 
> Of those:
> 
> Failed to parse the file  3  0
> 
> Some keys have expired  306  1
> 
> All keys have expired   469  2
> 
> 
> Another about 40 distinct keys will expire within the next three months.
> 
> So for more than 20 percent of the packages with d/u/s-k, it's
> impossible to verify a new upstream tarball without extra work. Ouch.

I don't think that there was ever any expectation that such signing
certificates would be usable for any future releases though? As these
do not take into account new release maintainers, and changed, revoked
or expired certificates.

> Of course I understand there are various reasons why this happens, and
> several are not the maintainer's fault. But at least in some cases it's
> obvious the maintainers didn't care: When there has been an upload with
> a new upstream version released after the expiration. This has
> happened, hopefully they've verified the tarball by other means.

That's IMO a tooling problem. For example dpkg-source didn't use to
verify these at build time in the past so that's an obvious place this
would be let through unnoticed. Even now it just only warns, which can
be easy to miss. Also I guess people might not always use uscan to
fetch the tarballs.

> So, how to go from here?

Daniel and I happened to discuss issues related to this several days
ago, and we summarized this in
.

> The obvious thing to do now was a mass bug filing, and I might
> do that.

I'm not sure that's helpful though? I think instead making our tooling
more strict would be. Stuff like making sure uscan, dpkg-source,
lintian, dupload/dput/dput-ng or even dak error out on these, would
avoid the problem at creation or upload time.

Filing bugs about this seems it would be similar to filing bugs about
signing problems with .dsc IMO.

> However, I uncertain whether is really worth the efforts to maintain
> d/u/s-k, or more precisely, ping maintainers to do so. Personally, I
> really like it when uscan also validates signatures. But it seems that
> enthusiasm isn't quite shared among all contributors.

I do think the upstream signatures make sense, as they provide a
provenance chain from Debian, which is helpful f.ex. in case upstream
disappears or the tarballs upstream get modified, or simply to quickly
check whether it was created by an upstream developer.

But this might require more work, as has been mentioned in the thread,
this needs checking what is the state of the signing certificates at
the current time and at the signing time, and the relation of the
owner of that certificate at those times.

In any case the security properties of the upstream tarball signatures
and .dsc/.changes/.buildinfo apply mainly in the path from the upstream
to Debian maintainer up to the Debian archive, where this transitions
to the signatures made by the archive which do support resigning and
automatic key rotation for example.

> PS: Those who want to argue lintian should for check for such expired
> key, I couldn't agree more. Please read the discussion in #985793 first.

Thanks,
Guillem

Re: Questioning debian/upstream/signing-key.asc

[Paul Wise]

On Fri, Mar 26, 2021 at 9:15 PM Timo Röhling wrote:

> It's the same for me: the only package I maintain where upstream signs their
> releases is the package where I am also the author. And I really don't think
> that it provides any additional value for Debian in this particular
> constellation; I just keep doing it in case some other distribution
> wants to rely on the signature as integrity check.

The stored keys have value in the potential future scenario where you
remain the upstream release manager but move package maintenance to a
team or hand off maintenance to someone you are mentoring or someone
else. Or even when you do a new upstream release but forget to upload,
and someone else NMUs it for you.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Questioning debian/upstream/signing-key.asc

[Andreas Metzler]

On 2021-03-26 Christoph Biedl  wrote:
> a few days ago, I ran uscan on a package where I knew there was a new
> upstream version - just to encounter an validation error since the
> keys in debian/upstream/signing-key.asc had expired.
[...]
> Another about 40 distinct keys will expire within the next three months.

> So for more than 20 percent of the packages with d/u/s-k, it's
> impossible to verify a new upstream tarball without extra work. Ouch.

> Of course I understand there are various reasons why this happens, and
> several are not the maintainer's fault. But at least in some cases it's
> obvious the maintainers didn't care: When there has been an upload with
> a new upstream version released after the expiration. This has
> happened, hopefully they've verified the tarball by other means.

> So, how to go from here?
[...]

Hello Christoph,

I think there are two different issues at hand.

Uploading a new upstream version of a package where
debian/upstream/signing-key.asc is expired or does not 
match the uploaded upstream signature is a (minor) bug.

Otoh having a debian/upstream/signing-key.asc which expired *since*
the first upload of the upstream version is kind of the natural way of
things. When a new version appears we download it and check the
signature. If it does not verify we will investigate, perhaps the
key expired and was extended or a new key was used. Trying to do this
before we look at (and actually have a new upstream) is error-prone
could be make-work. (No new upstream released before this key experies,
too.)

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Questioning debian/upstream/signing-key.asc

[Christoph Biedl]

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


signature.asc
Description: PGP signature

Re: Questioning debian/upstream/signing-key.asc

[Russ Allbery]

Timo Röhling  writes:
> * Russ Allbery  [2021-03-26 13:01]:

>> If this were the case, it would be fine to re-sign *.dsc files, but
>> there has been quite a lot of opposition to that in the past.  The
>> upstream signing key is at least as useful as the signature on the
>> *.dsc file, for exactly the same reasons.

> I do not understand this, but I am probably too new with Debian. Can you
> point me to a discussion about this?

I'm not sure that I completely understand either (and unfortunately am not
adept enough with our list archives to find the previous discussion), but
my understanding was that even though DAK had checked the validity of the
packages, people wanted the option to be able to go back to the original
signatures and recheck them.

One possible scenario in which that would be useful is recovering from a
compromise of the Debian archive, in which the archive signature may no
longer be trustworthy.

Thinking about this some more, I overstated the merits of having the
upstream signing key, since of course the *.dsc signature also covers the
upstream tarball.  I think it's only useful as documentation of the
validity of the upstream signature and for retrieving new upstream
tarballs, since the *.dsc signature establishes the validity of the
upstream tarball for that specific Debian package.

Apologies for the sloppy thinking on my part.

> You're right, I did conflate those two concepts too much. Let me try and
> rephrase. What I meant to convey was: there is no way to know when a
> signature was created except trusting what the signature itself says,
> because anyone who has control over the key can forge any date. That's
> fine, because in this context, the actual date of the signature doesn't
> really matter: the signature is meant to prevent an attacker from
> tampering with the source code, not to prove when exactly the release
> happened.

> Thus, there is no reason to stop trusting the signature after the key
> has expired, unless you assume that someone could have replaced the
> original source and forged a backdated signature, i.e. the key was
> compromised.

> I am making more sense now?

Yes, thank you, that makes sense.  And therefore if we have an external
dating source (such as the upload to the archive), we can know that the
signature was not backdated outside of that range, which in turn is
probably enough information to trust signatures from subsequently expired
keys, but the open question is whether we would ever care to validate the
signature at that point given that we could just use the *.dsc signature
from the Debian maintainer.

The only scenario in which I could see wanting to do that is if we wanted
to double-check whether the maintainer verified the upstream signature at
the time of upload (or if the upstream tarball was somehow tampered with
on the maintainer's system between the time they checked and the time they
uploaded the source package to the archive).

-- 
Russ Allbery (r...@debian.org)  

Re: Questioning debian/upstream/signing-key.asc

[Timo Röhling]

* Russ Allbery  [2021-03-26 13:01]:

Personally, I'd be happy to drop the upstream signing keys from all of my
packages and save a bit of work.  I never use them as the package
maintainer because I'm the only upstream of my packaging that signs
packages, and therefore I already know the tarballs are authentic without
using a signature to prove it.  I include them only for the use of others.
If you're right that no one else cares, I'll save myself the time and
energy of refreshing them periodically.  But I'd like to see some
confirmation that people really don't care.

It's the same for me: the only package I maintain where upstream signs their
releases is the package where I am also the author. And I really don't think
that it provides any additional value for Debian in this particular
constellation; I just keep doing it in case some other distribution
wants to rely on the signature as integrity check.

- Timo



signature.asc
Description: PGP signature

Re: Questioning debian/upstream/signing-key.asc

[Timo Röhling]

* Russ Allbery  [2021-03-26 13:01]:

If this were the case, it would be fine to re-sign *.dsc files, but there
has been quite a lot of opposition to that in the past.  The upstream
signing key is at least as useful as the signature on the *.dsc file, for
exactly the same reasons.

I do not understand this, but I am probably too new with Debian. Can you
point me to a discussion about this?


Key expiration, at least in my understanding, says that signatures made by
that key are valid up until the point that the key has expired, but not
after that point.  It cannot protect against key compromise prior to the
expiration date.  That's what a revocation is for.

You're right, I did conflate those two concepts too much. Let me try and
rephrase. What I meant to convey was: there is no way to know when a
signature was created except trusting what the signature itself says,
because anyone who has control over the key can forge any date. That's
fine, because in this context, the actual date of the signature doesn't
really matter: the signature is meant to prevent an attacker from
tampering with the source code, not to prove when exactly the release
happened.

Thus, there is no reason to stop trusting the signature after the
key has expired, unless you assume that someone could have replaced the
original source and forged a backdated signature, i.e. the key was
compromised.

I am making more sense now?

- Timo



signature.asc
Description: PGP signature

Re: Questioning debian/upstream/signing-key.asc

[Russ Allbery]

Timo Röhling  writes:

> Once the package has been uploaded, it does no longer make a difference
> whether or not the upstream package was signed in the first place: any
> package will be protected by the Debian archive keys anyway.

If this were the case, it would be fine to re-sign *.dsc files, but there
has been quite a lot of opposition to that in the past.  The upstream
signing key is at least as useful as the signature on the *.dsc file, for
exactly the same reasons.

> Without that, like Ansgar pointed out, there is no trusted party left to
> determine whether or not a signature has been backdated, because we have
> to assume that an expired key might have been compromised at some point
> (or the whole idea of key expiry becomes meaningless).

I don't understand this statement.  It sounds like you want to treat a key
expiration as synonymous with a revocation, but that isn't my
understanding of the semantics at all.

Key expiration, at least in my understanding, says that signatures made by
that key are valid up until the point that the key has expired, but not
after that point.  It cannot protect against key compromise prior to the
expiration date.  That's what a revocation is for.

> The upstream key is only really needed by the maintainer if and when
> they package a new release, and this is exactly the time when uscan will
> complain about an expired key.

If the upstream key is only used by the package maintainer at the time of
packaging, we shouldn't put it in the Debian package at all.  But I don't
believe that was the intent.

Personally, I'd be happy to drop the upstream signing keys from all of my
packages and save a bit of work.  I never use them as the package
maintainer because I'm the only upstream of my packaging that signs
packages, and therefore I already know the tarballs are authentic without
using a signature to prove it.  I include them only for the use of others.
If you're right that no one else cares, I'll save myself the time and
energy of refreshing them periodically.  But I'd like to see some
confirmation that people really don't care.

-- 
Russ Allbery (r...@debian.org)  

Re: Questioning debian/upstream/signing-key.asc

[Jeremy Stanley]

On 2021-03-26 09:35:31 -0700 (-0700), Russ Allbery wrote:
[...]
> We do have a trusted timestamp for the point at which the upstream
> tarball and signature were uploaded to the Debian archive, though,
> so if the key had not yet expired at that point, I think we can
> infer it wasn't expired when the signature was made.

Speaking as someone who does this upstream (keeps a maximum one-year
expiration on OpenPGP keys used for signing release artifacts and
then extends them periodically) but also packages for Debian, it's
always been my assumption that an upstream tarball/tag signature
which was made with a key not expired at the time of upload into
Debian should be considered safe, since otherwise both the original
upstream key and Debian's archive signing keys would need to be
compromised to effect a convincing post-hoc substitution of the
source package. More likely, the attacker would only compromise the
archive signing and then replace the debian/upstream/signing-key.asc
with a different one under their control and sign the original
source with that instead (or not even bother because, let's be
honest, statistically speaking their targets are installing binary
packages anyway and so the attacker couldn't care less about source
package integrity).

The primary benefit I see for debian/upstream/signing-key.asc files
is that it's a record of what the package maintainer used to
validate the source they uploaded, and it provides some record of
whether there were changes in upstream signing practices (same key
ID with a new expiration date? different key but the keyserver
network contains keysigs for it from the previous one?). Actually
verifying signatures made with it after the source package has
appeared in the Debian archive seems to serve limited use.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Questioning debian/upstream/signing-key.asc

[Timo Röhling]

* Russ Allbery  [2021-03-26 09:35]:

We do have a trusted timestamp for the point at which the upstream tarball
and signature were uploaded to the Debian archive, though, so if the key
had not yet expired at that point, I think we can infer it wasn't expired
when the signature was made.

Once the package has been uploaded, it does no longer make a difference
whether or not the upstream package was signed in the first place: any
package will be protected by the Debian archive keys anyway.  Without
that, like Ansgar pointed out, there is no trusted party left to
determine whether or not a signature has been backdated, because we have
to assume that an expired key might have been compromised at some point
(or the whole idea of key expiry becomes meaningless).

The upstream key is only really needed by the maintainer if and when they
package a new release, and this is exactly the time when uscan will
complain about an expired key.

What might be useful is a Lintian warning when an upstream key is soon to
expire, assuming that upstream cares enough to have a proper key
rotation scheme.

- Timo



signature.asc
Description: PGP signature

Re: Questioning debian/upstream/signing-key.asc

[Russ Allbery]

Ansgar  writes:
> On Fri, 2021-03-26 at 09:06 -0700, Russ Allbery wrote:

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

> How would you know that the signature was made before the key expired?

> Other systems (e.g. signed executables on Windows) have a trusted third
> party sign the timestamp for that, but OpenPGP doesn't do so.

That's a great question.  I didn't think about that.

We do have a trusted timestamp for the point at which the upstream tarball
and signature were uploaded to the Debian archive, though, so if the key
had not yet expired at that point, I think we can infer it wasn't expired
when the signature was made.

-- 
Russ Allbery (r...@debian.org)  

Re: Questioning debian/upstream/signing-key.asc

[Ansgar]

On Fri, 2021-03-26 at 09:06 -0700, Russ Allbery wrote:
> 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.

How would you know that the signature was made before the key expired?

Other systems (e.g. signed executables on Windows) have a trusted third
party sign the timestamp for that, but OpenPGP doesn't do so.

Ansgar

Re: Questioning debian/upstream/signing-key.asc

[Russ Allbery]

Christoph Biedl  writes:

> Of course I understand there are various reasons why this happens, and
> several are not the maintainer's fault. But at least in some cases it's
> obvious the maintainers didn't care: When there has been an upload with
> a new upstream version released after the expiration. This has happened,
> hopefully they've verified the tarball by other means.

That feels like a bug to be sure.

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.

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.

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.

-- 
Russ Allbery (r...@debian.org)  

Re: Questioning debian/upstream/signing-key.asc

[Christoph Biedl]

Christoph Biedl wrote...

> PS: Those who want to argue lintian should for check for such expired
> key, I couldn't agree more. Please read the discussion in #985793 first.

Sorry, that should have been #964971.



signature.asc
Description: PGP signature

Questioning debian/upstream/signing-key.asc

[Christoph Biedl]

Hello,

a few days ago, I ran uscan on a package where I knew there was a new
upstream version - just to encounter an validation error since the
keys in debian/upstream/signing-key.asc had expired.

After that, things escalated a little, and eventually I wrote a script
that downloads d/u/s-k for each source package and examines the
expiration status. And I ended up with:


  maincontrib

Total number of   32761161
source packages

Source packages that   2157  8
ship d/u/s-k

Of those:

Failed to parse the file  3  0

Some keys have expired  306  1

All keys have expired   469  2


Another about 40 distinct keys will expire within the next three months.

So for more than 20 percent of the packages with d/u/s-k, it's
impossible to verify a new upstream tarball without extra work. Ouch.

Of course I understand there are various reasons why this happens, and
several are not the maintainer's fault. But at least in some cases it's
obvious the maintainers didn't care: When there has been an upload with
a new upstream version released after the expiration. This has
happened, hopefully they've verified the tarball by other means.

So, how to go from here?

The obvious thing to do now was a mass bug filing, and I might
do that.

However, I uncertain whether is really worth the efforts to maintain
d/u/s-k, or more precisely, ping maintainers to do so. Personally, I
really like it when uscan also validates signatures. But it seems that
enthusiasm isn't quite shared among all contributors.

Christoph

PS: Those who want to argue lintian should for check for such expired
key, I couldn't agree more. Please read the discussion in #985793 first.


signature.asc
Description: PGP signature