[Git][reproducible-builds/reproducible-website][master] 6 commits: hamburg2023: Add guix-todo notes
Evangelos Ribeiro Tzaras (@devrtz)
gitlab at salsa.debian.org
Thu Nov 2 16:48:11 UTC 2023
Evangelos Ribeiro Tzaras pushed to branch master at Reproducible Builds / reproducible-website
Commits:
4d34fe50 by Evangelos Ribeiro Tzaras at 2023-11-02T17:47:31+01:00
hamburg2023: Add guix-todo notes
- - - - -
9e9b7dec by Evangelos Ribeiro Tzaras at 2023-11-02T17:47:31+01:00
hamburg2023: Add notes from the signature storage session
- - - - -
18e4daa6 by Evangelos Ribeiro Tzaras at 2023-11-02T17:47:31+01:00
hamburg2023: Fix/Add metadata in a couple of pages
- - - - -
df804816 by Evangelos Ribeiro Tzaras at 2023-11-02T17:47:31+01:00
hamburg2023: Add notes from verification 1&2 sessions
- - - - -
e7202d0e by Evangelos Ribeiro Tzaras at 2023-11-02T17:47:31+01:00
hamburg2023: Add notes from "Born Reproducible 1"
- - - - -
51b34f60 by Evangelos Ribeiro Tzaras at 2023-11-02T17:47:41+01:00
hamburg2023: Add agenda for day 2
- - - - -
9 changed files:
- _events/hamburg2023/agenda.md
- + _events/hamburg2023/born-repro.md
- + _events/hamburg2023/guix-todo.md
- _events/hamburg2023/images-filesystems.md
- + _events/hamburg2023/public-verification.md
- _events/hamburg2023/rb-commandments.md
- + _events/hamburg2023/signature-storage.md
- _events/hamburg2023/site-audiences.md
- + _events/hamburg2023/verification-use-cases.md
Changes:
=====================================
_events/hamburg2023/agenda.md
=====================================
@@ -45,25 +45,27 @@ Day 1 - Tuesday, October 31
Day 2 - Wednesday, November 1st TODO
-------------------------------
-* 9.00 Opening Circle
+* 9.30 Opening Circle
* The day started with a summary of Day 1 outcomes and a Day 2 Agenda Overview.
-* 9.30 Collaborative Working Sessions, break-out discussions continue.
- * [Documentation + Tooling]({{ "/events/venice2022/documentation+tooling/" | relative_url }})
- * [Metrics]({{ "/events/venice2022/metrics/" | relative_url }})
- * [Packaging]({{ "/events/venice2022/packaging/" | relative_url }})
- * Motivation FIXME https://pad.riseup.net/p/rbsummmit2022-motivation-keep
+* 9.45 Collaborative Working Sessions, break-out discussions continue.
+ * [Ten Commandments]({{ "/events/hamburg2023/rb-commandments/" | relative_url }})
+ * Embedded systems FIXME (no notes in the pad)
+ * [Guix To-do's]({{ "/events/hamburg2023/guix-todo/" | relative_url }})
+ * [Signature storage and sharing]({{ "/events/hamburg2023/signature-storage/" | relative_url }})
+ * [Public verification service]({{ "/events/hamburg2023/verification1/" | relative_url }})
* 11.15 Break
-* 11.15 Participant Skill Share
+* 11.30 Participant Skill Share
* Participants were encouraged to share any skill the consider relevant to the meeting scope. The session was structured so as to minimize group size and maximize 1-on-1 sharing opportunities.
-* 12.30 Lunch
-* 13.30 Collaborative Working Sessions
- * [Source mirrors]({{ "/events/venice2022/source-mirrors/" | relative_url }})
- * SBOM FIXME https://pad.riseup.net/p/rbsummmit2022-sbom-keep
- * Packaging
- * Motivation II FIXME https://pad.riseup.net/p/rbsummmit2022-motivationII-keep
-* 15.00 Break
-* 15:15 Hacking Time
-* 16.45 Closing Circle
+* 13.00 Lunch
+* 14.00 Collaborative Working Sessions
+ * [Verification use cases]({{ "/events/hamburg2023/verification2/" | relative_url }})
+ * [Web site audiences]({{ "/events/hamburg2023/source-mirrors/" | relative_url }})
+ * [Enabling new projects to be "born reproducible"]({{ "/events/hamburg2023/source-mirrors/" | relative_url }})
+ * RB Success Stories FIXME (no notes in the pad)
+ * RB relationship to SBOM FIXME (no notes in the pad)
+* 15.15 Break
+* 15:30 Hacking Time
+* 16.35 Closing Circle
* 17.00 Adjourn
Day 3 - Thursday, November 2nd TODO
=====================================
_events/hamburg2023/born-repro.md
=====================================
@@ -0,0 +1,38 @@
+---
+layout: event_detail
+title: Born Reproducible 1
+event: hamburg2023
+order: 213
+permalink: /events/hamburg2023/site-audiences/
+---
+
+# Notes
+
+Who is running it
+Who is running builds
+At what granularity are build steps defined
+What os/platform are necessary to support
+How (or if) non-owned build inputs are fetched/supported
+What are the different "stacks" that run builders
+How closely does "build input" reflect the full set of things that can inpact output
+How "explicit" is the build definition
+
+Rebuild evidence
+(re)builder indentity
+Both successes and failures to rebuild
+
+
+What are we trying to do?
+Understand build diffs
+Build integrity <- many similar builders
+Build malice <- many different builders
+Rebuild debugging/detection
+* Transient mismatch
+* Deterministic mismatch
+Rebuild smells <- environment variation injector (e.g., build diversity fuzzer)
+
+What are the techniques that can help?
+File system isolation
+Ephemeral environment
+Deterministic Scheduling
+Multiple sequential rebuilds
=====================================
_events/hamburg2023/guix-todo.md
=====================================
@@ -0,0 +1,49 @@
+---
+layout: event_detail
+title: Guix To-Do's
+event: hamburg2023
+order: 203
+permalink: /events/hamburg2023/guix-todo/
+---
+
+# Long term goals:
+
+ - All packages build reproducibly
+ - Benefits security
+ - Future proofing
+
+ - K of N trust in substitutes (where K > 1)
+ - Benefits security
+
+# Things related to reproducible builds
+
+ - The data service info
+ - `guix challenge`
+ - `guix build --check` and `guix build --rounds`
+
+TODO list:
+ - build with disorderfs
+ - linter for matching substitutes (to flag non reproducible packages)
+ - QA checking reproducibility in patches/branches
+ - User submitted build results
+ - Prioritised list of packages/issues to fix
+
+# Actionable items
+
+## Some kind of guix buildinfo
+
+That you can submit to the data service to describe a build you've done. Would be useful from the build coordinator but also submitted from users. This would help to find non-reproducible packages.
+
+## QA doing builds to test reproducibility
+
+## Improve qa.guix.gnu.org/reproducible-builds
+
+Check and prioritise issues.
+
+## Track package reproducibility percentage over time
+
+And backfill data.
+
+## Implement K of N trust in substitutes
+
+See https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00179.html
=====================================
_events/hamburg2023/images-filesystems.md
=====================================
@@ -1,9 +1,9 @@
---
layout: event_detail
-title: Agenda
+title: Images, filesystems and containers
event: hamburg2023
-order: 10
-permalink: /events/hamburg2023/agenda/
+order: 303
+permalink: /events/hamburg2023/images-filesystems/
---
# Filesystem/Container images meeting
=====================================
_events/hamburg2023/public-verification.md
=====================================
@@ -0,0 +1,81 @@
+---
+layout: event_detail
+title: Public verification service
+event: hamburg2023
+order: 205
+permalink: /events/hamburg2023/verification1/
+---
+
+# Server collects build data
+
+- Includes Hashes of Outputs
+- Info About Build Environment
+- Finds out what environment factors matter
+
+# Use cases
+
+## Use data to determine what's causing builds to differ
+## What percentage of X builds reproducibly
+
+
+
+# Building or rebuilding stuff
+
+Components are things like build environment and sources
+
+## Build spec
+
+Build spec:
+ - Input archive
+ - Patches
+ - Build instructions
+ - Target distro/OS
+
+
+Environment:
+ - What's installed
+ - Contents of /etc
+ - File system types
+ - Initial working directory
+ - Environment variables
+ - TZ
+ - Locale
+ - Running kernel
+ - Hardware architecture
+ - Current user (UID/GID)
+
+Outputs:
+ - 'treeish' hash
+ - Include some file metadata, but not all
+ - Should timestamps be stored?
+ - Is-Test (delete periodically if true)
+
+(above is the payload)
+
+
+Metadata:
+ - Name + Version
+ - Project URL
+ - Uploader
+ - Optional signature
+ - Comment
+ - Link to build
+
+ Formats:
+ - Linked Data / RDF
+ - JSON
+ - SBOM / SPDX / CycloneDX / ... ?
+ - Maybe In-TOTO?
+
+Hook In:
+ - After 'Fetch' / Before 'Build'
+ - After 'Artifact Generation'
+
+
+People interested in contributing to implementation:
+ - Hervé Boutemy (hboutemy at apache.org)
+ - Arnout Engelen (arnout at bzzt.net)
+ - Janis Peyer (janispeyer at bluewin.ch)
+ - Nicolas (boklm at torptoject.org)
+ - quae at daurnimator.com
+
=====================================
_events/hamburg2023/rb-commandments.md
=====================================
@@ -1,9 +1,9 @@
---
layout: event_detail
-title: Agenda
+title: The Ten Commandments
event: hamburg2023
-order: 10
-permalink: /events/hamburg2023/agenda/
+order: 201
+permalink: /events/hamburg2023/rb-commandments/
---
# RB Ten Commandments
=====================================
_events/hamburg2023/signature-storage.md
=====================================
@@ -0,0 +1,38 @@
+---
+layout: event_detail
+title: Signature storage and sharing
+event: hamburg2023
+order: 204
+permalink: /events/hamburg2023/signature-storage/
+---
+
+Signature storage and sharing
+-----------------------------
+
+* Most uses PGP keys, some uses SSH keys for commit signing (YubiKeys
+ support HSM management of SSH keys)
+* Key discovery is not always trivial
+* Unclear story around how to verify signatures
+* Commit signing can be hard as certain CI/CD systems either signes
+ commits used in UI with their own key, or shows badges such as
+ "commit verified". This only works of the CI/CD knows about all the
+ commit sining keys, and so can show "commit not verified" which can
+ be false or misleading
+* For package manager, Maven contains each maintainer's public key
+* Similar for many distributions (knows about maintainer's public
+ keys)
+* Android uses an allow list of developer keys
+* In general, the security of allowed keys at resit is not resilient
+ against tampering (i.e an attack on a server)
+* TUF could be used to secure trusted keys (both at rest and in
+ transit)
+* Some pacakge repositories signs the packages (can still be signed by
+ the developer before publish, i.e multiple signatures)
+* With PGP, keys can be rotated. New key N+1 can be signed with
+ current key N. Not possible with SSH keys
+* Summary (for the general case):
+ * Key distribution is hard
+ * No easy verification flow
+
+
+
=====================================
_events/hamburg2023/site-audiences.md
=====================================
@@ -1,9 +1,9 @@
---
layout: event_detail
-title: Agenda
+title: Web site audiences
event: hamburg2023
-order: 10
-permalink: /events/hamburg2023/agenda/
+order: 212
+permalink: /events/hamburg2023/site-audiences/
---
# website meeting
=====================================
_events/hamburg2023/verification-use-cases.md
=====================================
@@ -0,0 +1,42 @@
+---
+layout: event_detail
+title: Verification Use Cases
+event: hamburg2023
+order: 211
+permalink: /events/hamburg2023/verification2/
+---
+
+Verification use cases
+----------------------
+
+- have some central place for people to upload attestations?
+
+ - put everything into one database?
+
+ - disks are cheap, but querying data is complicated
+
+- how do we display data?
+
+ - have a website?
+
+ - a graph?
+
+- maybe collect them in git repos?
+
+ - every entity runs their own repo
+
+- we need to be able to tell which entity did the rebuild
+- do we need additional data for easier triage?
+
+ - cpu features?
+
+- maybe she should keep track of the cpu features of the rebuilder?
+- the buildinfo file should canonically describe a "blessed" environment
+- each language package manager (cargo, npm, composer, ...) is their own "distro", from a r-b point of view
+- do we want to match results between distros?
+
+ - is this doable/useful?
+
+ - in Arch Linux, we often know what the issue is based on a single diffoscope, the challenge is triage/fixing all root causes
+
+- maybe something similiar to crev? https://github.com/crev-dev/crev/
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/compare/f28ef41e20f61f7e48fdaf740c5e5743a4e5ac35...51b34f604ffd8bf1e51a663f198566b1f9e8c91e
--
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/compare/f28ef41e20f61f7e48fdaf740c5e5743a4e5ac35...51b34f604ffd8bf1e51a663f198566b1f9e8c91e
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/20231102/689389a0/attachment.htm>
More information about the rb-commits
mailing list