[clug] Re-signing Debian Packages

jm jeffm at ghostgun.com
Thu Jan 12 23:09:35 UTC 2023


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.


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

Jeff.




More information about the linux mailing list