Expired GPG keys of older release

[john doe]

Hello,
GPG key that signed the Squeeze repo is now expired. How should I handle
this properly ? Despite the key is expired, it use to be valid and I
don't like much the idea of going for [trusted=yes] for each impacted
sources.list entry.

Sadly, if the expiry date of the key is not extended there is little you
can do beyond insuring that the key in your keyring is up-to-date which
is normaly done automatically on Debian.

Googling this gives some things to try.

[john doe]

Post by john doe

Hello,
GPG key that signed the Squeeze repo is now expired. How should I
handle this properly ? Despite the key is expired, it use to be valid
and I don't like much the idea of going for [trusted=yes] for each
impacted sources.list entry.

Sadly, if the expiry date of the key is not extended there is little you
can do beyond insuring that the key in your keyring is up-to-date which
is normaly done automatically on Debian.
Googling this gives some things to try.

Reading:

https://wiki.debian.org/DebianKeyring

you could try:

"# Fetch a key from the keyring
$ gpg --keyserver keyring.debian.org --recv-key 0xkeyid"

Where <0xkeyid> is the keyid to be updated.

$ --refresh-keys

I don't use squeeze so I can't properly test it! :)

[Andy Smith]

Hello,

Post by john doe
https://wiki.debian.org/DebianKeyring
"# Fetch a key from the keyring
$ gpg --keyserver keyring.debian.org --recv-key 0xkeyid"

It won't help because the problem isn't that the keys are missing,
it's that the keys are expired. All the above will do is get another
copy of the key, which is still expired.

If you need to use an EOL release, all you can do is ignore the
warnings about expired keys.

Cheers,
Andy

[Don Armstrong]

That's a pity, don't you think so ? I think Debian should renew the
archive key, so we can still verify packages signatures.

You can still verify them. Key expiration doesn't make existing
signatures invalid. [Indeed, gpgv doesn't even check for expired keys.]

[john doe]

Post by Don Armstrong

That's a pity, don't you think so ? I think Debian should renew the
archive key, so we can still verify packages signatures.

You can still verify them. Key expiration doesn't make existing
signatures invalid. [Indeed, gpgv doesn't even check for expired keys.]

With apt ? I had to set allowunauthenticated = 1 in apt.conf, otherwise
apt wouldn't install anything.

Can you give us the warning/error you're getting?

[john doe]

Post by john doe

Post by Don Armstrong

That's a pity, don't you think so ? I think Debian should renew the
archive key, so we can still verify packages signatures.

You can still verify them. Key expiration doesn't make existing
signatures invalid. [Indeed, gpgv doesn't even check for expired keys.]

With apt ? I had to set allowunauthenticated = 1 in apt.conf,
otherwise apt wouldn't install anything.

Can you give us the warning/error you're getting?

 ---> Running in 2300490ebb96
Get:1 http://archive.debian.org squeeze Release.gpg [1655 B]
Get:2 http://archive.debian.org squeeze-lts Release.gpg [819 B]
Get:3 http://archive.debian.org squeeze Release [96.0 kB]
Ign http://archive.debian.org squeeze Release
Get:4 http://archive.debian.org squeeze-lts Release [34.3 kB]
Get:5 http://archive.debian.org squeeze/main amd64 Packages [8370 kB]
Get:6 http://archive.debian.org squeeze-lts/main amd64 Packages [390 kB]
Fetched 8893 kB in 0s (10.0 MB/s)
Reading package lists...
W: GPG error: http://archive.debian.org squeeze Release: The following
signatures were invalid: KEYEXPIRED 1520281423 KEYEXPIRED 1501892461
Reading package lists...
Building dependency tree...
Reading state information...
  libssl0.9.8 openssl
  ca-certificates libssl0.9.8 openssl wget
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 2980 kB of archives.
After this operation, 7578 kB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  ca-certificates
E: There are problems and -y was used without --force-yes

As other as pointed out if the expiration date is not extended on the
key your out of luck! :)

https://www.debian.org/News/2011/20110209

One workaroungd could be:
1) Download all required packages
2) Verify the downloaded packages using 'gpg --verify'
3) Install the verified pkgs

