On June 24, 2024 2:48:49 PM UTC, Aigars Mahinovs <aigar...@gmail.com> wrote:
>On Sun, Jun 23, 2024, 19:17 Scott Kitterman <deb...@kitterman.com> wrote:
>
>> As an example, I think the fact that I can download any source package in
>> the
>> archive and cryptographically verify who uploaded it and that it's
>> unmodified
>> from what was uploaded is an important property of our current archive
>> structure. IIRC, you've claimed it's not. I don't think either of us has
>> a
>> very good understanding of why the other believes that. I think for both
>> of
>> us it's just too obviously true/not true to be easy to explain.
>>
>
>There are a few problems with that.
>
>1. The source package is not the end state and not what the end user ends
>up using in their system. Users use a binary deb that is .. generated by
>build and signed automatically by build key. You have to trust the build in
>the source to deb translation. Nowadays most builds are reproducible, but
>not all and they were not when buildd keys were introduced. The
>git-to-source conversion is a much simpler process than a build. I have not
>seen any good arguments against applying the same logic here.
>
>2. What is signed is not the same as what the developer has been writing or
>reading. You are putting a lot of weight on this signature of intermediate,
>generated artifacts. Developers basically never verify that contents of the
>tarballs and diffs they are signing actually match the contents of their
>work folder. It would be trivial the create a modified tool in the
>dpkg-source chain that would inject malicious software just into the source
>package files just before they are signed, especially if targeting a
>particular developer.
>
>The tag in git is closest to what the developer inspected and actually can
>sign with confidence. All the downstream from that is a generated artifact
>that may be tampered with and is much harder to manually verify. From this
>perspective relying on debian source package signatures is less secure than
>the proposal with git2upload, but that is what we have historically agreed
>to accept.
>
>There is a bunch of steps between developer uploading the source package to
>the archive and all the way to the end user downloading and installing the
>final package into their system. And we (as Debian) have been diligently
>working towards automating and centrally managing as many of them as
>feasible. All this does is (for some packages) moving the automation state
>one more step closer to the actual source code. Just because this step used
>to be the first does not make it so special as not to be extendable in the
>same way.
>
>And then we can work or reproducible source builds and running two
>conversion servers and comparing results and other security improvements
>(which is a higher bar than what we demand for binary packages that actual
>end users are running).
None of that changes the fact that it's what they signed. Historically, the
project has found that useful and I think it still is.
Scott K
