[clug] Re-signing Debian Packages

[jm]

On 13/1/23 13:26, Tony Lewis via linux wrote:
>
> On 13/1/23 10:09, jm via linux wrote:
>> On 13/1/23 09:34, Tony Lewis via linux wrote:
>>> From a security view, perhaps it would be the least worst to 
>>> validate against the old expired key first before resigning with the 
>>> new key.  Sorry I don't have much experience with package signing 
>>> itself.
>>>
>> That's what I'd like to tell it to do. Keep using the old key. Just 
>> pretend it hasn't expired. However, I don't see an option for that 
>> the closest I've been able to get to work is adding "[trusted=yes]" 
>> to the /etc/apt/source.list file which ignores it.
>
> That's a bit different to what I had in mind.  I meant rather that as 
> a one-off diligent process, you manually validate the package against 
> the key, but ignoring expiry, and in that process you resign with a 
> different key (and maybe hosting in your own repo that gives packages 
> signed with that key.  After that, just use your key and you are back 
> to operating as close to standard practices as possible.
>
If you know how I'd like to investigate that.

> The [trusted=yes] solution seems significantly more evil to me. It 
> means any package dropped into your repo, with malicious intent or 
> not, gets a free pass forever.  By contrast resigning once (as above) 
> or setting a config for users that says "verify using old key but 
> ignore expiry" is much less risk, as it looks like you've been using 
> these packages for years or decades, and continuing to use them is 
> probably no change to your risk profile (other than them not getting 
> patches, a separate issue)
>
Yes, that's the problem which is why I asked about resigning the packages.

Excuse the terseness trying to get to reading the links from the other 
emails before the end of the day.

Jeff.