[clug] Re-signing Debian Packages

[Tony Lewis]

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.

>
>
>> Is this an ongoing issue (i.e. these legacy systems will endure) or 
>> part of migrating off to a newer version?  If the former, then just 
>> keep in mind how you did it, so that before your new key expires, you 
>> could make a decision to re-resign with a new new key. 
>
>
> Ongoing enduring legacy system with no path to move way from the old 
> distro. Worse, in this context, more systems are being added. We have 
> an internal mirror we use so none of the traffic is out on the 
> Internet. Letting use get away with the less than ideal 
> "[trusted=yes]". Hence, I would ideally like something which would 
> simply ignore the expiry or let me easily resign the packages with our 
> own keys which we can then deploy. It's really a lesser of two evils 
> situation.

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)

Tony