[clug] Re-signing Debian Packages

[Ambrose Andrews]

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.
>
Given you have stated your constraints and choices, I will hold my tongue.

As for the signing for the last decade at least it's not that individual 
packages are signed but a release file containing hashes of the packages 
in the archive.

You might need to make your own local (or enterprise specific) archive 
using a tool like debmirror or apt-move (or something more recent 
probably), including a signed release file with a key of your own.  This 
key would want to be added to the all the machines in ways documented in 
the Debian wiki: 
https://wiki.debian.org/DebianRepository/UseThirdParty.  The details of 
this do depend I think on how old is the release you are stuck on.  
There was previously apt-key which is deprecated but has a manpage.

There is a tool called aptly which might be helpful for creating a 
custom repository / mirror. https://www.aptly.info/

   -AA.



>> 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.
>
>
-- 
--https://social.librem.one/@znalo
--LPO box 8274, ANU, ACT 0200 Australia