On Fri, 2020-12-18 at 01:15 +, Paul Wise wrote:
> On Thu, Dec 17, 2020 at 10:03 AM Ansgar wrote:
> > (Bonus points if this keeps the original signature if
> > possible.)
>
> Two separate signatures is possible for Release+Release.gpg, just
> rename the latter to .old, but what can you do f
On Fri, 2020-12-18 at 01:15 +, Paul Wise wrote:
> On Thu, Dec 17, 2020 at 10:03 AM Ansgar wrote:
>
> > (Bonus points if this keeps the original signature if possible.)
>
> Two separate signatures is possible for Release+Release.gpg, just
> rename the latter to .old, but what can you do fo
On Thu, Dec 17, 2020 at 10:03 AM Ansgar wrote:
> (Bonus points if this keeps the original signature if possible.)
Two separate signatures is possible for Release+Release.gpg, just
rename the latter to .old, but what can you do for InRelease? Is it
possible to have multiple signatures in one b
Hi Ansgar!
On 12/17/20 11:02 AM, Ansgar wrote:
> Maybe the same could be done for archive.d.o?
>
> I might be interested to experiment with this as it seems reasonably
> small project to implement. :-)
That would be fantastic and a huge improvement in user experience.
Adrian
--
.''`. John P
On Thu, 2020-12-17 at 00:47 +0100, John Paul Adrian Glaubitz wrote:
> On 12/17/20 12:36 AM, Paul Wise wrote:
> > * snapshot could gain a re-signing service (#763419)
>
> That would be absolutely awesome. Whom do I throw my money at?
It doesn't seem too complicated to implement and could be devel
On 12/17/20 12:36 AM, Paul Wise wrote:
> * snapshot could gain a re-signing service (#763419)
That would be absolutely awesome. Whom do I throw my money at?
FWIW, snapshot.debian.org is a Godsent and extremely helpful when
working with different ports.
It's one of the best features we have in D
On Thu, 2020-12-17 at 00:03 +0100, Samuel Thibault wrote:
> Indeed, but one can use trusted=yes
That disables the OpenPGP checks completely rather than just ignoring
that the OpenPGP key is expired, so it is fairly unsafe and definitely
should be at minimum combined with TLS, which snapshot suppo
I spent so long fiddling with my chroot to try and find a repoistory with
an invalid release file but a valid key (I was looking in
archives.debian.org, not realizing that the valid-until field didn't exist
for any of them!), that it seems Paul has beaten me to the punch.
Whoops.
Calum
signatur
On Wed, 2020-12-16 at 19:06 +0100, John Paul Adrian Glaubitz wrote:
> Hi!
>
> For some reason, apt is ignoring the "check-valid-until" flag for me, no
> matter whether
> I'm passing that option in /etc/apt/sources.list or on the command line
> (see below).
>
> Does anyone have any idea what I'm m
On 12/16/20 11:53 PM, Paul Wise wrote:
> It seems to be saying that the 2019 ports archive signing key used for
> signing the snapshot URLs is expired, I don't think check-valid-until
> ignores key expiry.
Ah, the "check-valid-until" is for the signature of the Release file, but
not for the signin
Hello,
Paul Wise, le mer. 16 déc. 2020 22:53:45 +, a ecrit:
> On Wed, Dec 16, 2020 at 6:06 PM John Paul Adrian Glaubitz wrote:
> > Does anyone have any idea what I'm missing?
>
> It seems to be saying that the 2019 ports archive signing key used for
> signing the snapshot URLs is expired, I d
On Wed, Dec 16, 2020 at 6:06 PM John Paul Adrian Glaubitz wrote:
> Does anyone have any idea what I'm missing?
It seems to be saying that the 2019 ports archive signing key used for
signing the snapshot URLs is expired, I don't think check-valid-until
ignores key expiry. I'm not sure if there is
Hi!
For some reason, apt is ignoring the "check-valid-until" flag for me, no matter
whether
I'm passing that option in /etc/apt/sources.list or on the command line (see
below).
Does anyone have any idea what I'm missing?
PS: Please CC me, I'm not subscribed to debian-devel.
Thanks,
Adrian
==
13 matches
Mail list logo