The best workaround would be to upgrade to Debian Stretch (6 to 7, 7 to
8, 8 to 9)! :)

For sake of completeness:
apt-key update - update keys using the keyring package
apt-key net-update - update keys using the network

[t***@tuxteam.de]

On Wed, Jun 20, 2018 at 09:43:03AM +0200, john doe wrote:

[...]

Post by john doe
As other as pointed out if the expiration date is not extended on
the key your out of luck! :)
https://www.debian.org/News/2011/20110209

Yes, exactly. Keys *have* to expire at some point, and you can't
re-sign archived packages with a fresh key. Note that this will
happen to all "old" documents, not only Debian packages.

Post by john doe
1) Download all required packages
2) Verify the downloaded packages using 'gpg --verify'
3) Install the verified pkgs
The best workaround would be to upgrade to Debian Stretch (6 to 7, 7
to 8, 8 to 9)! :)

Yes, but there may be perfectly valid reasons to stick to an old
Debian: that's why they are available in the archives. One example
would be "old hardware".

Post by john doe
apt-key update - update keys using the keyring package
apt-key net-update - update keys using the network

Yes, but that won't help in the above case. It's more of a "structural"
problem.

Cheers
- -- t

[john doe]

Post by john doe

Post by john doe

Post by Don Armstrong

That's a pity, don't you think so ? I think Debian should renew the
archive key, so we can still verify packages signatures.

You can still verify them. Key expiration doesn't make existing
signatures invalid. [Indeed, gpgv doesn't even check for expired keys.]

With apt ? I had to set allowunauthenticated = 1 in apt.conf,
otherwise apt wouldn't install anything.

Can you give us the warning/error you're getting?

  ---> Running in 2300490ebb96
Get:1 http://archive.debian.org squeeze Release.gpg [1655 B]
Get:2 http://archive.debian.org squeeze-lts Release.gpg [819 B]
Get:3 http://archive.debian.org squeeze Release [96.0 kB]
Ign http://archive.debian.org squeeze Release
Get:4 http://archive.debian.org squeeze-lts Release [34.3 kB]
Get:5 http://archive.debian.org squeeze/main amd64 Packages [8370 kB]
Get:6 http://archive.debian.org squeeze-lts/main amd64 Packages [390 kB]
Fetched 8893 kB in 0s (10.0 MB/s)
Reading package lists...
W: GPG error: http://archive.debian.org squeeze Release: The
following signatures were invalid: KEYEXPIRED 1520281423 KEYEXPIRED
1501892461
Reading package lists...
Building dependency tree...
Reading state information...
   libssl0.9.8 openssl
   ca-certificates libssl0.9.8 openssl wget
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 2980 kB of archives.
After this operation, 7578 kB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
   ca-certificates
E: There are problems and -y was used without --force-yes

As other as pointed out if the expiration date is not extended on the
key your out of luck! :)
https://www.debian.org/News/2011/20110209
1)   Download all required packages
2)  Verify the downloaded packages using 'gpg --verify'
3)  Install the verified pkgs
The best workaround would be to upgrade to Debian Stretch (6 to 7, 7
to 8, 8 to 9)! :)
  apt-key update              - update keys using the keyring package
  apt-key net-update          - update keys using the network

Well, that's a docker image, I'm not using Squeeze on production
anywhere except this hacky stuff for a friend ;-)

Mabey:

From:

https://unix.stackexchange.com/questions/2544/how-to-work-around-release-file-expired-problem-on-a-local-mirror


"-o Acquire::Check-Valid-Until=false
For example:
sudo apt-get -o Acquire::Check-Valid-Until=false update"

https://manpages.debian.org/stretch/apt/apt.conf.5.en.html

[Greg Wooledge]

 ---> Running in 2300490ebb96

