[Git][reproducible-builds/reproducible-website][master] vienna2025: Add d3 working groups notes
Robin Candau (@Antiz)
gitlab at salsa.debian.org
Thu Oct 30 16:59:56 UTC 2025
Robin Candau pushed to branch master at Reproducible Builds / reproducible-website
Commits:
7b7cd546 by Robin Candau at 2025-10-30T17:59:42+01:00
vienna2025: Add d3 working groups notes
- - - - -
9 changed files:
- _events/vienna2025/agenda.md
- _events/vienna2025/agenda/d2-distributedverification3.md
- _events/vienna2025/agenda/d2-successfailure.md
- _events/vienna2025/agenda/d3-definition.md
- + _events/vienna2025/agenda/d3-engagingacademia.md
- _events/vienna2025/agenda/d3-python.md
- _events/vienna2025/agenda/d3-sourcerepro.md
- + _events/vienna2025/agenda/d3-standards.md
- + _events/vienna2025/agenda/d3-website.md
Changes:
=====================================
_events/vienna2025/agenda.md
=====================================
@@ -115,30 +115,17 @@ The day will start with a summary of Day 2 outcomes and a Day 3 Agenda Overview.
9.45 Collaborative Working Sessions
-* Source tarball reproducibility
-** [NOTES](/events/vienna2025/agenda/d3-sourcerepro)
-
-* Web site WG
-** NOTES: https://pad.riseup.net/p/rbsummmit2025-d3-website-keep
-
-* NIST, Governments, and standards
-** NOTES: https://pad.riseup.net/p/rbsummmit2025-d3-standards-keep
-
-* Engaging Academia
-** NOTES: https://pad.riseup.net/p/rbsummmit2025-d3-engagingacademia-keep
-
-* Python
-** [NOTES](/events/vienna2025/agenda/d3-python)
-
-* RB Definition
-** NOTES: https://pad.riseup.net/p/rbsummmit2025-d3-rbdefinition-keep
-
-
+* Source tarball reproducibility: [NOTES](/events/vienna2025/agenda/d3-sourcerepro)
+* Web site working group: [NOTES](/events/vienna2025/agenda/d3-website)
+* NIST, Governments, and standard: [NOTES](/events/vienna2025/agenda/d3-standards)
+* Engaging Academia: [NOTES](/events/vienna2025/agenda/d3-engagingacademia)
+* Python: [NOTES](/events/vienna2025/agenda/d3-python)
+* RB Definition: [NOTES](/events/vienna2025/agenda/d3-rbdefinition)
11.15 Break
=====================================
_events/vienna2025/agenda/d2-distributedverification3.md
=====================================
@@ -3,7 +3,7 @@ layout: event_detail
title: Collaborative Working Sessions - Distributed verification III
event: vienna2025
order: 23
-permalink: /events/vienna2025/agenda/d2-distributed-verification3.md/
+permalink: /events/vienna2025/agenda/d2-distributed-verification3/
---
# Evaluation criteria
=====================================
_events/vienna2025/agenda/d2-successfailure.md
=====================================
@@ -3,7 +3,7 @@ layout: event_detail
title: Collaborative Working Sessions - Success and failures
event: vienna2025
order: 24
-permalink: /events/vienna2025/agenda/d2-successfailure.md/
+permalink: /events/vienna2025/agenda/d2-successfailure/
---
Standardizing and sharing success and failure
=====================================
_events/vienna2025/agenda/d3-definition.md
=====================================
@@ -1,8 +1,8 @@
---
layout: event_detail
-title: Collaborative Working Sessions - Definition
+title: Collaborative Working Sessions - RB Definition
event: vienna2025
-order: 214
+order: 32
permalink: /events/vienna2025/agenda/d3-definition/
---
=====================================
_events/vienna2025/agenda/d3-engagingacademia.md
=====================================
@@ -0,0 +1,57 @@
+---
+layout: event_detail
+title: Collaborative Working Sessions - Engaging academia
+event: vienna2025
+order: 30
+permalink: /events/vienna2025/agenda/d3-engagingacademia/
+---
+
+Reproducible Builds Summit 2025 Thursday - Engaging Academia
+
+* make academic research
+* often academics go too esoteric
+* academics need credit in the official ways: publishing papers, conferences, etc.
+
+get these groups working together, what are the requirements?
+* industry (Linux Foundation, etc)
+* academia
+* community projects (Debian, F-Droid, etc)
+
+NSF SafeOSE $1.5 mil projects
+
+* other funding strategies, like small directs contracts
+* small, quick funds like NLnet, Sovereign Tech Fund, etc.
+
+* publication-driven (academia) vs practitioner-driven (industry, FOSS communities, etc)
+
+* academics need prestige and ranked events
+* lots of practitioners want to avoid that whole scene
+* how to make an event that works for all?
+
+What are examples that work at mixing academia and practitioners?
+* some academic conferences work to include practitioners
+ * https://scored.dev/
+ * these often aren't ranked high enough for some academics
+* some practitioner conferences are well known:
+ * https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/
+* worked but became too academic, but might work
+ * https://www.acsac.org/
+
+* academics don't want to get scooped, because of "publish or perish"
+* FOSS communities view it as a goal to have more people working on the same things
+
+Idea: get NSF TIP program managers to endorse the conference in some important way. This will grab the attention of top academic researchers and might better bootstrap the event in the eyes of academics.
+
+Other key people to bring in to make critical mass in an event:
+* funders: National Science Foundation (NSF), Open Tech Fund (OTF)
+* government/regulators: auto regulators, European Commission
+
+CORE ranking system is key measure for some universities, they only want to submit to well ranked events https://www.core.edu.au/conference-portal
+
+* How can we include small universities? There are lots of them around the world, they often work directly with practitioners already. They have a lot more flexibility and are much cheaper to fund.
+
+SATML https://satml.org/
+
+
+Let's try to organize something at https://scored.dev/
+
=====================================
_events/vienna2025/agenda/d3-python.md
=====================================
@@ -2,7 +2,7 @@
layout: event_detail
title: Collaborative Working Sessions - Python
event: vienna2025
-order: 214
+order: 31
permalink: /events/vienna2025/agenda/d3-python/
---
=====================================
_events/vienna2025/agenda/d3-sourcerepro.md
=====================================
@@ -1,9 +1,9 @@
---
layout: event_detail
-title: Collaborative Working Sessions - Success stories
+title: Collaborative Working Sessions - Source tarball reproducibility
event: vienna2025
-order: 214
-permalink: /events/vienna2025/agenda/
+order: 27
+permalink: /events/vienna2025/agenda/d3-sourcerepro/
---
== Reproducibility of source tarballs
=====================================
_events/vienna2025/agenda/d3-standards.md
=====================================
@@ -0,0 +1,118 @@
+---
+layout: event_detail
+title: Collaborative Working Sessions - NIST, Governments, and standards
+event: vienna2025
+order: 29
+permalink: /events/vienna2025/agenda/d3-standards/
+---
+
+NIST, Governments, and standards
+Notes
+
+Jarl Gullberg
+
+
+standards from what has been done for a long time
+vs industry standard
+goal: make it easy to implement, interoperate, verifiability
+ gov: e.g. vuln-reporting ; usually abstract
+good: NIST SSDF, actionable, not overly specific: describes outcomes, model,...
+
+what outcome?
+being able to reproduce binaries independently
+why?
+CIA + non-repudiation + traceability
+correctness, integrity, availability
+correctness: avoid build-time race-conditions
+integrity: make it tamper-proof
+traceability: because we are imperfect and need to improve after a failure
+availability: because r-b ensures artifacts can be produced later/elsewhere
+non-repudiation: because we need to know who did what
+
+
+need to reduce effort to implement via anti-bikeshedding
+consuming 3rd party binaries, need trust. Attestation vs audit (effort/price)
+reference-implementations do help.
+
+scope:
+Transformation from any source material through a set of tools into output artifacts, in a deterministic way
+
+it is easier to add users to ?
+
+=> need to find existing standards with users
+especially standards with consideration for security
+
+1. outcome
+2. guidelines (e.g. use hermetic environment)
+3. example implementations
+
+ToDo: create an inventory of national standards aligning with r-b outcomes
+ so that we can influence standards process + docs to create demand for r-b, so that investment into r-b happens as a result
+
+formalizing conformance testing to r-b in ecosystems
+
+standards provide a shortcut / framework for reasoning about outcomes.
+e.g. governments know they want resilient secure software for critical infrastructure, but they don't know that they need r-b for that.
+
+convergence towards common approaches
+
+watch for and engage with emerging standards, become part of the working group (e.g. CRA(cyber-resilience), SLSA)
+
+Add website docs for standards bodies / workgroup engangement / vendor partnering
+
+Create our WG
+
+previous summit:
+https://reproducible-builds.org/events/hamburg2024/ReproducibleSummit2024EventDocumentation.pdf
+page 44
+
+# Sketch page
+Developers of software
+System designers
+Operators
+Security experts
+Auditors
+Researchers
+
+**Hermetic Determinism**
+
+Tamper proof (integrity)
+Availability
+Non-repudiation
+Traceability (providence)
+~~Interoperability~~
+Correctness
+
+Spec -> publish, advocate, engage
+Lobby -> NIST -> educate
+
+# Getting standardization bodies to care about reproducible builds
+## We care about standards because
+* Standards are a framework for reasoning about outcomes
+* They act as shortcuts to solution design
+* They encourage convergence on common approaches
+
+## Reproducibility is a means to achieving these outcomes
+* Tamper-resistance (integrity)
+* Availability
+* Non-repudiation
+* Traceability
+* Correctness
+
+These are well-known terms of art within existing security and safety standards, coalesced around security and resilience.
+
+## The road to standardization
+* We want to attach and map to existing standards, working top-down to document and align on de jure directives
+* We want to normalize solutions in the ecosystem, working bottom-up to form de facto implementations
+* We want to watch for and engage with emerging standards, such as the Cyber Resiliency Act
+
+## Next steps
+* Make an inventory of national, international, industrial, and ecosystem standards to identify applicable areas of work
+* Mapping reproducibility outcomes to requirements in applicable standards
+* Picking one and doing it!
+
+ - SLSA is an existing standards body with a known focus on reproducibility
+
+ - The CRA is a set of emerging standards with opportunities for advocay and adaptation
+
+* Create a working group to drive the work
=====================================
_events/vienna2025/agenda/d3-website.md
=====================================
@@ -0,0 +1,138 @@
+---
+layout: event_detail
+title: Collaborative Working Sessions - Website
+event: vienna2025
+order: 28
+permalink: /events/vienna2025/agenda/d3-website/
+---
+
+Web site WG Notes
+=================
+
+*note that this session follows closely onward from the Day 2 community collaboration working session.*
+
+## scope
+
+- _someday_, we find it _nice to have_ some meta plans about working groups.
+ - today we're going to focus on doing the first one.
+
+- we end up with a few discussion notes here about working groups in a general way, but they are intermingled and non-final.
+
+
+## discussion
+
+- if we want to move the website...
+ - currently the code lives on debian's "salsa" server. (which is a gitlab.)
+ - -> this needs to move to some github org.
+ - **we do not know if we have the reproducibile-builds github org.**
+ - -> more people who may have access have been contacted, but pending.
+ - currently there is a jenkins build.
+ - site is a static site, but it is built by jekyll.
+ - -> may need to change this to a github action.
+ - (this should be pretty trivial. mattia says it's practically a one liner in jenkins right now.)
+ - dns will need to be updated.
+ - -> mattia has direct access to this. also holger.
+ - and if we need to *write* new dns entries entirely (github pages may require this)...
+ - -> yes that too! yay.
+ - -> gandi is the actual host.
+ - -> this is ultimately owned by SFConservancy (see notes in billing below).
+ - can we have an infrastructure-as-code repo?
+ - -> we _wish_, but the time/ROI here is probably unfortunately not good :/
+ - ssl certs...?
+ - it's currently done by letsencrypt.
+ - github pages will support a similar thing.
+ - we don't have very exciting requirements here (good).
+ - do we have any billing issues to worry about here?
+ - -> it seems like "no"! If we're using github pages, etc, and public repos... this is going to be... free.
+ - -> if we *do* need a credit card for billing purposes... it is possible, but it is based in an organzational conversation with the SFConservancy, so... expect this to require a roundtrip.
+ - the **minimum viable updates** to the website:
+ - -> we *do not want to do massive website changes here*; that is *not our goal in this group*.
+ - -> but we do want to update any links to "where the source is".
+ - and maybe there's a page in the website about registering for salsa which can be removed.
+ - cleanup for debian: the debian internal stuff can also drop some references.
+
+
+- sidenote: did you know we also own reproducible.build ? do we have interest in that?
+ - it's currently just a redirect.
+ - -> it's neat but we'll keep it in our back pocket :)
+ - we don't love that you tend to need another conversational RTT to explain "yes it's a weird TLD" :)
+
+- more website content that is a priority...
+ - _this is not our primary focus today. there is plenty of that._
+ - somewhere under the people page, we probably do want a page that says that there is this working group.
+
+- what else MUST we do before we feel comfortable advancing as a working group?
+ - we DO want to *communicate transparently* that a group will form to handle this topic (and has already discussed it considerably).
+ - on rb-general!
+ - we're making a group.
+ - of this original list of people {etc}.
+ - with the goal of moving the website to a more engagable situation.
+ - at the summit, we have discussed several possibilities, and found the greatest acceptance during the summit that... {etc}
+ - (we realize that not everything about this option is perfect, but nothing is perfect about *any* option. here we place the greatest priority on something that we feel is as engagement-friendly as possible, and does not privilege the friction of any particular group over another.)
+ - we DO NOT want to communicate that anyone can sign up -- not because we want to be exclusive, but because we want a group of a size that is focused enough to *get things done*.
+
+- we may put some alternative ways to contribute to the website in the website...
+ - but it might be something like...
+ - "you can send patches to the mailing list if you're not interested in engaging via github. However you are hoping that someone will do additional work on your behalf to integrate those, and we do not guarantee that :)"
+ - could we have more than one active mirror?
+ - well maybe.
+ - it's git. **we are not afraid of doing this _later_.** that is good and that means we can move forward with incremental steps now :)
+
+
+- considerations for working groups in the future...
+ - a working group can ask for a mailing list
+ - (... discussion ensues ...)
+ - (... something about mailman versions ...)
+ - "should we distribute pagers?"
+ - we're kidding. we're kidding.
+ - working groups should have some page under the people section of the website.
+ - list people.
+ - list goals.
+ - list any extra communication channels for this group.
+ - mailing lists?
+ - chat systems?
+ - places like _github issues_ _also count_.
+ - list any completion criteria / termination conditions! (hopefully you have them!)
+ - will there be an archive of closed working groups?
+ - sure. probably. can figure that out later :)
+ - working groups should probably have an expiration date and a clear end goal (where when it's done, the group is done).
+ - working groups should probably not have one person. three is a nice number. five is a nice number. bigger numbers are questionable numbers.
+ - are you REQUIRED to make a mailing list for a working group?
+ - NO.
+
+- guidance for working groups...
+ - as a heuristic: a working group should be mindful of accepting contributions if they will create a maintenance burden.
+ - It may sound harsh, but *we cannot assume continuous future involvement* from *every person*.
+ - as a heuristic: do stuff, but think twice before doing stuff that either {locks in future choices} or {has maintenance costs that don't have a clear future story}.
+ - and the inverse: if something can happen later, and nothing we're doing now blocks that, that's great. (e.g. git mirror stuff.)
+
+- do we want to form a working group working group?
+ - well, maybe.
+ - the defacto for this is the people currently in the rb core team (e.g. mattia, holger... shortlist).
+ - (we are happy with the people who are involved right now! the discussion is mostly about if there is more formalization and clarification to do.)
+ - this might be worth growing.
+ - probable domain is:
+ - the approval of working groups
+ - the garbage collection of inactive working groups!
+ - etc.
+ - today's progress:
+ - we agree that it's probably good to start working on some draft thoughts (like some of the above) about what we could do here.
+ - we are going to test-run doing this with this website project.
+ - we are **not** going to push any **specific procedural policies** right now, because that is a bigger discussion, we are not going to be that decisive today, we want to be very inclusive with big policy things... etc.
+
+
+- WE GOT TEN MINUTES LEFT HERE. WHAT ARE WE DOING AS A NEXT STEP.
+ - we do not want to send each other an email on rb-general to ask "who's awake next monday", it's embarassing and it's noisy and it would be silly.
+ - so what
+ - one of us doesn't have an irc bouncer and does not find that funny.
+ - so what
+ - SO WHAT GUYS
+ - (i'm leaving this in the notes because it's educational to note that PICK THE NEXT THING is actually REALLY HARD and when organizing a working group YOU REALLY HAVE TO FOCUS on PICK. THE. NEXT. THING.)
+ - we're going to agree to a time to continue with one video meeting, amongst exactly ourselves here, because this is hard enough :)
+ - OUR AGENDA FOR THAT NEXT MEETING:
+ - draft email to announce intentions and process.
+ - and work again on defining when we meet next to continue again.
+ - WHAT NEEDS TO HAPPEN BEFORE THAT MEETING TO MAKE IT EFFECTIVE?
+ - get info/access about the github org.
+ - exchange links for where we do the video meeting (it's probably jitsi).
+ - exchange links to a scratchpad editor.
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/7b7cd546c8412737b7a703e13a0a5b101986405f
--
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/7b7cd546c8412737b7a703e13a0a5b101986405f
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/20251030/0fde0438/attachment.htm>
More information about the rb-commits
mailing list