unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Karl Semich <fuzzytew@gmail.com>
To: "Thompson, David" <dthompson2@worcester.edu>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Deterministic Library Calls when Building
Date: Sun, 20 Mar 2016 12:53:42 -0400	[thread overview]
Message-ID: <CABnEbCFsKEa3VQ1QeMgRZqL2n-b+d1KPdMw1qiya6XW2zvmOaA@mail.gmail.com> (raw)
In-Reply-To: <CAJ=RwfY6V0a5L-zOG82_Xh7n5L2=nqJXWQLFvqA0zQKYt6ztuw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]

It seems to me it would be the most reliable, future-proof, way, but might
have the downside of making it a step harder for people without the special
environment to reproduce the build.

I'm pretty new at looking under the hood of linux, but I can imagine these
approaches at least:
- preload system library wrappers around key nondeterministic functions
- replace /dev/*random with fakes (could be named pipes, dummy devices fed
by modules, or just flat files!)
- replace system libraries with fullblown libraries with nondeterministic
calls rewritten (could merge changes upstream, provide a flag)
- create a kernel module which alters the behavior of the running kernel to
be more deterministic
- change the kernel itself to have a "deterministic mode" (could merge
upstream)

The goal of making packages deterministic would change from modifying the
packages themselves, to modifying the build environment, with the hope of
making a build environment that always creates deterministic builds for
normal software packages.  This should be very possible.

The approach of small library wrappers and/or replacing device files could
be pretty fast to implement, but not as "far thinking" as the other end of
the spectrum, where changes to glibc and linux could be merged upstream.

On Sun, Mar 20, 2016 at 8:51 AM, Thompson, David <dthompson2@worcester.edu>
wrote:

> On Sun, Mar 20, 2016 at 6:04 AM, Karl Semich <fuzzytew@gmail.com> wrote:
> > Hi,
> >
> > I recently learned about guix and I haven't found any information on
> > approaching deterministic builds by changing library and kernel
> > functions to have deterministic behavior.  Has anybody done this?
> >
> > For example, I would imagine if I needed timestamps to no longer be a
> > factor, I might change how the current time is reported to the build
> > environment, such that it is always precisely equal to the time of
> > last modification of the source package.  Similarly /dev/*random
> > should return deterministic numbers seeded by perhaps the hash of the
> > source package and all dependencies.
> >
> > Has there been a discussion of this somewhere?
>
> I'm not sure if there has been an on-the-record discussion of this
> anywhere, but I have thought about similar things re: random numbers.
> Maybe this thread is the time to discuss? :)
>
> - Dave
>

[-- Attachment #2: Type: text/html, Size: 2998 bytes --]

  reply	other threads:[~2016-03-20 16:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-20 10:04 Deterministic Library Calls when Building Karl Semich
2016-03-20 12:51 ` Thompson, David
2016-03-20 16:53   ` Karl Semich [this message]
2016-03-20 17:35     ` Jookia
2016-03-20 21:05     ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABnEbCFsKEa3VQ1QeMgRZqL2n-b+d1KPdMw1qiya6XW2zvmOaA@mail.gmail.com \
    --to=fuzzytew@gmail.com \
    --cc=dthompson2@worcester.edu \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).