You didn't show the command that you typed. That makes it harder to
give solutions.

W: GPG error: http://archive.debian.org squeeze Release: The following

Is a warning. You can tell by the giant W.

WARNING: The following packages cannot be authenticated!

Is a warning. You can tell by the giant WARNING.

E: There are problems and -y was used without --force-yes

Stop typing the -y option when you type the command in the terminal
that you're typing commands into. Or, as a second-rate fallback
solution, consider typing the --force-yes option as well.

And if you mention the D word (the one that is not Debian) to me, or
if you say that you are not typing commands into a terminal, I will
most likely yell at you.

[t***@tuxteam.de]

On Wed, Jun 20, 2018 at 02:27:24PM +0200, Adam Cecile wrote:

[...]

I still thinks it *sucks* to have no alternative then considering
packages signed by an expired key like unsigned packages....

That was my impression too: there should be a separate option for
"yes, I know the key is expired". Perhaps you can bring it up in
debian-devel or on the APT mailing list (https://lists.debian.org/deity/),
to see if they recommend filing a bug?

Cheers
- -- tomás

[Curt]

Post by t***@tuxteam.de
[...]

I still thinks it *sucks* to have no alternative then considering
packages signed by an expired key like unsigned packages....

That was my impression too: there should be a separate option for
"yes, I know the key is expired". Perhaps you can bring it up in
debian-devel or on the APT mailing list (https://lists.debian.org/deity/),
to see if they recommend filing a bug?
Cheers
- -- tomás

What does this do?

-o Acquire::Check-Valid-Until=false update

[t***@tuxteam.de]

[...]

Post by Curt
What does this do?
-o Acquire::Check-Valid-Until=false update

NOTE: this is just from what I understand from the man page,
apt.conf(5). This would disable to disable checking the Valid-Until
header in the Release file. As far as I understood this thread, the
problem at hand seems to be an expired (gpg) key.

But hey, experiment tops theory especially a mushy theory :-)

Cheers
- -- t

[Curt]

Post by t***@tuxteam.de
[...]

Post by Curt
What does this do?
-o Acquire::Check-Valid-Until=false update

NOTE: this is just from what I understand from the man page,
apt.conf(5). This would disable to disable checking the Valid-Until
header in the Release file. As far as I understood this thread, the
problem at hand seems to be an expired (gpg) key.
But hey, experiment tops theory especially a mushy theory :-)
Cheers
- -- t

You're right (ignore Release file expiration); it's the solution
to another question (in another thread).

What we need is the same kind of parameter for key expiration (or
something).

Thanks.

[Greg Wooledge]

Anyway, the command is apt-get install -y wget ca-certificates

What happens if you remove the -y option?

[Roberto C. Sánchez]

Post by Greg Wooledge

Anyway, the command is apt-get install -y wget ca-certificates

What happens if you remove the -y option?

The output appears to be from a step in a Dockerfile. Remove -y would
then require an interactive response from the user, which is
undesireable in this situation.

As the error output indicates, the command can be forced to complete
with --force-yes, but I can understand why anybody would be hesitant to
use that.

Regards,

-Roberto

[Greg Wooledge]

Post by Roberto C. Sánchez
The output appears to be from a step in a Dockerfile.

Then the Docker users should know how to use their stupid Dockers and
shouldn't require hand-holding from non-Docker mailing lists.

Or IRC channels.

[Roberto C. Sánchez]

Post by Greg Wooledge

Post by Roberto C. Sánchez
The output appears to be from a step in a Dockerfile.

Then the Docker users should know how to use their stupid Dockers and
shouldn't require hand-holding from non-Docker mailing lists.

To be fair, Adam appears to know what he is doing. The issue he has
raised is that there does not appear to be a way to get apt to ignore
the key expiration. The two options are apparently "all security on"
or "all security off". It is clear that there are users that need a
middle ground option that does not currently exist.

Regards,

-Roberto

[Dan Purgert]

Post by Greg Wooledge

