Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #196779 > unrolled thread

Re: Expired GPG keys of older release

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Expired GPG keys of older release john doe <johndoe65534@mail.com> - 2018-06-19 20:40 +0200
    Re: Expired GPG keys of older release john doe <johndoe65534@mail.com> - 2018-06-19 22:00 +0200
    Re: Expired GPG keys of older release Don Armstrong <don@debian.org> - 2018-06-19 22:50 +0200
      Re: Expired GPG keys of older release john doe <johndoe65534@mail.com> - 2018-06-20 08:50 +0200
        Re: Expired GPG keys of older release john doe <johndoe65534@mail.com> - 2018-06-20 09:50 +0200
          Re: Expired GPG keys of older release <tomas@tuxteam.de> - 2018-06-20 10:00 +0200
          Re: Expired GPG keys of older release john doe <johndoe65534@mail.com> - 2018-06-20 10:10 +0200
        Re: Expired GPG keys of older release Greg Wooledge <wooledg@eeg.ccf.org> - 2018-06-20 14:20 +0200
          Re: Expired GPG keys of older release <tomas@tuxteam.de> - 2018-06-20 17:10 +0200
            Re: Expired GPG keys of older release Curt <curty@free.fr> - 2018-06-20 19:10 +0200
              Re: Expired GPG keys of older release <tomas@tuxteam.de> - 2018-06-20 21:20 +0200
                Re: Expired GPG keys of older release Curt <curty@free.fr> - 2018-06-20 22:00 +0200
          Re: Expired GPG keys of older release Greg Wooledge <wooledg@eeg.ccf.org> - 2018-06-20 17:10 +0200
            Re: Expired GPG keys of older release Roberto C. Sánchez <roberto@debian.org> - 2018-06-20 17:20 +0200
              Re: Expired GPG keys of older release Greg Wooledge <wooledg@eeg.ccf.org> - 2018-06-20 17:20 +0200
                Re: Expired GPG keys of older release Roberto C. Sánchez <roberto@debian.org> - 2018-06-20 18:00 +0200
                Re: Expired GPG keys of older release Dan Purgert <dan@djph.net> - 2018-06-20 18:00 +0200
              Re: Expired GPG keys of older release David Wright <deblis@lionunicorn.co.uk> - 2018-06-21 04:00 +0200
          Re: Expired GPG keys of older release Ben Finney <bignose@debian.org> - 2018-06-21 04:30 +0200
            Re: Expired GPG keys of older release rhkramer@gmail.com - 2018-06-21 14:20 +0200
              Re: Expired GPG keys of older release Ben Finney <bignose@debian.org> - 2018-06-22 01:10 +0200
      Re: Expired GPG keys of older release Don Armstrong <don@debian.org> - 2018-06-20 19:40 +0200
        Re: Expired GPG keys of older release <tomas@tuxteam.de> - 2018-06-20 21:30 +0200
          Re: Expired GPG keys of older release Don Armstrong <don@debian.org> - 2018-06-20 22:10 +0200
            Re: Expired GPG keys of older release <tomas@tuxteam.de> - 2018-06-21 09:00 +0200
          Re: Expired GPG keys of older release Ansgar Burchardt <"Ansgar Burchardt"@43-1.org> - 2018-06-21 00:30 +0200
            Re: Expired GPG keys of older release <tomas@tuxteam.de> - 2018-06-21 09:00 +0200

Page 1 of 2  [1] 2  Next page →

#196779 — Re: Expired GPG keys of older release

On 6/19/2018 9:22 AM, Adam Cecile wrote:
> 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

[toc] | [next] | [standalone]

#196781

On 6/19/2018 8:33 PM, john doe wrote:
> On 6/19/2018 9:22 AM, Adam Cecile wrote:
>> 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! :)

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#196786

On Tue, 19 Jun 2018, Adam Cecile wrote:
> 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.]

-- 
Don Armstrong                      https://www.donarmstrong.com

Where I sleep at night, is this important compared to what I read
during the day? What do you think defines me? Where I slept or what I
did all day?
 -- Thomas Van Orden of Van Orden v. Perry

[toc] | [prev] | [next] | [standalone]

#196790

On 6/19/2018 10:55 PM, Adam Cecile wrote:
> On 06/19/2018 10:48 PM, Don Armstrong wrote:
>> On Tue, 19 Jun 2018, Adam Cecile wrote:
>>> 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

[toc] | [prev] | [next] | [standalone]

#196793

