Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Expired GPG keys of older release
2,286 views
Skip to first unread message
john doe
Jun 19, 2018, 2:40:04 PM6/19/18
to
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
> 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
john doe
Jun 19, 2018, 4:00:04 PM6/19/18
to
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
Don Armstrong
Jun 19, 2018, 4:50:03 PM6/19/18
to
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
> 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
Andy Smith
Jun 19, 2018, 9:00:03 PM6/19/18
to
Hello,
On Tue, Jun 19, 2018 at 09:52:42PM +0200, john doe wrote:
> Reading:
>
> https://wiki.debian.org/DebianKeyring
>
> you could try:
>
> "# 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
--
https://bitfolk.com/ -- No-nonsense VPS hosting
On Tue, Jun 19, 2018 at 09:52:42PM +0200, john doe wrote:
> Reading:
>
> https://wiki.debian.org/DebianKeyring
>
> you could try:
>
> "# Fetch a key from the keyring
> $ gpg --keyserver keyring.debian.org --recv-key 0xkeyid"
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
--
https://bitfolk.com/ -- No-nonsense VPS hosting
john doe
Jun 20, 2018, 2:50:03 AM6/20/18
to
On 6/19/2018 10:55 PM, Adam Cecile wrote:
> apt wouldn't install anything.
>
Can you give us the warning/error you're getting?
--
John Doe
> 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
>> 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.]
>>
> apt wouldn't install anything.
>
Can you give us the warning/error you're getting?
--
John Doe
to...@tuxteam.de
Jun 20, 2018, 3:30:04 AM6/20/18
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, Jun 19, 2018 at 09:22:22AM +0200, 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.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlsqAF4ACgkQBcgs9XrR2kY9tQCffzppTznd/U5l0HKW8q3uVya3
oCIAn14QUYeEe64pbqTEmXHe8ipWH/SN
=AG66
-----END PGP SIGNATURE-----
Hash: SHA1
On Tue, Jun 19, 2018 at 09:22:22AM +0200, 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.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlsqAF4ACgkQBcgs9XrR2kY9tQCffzppTznd/U5l0HKW8q3uVya3
oCIAn14QUYeEe64pbqTEmXHe8ipWH/SN
=AG66
-----END PGP SIGNATURE-----
john doe
Jun 20, 2018, 3:50:03 AM6/20/18
to
On 6/20/2018 8:47 AM, Adam Cecile wrote:
> ---> 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
> 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
to...@tuxteam.de
Jun 20, 2018, 4:00:03 AM6/20/18
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Jun 20, 2018 at 09:43:03AM +0200, john doe wrote:
Hash: SHA1
[...]
> 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
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)! :)
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
problem.
Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlsqB+cACgkQBcgs9XrR2ka90ACff8t+OZV4/2kc/4b4WyAT1eDV
Version: GnuPG v1.4.12 (GNU/Linux)
rzIAn34J0aj3Ye5IGS5EgCjmmy5pCm9U
=4R0W
-----END PGP SIGNATURE-----
john doe
Jun 20, 2018, 4:10:04 AM6/20/18
to
On 6/20/2018 9:55 AM, Adam Cecile wrote:
> 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
> 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
Greg Wooledge
Jun 20, 2018, 8:20:04 AM6/20/18
to
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.
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.
> ---> Running in 2300490ebb96
You didn't show the command that you typed. That makes it harder to
give solutions.
Is a warning. You can tell by the giant W.
> WARNING: The following packages cannot be authenticated!
> E: There are problems and -y was used without --force-yes
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.
Greg Wooledge
Jun 20, 2018, 11:10:04 AM6/20/18
to
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?
> Anyway, the command is apt-get install -y wget ca-certificates
What happens if you remove the -y option?
to...@tuxteam.de
Jun 20, 2018, 11:10:04 AM6/20/18
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
Version: GnuPG v1.4.12 (GNU/Linux)
oCkAni9O+K/nltB1KUIshFM/nId2U3p7
=S+Ta
-----END PGP SIGNATURE-----
Roberto C. Sánchez
Jun 20, 2018, 11:20:04 AM6/20/18
to
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
Greg Wooledge
Jun 20, 2018, 11:20:04 AM6/20/18
to
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
> The output appears to be from a step in a Dockerfile.
shouldn't require hand-holding from non-Docker mailing lists.
Or IRC channels.
Dan Purgert
Jun 20, 2018, 12:00:04 PM6/20/18
to
--
|_|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
Roberto C. Sánchez
Jun 20, 2018, 12:00:04 PM6/20/18
to
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.
Curt
Jun 20, 2018, 1:10:04 PM6/20/18
to
On 2018-06-20, <to...@tuxteam.de> <to...@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?
>
> 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
>
>
-o Acquire::Check-Valid-Until=false update
Don Armstrong
Jun 20, 2018, 1:40:04 PM6/20/18
to
On Tue, 19 Jun 2018, 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.]
> >
> > > 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
> wouldn't install anything.
actually tests the time.
In theory, [allow-weak=yes] should work, but I haven't actually tested
this.
You are educated when you have the ability to listen to almost
anything without losing your temper or self-confidence.
-- Robert Frost
to...@tuxteam.de
Jun 20, 2018, 3:20:04 PM6/20/18
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA1
On Wed, Jun 20, 2018 at 05:04:33PM +0000, Curt wrote:
> On 2018-06-20, <to...@tuxteam.de> <to...@tuxteam.de> wrote:
[...]
> On 2018-06-20, <to...@tuxteam.de> <to...@tuxteam.de> wrote:
> What does this do?
>
> -o Acquire::Check-Valid-Until=false update
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
Version: GnuPG v1.4.12 (GNU/Linux)
xeQAnA2VScFDvs6LXqPFWtTgiDsgQm9X
=8XsS
-----END PGP SIGNATURE-----
to...@tuxteam.de
Jun 20, 2018, 3:30:04 PM6/20/18
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Jun 20, 2018 at 10:37:19AM -0700, Don Armstrong wrote:
Hash: SHA1
[...]
> Hrm; it looks like apt has its own internal version of gpgv which
> actually tests the time.
Thanks!
> In theory, [allow-weak=yes] should work, but I haven't actually tested
> this.
expired key, would you agree that it'd be useful to have an option
to accept such a key?
Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
l38AniWzwgA72Ej8X1GVE/MDIMHvBjVL
=jbKR
-----END PGP SIGNATURE-----
Curt
Jun 20, 2018, 4:00:04 PM6/20/18
to
On 2018-06-20, <to...@tuxteam.de> <to...@tuxteam.de> wrote:
>
> On Wed, Jun 20, 2018 at 05:04:33PM +0000, Curt wrote:
>> On 2018-06-20, <to...@tuxteam.de> <to...@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
>
> On Wed, Jun 20, 2018 at 05:04:33PM +0000, Curt wrote:
>> On 2018-06-20, <to...@tuxteam.de> <to...@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
>
>
to another question (in another thread).
What we need is the same kind of parameter for key expiration (or
something).
Thanks.
Don Armstrong
Jun 20, 2018, 4:10:04 PM6/20/18
to
On Wed, 20 Jun 2018, to...@tuxteam.de wrote:
> 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
> 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?
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.
life's not a paragraph
And death i think is no parenthesis
-- e.e. cummings "Four VII" _is 5_
Ansgar Burchardt
Jun 20, 2018, 6:30:04 PM6/20/18
to
<to...@tuxteam.de> writes:
> On Wed, Jun 20, 2018 at 10:37:19AM -0700, Don Armstrong wrote:
>> 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
> On Wed, Jun 20, 2018 at 10:37:19AM -0700, Don Armstrong wrote:
>> 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?
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
David Wright
Jun 20, 2018, 10:00:05 PM6/20/18
to
then check the files' digests "manually" rather than by using
apt-get, then install the downloaded files with dpkg -i.
Cheers,
David.
Ben Finney
Jun 20, 2018, 10:30:04 PM6/20/18
to
Adam Cecile <adam....@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
> I still thinks it *sucks* to have no alternative then considering
> packages signed by an expired key like unsigned packages....
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
to...@tuxteam.de
Jun 21, 2018, 3:00:04 AM6/21/18
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, Jun 21, 2018 at 12:08:11AM +0200, Ansgar Burchardt wrote:
Hash: SHA1
[...]
> But a user of an archived Debian release wouldn't get an updated apt
> which includes this new option. :-)
one "disregard all security" is the best of those. Perhaps not.
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
NOsAn2QaFk/4FJcIA+Hw57dO3MLqUnda
=AK48
-----END PGP SIGNATURE-----
to...@tuxteam.de
Jun 21, 2018, 3:00:04 AM6/21/18
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA1
On Wed, Jun 20, 2018 at 01:06:02PM -0700, Don Armstrong wrote:
> On Wed, 20 Jun 2018, to...@tuxteam.de wrote:
> > 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
> On Wed, 20 Jun 2018, to...@tuxteam.de wrote:
> > 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.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlsrS2cACgkQBcgs9XrR2kayEgCfREHbAQtIs+TCYGxiim4eXocy
Version: GnuPG v1.4.12 (GNU/Linux)
IOsAmgO1iOdreJVvxstzxA/IdfMOhE6V
=HgoW
-----END PGP SIGNATURE-----
rhkr...@gmail.com
Jun 21, 2018, 8:20:04 AM6/21/18
to
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
> 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.
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 ;-)
Ben Finney
Jun 21, 2018, 7:10:03 PM6/21/18
to
rhkr...@gmail.com writes:
> 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?
The difference is in the degree of confidence that can be expected. When
> 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?
the key was created, the key's creator thereby expressed the upper bound
of duration for that confidence remaining acceptably high.
--
\ “Say what you will about the Ten Commandments, you must always |
`\ come back to the pleasant fact that there are only ten of |
_o__) them.” —Henry L. Mencken |
Ben Finney
James Cloos
Jun 22, 2018, 2:50:04 PM6/22/18
to
>>>>> "T" == <to...@tuxteam.de> writes:
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
--
James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
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
--
James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
to...@tuxteam.de
Jun 22, 2018, 3:20:04 PM6/22/18
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA1
On Fri, Jun 22, 2018 at 02:39:52PM -0400, James Cloos wrote:
> >>>>> "T" == <to...@tuxteam.de> writes:
>
> 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...
> >>>>> "T" == <to...@tuxteam.de> writes:
>
> 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.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
QzIAnRbBCpIyFXPsR4JC9H7VtI99moyA
=UFsZ
-----END PGP SIGNATURE-----
David Wright
Jun 23, 2018, 12:50:03 AM6/23/18
to
On Fri 22 Jun 2018 at 21:12:51 (+0200), to...@tuxteam.de wrote:
> On Fri, Jun 22, 2018 at 02:39:52PM -0400, James Cloos wrote:
> > >>>>> "T" == <to...@tuxteam.de> writes:
> >
> > 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...
>
> > 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
> On Fri, Jun 22, 2018 at 02:39:52PM -0400, James Cloos wrote:
> > >>>>> "T" == <to...@tuxteam.de> writes:
> >
> > 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...
>
> > 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.
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.
to...@tuxteam.de
Jun 23, 2018, 3:00:04 AM6/23/18
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA1
On Fri, Jun 22, 2018 at 11:48:00PM -0500, David Wright wrote:
> On Fri 22 Jun 2018 at 21:12:51 (+0200), to...@tuxteam.de wrote:
[...]
> On Fri 22 Jun 2018 at 21:12:51 (+0200), to...@tuxteam.de wrote:
> 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.
around, so I won't be the one. But I'm curious too...
> 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.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
pZsAn0Y3ktHGU9QJaKveKZSEUfr0ZIQb
=5MG1
-----END PGP SIGNATURE-----
john doe
Jun 23, 2018, 4:50:03 AM6/23/18
to
On 6/23/2018 8:58 AM, to...@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, Jun 22, 2018 at 11:48:00PM -0500, David Wright wrote:
>> On Fri 22 Jun 2018 at 21:12:51 (+0200), to...@tuxteam.de wrote:
>
> [...]
>
>> 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...
>
>> 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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, Jun 22, 2018 at 11:48:00PM -0500, David Wright wrote:
>> On Fri 22 Jun 2018 at 21:12:51 (+0200), to...@tuxteam.de wrote:
>
> [...]
>
>> 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...
>
>> 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.
>
https://www.apache.org/dev/key-transition.html
--
John Doe
Richard Hector
Jun 24, 2018, 8:00:04 PM6/24/18
to
On 23/06/18 06:39, James Cloos wrote:
>>>>>> "T" == <to...@tuxteam.de> writes:
>
> 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
>>>>>> "T" == <to...@tuxteam.de> writes:
>
> 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.
compromised means, right?), then they can fake the timestamp.
Richard
0 new messages