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

[Stefan Monnier]

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

I thought you just preferred to "go with the flow", which would make a
lot of sense (i.e. keep the renaming for a separate patch).

> Do we have a way to work around that?

Not really, no.  You could do

    (define-error 'bad-timestamp "Failed to verify timestamp" 'package-error)
    (define-error 'package-bad-timestamp "Failed to verify timestamp" 
'bad-timestamp)

so packages which catch `bad-timestamp` will also catch
`package-bad-timestamp`, but then when package.el will presumably fail
to catch the `bad-timestamp` raised by other packages.  And we don't
have a mechanism in place to mark an error like `bad-timestamp` as obsolete.

> Or do you think this is not something we need to worry all that
> much about?

I wouldn't worry about it, indeed.

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

That's fairly secondary to me.

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

Ah... I assumed we could reuse existing code for that.  If not, then
it's definitely not worth the trouble.


        Stefan