[Git][reproducible-builds/reproducible-presentations][master] 2 commits: seagl-two-ways-to-trustworthy: dump some very rough content ideas to turn into slides.

Thu Nov 7 07:08:26 UTC 2024


Vagrant Cascadian pushed to branch master at Reproducible Builds / reproducible-presentations


Commits:
e0c7ed58 by Vagrant Cascadian at 2024-11-06T22:36:36-08:00
seagl-two-ways-to-trustworthy: dump some very rough content ideas to turn into slides.

- - - - -
c399956e by Vagrant Cascadian at 2024-11-06T23:07:11-08:00
seagl-two-ways-to-trustworthy: more notes...

- - - - -


1 changed file:

- 2024-11-08-SeaGL-Two-Ways-to-Trustworthy/Two-Ways-to-Trustworthy.org


Changes:

=====================================
2024-11-08-SeaGL-Two-Ways-to-Trustworthy/Two-Ways-to-Trustworthy.org
=====================================
@@ -198,3 +198,171 @@ https://reproducible-builds.org/who/sponsors
 
   To view a copy of this license, visit
   https://creativecommons.org/licenses/by-sa/4.0/
+
+* Why compare these two Operating Systems?
+
+They are examples of projects with a very different history,
+organizational structure and even rarer, fundamental differences in
+their approach to packaging
+
+* Fundamental Security vs. Individual issues
+
+Fundamental security allows you to work with confidence that the
+source code is actually what produces the running code.
+
+Without fixing fundamental security problems, without tying the issues
+back to the actual source code, attempting to fix individual issues
+with patches to source code may not have the desired effect.
+
+* Strong vs. Loose maintainership models
+
+Debian has historically had a strong maintainership model, gradually
+moving towards various forms of collaborative maintenence (teams,
+opt-in weaker non-maintainer upload requirements). Updating a package
+maintained by someone else requires a additional processes, at least
+socially. Technically, anyone can upload anything.
+
+Guix is a very weak model; there are not specific maintainers for
+specific packages.
+
+* Middle of the road maintenence
+
+Guix is moving towards more identified ownership, having adding teams
+and more structured expectations for review of updates, though it is
+not comprehensive.
+
+Debian has moved many packages towards team-maintenence or or weakened
+requirements to update an individual package.
+
+* Bootstrapping
+
+You can build guix from a very small set of bootstrap seeds, and end
+up with a bit-for-bit reproducible result for most of the operating
+system. They have historically recorded all of the bootstrap seeds
+from the very beginning.
+
+Exactly how Debian was bootstrapped is more or less lost to
+history. Some compiler was used decades ago to build early versions of
+Debian, and then Debian was used to build newer versions of itself,
+over the course of decades. There is to my knowledge no way to
+reproduce these original bootstrap environments.
+
+* Very Credible Sources
+
+Debian predates modern version control systems, such as git.
+
+guix founded after git was already well established, if not even
+dominant.
+
+* Apples to Kumquats
+
+In Debian each package may have a separate git repository, if any at
+all. It May be hosted on infrastructure outside of Debian. The
+packaging may be a more-or-less complete copy of what is uploaded to
+the archive, or simply the Debian packaging parts.
+
+The entirety of Guix is maintained in a single git repository,
+although this git repository typically only contains references of how
+to download the code from largely infrastructure outside of guix.
+
+* A Bee Eye
+
+Debian infrastructure plans on ABI compatibility, to avoid rebuilding
+the world all the time. It mostly works ok.
+
+Guix rebuilds everything any time a change in a dependency is
+changed. Recursively. Just to make sure it works.
+
+Security fixes for low level packages would require world rebuilds in
+guix, so sometimes guix cheats.
+
+* Sources and Binaries
+
+Debian is fundamentally a binary based distribution.
+
+Guix is a source-based distribution, that distributes binaries as an
+optimization.
+
+* Archiving Reproducibly
+
+This requires very different archival needs, in order to be able to
+get a sufficiently similar build environment.
+
+snapshot.debian.org has had some historic troubles and misses soem
+generations of both binary and source packages.
+
+guix relies on softwareheritage.org to archive the upstream sources,
+as well as some other projects, such as disarchive. Binaries might be
+available, but are semi-frequently garbage collected.
+
+* Building Trust
+
+How do you know who is responsible?
+
+Both projects have structures and teams who handle important things such as security issues.
+
+The Debian security team has had for some years some rotating
+responsibilities with who handles newly identified security issues,
+and works with maintainers to facilitate that the updates follow
+appropriate processes.
+
+Guix also has a team of folks as a security point of contact, though
+my understanding is that it is a bit more informal at this point.
+They have some technical challenges working around security fixes that
+would normally trigger world rebuilds.
+
+Both projects try to be clear and transparent about how they approach
+individual security issues when identified, having teams of trusted
+people who carry out this often thankless work.
+
+* On Youth and Maturity
+
+Guix is a much younger project (2012) and in stage of faster
+evolution, largely focused on a primary development branch in a
+rolling release. It is gradually growing and experimenting with the
+need for more formal or complicated structures.
+
+Debian is a much older project (1993) and mature, often with multiple
+concurrent releases (stable, oldstable, oldoldstable), a development
+branch (testing) and a staging area (unstable), with more established
+guidelines and careful challenging processes for widespread
+change. Sometimes it is conservative to move, having so many competing
+interests within Debian.
+
+* The Scales are Unbalanced
+
+Guix has tens or maybe hundreds of active contributors.
+
+Debian has thousands of active contributors.
+
+They both maintain tens of thousands of packages.
+
+* Being Nimble
+
+In a sense Debian is too big to respond swiftly to big changes.  It
+has taken the Reproducible Builds project many years to nudge the many
+packages and projects within towards reproducibility.
+
+To make a change in Debian that affects, say, 5000 packages, you may
+need to make many changes in the individual packages.
+
+In contrast, guix can make some wide-sweeping changes in a single git
+commit.
+
+* Subtle Nuance
+
+Debian is, in some ways, a collection of many small projects for each package.
+
+Guix is a smaller group leveraging those outside projects to create
+packages.
+
+* what you need
+
+to audit code you need to be able to:
+
+- see it (free software)
+
+- bootstrap it (confidence in the used toolchain)
+
+- know the running code is produced from the source code (Reproducible
+  Builds)



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-presentations/-/compare/5aeab2ae306f87ca44c0306b2d758557780f206e...c399956ee6d04e7fb106774a9f5fe65e4309ebb7

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-presentations/-/compare/5aeab2ae306f87ca44c0306b2d758557780f206e...c399956ee6d04e7fb106774a9f5fe65e4309ebb7
You're receiving this email because of your account on salsa.debian.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-commits/attachments/20241107/5644313a/attachment.htm>
