On 22.06.24 07:36, Soren Stoutner wrote:
1. Maintain a complete history of the source of Debian packages in Git, including their Git history. 2. Create the source packages in a controlled, centralized environment. 3. Eliminate the need for a fat client or any special Debian tooling on the DD’s end, and handle everything with standard Git tools.I find points 1 and 2 to be compelling. I don’t personally find point 3 to be compelling. I could take it or leave it in the final tag2upload implementation.
There is literally nothing for tag2upload to do when (3) falls away because these goals do not require dgit to tag *or* upload anything (beyond the simple, unsigned tagging and uploading that it already does, of course).
"dgit push-source" already does (1). Nothing to do here.To achieve (2) it could simply add a field to the .dsc with the hash of the git commit that it already pushes to its append-only archive. A separate service (to be queried by dak when it sees that field) could do the verification; said verification doesn't need to reproduce the same hash as the source upload, it only needs to test whether unpacking the result of "dgit build-source" produces mostly-the-same result as "apt-get source".
This approach would be completely uncontroversial AFAICT; it doesn't require any involvement by ftpmaster (beyond agreeing that adding the call-out to dak is a Good Idea, which should be reasonably uncontroversial), let alone a GR.
However.My personal goal, i.e. why I'm involved with these threads instead of leaning back with a bag of popcorn and letting everybody else hash it out, is to enable us, and our maintainers, to get rid of all that. Long term, that is.
We can argue all day about whether running dgit on a server is a single point of failure and thus less secure — or a consistently-maintained walled-off sandbox and thus more secure — than having every maintainer do it locally, but that's all a matter of conjecture and personal opinion and doesn't get us anywhere.
The point is that a workflow that doesn't exist at all beats both of these.When you can simply tag and push whatever it is that the maintainer (or the CI job on Salsa!) has successfully built and tested, thus requesting our builders to pull the tagged commit and run their equivalent of "debuild -b/-B" on it, all those intermediate steps that potentially allow an adversary to introduce an exploitable security hole simply go away.
We could then build the source packages separately (which by itself reduces the attack surface) – assuming that we can't simply stop making them, but that's a separate discussion.
-- -- regards -- -- Matthias Urlichs
OpenPGP_signature.asc
Description: OpenPGP digital signature