Post by Roberto C. Sánchez
The output appears to be from a step in a Dockerfile.

Then the Docker users should know how to use their stupid Dockers and
shouldn't require hand-holding from non-Docker mailing lists.

Is "set it on fire and throw it out the window" a valid option?

[David Wright]

Post by Roberto C. Sánchez

Post by Greg Wooledge

Anyway, the command is apt-get install -y wget ca-certificates

What happens if you remove the -y option?

The output appears to be from a step in a Dockerfile. Remove -y would
then require an interactive response from the user, which is
undesireable in this situation.
As the error output indicates, the command can be forced to complete
with --force-yes, but I can understand why anybody would be hesitant to
use that.

Can't the OP just use --force-yes -d to *download* the files,
then check the files' digests "manually" rather than by using
apt-get, then install the downloaded files with dpkg -i.

Cheers,
David.

[Ben Finney]

This post might be inappropriate. Click to display it.

[r***@gmail.com]

Post by Ben Finney
In other words: Yes, it's inconvenient, but it's because *no one can
know* with confidence any more whether that key has been compromised.

Well, I should study up more on keys and expiration, but isn't the situation
much the same before the key expires? I mean, the issuer / owner of the key
really doesn't know whether the key has been compromised?

(There might be / probably is less chance it has been compromised (in
congruence with your last paragraph, quoted below), but, the person that
breaks a key doesn't report to the owner that he has done so ;-)

Post by Ben Finney
So that does put it into the same category as “who the hell knows
whether this signature is associated with the key owner”.
That's just a fact that follows from the finite lifetime of the security
of a given key. The longer it's been out there, the larger the window
for compromise; and we're now outside the window where the key owner
warrants to still be in control of that key. Don't trust whatever
signatures you find with that key any more.

[Ben Finney]

Post by r***@gmail.com

Post by Ben Finney
In other words: Yes, it's inconvenient, but it's because *no one can
know* with confidence any more whether that key has been compromised.

Well, I should study up more on keys and expiration, but isn't the
situation much the same before the key expires? I mean, the issuer /
owner of the key really doesn't know whether the key has been
compromised?

The difference is in the degree of confidence that can be expected. When
the key was created, the key's creator thereby expressed the upper bound
of duration for that confidence remaining acceptably high.

[Don Armstrong]

Post by Don Armstrong

That's a pity, don't you think so ? I think Debian should renew the
archive key, so we can still verify packages signatures.

You can still verify them. Key expiration doesn't make existing
signatures invalid. [Indeed, gpgv doesn't even check for expired keys.]

With apt ? I had to set allowunauthenticated = 1 in apt.conf, otherwise apt
wouldn't install anything.

Hrm; it looks like apt has its own internal version of gpgv which
actually tests the time.

In theory, [allow-weak=yes] should work, but I haven't actually tested
this.

[t***@tuxteam.de]

On Wed, Jun 20, 2018 at 10:37:19AM -0700, Don Armstrong wrote:

[...]

Post by Don Armstrong
Hrm; it looks like apt has its own internal version of gpgv which
actually tests the time.

Ah, at last someone in the know :-)

Thanks!

Post by Don Armstrong
In theory, [allow-weak=yes] should work, but I haven't actually tested
this.

Since it seems that an archived Debian release is bound to have an
expired key, would you agree that it'd be useful to have an option
to accept such a key?

Cheers
- -- t

[Don Armstrong]

Post by t***@tuxteam.de
Since it seems that an archived Debian release is bound to have an
expired key, would you agree that it'd be useful to have an option to
accept such a key?

Probably. I would not put my personal development time into if existing
features don't already support it, though. Releases as old as squeeze
are known to have multiple security exploits, and shouldn't be used at
all for new installations. Therefore I can't argue for someone else to
spend their development time implementing such a feature.

[t***@tuxteam.de]

Post by Don Armstrong

Post by t***@tuxteam.de
Since it seems that an archived Debian release is bound to have an
expired key, would you agree that it'd be useful to have an option to
accept such a key?

Probably. I would not put my personal development time into if existing
features don't already support it, though. Releases as old as squeeze
are known to have multiple security exploits, and shouldn't be used at
all for new installations. Therefore I can't argue for someone else to
spend their development time implementing such a feature.

Understood. And for squeeze the horses are already out, as Ansgar points
out downstream. But somehow it seems worth thinking about, since it is
a structural problem (how do people solve the "old signed documents"
problem" anyway?).

It is clear that an archived release has (known & unknown) unfixed security
problems, since it doesn't change. And veryfying the key can only tell
you "well, at the time this seems to have been signed correctly". Perhaps
the new Debian maintainers can attest to this fact with new signatures.

In short, this is going to haunt us beyond Unix "end-of-time" (with a
tip of the hat to Ansgar).

Cheers
- -- tomás

[Ansgar Burchardt]

Post by t***@tuxteam.de

Post by Don Armstrong
In theory, [allow-weak=yes] should work, but I haven't actually tested
this.

Since it seems that an archived Debian release is bound to have an
expired key, would you agree that it'd be useful to have an option
to accept such a key?

But a user of an archived Debian release wouldn't get an updated apt
which includes this new option. :-)

By the time Debian oldoldoldstable includes this option, the end of UNIX
time might already be so clone that oldoldoldstable software wants a
date safely in the past and one has to fake system time. That would
make the keys unexpired at the same time.

Ansgar

[t***@tuxteam.de]

On Thu, Jun 21, 2018 at 12:08:11AM +0200, Ansgar Burchardt wrote:

[...]

Post by Ansgar Burchardt
But a user of an archived Debian release wouldn't get an updated apt
which includes this new option. :-)

