Re: scratch/package-security bcde5f8 2/2: Support expiration of metadata by package archives

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> @@ -449,6 +458,7 @@ synchronously."
>>  (define-error 'bad-size "Package size mismatch" 'package-error)
>>  (define-error 'bad-signature "Failed to verify signature" 'package-error)
>>  (define-error 'bad-checksum "Failed to verify checksum" 'package-error)
>> +(define-error 'bad-timestamp "Failed to verify timestamp" 'package-error)
>
> Hmm, these errors should all have a `package-` prefix.

Agreed.  But I was worried that changing it would break some third-party
packages.  Do we have a way to work around that?  Or do you think this
is not something we need to worry all that much about?

[...]
> Hmm... I think you forgot the `error` in this
> `condition-case-unless-debug` (i.e. the way you wrote it, it will catch
> all `lwarn` errors).

Indeed, thanks.  I'll fix it.

>> +(defun package--parse-valid-until-from-buffer (name)
>> +  "Find and return \"Valid-Until\" header for archive NAME."
>> +  (package--parse-header-from-buffer "Valid-Until" name))
>
> It would be easier for the ELPA archives is to use a "validity duration"
> header, since it could then be constant.

FWIW, I feel like the current way is more human readable: I immediately
know the exact time and date when it will expire.

Also, we don't need to have a number like "7" where it is not
immediately clear if it means hours, weeks or days, and we don't need to
write a parser for "7 days", "1 week", etc. but can just reuse existing
well-tested parsers.

But of course you can just reply that you would rather just immediately
know how long it is until these files normally expire without having to
calculate it.  So I guess we can go around in circles about this.  Hmm.

( BTW, the name and semantics of this field is based on APT:
  https://wiki.debian.org/DebianRepository/Format#Date.2C_Valid-Until )

> Other that that, LGTM,

Thanks for reviewing.