[pacman-dev] [PATCH] Disable embedded signatures by default

Allan McRae allan at archlinux.org
Fri Aug 28 04:37:20 UTC 2020


On 27/8/20 10:26 am, Anatol Pomozov wrote:
> Hi
> 
> On Mon, Aug 10, 2020 at 2:45 PM Eli Schwartz <eschwartz at archlinux.org> wrote:
>>
>> On 8/10/20 5:34 PM, Anatol Pomozov wrote:
>>> Switching from embedded to detached signatures is a big change. This
>>> feature needs to be thoroughly tested before embedded signatures will be
>>> completely removed from the database.
>>>
>>> To help with detached signatures testing we enable it by default. But in
>>> case if an user needs to go back to embedded signatures we add a config
>>> option to reenable it - "UseEmbeddedSignatures".
>> What is the purpose of this? Either signature source should be
>> equivalent,
> 
> Indeed the signatures are equivalent. The only difference whether they
> are stored inside the database file or as *.sig next to the packages
> itself.
> 
>> and you should be able to trivially test this by creating a
>> repo with unsigned packages, then bulk-signing the packages after they
>> were repo-added. I don't believe that pacman should include such an
>> end-user option purely to double-check whether a current feature
>> actually works.
> 
> The purpose of the change is to start using the detached signatures
> codepath. The detached signatures are shipped with repos for a long
> time and pacman can handle it. Now it is time to actually enable it by
> default.
> 
>  "UseEmbeddedSignatures" option has been added as a fallback plan in
> case we find that the detached signatures codepath is broken. Do you
> think this is too much hassle and we should just start using detached
> signatures by default without any fallback config option?
> 

I think we should test using detached signatures, and release without
pacman having a fallback option in and of itself.  The fallback option
should be in repo-add, whether it adds the signatures to the database or
not.

>> This is the right approach, yeah. I was thinking we'd wait until pacman
>> 6.1 before stopping the signature embedding, to provide a transition
>> period for people depending on SigLevel = Required (which should be
>> everyone, and certainly includes Arch!) to upgrade to 6.x before
>> repo-add starts generating databases useless to pacman 5.x
> 
> There are 2 sets of changes that need to be done:
> 1) make pacman to use detached signatures instead of embedded ones
> 2) change "repo-add" to avoid adding embedded signatures
> 
> We should release changes for #1 first, test it, make sure that
> detached signatures fully work (while dbs still have pacman
> 5.x-compatible embedded sigs). And only then release #2 to get smaller
> databases compatible with pacman version >= 6.0.
> 
> I was thinking #1 can be released with 6.0 and #2 with 6.1.

I was thinking #2 would be an option to repo-add.  I'm looking at making
signature embedding only occur with the "--add-signatures" option (or
whatever I decide to call it).  Arch would need to patch devtools to use
this option.  They would then make a News announcement about the need to
have pacman-6.0 installed after 3-6 months and stop repo-add including
signatures.

However, I think pacman should always use the signatures in the database
if they are present.  Particularly if they are not embedded by default.

So to actually test the detached signature path, I am thinking it best
to tag 6.0.0beta1, make a package from that tag with a patch to enable
using detached signatures as a priority.  While that is not an ideal
approach to testing, I think the current code path is well tested, and
this should be a reasonably trivial patch.

Allan


More information about the pacman-dev mailing list