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

Holger Levsen (@holger) gitlab at salsa.debian.org
Thu Jan 26 13:01:40 UTC 2023



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


Commits:
80e4e5b9 by Holger Levsen at 2023-01-26T14:01:29+01:00
venice 2022: move https://pad.riseup.net/p/rbsummmit2022-tools-keep to here

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

- - - - -


5 changed files:

- _events/venice2022/agenda.md
- _events/venice2022/documentation+tooling.md
- _events/venice2022/metrics.md
- _events/venice2022/packaging.md
- + _events/venice2022/tools.md


Changes:

=====================================
_events/venice2022/agenda.md
=====================================
@@ -52,7 +52,7 @@ Day 1 - Tuesday, November 1st
 * 12.30 Lunch
 * 13.30 Collaborative Working Sessions
   * Documentation FIXME https://pad.riseup.net/p/rbsummmit2022-documentation-keep
-  * Tools FIXME https://pad.riseup.net/p/rbsummmit2022-tools-keep
+  * [Tools]({{ "/events/venice2022/tools/" | relative_url }})
   * [Packaging]({{ "/events/venice2022/packaging/" | relative_url }})
 * 15.00 Break
 * 15.30 Closing Circle


=====================================
_events/venice2022/documentation+tooling.md
=====================================
@@ -2,7 +2,7 @@
 layout: event_detail
 title: Collaborative Working Sessions - Documentation + Tooling
 event: venice2022
-order: 40
+order: 50
 permalink: /events/venice2022/documentation+tooling/
 ---
 


=====================================
_events/venice2022/metrics.md
=====================================
@@ -2,7 +2,7 @@
 layout: event_detail
 title: Collaborative Working Sessions - Metrics
 event: venice2022
-order: 50
+order: 60
 permalink: /events/venice2022/metrics/
 ---
 


=====================================
_events/venice2022/packaging.md
=====================================
@@ -2,7 +2,7 @@
 layout: event_detail
 title: Collaborative Working Sessions - Packaging
 event: venice2022
-order: 60
+order: 40
 permalink: /events/venice2022/packaging/
 ---
 


