[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