On 23/06/18 06:39, James Cloos wrote:
>> "T" == 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
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
-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
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" == writes:
> >
> > T> And just extending the keys' validity (as someone proposed in this
> > T> thread) seems a bad idea too, since the requirement for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Jun 22, 2018 at 02:39:52PM -0400, James Cloos wrote:
> > "T" == 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
> "T" == 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
rhkra...@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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Jun 21, 2018 at 12:08:11AM +0200, Ansgar Burchardt wrote:
[...]
> 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
-BEGIN PGP SIGNED MESSAGE-
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
Adam Cecile 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
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
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
>
Oh nice, i'll check tomorrow or on Friday, thanks for this suggestion. Could
help a lot with third parties repo using weak timestamp also.
On June 20, 2018 7:37:19 PM GMT+02:00, Don Armstrong wrote:
>On Tue, 19 Jun 2018, Adam Cecile wrote:
>> On 06/19/2018 10:48 PM, Don Armstrong wrote:
>> > On
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
On 2018-06-20, wrote:
>
> On Wed, Jun 20, 2018 at 05:04:33PM +, Curt wrote:
>> On 2018-06-20, 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
Again, this is aim to disable Release timestamp validation, not related to gpg
:/
On June 20, 2018 7:04:33 PM GMT+02:00, Curt wrote:
>On 2018-06-20, wrote:
>>
>> On Wed, Jun 20, 2018 at 02:27:24PM +0200, Adam Cecile wrote:
>>
>> [...]
>>
>>> I still thinks it *sucks* to have no alternative
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jun 20, 2018 at 10:37:19AM -0700, Don Armstrong wrote:
[...]
> 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!
> In theory, [allow-weak=yes] should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jun 20, 2018 at 05:04:33PM +, Curt wrote:
> On 2018-06-20, 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
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.
On 2018-06-20, 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
Exactly, thank you.
Actually I've been contributing to Debian a lot some time ago and I don't think
I've been rude or something, so please show some respect.
On June 20, 2018 5:57:45 PM GMT+02:00, "Roberto C. Sánchez"
wrote:
>On Wed, Jun 20, 2018 at 11:16:46AM -0400, Greg Wooledge wrote:
>>
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
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 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.
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.
-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
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?
On 06/20/2018 02:17 PM, Greg Wooledge wrote:
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
On 06/20/2018 10:08 AM, john doe wrote:
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 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.
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.
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:
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
-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
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
-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
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
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.
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
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
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
That's a pity, don't you think so ? I think Debian should renew the archive
key, so we can still verify packages signatures.
On June 19, 2018 8:33:21 PM GMT+02:00, john doe wrote:
>On 6/19/2018 9:22 AM, Adam Cecile wrote:
>> Hello,
>>
>>
>> GPG key that signed the Squeeze repo is now expired.
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,
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.
Thanks in advance,
Adam.
Vineet Kumar [EMAIL PROTECTED] writes:
[snip]
I figured; which is why I didn't go and file it (and I figured that
Martin has the sense to check the existing bugs before filing a new
one). I usually keep up-to-date with a little loop I run manually every
so often:
gpg --list-keys | grep
also sprach Walt Mankowski [EMAIL PROTECTED] [2002.10.17.2231 +0200]:
Gnupg added a feature to do this in version 1.0.7, although
unfortunately it's poorly documented so not many people seem to know
about it. The option is --refresh-keys. In 1.0.7 it was only
documented in the release notes.
On Fri, Oct 18, 2002 at 12:31:01PM +0200, martin f krafft wrote:
Cool. But this is a rather time-consuming process. Is there a way to
have it refresh just the keys that are relevant as it verifies
a signature or decodes a message?
Not that I'm aware of. I just run --refresh-keys every night
* martin f krafft ([EMAIL PROTECTED]) [021016 08:52]:
i regularly get mails alerting me of my expired GPG key. but i have
a new (sub-)key uploaded to the keyservers since the day the old
expired. now i do realize that everyone who obtained my key from the
keyservers last year has that one
On Thu, Oct 17, 2002 at 12:50:05AM -0700, Vineet Kumar wrote:
Even better would be that gpg could re-fetch keys every so often even if
they haven't expired, to get new signatures, revocations, etc. That's
probably a worthy wishlist item.
This has already happened. Please bugview gnupg.
50 matches
Mail list logo
