[Git][reproducible-builds/reproducible-website][master] venice 2022: move https://pad.riseup.net/p/rbsummmit2022-src-mirror-keep to here

[Holger Levsen (@holger)]

Holger Levsen pushed to branch master at Reproducible Builds / reproducible-website


Commits:
385c83e9 by Holger Levsen at 2023-01-21T00:27:08+01:00
venice 2022: move https://pad.riseup.net/p/rbsummmit2022-src-mirror-keep to here

Signed-off-by: Holger Levsen <holger at layer-acht.org>

- - - - -


3 changed files:

- _events/venice2022/agenda.md
- _events/venice2022/packaging.md
- + _events/venice2022/source-mirrors.md


Changes:

=====================================
_events/venice2022/agenda.md
=====================================
@@ -77,7 +77,7 @@ Day 2 - Wednesday, November 2nd
   * 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 FIXME https://pad.riseup.net/p/rbsummmit2022-src-mirror-keep
+  * [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


=====================================
_events/venice2022/packaging.md
=====================================
@@ -2,7 +2,7 @@
 layout: event_detail
 title: Collaborative Working Sessions - Packaging
 event: venice2022
-order: 30
+order: 60
 permalink: /events/venice2022/packaging/
 ---
 
@@ -85,4 +85,4 @@ Practical tests:
    * Git repo
 
 
-In debian's case everything that is released is built from scratch, including Java packages for instance. The minimal subset of inputs required to be able to generate reproducibile builds is the set of dependencies and some environment variables. The assumption is that the dependecies are safe. 
+In Debian's case everything that is released is built from scratch, including Java packages for instance. The minimal subset of inputs required to be able to generate reproducibile builds is the set of dependencies and some environment variables. The assumption is that the dependecies are safe. 


=====================================
_events/venice2022/source-mirrors.md
=====================================
@@ -0,0 +1,55 @@
+---
+layout: event_detail
+title: Collaborative Working Sessions - Source mirrors
+event: venice2022
+order: 70
+permalink: /events/venice2022/source-mirrors/
+---
+
+Reproducible Builds Summit 2022
+
+*The problem*: Building old software and/or building current software far in to the future
+
+This isn't strictly a build reproducibility problem, but more of a practical problem. If you have software that builds reproducibly, but loose the source material, then you can't build it.
+
+
+Current approaches (with disadvantages):
+    
+ * Specific project maintained stores of source material
+   * Some projects tweak or handle source material differently
+   * Every project ends up doing this
+ * Generic internet archives (e.g. archive.org)
+   * Retention and availability might not be great
+ * Software heritage
+   * Lacks some tarballs, disarchive can help with this (GNU Guix is using disarchive)
+      
+
+Proposed basic API interface:
+    
+ * Source archives should provide and communicate a way to query by a hash (treated as a simple string)
+ * A query should either result in a message about this hash being unknown, or a single stream of data.  The stream of data must be able to be verified to match the hash used in the query.
+
+
+This leaves quite a few things undefined, but is simple enough that it should be possible that archives supporting this simple interface are generally useful
+
+
+
+Following on from this, here are some related problems:
+    
+ * A standard way of computing hashes over checkouts of version control repositories (e.g. Git) would be useful, and allow 
+ * How do you know what archives exist?
+ * Is there a consistent API that many/all archives support?
+ * A transparency log for source code would be useful
+ * Being able to track new source code releases would be useful
+ * Mirroring an archive would be useful
+
+We consider that a well-designed standard for a transparency log with serial messaging format may solve several of these problems at once time.
+
+- a serialized transparency log _is_ a consistent API.
+- following a transparency log's appends is a way to listen for new source code releases.
+- a transparency log (especially if it refers to a root hash of a merkle tree containing current state) provides a list of all content tracked, which makes mirroring of the complete set of metadata possible.
+- a transparency log has an additional sociological effect: it should greatly disincentivize people in the community at large from "re-releasing" things with the same names, which is a generally chaotic thing that we would like to discourage!
+- a transparency log means that even if some of the fullsize content bodies for some release are dropped from retainment, we do at least persistently know that that content existed, which may remove some uncertainty from any future archeology.
+
+In a meta-analysis of the conversation we had: we notice that in general, a great deal of conversation and interesting topics was generated after we identified the requirement of easily mirroring subsets of the archive.  For projects in this space, we would recommend that a central consideration be designing (and clearly communicating) the mechanism for supporting mirroring of the primary index (both complete, partial, and incremental).
+



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/385c83e9704cb29ec8f330f41578dfbae3efab86

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/385c83e9704cb29ec8f330f41578dfbae3efab86
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/20230120/ff7bd789/attachment.htm>