[clug] Re-signing Debian Packages

[Tony Lewis]

On 13/1/23 13:34, jm via linux wrote:
> 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.

https://wiki.debian.org/SecureApt seems like a good place to start.

I had a quick poke, but had to stop because I have a deadline today.  In 
brief, here's how I'd tackle it.

Please note that this is speculative, I haven't done due diligence on 
this.  Tread carefully and make sure you're comfortable with the 
integrity of each step.

Find the public key of the expired repo.  It should be in the keyring of 
one of your servers.  Maybe just copy that keyring into your working dir.

Use the keyring to verify the signature of `Release` - something like 
(BUT PLEASE VERIFY, I haven't looked closely at this):

     gpg --trustdb-name ./my-copy-of-the-keyring Release.gpg Release

I would think that if you're doing this right, then you can trust the 
hashes in this file, and this will include Packages files.  If you're 
doing it right, you hopefully will get a "The key is expired but the 
signature checks out".  If you don't get that, then DON'T TRUST THE 
RESULT.  If you get a "the key is expired, I can't check it" then maybe 
set up a VM and set the clock back a few years and validate that way.  
It's key that you get positive validation that the signature is right.

Now, generate a new key if you haven't already.  Something like the 
following.  When you do this for real, take care to use meaningful values:

     mkdir -m700 newkeyring

     gpg --homedir ./newkeyring --full-gen-key

Now probably all you need to do is re-sign the Release with a valid key, 
creating a new Release.gpg.  If the public key is distributed to the 
users then they should be able to trust everything.  I don't think 
you'll need to verify each package (though I might have hinted at it 
previously).  Sign it thusly:

     gpg --homedir ./newkeyring --detach-sign --armor Release

This will create Release.asc, which is your new replacement for 
Release.gpg.  Test it:

     gpg --homedir ./newkeyring --verify Release.asc Release

I stress again, do your diligence on this.  I'm just hacking around.

Tony


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