On Tue, 18 Jun 2024 at 18:11, Soren Stoutner <so...@debian.org> wrote:
>
> On Tuesday, June 18, 2024 8:57:28 AM MST Aigars Mahinovs wrote:
> > On Tue, 18 Jun 2024 at 17:44, Soren Stoutner <so...@debian.org> wrote:
> > > From a security perspective, it makes sense to me that the DD should
> create
> > > a
> > > .dsc and .changes and sign them, and then tag2upload should create them as
> > > well and verify they match exactly.
> >
> > They will not. Translation from a git tree to a Debian source package
> > with dsc and changes
> > is not a trivial operation.
>
> If we can’t do this reproducibly and verifiably, then I don’t think we should
> do tag2upload at all.
It would be equivalent to only allowing source-only uploads if the
developer has to always
upload source files *and* a checksum of locally-built resulting deb
files and rejecting any uploads
where buildd generated deb files differ from those checksums.
We did not have 100% reproducible builds when source-only uploads
started and for sure
we did not have them when buildds started uploading debs to the
archive and yet that did not
block the progress. Even now a compiler version difference will
produce different binaries. And
that is a good thing. Forcing binary reproducibility is not a useful
metric. Especially when one
of the environments is an uncontrolled developer local machine that
may even have unreleased
versions of various software running.
Having two separate tag2upload servers create a Debian source package
from the same git commt
with the same versions of all software installed, that can be a valid
improvement to security. Doing
non-trivial computations on the developer machine only increases false
positives.
--
Best regards,
Aigars Mahinovs