Quite right: the best (s)he can hope for is a workaround. Perhaps the
one "disregard all security" is the best of those. Perhaps not.

Post by Ansgar Burchardt
By the time Debian oldoldoldstable includes this option, the end of UNIX
time might already be so clone that oldoldoldstable software wants a
date safely in the past and one has to fake system time. That would
make the keys unexpired at the same time.

:-)

Cheers
- -- t

[t***@tuxteam.de]

Hello,
GPG key that signed the Squeeze repo is now expired. How should I
handle this properly ? Despite the key is expired, it use to be
valid and I don't like much the idea of going for [trusted=yes] for
each impacted sources.list entry.

Squeeze is, as others have noticed, beyond "end-of-life". That means
that it is "archived". It won't change. Ever.

Re-signing the packages with fresh keys would mean "change". Bad idea.

And just extending the keys' validity (as someone proposed in this
thread) seems a bad idea too, since the requirement for secure keys
evolves over time, as the NSA^H^H^H bad guys buy more GPUs.

So as far as I see it, there's no easy solution to that. I guess
you'll have to live with an expired key.

Perhaps one could talk the Apt folks into treating expired keys
in a different way than plain invalid or non-existing ones. I
wouldn't hold my breath, though.

Cheers
- -- tomás

[James Cloos]

T> And just extending the keys' validity (as someone proposed in this
T> thread) seems a bad idea too, since the requirement for secure keys
T> evolves over time, as the NSA^H^H^H bad guys buy more GPUs.

The problem is that the point of a key's expiration time is that
signatures newer than that should fail, but all signatures made before
the expiration should verify.

So, if apt's signature verification only looks at the key's expiration
date and not at the signature's timestamp, that is a bug.

-JimC

[t***@tuxteam.de]

Post by James Cloos
T> And just extending the keys' validity (as someone proposed in this
T> thread) seems a bad idea too, since the requirement for secure keys
T> evolves over time, as the NSA^H^H^H bad guys buy more GPUs.
The problem is that the point of a key's expiration time is that
signatures newer than that should fail, but all signatures made before
the expiration should verify.

Makes sense...

Post by James Cloos
So, if apt's signature verification only looks at the key's expiration
date and not at the signature's timestamp, that is a bug.

Hm. But a stern warning (along the lines "this signature isn't as secure
as it used to be") seems in order, no?

For the current case, what's needed most is some kind of workaround, since
an old apt can't be fixed retroactively, though.

Cheers
- -- tomás

[David Wright]

Post by t***@tuxteam.de

Post by James Cloos
T> And just extending the keys' validity (as someone proposed in this
T> thread) seems a bad idea too, since the requirement for secure keys
T> evolves over time, as the NSA^H^H^H bad guys buy more GPUs.
The problem is that the point of a key's expiration time is that
signatures newer than that should fail, but all signatures made before
the expiration should verify.

Makes sense...

Post by James Cloos
So, if apt's signature verification only looks at the key's expiration
date and not at the signature's timestamp, that is a bug.

Hm. But a stern warning (along the lines "this signature isn't as secure
as it used to be") seems in order, no?
For the current case, what's needed most is some kind of workaround, since
an old apt can't be fixed retroactively, though.

Well, I attempted to supply that in
https://lists.debian.org/debian-user/2018/06/msg00528.html
but I have no idea whether that would be achievable in docker
or not because the suggestion has had no follow-up.

BTW Reading your "Keys *have* to expire at some point, and you can't
re-sign archived packages with a fresh key", it's not clear why the
expired key can't be unexpired, ie given an expiration date in the
future, if it's known to be still good.

Cheers,
David.

[t***@tuxteam.de]

[...]

Post by David Wright
Well, I attempted to supply that in
https://lists.debian.org/debian-user/2018/06/msg00528.html
but I have no idea whether that would be achievable in docker
or not because the suggestion has had no follow-up.

I'm not the docker guy, and there are lots of "interesting" things
around, so I won't be the one. But I'm curious too...

Post by David Wright
BTW Reading your "Keys *have* to expire at some point, and you can't
re-sign archived packages with a fresh key", it's not clear why the
expired key can't be unexpired, ie given an expiration date in the
future, if it's known to be still good.

Yes, you're right: a GPG key's validity can be extended with a new
certificate (whether it's responsible to do is another thing, since
available computing power grows, *and* there has been more time to
hack at this key, its crypto, and for things to leak). So practically
speaking still keys have to expire at some point.

The only way out would be for an archive declared immutable to set
up an attestation service which signs (state-of-the-art) package
hashes with (state-of-the-art) signing procedures and refreshes
things periodically. Debian hasn't decided to set that up, a thing
I can understand.

Cheers
- -- tomás

[john doe]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[...]

Post by David Wright
Well, I attempted to supply that in
https://lists.debian.org/debian-user/2018/06/msg00528.html
but I have no idea whether that would be achievable in docker
or not because the suggestion has had no follow-up.

I'm not the docker guy, and there are lots of "interesting" things
around, so I won't be the one. But I'm curious too...

Post by David Wright
BTW Reading your "Keys *have* to expire at some point, and you can't
re-sign archived packages with a fresh key", it's not clear why the
expired key can't be unexpired, ie given an expiration date in the
future, if it's known to be still good.

Yes, you're right: a GPG key's validity can be extended with a new
certificate (whether it's responsible to do is another thing, since
available computing power grows, *and* there has been more time to
hack at this key, its crypto, and for things to leak). So practically
speaking still keys have to expire at some point.

Or maybe key transitioning could be an option:

https://www.apache.org/dev/key-transition.html

[Richard Hector]

Post by James Cloos
T> And just extending the keys' validity (as someone proposed in this
T> thread) seems a bad idea too, since the requirement for secure keys
T> evolves over time, as the NSA^H^H^H bad guys buy more GPUs.
The problem is that the point of a key's expiration time is that
signatures newer than that should fail, but all signatures made before
the expiration should verify.
So, if apt's signature verification only looks at the key's expiration
date and not at the signature's timestamp, that is a bug.

Disagree. If someone has a copy of the expired key (which is what
compromised means, right?), then they can fake the timestamp.

Richard