Hi, Quoting Dima Kogan (2023-03-02 07:00:13) > >> Since apt only supports a single keyring file and directory, respectively, > >> you can not use this option to pass multiple files and/or directories. > > I did see that note. But for most other stuff in /etc the main config > lives in /etc/thing, and optional extra stuff lives in /etc/thing.d/ so > my (incorrect!) assumption was that the main keys live in > /etc/apt/trusted.gpg and if I added my extra thing to > /etc/apt/trusted.gpg.d/ then I'd have the full set of stuff. If we > transitioned to /etc/apt/trusted.gpg.d/ being the main set of keys, we > REALLY should delete /etc/apt/trusted.gpg to avoid any confusion.
if I remember discussions in #debian-apt correctly, then moving away from /etc/apt/trusted.gpg is indeed the plan. > I do think --keyring can be useful if we change what it does. mmdebstrap can > gather all the keys in all the --keyring arguments, put them all into a new > directory, feed that to Dir::Etc::TrustedParts, and put that into > /etc/apt/trusted.gpg.d/ in the final chroot. You can say that without any > --keyring arguments it uses /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/, > but with any --keyring you have to specify them all explicitly, including > /etc/apt/.... But that is not how --keyring works in debootstrap. As I mentioned in my last mail, I probably should never have added the --keyring argument. After this bug, I'm thinking about deprecating this option and printing a warning if somebody uses it. mmdebstrap tries to be a 90% debootstrap drop-in replacement and debootstrap has the --keyring argument which allows you to pass a keyring that will be used to verify the downloaded Release file but which will *not* be permanently stored in the chroot. That's why the mmdebstrap --keyring argument doesn't store the keys permanently either. So the --keyring argument is only a convenience option and indeed its functionality can be achieved using other options as well. Its main reason for existance is to make debootstrap users happy. In your case, since you have multiple repositories, you cannot use debootstrap but that's also why the limitation that only one keyring can be passed is not a problem for people who use the --keyring argument as they would with debootstrap because they do not use multiple repositories anyways. If you do use multiple repositories, don't use keyring but signed-by as the documentation of --keyring now points out. > > You can create a directory and copy your keys into it, yes. But the docs > > for --keyring also suggest that you use signed-by instead. Is that not a > > better solution than copying keys from debian-archive-keyring around? If > > you use signed-by you also do not need the --keyring argument anymore. > > I saw that too. I had a reason to not do that, but I now think that > reason is wrong. I was concerned that I could have different keys for > signing the repository (InRelease file) and for signing the various > packages inside it. But the only key I care about here is the > repo-signing key, so that signed-by would have been just fine, I think. > > I like your documentation patch. And now that I realize that the > repository key is the main one to care about, maybe --keyring isn't needed > most of the time, as you say. If you think that there is no more to handle in this bug, please close it. Thanks! cheers, josch