On 6/20/2018 8:47 AM, Adam Cecile wrote:
> On 06/20/2018 08:39 AM, john doe wrote:
>> On 6/19/2018 10:55 PM, Adam Cecile wrote:
>>> On 06/19/2018 10:48 PM, Don Armstrong wrote:
>>>> On Tue, 19 Jun 2018, Adam Cecile wrote:
>>>>> 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...
> The following extra packages will be installed:
>    libssl0.9.8 openssl
> The following NEW packages will be installed:
>    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


-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#196794

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

[...]

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

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

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

> For sake of completeness:
>   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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsqB+cACgkQBcgs9XrR2ka90ACff8t+OZV4/2kc/4b4WyAT1eDV
rzIAn34J0aj3Ye5IGS5EgCjmmy5pCm9U
=4R0W
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#196795

On 6/20/2018 9:55 AM, Adam Cecile wrote:
> On 06/20/2018 09:43 AM, john doe wrote:
>> On 6/20/2018 8:47 AM, Adam Cecile wrote:
>>> On 06/20/2018 08:39 AM, john doe wrote:
>>>> On 6/19/2018 10:55 PM, Adam Cecile wrote:
>>>>> On 06/19/2018 10:48 PM, Don Armstrong wrote:
>>>>>> On Tue, 19 Jun 2018, Adam Cecile wrote:
>>>>>>> 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...
>>> The following extra packages will be installed:
>>>    libssl0.9.8 openssl
>>> The following NEW packages will be installed:
>>>    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
>>
>>
> 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

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#196798

On Wed, Jun 20, 2018 at 08:47:39AM +0200, Adam Cecile wrote:
>  ---> 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.

[toc] | [prev] | [next] | [standalone]

#196800

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsqbecACgkQBcgs9XrR2kYAhQCfVsSG+LOLDTSmGAzcSM71b1td
oCkAni9O+K/nltB1KUIshFM/nId2U3p7
=S+Ta
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#196806

On 2018-06-20, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
> 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
>
>

What does this do?

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

[toc] | [prev] | [next] | [standalone]

#196808

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jun 20, 2018 at 05:04:33PM +0000, Curt wrote:
> On 2018-06-20, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:

[...]

> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsqqBAACgkQBcgs9XrR2kZu3gCeL7DH2mF6YaHKtp7OLUB5bbSx
xeQAnA2VScFDvs6LXqPFWtTgiDsgQm9X
=8XsS
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#196810

On 2018-06-20, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
> On Wed, Jun 20, 2018 at 05:04:33PM +0000, Curt wrote:
>> On 2018-06-20, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
> [...]
>
>> 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.

[toc] | [prev] | [next] | [standalone]

#196801

On Wed, Jun 20, 2018 at 02:27:24PM +0200, Adam Cecile wrote:
> Anyway, the command is apt-get install -y wget ca-certificates

What happens if you remove the -y option?

[toc] | [prev] | [next] | [standalone]

#196802

On Wed, Jun 20, 2018 at 11:04:01AM -0400, Greg Wooledge wrote:
> On Wed, Jun 20, 2018 at 02:27:24PM +0200, Adam Cecile wrote:
> > 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

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#196803

On Wed, Jun 20, 2018 at 11:12:18AM -0400, Roberto C. Sánchez wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#196804

On Wed, Jun 20, 2018 at 11:16:46AM -0400, Greg Wooledge wrote:
> On Wed, Jun 20, 2018 at 11:12:18AM -0400, Roberto C. Sánchez wrote:
> > 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

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#196805

Greg Wooledge wrote:
> On Wed, Jun 20, 2018 at 11:12:18AM -0400, Roberto C. Sánchez wrote:
>> 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?


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#196822

On Wed 20 Jun 2018 at 11:12:18 (-0400), Roberto C. Sánchez wrote:
> On Wed, Jun 20, 2018 at 11:04:01AM -0400, Greg Wooledge wrote:
> > On Wed, Jun 20, 2018 at 02:27:24PM +0200, Adam Cecile wrote:
> > > 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.

[toc] | [prev] | [next] | [standalone]

#196823

Adam Cecile <adam.cecile@hitec.lu> writes:

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

The key is expired, which means its creator no longer claims it as their
key. Any signatures found using that key, can no longer be known to be
made by the person who nominally owns that key.

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

-- 
 \     “I have had a perfectly wonderful evening, but this wasn't it.” |
  `\                                                     —Groucho Marx |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#196835

On Wednesday, June 20, 2018 10:25:25 PM Ben Finney wrote:
> 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 ;-)

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web