control: tag -1 + confirmed upstream control: forwarded -1 https://propellor.branchable.com/todo/Apt.trustsKey_should_not_invoke_apt-key/
Hello, On Sat 25 Aug 2018 at 09:29PM -0300, David Bremner wrote: > Prior to upstream commit 1d39a530, Propellor did something like > > (proc "gpg" ["--no-default-keyring", "--keyring", f, "--import", "-"]) > > which created a a gpg keyring, and the format of those changed at some > point to something that apt-key does not support. To fix this breakage > Propeller switched to calling apt-key add, which works, for now, but > it complains, and will probably break at some point. > > According to the apt-key manpage > > "Instead of using this [add] command a keyring should be placed > directly in the /etc/apt/trusted.gpg.d/ directory with a > descriptive name and either "gpg" or "asc" as file extension." > > As far as I can tell, if the privdata is in the right format (which is > always an issue with propellor), no call to gpg should be necessary, > and trustsKey could be implimented e.g. with File.hasPrivContent. What we are talking about here are public keys, and in fact Apt.trustsKey does not work with any privcontent, but simply with a String, i.e., it implicitly expects the output of `gpg -a --export` right there in your config.hs. So Apt.trustsKey should be implemented with File.hasContents. -- Sean Whitton
signature.asc
Description: PGP signature
