Hi Julian, David, all, First of all I am terribly sorry that I didn't reply earlier to your feedback. Resuming work related to apt-verify has been on my todo-list since I did the ITP and upload a couple of weeks ago, and I checked out for christmas after doing the ITP upload and haven't done anything more. I still haven't gotten back to this properly, and discussing your concerns was the main activity I wanted to get back to you on. I'm now subscribed to the deity list and is happy to discuss further. Perhaps it will help to understand the problem that apt-verify is intended to help facilitate against: mis-use of the archive OpenPGP key. Now there is no protection against anyone knowing the private key of an APT archive to perform a man-in-the-middle attack on users that use http:// as the transport mechanism against a server with a package pool. That's the default setup for most users. There are projects like Sigstore and Sigsum that help address this problem by making OpenPGP private key use auditable by committing signed content to a tamper-proof publicly verifiable log. I'm sure you know about Certificate Transparency which achieves this for HTTPS WebPKI CA private keys. Sigstore and Sigsum offers this functionality for any use-case. They aren't perfect and there is more to do here, but at least they provide some improvement to the current state of the art. There are many things to discuss, both on a high level and low level, both technical and procedural/social issues, so maybe it can help to get questions and topics up on the table. I will likely be at FOSDEM if in-person discussions can help. - Do you have something to comment on the problem statement above? Is the problem well understood and agreed on? Even if solutions can differ. - Are you interested in working on solving this problem in apt? If not, what concerns do you have about others working on solving this problem? - What is a good interface from apt to plugins that offer improved verification of data? My experience is that the Release/InRelease file combo that apt is going to use is needed as input, but it would help to also get the apt repository URL and some other meta-data. This could be passed as environment variables, parameters, data in file, or some inter-process protocol. - Regarding your concerns about apt-verify I would like to understand more. Is it the naming of the package, its use of /etc/apt/ namespace (used by other packages too), its use of the apt::key::gpgvcommand interface (used by other packages too), or something else you object to? I'm open to discuss and changing the name and the other issues if that would resolve your concerns. I'm reaching out to hope and restore some confidence and trust to work together on solving things. I'm not merried to any particular solutions or outcome, as long as we get to ship solutions that address the problem statement above. /Simon
Attachment:
signature.asc
Description: PGP signature