Martin via rb-general wrote on Sun, Dec 18, 2022 at 01:09:37 +:
> In my opinion the biggest problem is that we are not able to audit and
> verify any hardware implementation for this work so it cannot be
> trusted at all. Controlling hardware is essential and it cannot be
> replaced by virtuali
Bernhard M. Wiedemann wrote on Wed, 23 Feb 2022 16:35 +00:00:
> The most practical approach is to add to the build scripts
> export TZ=UTC
> (or UTC0)
>
> If it is a regional project, hardcoding that local timezone would also
> yield reproducible results.
Note that if you go down this road, you ne
David A. Wheeler wrote on Sun, 24 Oct 2021 01:41 +00:00:
>> On Oct 23, 2021, at 3:23 PM, Arthur Gautier wrote:
>> All I'm suggesting is to checksum the inflated version of the archive
>> and not the compressed one.
>
> Checksumming the inflated version makes sense to me, so that improved/varying
>
Santiago Torres-Arias wrote on Tue, 06 Apr 2021 23:25 +00:00:
> > Thanks!
> >
> > Where are those edits? I don't see them in reproducible-website.git or in
> > your reply.
>
> Oh, I just pushed, my bad (I wanted to double check it rendered properly
> locally and I went down a rabbit hole of fix
Santiago Torres-Arias wrote on Tue, 06 Apr 2021 18:17 +00:00:
> On Tue, Apr 06, 2021 at 05:02:58PM +0000, Daniel Shahaf wrote:
> > > Do notice that verification is not part of the user story yet (i.e.,
> > > anybody can claim to own any artifact).
> >
> > So, if
Good morning Santiago,
Santiago Torres-Arias wrote on Tue, Apr 06, 2021 at 10:50:20 -0400:
> > I think mentioning sigstore is value. Reproducible builds let you verify
> > that
> > a given build *is* generated from a given source; sigstore can let you
> > verify that you got the *correct* source
Chris Lamb wrote on Mon, 05 Apr 2021 09:03 +00:00:
> Please review the draft for March's Reproducible Builds report:
>
> https://reproducible-builds.org/reports/2021-03/?draft
I don't understand from that post what's so significant about sigstore,
even after having followed the link to upstream
Vagrant Cascadian wrote on Wed, 25 Nov 2020 22:48 +00:00:
> The location will be irc.oftc.net in the #reproducible-builds
> channel. If you are new to IRC, there is a web interface available:
Also, if you're new to IRC, please remember to wait for a few minutes
after asking a question, to give peo
Graham Inggs wrote on Sun, 05 Jul 2020 10:45 +0200:
> Any ideas why openorienteering-mapper FTBFS on the reproducible build
> infrastructure [1]? It builds fine for me locally and on the buildds
> [2]. It's also had some recent binNMUs.
>
> I've copied part of the failed build log below. It see
> > Bernhard's point is that if Alice has a PGP trust path to a hash value
> > [e.g., if Bob signed some hash value and Alice trusts Bob's key], has
> > a file whose hash is that value, and the hash function is sufficiently
> > strong, then Alice may trust that file as well, _regardless of its
> >
Bernhard M. Wiedemann wrote on Tue, 09 Jun 2020 12:31 +0200:
> Am 08.06.20 um 07:52 schrieb Daniel Shahaf:
> > Besides, there was no question, no concrete request, no clickable
> > URL…
>
> https://walletscrutiny.com/ was mentioned, though.
So was the word "clickable
> > https://walletscrutiny.com/ was mentioned, though.
> > IMHO an interesting and worthwhile project. It probably could use more
> > automation in verifying reproducibility.
> >
> > How would the app-update workflow work in a perfect world, where we do
> > not have to trust the app builder?
> >
>
Chris Lamb wrote on Sun, 07 Jun 2020 22:50 -:
> Hi Leo,
> > Thanks for featuring WalletScrutiny! My original mail to the list had not
> > yielded feedback, so I was a bit surprised :D
>
> I can't speak for anyone else of course but I've been quite busy with
> other stuff so your mail kept be
Hans-Christoph Steiner wrote on Fri, 01 May 2020 10:08 +0200:
> Translations are no different. What we're proposing for this website
> is something that is achievable with the small level of contributor
> time that is available. We can definitely deliver something that is
> useful without being a
Hans-Christoph Steiner wrote on Thu, 30 Apr 2020 20:11 +00:00:
>
>
> Daniel Shahaf:
> > Hans-Christoph Steiner wrote on Thu, 30 Apr 2020 19:14 +00:00:
> >>
> >>
> >> Daniel Shahaf:
> >>> Hans-Christoph Steiner wrote on Wed, 29 Apr 2020 14:
Hans-Christoph Steiner wrote on Thu, 30 Apr 2020 19:14 +00:00:
>
>
> Daniel Shahaf:
> > Hans-Christoph Steiner wrote on Wed, 29 Apr 2020 14:05 +0200:
> >> Daniel Shahaf:
> >>> Hans-Christoph Steiner wrote on Wed, 29 Apr 2020 10:44 +0200:
> >>>&g
Hans-Christoph Steiner wrote on Wed, 29 Apr 2020 14:05 +0200:
> Daniel Shahaf:
> > Hans-Christoph Steiner wrote on Wed, 29 Apr 2020 10:44 +0200:
> >> Mattia Rizzolo:
> >>> I didn't check, but is the proposed framework able to properly track
> >>&g
Hans-Christoph Steiner wrote on Wed, 29 Apr 2020 10:44 +0200:
> Mattia Rizzolo:
> > I didn't check, but is the proposed framework able to properly track
> > translation updates?
>
> Of course, that's an essential part of any localization process.
What happens between the update of an English or
Santiago Torres-Arias wrote on Sun, 19 Apr 2020 19:23 -0400:
> Hi,
>
> I tried to build disorderfs for Arch, and it seems to me that the tar.gz
> in [1] doesn't pass signature verification:
>
> [santiago@meme-cluster trunk]$ gpg --verify disorderfs-0.5.9.tar.gz
> disorderfs-0.5.9.tar.gz.asc
Jakub Wilk wrote on Fri, Jan 10, 2020 at 11:05:49 +0100:
> -* [`python-ipydatawidgets`](https://build.opensuse.org/request/show/760182)
> (make `pip install reproducible`, avoid trouble with Zip order &
> [mtime](https://en.wikipedia.org/wiki/Mtime))
> +* [`python-ipydatawidgets`](https://build.o
Linus Nordberg wrote on Mon, 04 Nov 2019 09:02 +00:00:
> That said, FreeBSD-12 requires user ntpd:ntpd (123:123) to exist, as per
> [0][1].
Holger manually created the ntpd user with uid 1004 rather than 123. Will
that be a problem?
___
rb-general@lists
Daniel Shahaf wrote on Thu, 26 Sep 2019 21:26 +00:00:
> Chris Lamb wrote on Thu, 26 Sep 2019 09:06 +00:00:
> > Daniel Shahaf wrote:
> >
> > > > Indeed, but I'm not sure we were really suggesting that we normalise
> > > > all "\b0x[0-9a-z]+
Chris Lamb wrote on Thu, 26 Sep 2019 09:06 +00:00:
> Daniel Shahaf wrote:
>
> > > Indeed, but I'm not sure we were really suggesting that we normalise
> > > all "\b0x[0-9a-z]+\b", rather that we patch the "repr"-like routine
> > > which
Chris Lamb wrote on Wed, 25 Sep 2019 19:15 +00:00:
> Hi Daniel,
>
> > Even for documentation builds, removing addresses entirely could have
> > downsides.
> […]
> >>>> hex(id(c.__class__))
> >'0x7352a0'
> >>>> hex(id(cls.C))
> >'0x4198d0'
>
> Indeed, but I'm not su
Chris Lamb wrote on Wed, Sep 25, 2019 at 12:14:24 +0100:
> Hi Rebecca,
>
> > - jupyter-nbconvert may well be a suitable "documentation builds go
> > through here, interactive use doesn't" place to disable address output
> > by default (either by passing a "disable address output" command-line
>
Lars Wirzenius wrote on Sun, 19 May 2019 10:09 +00:00:
> 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 co
For avoidance of doubt: this announcement was an April Fools' Day prank.
Cheers,
Daniel
___
rb-general@lists.reproducible-builds.org mailing list
To change your subscription options, visit
https://lists.reproducible-builds.org/listinfo/rb-general.
To
Orians, Jeremiah (DTMB) wrote on Mon, Apr 01, 2019 at 09:13:31 +:
> > Ultimately, nice though reproducible builds may be, if we are to avoid RoTT
> > attacks we must have audited, verified hardware as well.
> Actually you need full lithography process control, which is what
> libresilicon is
I'd like to crowdfund an audit of Intel's 8086 CPU¹.
Ultimately, nice though reproducible builds may be, if we are to avoid
RoTT attacks we must have audited, verified hardware as well. Auditing
the 8086 is a first step towards auditing modern-day CPUs derived from
it, and will be separately usef
Vagrant Cascadian wrote on Fri, 29 Mar 2019 20:58 +00:00:
> A professor at Portland State University suggested we make a proposal
> for student capstone projects,
What's the students' background?
> where Reproducible Builds would
> essentially be a "client" with specifications and requirements an
Vagrant Cascadian wrote on Sat, 02 Mar 2019 01:11 +00:00:
> On 2019-03-01, Daniel Shahaf wrote:
> > David A. Wheeler wrote on Fri, 01 Mar 2019 23:01 +00:00:
> >> The *majority* (54%) of packages in real-world Debian Buster are now
> >> reproducible!!
> >
> &g
David A. Wheeler wrote on Fri, 01 Mar 2019 23:01 +00:00:
> The *majority* (54%) of packages in real-world Debian Buster are now
> reproducible!!
(Just to be clear, that's the figure for binary packages. I don't know
if the figure for source packages is higher or lower.)
_
Hervé Boutemy wrote on Wed, 09 Jan 2019 08:30 +0100:
> Le lundi 7 janvier 2019, 14:39:35 CET Daniel Shahaf a écrit :
> > Once again I disagree. A rebuilder _can_ sign the both the input
> > buildinfo file and the output buildinfo file, *provided that the
> > signature exp
Hervé Boutemy wrote on Mon, Jan 07, 2019 at 09:26:44 +0100:
> Le dimanche 6 janvier 2019, 20:10:50 CET Daniel Shahaf a écrit :
> > I think the questions, at this point, are:
> >
> > - Is a rebuild expected to reproduce the binary artifact verbatim?
> AFAIK, the objective
From: Daniel Shahaf
To: General discussions about reproducible builds
Cc:
Bcc:
Subject: Re: [rb-general] [jvm] How to share rebuilder attestations
Reply-To:
In-Reply-To: <4276759.a8cb7drmQk@giga>
Hervé Boutemy wrote on Sat, Jan 05, 2019 at 08:00:49 +0100:
> Le jeudi 3 janvier 2019,
Hervé Boutemy wrote on Thu, Jan 03, 2019 at 09:21:49 +0100:
> Le mercredi 2 janvier 2019, 13:11:43 CET Arnout Engelen a écrit :
> > Having each successful rebuilder append his signature to a shared .asc
> > would indeed be elegant
> +1
>
> > when we can expect the .buildinfo for the
> > original b
Eli Schwartz wrote on Tue, 25 Dec 2018 15:52 -0500:
> Eh, it's hardly harmful either way. I don't believe there was any
> explicit desire to avoid relying on toolchain fixes though. Especially
> since the patch is definitely in Arch Linux's toolchain (we have gcc 8)
> so in the ordinary way of thin
Bernhard M. Wiedemann wrote on Wed, 19 Dec 2018 11:29 +0100:
> On 18/12/2018 15.44, Eric Myhre wrote:
> > I think it's fairly open to interpretation. Implementing it as
> > h(h(➡),■) would be more or less the same semantics, no?
>
> you could even use h(h(➡),h(■))
> so that you only have to hash
Eric Myhre wrote on Tue, 18 Dec 2018 11:48 +0100:
> h(➡) → h(■) vs
> h(➡) → h(➡■) --
What is the argument to the last of these h()'s?
I get that h() is a cryptographic hash function, that ➡ is a callable
function and actual parameters for it (which can be evaluated to produce
some sort of output)
[fixing bug's address in Cc]
Dmitry Bogatov wrote on Mon, 10 Dec 2018 19:49 +:
> I believe, most of us keep repositories of git packages somewhere under
> ~/. For example, for me, ucspi-tcp package is located at
> /home/iu/devel/salsa/ucspi-tcp.
>
> So my workflow is following:
>
> $ cd /h
Daniel Shahaf wrote on Sun, 09 Dec 2018 21:11 +:
> In addition to svn:keywords, you may also need to make sure that
> svn:eol-style is either unset or set to 'LF'.
Sorry, small correction here: you should make sure that svn:eol-style
isn't set to 'native'.
Jelle van der Waa wrote on Sun, 09 Dec 2018 20:38 +0100:
> Another issue was found using the repro tool with our SVN propsets making it
> unreproducible, the propsets are now removed from our PKGBUILDs - also due to
> not being useful anymore. [2]
>
> [2]:
> https://www.mail-archive.com/arch-dev-
Holger Levsen wrote on Wed, 05 Dec 2018 13:59 +:
> On Wed, Dec 05, 2018 at 02:49:24PM +0100, Arnout Engelen wrote:
> (and that's why I think one standard .buildinfo file format for all the
> linux distros, android apps, BSD and node/etc and whatnot will not work.)
>
>
> I think what we can, i
David A. Wheeler wrote on Mon, 29 Oct 2018 06:22 -0400:
>
> >I would skip the numbers or put them last in the news bit.
> >Or mention our non-real-world (higher) reproducibility percentage as
> >well, otherwise this is plain confusing, despite the TL;DR explaination
> >that follows.
>
>
> I like
44 matches
Mail list logo