Re: Security review of tag2upload
Louis-Philippe Véronneau <pollo@debian.org> writes:
> On 2024-06-16 2 h 23 p.m., Russ Allbery wrote:
>> For the existing source package signatures, a simplified sequence looks
>> like this:
>> human --> (1) dpkg-buildpackage --> (2) debsign --> (3) archive
>> For tag2upload, a simplified sequence looks like:
>> human --> (1) Git --> (2) tag2upload --> (3) debsign --> (4)
>> archive
> Please excuse my naiveté, but how do you actually know that your package
> "works" with the tag2upload workflow if you're not building anything
> locally before pushing?
Jonas is correct that this is a highly simplified picture intended only to
highlight the security properties, and I personally will do all sorts of
other things locally to verify my work before I decide to upload it.
But that's a boring answer; the really interesting answer for the purposes
of what tag2upload could accomplish is "Salsa CI." Salsa is already
capable of doing a lot of those tests, like running Lintian and
autopkgtests, so if you have a good suite of autopkgtests, it can do most
of the heavy lifting for you. You can put up a merge request, walk away
and have a cup of coffee or work on some other problem, and come back to
see if it found any issues.
This is a development model used a lot outside of Debian: development
consists mostly of reviewing and merging merge requests in a forge, the
forge CI takes care of testing every change with every useful test that
people have accumulated for the software package, and when it seems ready
for release, that release is done via Git tag.
Doing local testing then becomes an option that you can use if you want a
faster iteration cycle or better logs or local information than the CI can
do, but routine patches can be tested only with CI without bothering to
set up a full local development environment.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: