Re: Which conferences are folks attending these days?
My goal this year is to attend: * All-Systems-Go, Sept. 25-26th, Berlin https://all-systems-go.io/ * Linux Security Summit, Sept. 16-17th, Vienna Austria. https://events.linuxfoundation.org/linux-security-summit-europe/ * Linux Plumbers, Sept. 18-20th, Vienna. https://lpc.events/ Plumbers and Security Summits are connected and same week in Vienna, and with ASG the week after in Berlin. So they make for a nice eurotour-conference trip i reckon. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: SBOMs - Anywhere?
On Sat, Feb 25, 2023 at 03:56:59PM +, Anthony Harrison wrote: > So should Reproducible Builds start creating and using SBOMs (and > delivering them with builds)? Well, we have been doing that for many years. One of the importants of being able to reproduce the builds is to record the information present in the build information into something serializeable. The repro community landed on calling these files "buildinfo" and they predate several of the current SBOM standards being defined. We have some documentation here: https://reproducible-builds.org/docs/recording/ The pacman format can be found here: https://man.archlinux.org/man/core/pacman/BUILDINFO.5.en Depending on the distributions they are not delivered with the builds. Debian/apt went with a out-of-build approach and the files are fetched centralized from one server, while Arch/pacman went with having these embedded into the package archives. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: How to Add a New Project within Reproducible Builds
On Sat, Nov 05, 2022 at 01:20:39AM +, Adrian Diglio via rb-general wrote: > > Hello! Yo! > Can someone please help me better understand the onboarding process and > requirements for joining reproducible-builds as a new project? I'd like to > learn more about how to engage with the community, and potentially how to add > a new project. The reason why you have had trouble getting any response the past few days is because there is a summit in Venice happening this week :) https://reproducible-builds.org/events/venice2022/ There is a meeting once a month on IRC, but how the Reproducible Builds effort works is less organized and more as a collaborative umbrella between different projects. > I'm inquiring to understand what the process is for joining and/or adding a > new project under the Project page of Reproducible-Builds.org Who is involved? > - reproducible-builds.org<https://reproducible-builds.org/who/projects/>? I believe you can just send a merge request with your changes to this repository: https://salsa.debian.org/reproducible-builds/reproducible-website > When adding a new project to reproducible-builds.org, I'm sure there's also > additional steps that would be required of us, such as documentation etc. Is > there anything in particular that is required to be added to your Continuous > Tests? Anything to help me understand your onboarding process would be great. Not really. As mentioned previously this is a lot of work by volunteers, thus natually less structured. Nothing is really required and a lot of the work is done on a best-effort basis. What project is Microsoft intending to add to Reproducible Builds? -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: You don't need reproducible builds
On Sat, Aug 01, 2020 at 01:32:57PM -0400, Julien Lepiller wrote: > Hi, > > With a subject like that, I know I have your attention :). This is actually > the title of a blog post I found on my social media, and I wanted to share in > case you hadn't read it yet: > > http://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducible-builds.html?m=1 > > I think it is important to listen to criticism, as it will help us to better > explain and educate about reproducible builds. > > Thoughts on this? > > Having met some of you at rb-summit in Paris, I know you're adorable people, > but remember to be polite if you decide to comment on his blog. We don't want > to sound like we're harassing people :) The article misses the point, which is quite apparent when you read the following section. > Now if the vendor is compromised or becomes malicious, they can’t give the > user any compromised binaries without also providing the source code. This > ignores some complexities, like ensuring security updates are delivered even > if one vendor is compromised, what to do if the reproducers stop working, or > how to reach consensus if the reproducers and your vendor disagree on what > software or fork you should be using. Tavis only looks at reproducible builds from the standpoint of a proprietary vendor. Which is obvious considering he works at Google. The section above outlines that the vendor providing the binaries, also provides the source code. But this is not the case for reproducible builds in the context of Linux distributions, or Free and Open-Source software in general. In our case (if I'm allowed to say that :p) the pristine source is separate from the distributor of the binary, and you don't need to have the distributor provide the source, you can fetch it yourself. Tavis also includes the "god argument" of bugdoor, which Reproducible Builds simply can't protect against, thus outside the scope of the project. In short: It's a nice criticism of reproducible builds in the context of proprietary vendors, but it doesn't hold up very well when we look at the Free and Open-Source software communities. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: Reproducible Builds Verification Format
On Thu, May 14, 2020 at 01:39:57PM +0200, Arnout Engelen wrote: > On Wed, May 13, 2020 at 10:31 PM kpcyrd wrote: > > The buildinfo is an output of the initial build and becomes an input for > > the rebuilder, but a rebuilder is always going to use the official > > buildinfo when verifying the official package. > > > I don't think the buildinfo of the initial build should be a required input > for a rebuilder. > > The main reason we're interested in reproducible builds is that we're not 100% > confident the initial build was not tampered with. Security-wise it would be > attractive when no information needs to flow from the initial build to the > reproducer. > > Of course the party comparing the results needs information from both the > original builder and the rebuilder, but that might be a separate entity. > Perhaps that should even be the responsibility of the 'collector' rather than > of the rebuilder? > > Now of course I know in practice it can be logistically convenient to use the > buildinfo from the initial build as input for the rebuilder. I'm not saying we > should forbid this. But I think we should design our standards / file formats > in such a way that we do not *require* rebuilders to have access to > information from the initial build. For example, triggering a 'rebuild' > whenever a new version is tagged in source control could in some cases be a > valid approach as well. This is an implementation detail, isn't it? A buildinfo wouldn't be required if you are in an environment where the build environment doesn't change. But in many cases, this isn't the case. Dependencies we pulled could have new versions which could very well interfer with the build. And if we don't have the buildinfo file at hand, how would we know what introduced the change? I'm unsure if you are proposing a rebuild, or argueing for multiple seperate builds of the same package at the same point in time. The latter is beside the goal of a rebuilder currently and would in any case be a CI/CD feature of the given distribution. -- Morten Linderud PGP: 9C02FF419FECBE16
Re: [rb-general] GNU Guix report on the summit
On Mon, Dec 16, 2019 at 02:47:38PM +0100, Ludovic Courtès wrote: > Hello! > > Here’s a report from us Guix about the Reproducible Builds Summit: > > https://guix.gnu.org/blog/2019/reproducible-builds-summit-5th-edition/ > > As in previous years, it’s been a good moment in itself and also a great > boost for our hacking projects. Thanks again to all the organizers and > participants! Yo! A little bit of a pointer regarding the Mes compiler work. > We decided to attempt a cross-distribution Diverse Double Compilation of Mes. I discussed this with Janneke and Vagrant on IRC, but I don't think this work is really proving DDC as explained by David. Mes is still built by gcc, albeit with different versions, which produced the reproducible Mes binary, but this doesn't produce a Mes compiler from a *trusted* compiler. It's all still just gcc. I know vagrant tried sending an email to David and ask for some input but haven't heard if he got any replies. The intention of this email is not to lessen the amazing work done by this by the way :)! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature ___ rb-general@lists.reproducible-builds.org mailing list To change your subscription options, visit https://lists.reproducible-builds.org/listinfo/rb-general. To unsubscribe, send an email to rb-general-unsubscr...@lists.reproducible-builds.org.
Re: [rb-general] Different checksum for libgcrypt20
On Thu, Jul 11, 2019 at 05:54:51PM +, Matt Bearup via rb-general wrote: > Hello all, Yo! > I'm experimenting with reproducible builds and, while I've managed to generate > several packages with correct hashsums (per reproducible-builds.org), there > are ~9 packages where I consistently get a different checksum. Focusing on > one package for this discussion... > > [...] > * However, I've tried multiple build tools (pbuilder and sbuild), multiple > build machines, and multiple host OSes (Stretch and Buster - though the > chroot is always buster). I *consistently* get a different sha256 checksum > for this package: > bbde6cee1fd915e5257b7c47977d8e88dc5e45816fe241fd8751a50aea98c6b8. None of these (pbuild and sbuild) recreate the environment with a BUILDINFO file necessary to recreate the hash. You can try using srebuild and see if it manages to produce the same hash as it would utilize the BUILDINFO to recreate the build environment. But this isn't a standalone tool yet. https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup/blob/master/builder/srebuild -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature ___ rb-general@lists.reproducible-builds.org mailing list To change your subscription options, visit https://lists.reproducible-builds.org/listinfo/rb-general. To unsubscribe, send an email to rb-general-unsubscr...@lists.reproducible-builds.org.
Re: [rb-general] Reproducible builds and distributed CI
On Sun, May 19, 2019 at 01:09:40PM +0300, Lars Wirzenius wrote: > Greetings, Yo! > The distributed idea would be that anyone can run their own > controller, and workers, and can offer workers for any controller. > A lot of people run a desktop machine, or other similar machine, and > could provide some of the resources of that, at least some of the > time, as a worker. Workers can run in isolation, in a highly > restricted VM, and so this is reasonably safe to do. Yes. There has been work towards this for a little while. What we currently have for Debian is a rebuilder setup where we have three components. - scheduler which pulls BUILDINFO files and adds to a Redis queue - worker which pops from the Redis queue and build the package - visualizer that accepts the rebuild submissions These rebuild submissions consists of a BUILDINFO file, and a in-toto link metadata file [0]. Currently there are two rebuilders that has been rebuilding packages as part of a research project [1]. > This immediately brings up the question of how a controller can trust > the output of a worker. Otherwise there's a tempatation to run workers > that produce malicious output. > > I'm thinking that if there's enough workers available, the controller > could give the same build to more than one worker, and compare the > result. This is easy if builds are bitwise reproducible. It is not > very easy otherwise. We discussed during the 2018 summit the possibility of saying that you have 10 rebuilders, we need 8 ACKs (same hash) and only accept 2 NACKS at most. What rebuilders to trust is up to the user, or a baseline can be distributed by the distribution for ease of use [2]. There is currently an APT transport written for the setup mentioned above [3]. > What do you think, you who have a lot of experience with reproducible > builds? Is there any merit in what I'm thinking? Any problems you > foresee in relying in reproducible builds like this? Is it > unreasonable to require random software developers to achieve > reproducible builds? Yes. We do want multiple independent parties to rebuild packages and publish the results, this has been discussed for a while I believe [4]. [0] https://in-toto.github.io/ [1] https://ssl.engineering.nyu.edu/blog/2019-01-18-in-toto-paris [2] https://reproducible-builds.org/events/paris2018/report/#Toc11384_331763073 [3] https://github.com/in-toto/apt-transport-in-toto [4] https://reproducible-builds.org/docs/sharing-certifications/ -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature ___ rb-general@lists.reproducible-builds.org mailing list To change your subscription options, visit https://lists.reproducible-builds.org/listinfo/rb-general. To unsubscribe, send an email to rb-general-unsubscr...@lists.reproducible-builds.org.