=====================================
_events/venice2022/tools.md
=====================================
@@ -0,0 +1,109 @@
+---
+layout: event_detail
+title: Collaborative Working Sessions - Tools
+event: venice2022
+order: 30
+permalink: /events/venice2022/tools/
+---
+
+Reproducible Builds Summit 2022
+
+Tools conversation
+------------------
+
+ - request for diffoscope to support the "nar" format.
+ - there is congratulations and thanks for diffoscope -- for some people here it is the "main tool"!  could not live without!
+ - ... also from the same person: "are there improvements you would like to see?"  "yeah."
+ - diffoscope can be quite verbose in its reporting.  it can become difficult to see a high-level result in large results.
+   - perhaps it would be nice to have some human-readable explanation of some of the kinds of changes which might be recognizable?
+     - (admitted that it is not clear how much this is possible)
+     - for example can we guess if this pattern of change indicates that certain compiler flags have been used?
+ - would live to have: a source code mirroring tool!
+   - example user story: i have an openWRT from 15 years ago I want to rebuild... and though I have some instructions... the source URLs have maybe moved or disappeared, and this stops me.
+     - is one example -- openWRT is not special in this -- source code is source code, we all need this.
+   - is the goal of the Software Heritage Foundation (SWH)?
+     - Possibly!
+     - Do we trust them?  should there be more decentralization of this?
+       - want our own instance!
+   - anecdote: we know some projects stop hosting their own source releases if they think they have a security vuln in it.
+     - entire table agrees: this is very very bad behavior.  archives should be kept!!
+     - "but surely it's still in their VCS"
+       - unclear!
+       - some projects produce "source" tarballs... but these may have e.g. autoconf has been run... and maybe that ISN'T in the VCS.  uh roh.
+   - anecdote: git archive behavior changes.
+   - discussed that want this to work where you ask the service for the source snapshot that is identified by a hash... this means it is easier to mirror, and does not require much trust.
+   - for example deb source files solve this... for debian.
+     - this also isn't necessarily archival and total.  doesn't necessarily contain older releases!
+     - emphasized that this solution is for debian and doesn't solve it for others.
+   - nixOS and guix "substitutes servers" may also contain this kind of snapshotted content.
+   - part of the problem is mirroring the content... part of the problem is seeing the names used to refer to stuff, and then snapshotting that as well.
+   - this is kinda like transparency logs!  like Certificate Transparency!
+     - want this like e.g. maven-central-transparency-logs !
+   - tor has some scripts that look at maven-central and the pom files and hashes them, and they do redistribute the hashes.
+     - they download the thing the first time, and recall the hash...
+       - the future build scripts will _check_ the hash.
+         - (somewhat complex: is _either_ a hash is checked, _or_ a sig is checked.)
+           - (note that the signature files -- the ".asc" files -- are not distributed right now.  maybe they should be.)
+       - the hash is stored in the tor git repo after first being seen.
+       - the future build scripts are still downloading.
+     - "can I have that?!" "we do not the cleverest thing.  we would like to improve that."
+       - "very simple txt files.  only the things we care about."
+   - arch linux stores hashes in their build scripts like this sometimes as well, we think!
+   - bazel has some fetching functions that takes a hash as an _optional_ parameter next to a URL.
+     - it's a shame it's optional
+     - the UX of this is... you have to find a hash somewhere and copy-paste it.
+       - where?
+       - this is human manual!
+   - in cases where git is used, sometimes simply using the git source hash seems like a good option.
+     - tor notes that they use these often, when possible.
+   - it seems many people have some scripts for doing this, but no one is proud of them enough to share :)
+ - possible that there are two parts of the mirroring problem...
+   - to have and to mirror the content blobs is one task
+   - to see the names that are used for this content is also a problem.
+ - what if there was a foundation that maintained version names and made sure people don't re-release things?
+ - what about tools for rebuilding?
+   - some people are not sure it's really seeming possible to share at this level.  many opinions.
+   - we notice reprobuilder tools for debian were topics in previous years but did not really show up on the topic board at all today...
+ - could we have some linters for things like `--Werror=datetime` ?
+   - something like this example above already exists we think, but we would like more like this!
+ - reproducible builds on windows seem to have less representation in this table
+   - some people here have done it!
+   - not much documentation is shared.  potential room for improvement!
+     - "black magic", "sparse information on websites"
+   - e.g. there are some checksum numbers in PE executable format in windows that needs to be normalized, and this is only described in some blog posts.
+   - going on the reproducible builds website was some help!
+ - discussion about difference between controlling supply of content to build vs controlling and describing build environment
+   - "do you have buildinfo files"
+ - it is interesting that gcc may be introducing new sections in the ELF header which describe the build environment.
+   - this could be terrible?!  or it could make some parts of life easier.
+     - depends on what information ends up being stored there, exactly!
+   - if they embed library version info, we welcome that!
+   - if they embed "debian vs redhat": "who cares"
+   - if they embed kernel version: please do not!
+   - if they embed timestamps: please do not!!!!!
+ - "debuginfod" is a thing a few years ago which puts debug info in a server/service
+   - part of an evolution of systems for many years now which puts less debug info in executable binaries themselves.  (e.g. debug symbols began to be put in separate files, starting a few years ago, or at least it is possible to do so.)
+ - reprobuilder / reprotest: have you heard of it?  what would you want from it?
+   - some have not heard of it.  some have.
+   - does it pay off?
+     - it has some features to make it easy to use with debian, but it's supposed to be generic
+     - you have a "exec this" option as well, which should be general.
+       - argument that this isn't very useful, because by the time i've manifested a whole system to hand to that, i've done a bigger piece of work than reprobuilder is.
+   - it has a nice suite of things it will aggressively vary!
+     - that's nice!
+     - sometimes.  some of the things it can vary, some people do not care about.
+       - example: hostname.  several people state they have no complaint to just hardcode a hostname, and don't care.
+       - example: timestamps: these already vary quite naturally so _usually_ it's not the biggest need.
+       - you can disable these if you don't want to waste time on them if you don't see them as interesting, but arguably also it is still a complexity that someone would maintain or know about but not use.
+ - misc things
+   - tor has ended up needing faketime for something on macOS
+ - signing is a problem for reproducibility sometimes, especially when embedded in bundles.
+   - the fdroid people have worked on some scripts for taking signatures out and putting them back in, in android packages!
+   - sometimes a "published private key" is used.
+ - it would be nice if we could convince more things to store _no_ time info instead of SOURCE_DATE_EPOCH
+   - the spec does say already that you should only use SOURCE_DATE_EPOCH as a last resort... but.  well.
+   - idea: should we perhaps amend the spec to say "if SOURCE_DATE_EPOCH=10000" (or some random number we select), "then that means please store no time at all".
+     - same wishes as already, but nudge people more explicitly to support this.
+     - would make it visible if a tool listens to SOURCE_DATE_EPOCH but shouldn't.
+
+



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

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/80e4e5b9bcfa6a30b9ce175e0c459534b35c01ae
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/20230126/0106c033/attachment.htm>


More information about the rb-commits mailing list