On 27/8/20 10:26 am, Anatol Pomozov wrote: > Hi > > On Mon, Aug 10, 2020 at 2:45 PM Eli Schwartz <eschwa...@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
