0:00:00.762,0:00:02.081
Welcome and good morning
0:00:03.719,0:00:07.221
This is the reproducible builds team,[br]talking about
0:00:07.221,0:00:09.941
"Stretching out towards trustworthy[br]computing"
0:00:12.280,0:00:19.921
[Applause]
0:00:22.281,0:00:25.881
We're 4 on stage, but actually this is a[br]team effort.
0:00:25.881,0:00:30.521
All these people listed here have[br]contributed to the project at one point.
0:00:30.521,0:00:33.191
The 4 of us, that's
0:00:33.191,0:00:34.161
Lunar − me
0:00:34.161,0:00:35.282
there's Dhole,
0:00:35.282,0:00:36.381
Chris Lamb − lamby
0:00:36.381,0:00:37.601
and Holger.
0:00:38.540,0:00:42.571
But actually, this is DebConf and so a lot[br]more of us have been or are
0:00:42.571,0:00:46.961
currently here and so, if you want to[br]thank anybody that is working on this
0:00:46.961,0:00:49.182
you need to actually thank all of[br]these folks
0:00:49.182,0:00:50.981
'cause, yay.
0:00:51.421,0:00:56.201
[Applause]
0:00:57.331,0:00:59.601
[Holger] The people in blue are here.
0:01:03.902,0:01:05.570
[Lunar] Let's get started.
0:01:05.570,0:01:07.884
Quick recap on what we're talking[br]about.
0:01:07.884,0:01:10.902
We have software, it's made from source.
0:01:10.902,0:01:15.032
Source is readable by humans or at least[br]a good amount of humans.
0:01:15.032,0:01:17.443
In this room it's good.
0:01:17.443,0:01:24.180
Binary, readable by computer and some[br]tiny fraction of humanity.
0:01:24.180,0:01:30.040
Going from source to binary is called[br]build, or like building or compiling
0:01:30.040,0:01:33.181
and we're doing free software and[br]free software is awesome because
0:01:33.181,0:01:37.541
we can actually run these binaries like[br]we want
0:01:37.541,0:01:44.001
We can actually study the software, how[br]it's been made by studying the source
0:01:44.001,0:01:48.541
and by studying the source we can assess[br]that it does what it's supposed to do
0:01:48.541,0:01:50.741
and not something else that does not
0:01:50.741,0:01:56.461
have malware, or trojans or security bugs
0:01:56.461,0:02:00.822
So we have the binary that can be used,[br]fine.
0:02:00.822,0:02:04.021
We have the source that can be verified.
0:02:04.021,0:02:10.461
Problem is that right now, the only way we[br]know that a binary that we get…
0:02:10.461,0:02:15.681
We have to trust a website or a Debian[br]repository that says
0:02:15.681,0:02:18.261
"Well, this binary has been made with this[br]source"
0:02:18.261,0:02:23.001
But there's no way we can actually prove[br]that.
0:02:23.001,0:02:27.400
This is actually a problem that has been[br]well explained by
0:02:27.400,0:02:33.541
Mike Perry and Seth Schoen at the 31c3[br]in Hamburg last december.
0:02:33.541,0:02:41.481
For example, Seth Schoen made a proof of[br]concept exploit for the Linux kernel
0:02:41.481,0:02:52.061
that when GCC was called, the kernel would[br]without modifying anything on the disk
0:02:52.061,0:02:58.962
when the kernel detects that GCC is going[br]to read a C file, it will insert some
0:02:58.962,0:03:06.260
extra lines of code, and these lines of[br]code can be a very bad thing
0:03:06.260,0:03:09.100
in the case of 31c3 talk I was just[br]recalling.
0:03:09.100,0:03:17.901
Actually, you can even have developers[br]who are in very good faith, who have
0:03:17.901,0:03:21.302
totally secure dev machines, or they[br]thought they have,
0:03:21.302,0:03:24.361
who have reviewed all their source code[br]for any bugs
0:03:24.361,0:03:31.022
and we would still get totally owned as[br]soon as their computer gets compromised
0:03:31.022,0:03:34.122
or one of the build demons from Debian[br]gets compromised for example.
0:03:34.122,0:03:41.241
This is not, like, hypothetical threats[br]here we're discussing
0:03:41.241,0:03:45.801
A couple of months after Seth an Mike's[br]talk at 31c3,
0:03:45.801,0:03:48.940
the Intercept revealed from the Snowden[br]leaks
0:03:48.940,0:03:56.281
that at a CIA conference in 2012, one[br]of the talks that happened
0:03:56.281,0:03:58.921
was about a project called Strawhorse.
0:03:58.921,0:04:04.942
Strawhorse is about modifying Apple XCode,[br]which is the development environment
0:04:04.942,0:04:08.861
for MacOS 10 and iOS applications
0:04:08.861,0:04:11.140
and well, they were modifying XCode so[br]it would produce,
0:04:11.140,0:04:13.482
without the developer knowing,
0:04:13.482,0:04:23.021
binaries with trojans, malware,[br]watermarked binaries, lots of bad things.
0:04:23.181,0:04:25.401
So, solution:
0:04:25.401,0:04:29.421
enable anyone to reproduce identical[br]binary packages from a given source.
0:04:29.421,0:04:34.901
Because if using a source, using the same[br]environment,
0:04:34.901,0:04:39.981
multiple people on different computers, on[br]different networks, at different times,
0:04:39.981,0:04:42.881
can all get the same thing[br]from the same source
0:04:42.881,0:04:44.621
all the same binary, byte for byte,
0:04:44.621,0:04:47.081
then there's a good chance that…
0:04:47.081,0:04:54.881
Well, everybody could be owned,[br]but let's be more joyful and say that
0:04:54.881,0:04:58.841
probably, if everybody gets the same[br]result, there was actually no problem
0:04:58.841,0:05:01.381
and everybody is safe.
0:05:01.841,0:05:04.461
We call that solution[br]"reproducible builds"
0:05:06.661,0:05:07.684
Yay.
0:05:08.481,0:05:10.562
[Applause]
0:05:12.721,0:05:14.681
Actually, it's not only about security.
0:05:14.681,0:05:19.061
For Debian, we have, if you're doing[br]"Multi-arch: same" packages,
0:05:19.061,0:05:24.880
well they only have the same bytes if[br]they are built for different architectures,
0:05:24.880,0:05:27.800
the files in the package.
0:05:27.800,0:05:34.462
Debug packages, you can create at a later[br]time, if you forgot to have debug packages
0:05:34.462,0:05:35.741
in the first place,
0:05:35.741,0:05:42.480
you can pass the no-strip option later and[br]because the package is reproducible,
0:05:42.480,0:05:46.582
you will get the debug symbols that work[br]for software that has been shipped already
0:05:46.582,0:05:50.360
We do early detection of FTBFS that way
0:05:50.360,0:05:53.581
because if we try pretty quickly[br]to reproduce a build,
0:05:53.581,0:05:55.141
then it has to work.
0:05:55.141,0:05:58.321
It's useful for build profiles.
0:05:58.321,0:06:01.682
We can get smaller .deb deltas,
0:06:01.682,0:06:05.381
because from one version to the next we[br]might have the same content.
0:06:05.381,0:06:08.861
We can do validation of cross-builds,
0:06:08.861,0:06:11.721
Helmut Grohne can talk to you about that.
0:06:11.721,0:06:16.702
And also, Niels Thykier told me that
0:06:16.702,0:06:21.081
he was very interested in reproducible[br]builds because it would enable him to
0:06:21.081,0:06:23.621
test debhelper better, because
0:06:23.621,0:06:28.510
if the package builds reproducibly,[br]then he makes a change to debhelper
0:06:28.510,0:06:32.111
he can rebuild the package ???
0:06:32.111,0:06:36.131
the same version of a package with a newer[br]debhelper and see what has changed
0:06:36.131,0:06:39.921
and this change can be isolated to only[br]what he has worked on debhelper
0:06:39.921,0:06:41.601
for example.
0:06:43.211,0:06:45.042
And, oh my.
0:06:45.042,0:06:47.820
The whole world is watching us.
0:06:47.820,0:06:56.482
Since two years or a year and a half ago,[br]everybody I meet in security conference,
0:06:56.482,0:06:59.101
in hacker conference, in free software[br]conference is like
0:06:59.101,0:07:01.160
"Oh you're working on that,[br]that's awesome."
0:07:01.160,0:07:08.621
And, I mean, I've been the one doing quite[br]a lot of talks, and everybody comes to me
0:07:08.621,0:07:11.102
and I'm like "Wow wow, this is way bigger",
0:07:11.102,0:07:15.682
but we're actually leading the field here.
0:07:15.682,0:07:18.580
Yay Debian.
0:07:18.580,0:07:25.560
[Applause]
0:07:25.952,0:07:29.320
[Holger] So, we are not the only ones [br]leading the field,
0:07:29.320,0:07:33.241
Bitcoin and Tor made their software[br]reproducible before us,
0:07:33.241,0:07:36.901
Coreboot also succeeded, if you build[br]Coreboot without any payload,
0:07:36.901,0:07:38.561
that's 100% reproducible.
0:07:38.561,0:07:43.702
FreeBSD has a page on their wiki since[br]2013
0:07:43.702,0:07:48.840
saying there are 5 reproducibility issues[br]in their base system.
0:07:48.840,0:07:51.861
We're at the moment trying to[br]confirm this.
0:07:51.861,0:07:57.080
On jenkins.debian.net, I've also set up[br]now tests for FreeBSD, NetBSD,
0:07:57.080,0:07:58.921
Coreboot and OpenWrt.
0:07:58.921,0:08:02.881
So if you go to[br]reproducible.debian.net/
0:08:02.881,0:08:04.901
you get that tested.
0:08:04.901,0:08:07.941
And there's more in the pipeline.
0:08:07.941,0:08:10.981
There are other projects interested[br]as well.
0:08:10.981,0:08:15.121
NetBSD also has a variable MKREPRO[br]which you can set
0:08:15.121,0:08:17.162
and that builds reproducibly.
0:08:17.162,0:08:20.281
Though they think "I'm keeping some[br]timestamps it's fine" and then
0:08:20.281,0:08:21.901
filtering them out later".
0:08:21.901,0:08:23.201
We disagree.
0:08:23.201,0:08:28.400
So this is how Debian looks like,[br]Debian Sid,
0:08:28.400,0:08:30.020
but this is a lie.
0:08:30.020,0:08:31.601
This is not the truth.
0:08:31.601,0:08:33.921
This is just our test setup.
0:08:33.921,0:08:35.659
Sid is not like this.
0:08:35.659,0:08:40.100
For Sid, it's all orange, there's zero[br]reprodicibility in Sid today.
0:08:40.100,0:08:43.962
But we'll talk now and in the following[br]round table,
0:08:43.962,0:08:46.781
it's to actually make Sid reproducible.
0:08:46.781,0:08:52.461
The current status is
0:08:52.461,0:08:57.981
we're working on this in Debian since[br]two years ago.
0:08:57.981,0:09:01.941
We have weekly reports about our project[br]now since May
0:09:01.941,0:09:07.201
and we've given several talks, especially[br]in the last year
0:09:07.201,0:09:11.422
and all these talks, presentation, also[br]other stuff is linked in the wiki.
0:09:11.422,0:09:14.921
There's a page with information about[br]Debian, these BSDs,
0:09:14.921,0:09:18.960
other Linuxes, upstream softwares[br]all on this wiki.
0:09:22.850,0:09:26.561
Since DebConf14, which is merely[br]a year ago,
0:09:26.861,0:09:28.720
we've made quite some changes.
0:09:28.720,0:09:32.781
We have introduced[br]strip-nondeterminism
0:09:32.781,0:09:38.880
which is called by dh at the end[br]of the build of the package
0:09:38.880,0:09:45.463
and will normalize some things[br]which Chris will explain later
0:09:45.463,0:09:50.041
We have decided on a fixed build path
0:09:50.041,0:09:53.761
because the build path is leaked[br]in the binaries and several things
0:09:53.761,0:09:57.083
We didn't find a way yet to make[br]the build path arbitrary.
0:09:57.083,0:10:03.461
We designed a way to record the build[br]environment
0:10:03.461,0:10:08.061
because to rebuild, you need to recreate[br]the build environment.
0:10:08.061,0:10:11.621
We set up this Jenkins setup.
0:10:11.621,0:10:17.381
We wrote diffoscope which used to be[br]called debbindiff
0:10:17.381,0:10:21.401
which shows differences between two[br]packages or two directories or
0:10:21.401,0:10:23.601
two filesystems by now.
0:10:23.601,0:10:30.931
There's SOURCEDATEEPOCH, which is a way[br]that the tools expose
0:10:30.931,0:10:33.691
the last modification of the source.
0:10:33.691,0:10:37.280
Because the build date, people want to[br]include the build date
0:10:37.280,0:10:39.461
because they think this is a [br]meaningful indication:
0:10:39.461,0:10:42.261
when a build was done,[br]which software used.
0:10:42.462,0:10:45.565
But if the build always recreates [br]the same results
0:10:45.565,0:10:47.340
the build date becomes meaningless
0:10:47.340,0:10:50.681
and the really interesting thing is[br]the latest modification of the source.
0:10:52.391,0:10:55.841
We have written patches for the tools
0:10:58.081,0:11:03.591
[Lunar] strip-nondeterminism:[br]is Andrew Ayer in the audience?
0:11:03.591,0:11:05.921
Yay! He did it!
0:11:05.921,0:11:12.361
It's written in Perl because we didn't[br]want to have a new build dependency
0:11:12.361,0:11:13.564
in all Debian packages.
0:11:13.564,0:11:18.443
Basically it takes anything and tries[br]to normalize it as much as it can
0:11:18.443,0:11:27.101
replacing timestamps or file permissions[br]or removing some issues.
0:11:27.101,0:11:30.901
It's working very well on many formats, [br]it's meant to be extensible
0:11:30.901,0:11:38.000
so we can actually add more things and[br]it's run by dh at the end of the process, as Holger said.
0:11:38.000,0:11:45.422
The .buildinfo is currently a proposal [br]we have not yet totally agreed
0:11:45.422,0:11:48.581
but we are generating them as part [br]of the test we have
0:11:48.581,0:11:56.882
and basically it's a new control file that[br]will tie the sources, the generated binary
0:11:56.882,0:12:00.560
the packages that were used to build this[br]binary and their version.
0:12:00.560,0:12:08.503
The idea is that we can use this file to[br]reinstall all the specific versions from snapshot
0:12:08.503,0:12:16.701
So we recreate the same build environment[br]then we can just start the build from that source
0:12:16.701,0:12:20.981
that was mentioned and see if the binary[br]that has been generated matches.
0:12:23.051,0:12:28.403
What it looks like for now, you see there is[br]a source binary, the build path
0:12:28.403,0:12:33.881
because currently we don't have any good[br]post-processing tool for buildpaths
0:12:33.881,0:12:41.061
in elf and dwarf binaries, we just decided[br]to specify the build path so when we do
0:12:41.061,0:12:44.941
a later rebuild we use that path and be safe.
0:12:44.941,0:12:51.522
The source is dsc, the binary is .deb and[br]a list of packages with the versions.
0:12:53.322,0:13:01.931
We currently use the base files version[br]to know which Debian release is to be used
0:13:01.931,0:13:04.044
as the basis.
0:13:11.331,0:13:17.851
[Holger] The general procedure for testing is:[br]we build the source, we save the results,
0:13:17.851,0:13:22.663
we modify the environment and we build[br]it again and compare the results.
0:13:22.663,0:13:31.741
That started as a shell script last year which I[br]put on jenkins and then it exploded a bit
0:13:32.002,0:13:36.141
and now we have 67 jenkins jobs running on[br]7 hosts.
0:13:36.141,0:13:44.821
Since last week we have 4 armhf small boards[br]where we will be able to test armhf,
0:13:44.821,0:13:46.001
but very slowly.
0:13:46.001,0:13:48.901
We have two new amd64 build nodes.
0:13:48.901,0:13:53.041
The code is now split into Python and bash[br]scripts.
0:13:53.041,0:13:58.541
For all the other distro testing there's a[br]lot of bash code now which is mostly
0:13:58.541,0:14:04.741
boilerplate and it's 5 lines or something[br]to build FreeBSD and 5 lines to build NetBSD
0:14:04.741,0:14:08.841
but there's 100 lines boilercode around so it's[br]really not that much code.
0:14:08.841,0:14:12.521
We do test Testing, Unstable and Experimental.
0:14:12.521,0:14:15.561
For arm we only start with Unstable.
0:14:15.561,0:14:22.063
We do like hardware so if you have hardware[br]to donate to us, that would be great,
0:14:22.063,0:14:24.961
we need ssh and then root basically.
0:14:26.921,0:14:34.150
We are testing Coreboot, OpenWrt and the[br]BSD's, soon I will also set up a Fedora test
0:14:34.150,0:14:39.681
I don't want to test all the 20,000 Fedora[br]packages but just 200 or something:
0:14:39.681,0:14:44.121
the base system of Fedora to examine how[br]rpm works
0:14:44.121,0:14:47.741
to get really the whole Free Software world[br]reproducible.
0:14:47.741,0:14:53.460
This is all run on ProfitBricks hardware [br]since 2002, so thanks to ProfitBricks.
0:14:56.861,0:15:00.081
This is the variations we do for Debian.
0:15:01.741,0:15:07.261
It's the hostname, username, timezone,[br]locale.
0:15:07.261,0:15:14.100
Chris will explain what modifications [br]this causes, variances...
0:15:14.100,0:15:19.061
We are not testing at the moment differences[br]in date so the date is always the same
0:15:19.061,0:15:20.381
the time is a bit different.
0:15:20.381,0:15:25.521
[Lunar] Well almost! Because we cheat with[br]the timezone, we use one timezone that is
0:15:25.521,0:15:32.241
GMT-14 and then GMT+12 so it's more than[br]24 hours appart.
0:15:32.650,0:15:35.941
[Holger] On the first of the month we[br]sometimes find new bugs where there's
0:15:35.941,0:15:38.002
packages which record the month.
0:15:41.002,0:15:43.821
We don't have variations of the CPU type[br]at the moment.
0:15:45.782,0:15:50.901
Both time and CPU type variations, we'll[br]have them about one or two weeks
0:15:50.901,0:15:53.663
the nodes are being prepared at the moment.
0:15:53.663,0:16:00.801
Then we will test all the meaningful[br]variations we could think of.
0:16:01.234,0:16:05.021
There will be probably some packages which[br]build different according to the number of
0:16:05.021,0:16:11.141
number of CD drives attached or whatever[br]things, but those will be find by you.
0:16:12.491,0:16:16.891
[Lunar] We are doing all these tests because[br]we want when you rebuild a package on
0:16:16.891,0:16:22.022
your machine that if any this is different from[br]the build deamons in Debian you get
0:16:22.022,0:16:23.291
the same results.
0:16:23.291,0:16:30.011
We use this to detect this problems early[br]before you actually a false positive that we have
0:16:30.011,0:16:34.151
to investigate when someone rebuilds a[br]package on their machine.
0:16:37.321,0:16:42.541
To understand the difference that we found[br]from one build to the other.
0:16:42.541,0:16:50.541
It started also as a 10 lines shellscript[br]and then it felt okeyish
0:16:50.541,0:16:51.941
and so Python!
0:16:51.941,0:16:57.601
And now it's a lot of code and it actually[br]grew way beyond a Debian package.
0:16:57.601,0:17:03.041
We changed the name, it was called debbindiff[br]but it's absolutely not tied to Debian anymore.
0:17:03.041,0:17:07.421
It's called diffoscope, thanks to Jocelyn[br]for the name.
0:17:07.421,0:17:12.020
Basically what it does: it tries to get to[br]the bottom of what is different between
0:17:12.020,0:17:13.801
two archives or directories.
0:17:13.801,0:17:22.260
Because it's not useful to compare bytes that[br]are compressed by gzip or xz, that will not
0:17:22.260,0:17:27.021
lead you to understand what is different[br]you need to uncompress and look at
0:17:27.021,0:17:32.801
uncompressed data, and if the thing actually[br]compressed is a tarball, you might actually
0:17:32.801,0:17:35.060
want to compare the files inside the tarball.
0:17:35.060,0:17:42.261
If there is a PDF inside this archive, you[br]don't want to compare the bytes of the PDF
0:17:42.261,0:17:43.981
you want to compare the text of the PDF.
0:17:43.981,0:17:49.681
So this is basically what diffoscope does,[br]it tries to transform anything that is
0:17:49.681,0:17:56.601
a container and compare things in this[br]container and if they can be transformed into
0:17:56.601,0:18:01.181
a human readable form it will try to do[br]that, and compare these human readable form.
0:18:01.181,0:18:05.151
And if it doesn't find any difference but[br]there are still differences from the bin
0:18:05.151,0:18:07.322
it will fall back to binary comparison.
0:18:07.521,0:18:12.681
Try it, extend it; it's Python, it's modular,[br]it's great.
0:18:12.681,0:18:23.041
It already supports squashfs, ISO, rpm,[br]gettext, mo files files and so many different things.
0:18:23.041,0:18:29.981
You can have HTML output like that,[br]so this is what is displayed on many
0:18:29.981,0:18:34.021
examples we've shown so far, and also[br]to make it easier for copy paste
0:18:34.021,0:18:38.141
and post processing we have the text output.
0:18:38.141,0:18:43.060
You can also use it to review packages before[br]uploading them to Debian.
0:18:43.060,0:18:49.161
It does fuzzy matching, so even if the[br]directory is different in the archive it will
0:18:49.161,0:18:52.441
find it like git does.
0:18:52.441,0:18:58.561
It has grown way more beyond just build[br]reproducibly. A useful tool.
0:19:01.451,0:19:07.371
[Dhole] In order to solve timestamp issues, we are[br]proposing the SOURCEDATEEPOCH variable.
0:19:07.381,0:19:11.851
This is because most of the times having[br]the build date embedded in a package
0:19:11.851,0:19:16.391
is not useful for the user, because you could[br]take a really old package and build it today
0:19:16.391,0:19:19.001
and that day would not be useful.
0:19:19.001,0:19:25.740
We are standardizing a replacement for build[br]dates so that tools can use it.
0:19:25.740,0:19:31.961
When this value is set, the tool instead of[br]embedding the current date, it will embed
0:19:31.961,0:19:37.501
the date taken from SOURCEDATEEPOCH which[br]will contain a Unix epoch timestamp.
0:19:37.501,0:19:42.881
This is a general solution we are trying to[br]standardize so that not only Debian uses it,
0:19:42.881,0:19:48.020
but other Free Software projects and [br]distributions and in the case of Debian,
0:19:48.020,0:19:52.461
we set this variable to the latest Debian[br]changelog entry timestamp.
0:19:55.101,0:20:00.721
We have already been sending patches to[br]different packages, mostly it's documentation
0:20:00.721,0:20:06.061
generation. So here's a list of bugs that[br]we have opened which have been closed
0:20:06.061,0:20:12.291
and merged; so it's help2man, epydoc,[br]ghostscript, texi2html and sphinx.
0:20:12.291,0:20:18.991
We are both sending these patches to Debian[br]and upstream so all the distributions can
0:20:18.991,0:20:28.161
use them, and we have also been sending[br]patches to other packages which are still
0:20:28.161,0:20:32.160
open, so we encourage you to take a look[br]at these packages if you are the maintainer
0:20:32.160,0:20:34.622
and merge the patch.
0:20:36.161,0:20:41.181
[Lunar] Thanks to Daniel Kahn Gillmor and[br]Ximin Luo for pushing this proposal forward.
0:20:41.181,0:20:45.541
And also lots of these patches have been[br]written by Akira and Dhole as part of their
0:20:45.541,0:20:48.681
Google Summer of Code, and you work really[br]great.
0:20:52.021,0:20:56.741
[Applause]
0:21:02.722,0:21:07.721
[Dhole] The gcc patch is: gcc uses two[br]macros which are _DATE and TIME_
0:21:07.721,0:21:14.300
which embed the timestamp and I wrote a[br]patch so that if SOURCEDATEEPOCH is set
0:21:14.300,0:21:18.740
instead of adding the current time, it takes[br]the time from that variable.
0:21:18.740,0:21:25.560
I sent this patch to gcc, it's still there[br]forgotten with many other patches
0:21:25.560,0:21:29.401
but hopefully at some point they will[br]realize that this is interesting and they
0:21:29.401,0:21:30.421
will merge it.
0:21:38.881,0:21:46.331
[Lamby] Hey. Let's very quickly run you[br]through some really simple ways
0:21:46.331,0:21:50.441
to fixing packages. The details don't[br]necessarily matter, it's just to give you
0:21:50.450,0:21:55.641
of what needs to be changed and basically[br]to point out that it's not rocket science.
0:21:55.641,0:21:57.661
So you can just come in and jump in.
0:21:57.661,0:22:07.861
For example gzip, it's a very old tool[br]and they decided to add timestamps when
0:22:07.861,0:22:11.942
you generate it, but it's an easy fix, you[br]just add -n flag.
0:22:11.942,0:22:19.981
Some other things easy to change: some[br]Python stuff had tag_date=True, which
0:22:19.981,0:22:25.081
I don't know if you can see it but adds a[br]timestamp to eggs. You just change it to
0:22:25.081,0:22:26.401
False to get rid of it.
0:22:26.401,0:22:34.342
Static libraries, they are just ar archives[br]so the same format as .deb, and you
0:22:34.342,0:22:37.941
can just use binutils or strip-nondeterminism[br]tool.
0:22:37.941,0:22:44.361
PNG has timestamps for some reason, you can[br]get rid of them, that's ImageMagick and it's
0:22:44.361,0:22:49.301
a bit ugly, but also strip-nondeterminism[br]gets rid of it.
0:22:49.301,0:22:54.641
Tarballs are quite interesting, they will[br]by default capture user and group
0:22:54.641,0:22:58.341
you just pass --owner=root bla bla bla...
0:22:58.341,0:23:04.502
Ordering, this is interesting as well, it[br]will usually use file system ordering
0:23:04.502,0:23:10.641
which is completely non-deterministic. So[br]you need to sort with LC_ALL=C.
0:23:14.741,0:23:18.781
[Lunar] Think about the locale! Because[br]sorting order varies from local to the next.
0:23:22.681,0:23:28.081
[Lamby] They also take timestamps, again[br]you can set --mtime or you can mock around
0:23:28.081,0:23:31.041
with find/xargs/touch bla bla...
0:23:31.041,0:23:37.401
Lots of other files have timestamps: Erlang[br]files for no reason, even upstream don't
0:23:37.401,0:23:39.601
know why they added a timestamp.
0:23:42.481,0:23:48.601
We have now a patch for SOURCEDATEEPOCH,[br]which I think landed a couple days ago.
0:23:49.881,0:23:57.141
Here's an interesting one, not necessarily[br]the current build timestamp, so this is a
0:23:57.141,0:24:04.642
timezone dependent date which Ruby loads[br]and then saves incorrectly as your local time.
0:24:04.642,0:24:07.420
This gets mangled, so that's patching.
0:24:07.420,0:24:14.501
I'm going from changing individual packages[br]to more toolchain things as you can see.
0:24:14.501,0:24:21.001
Upstream configure scripts, you can maybe[br]see the top that it just uses hostname
0:24:21.001,0:24:26.241
for no reason. Sometimes you can override[br]it in debian/rules just by exporting something
0:24:26.241,0:24:31.921
or passing a variable to dh_autobuild or[br]whatever. That's just a little bit more
0:24:31.921,0:24:33.880
involved, you have to look at it more[br]carefully.
0:24:33.880,0:24:40.441
Perl hash order, lot of Perl uses data[br]Data::Dumper to just output a bunch of stuff which
0:24:40.441,0:24:46.761
is just not deterministic. So often just[br]setting Sortkeys, but sometimes it's
0:24:46.761,0:24:48.461
a completely different solution.
0:24:48.461,0:24:53.321
Header files, so you can maybe see that[br]they are using the timestamp essentially
0:24:53.321,0:24:59.481
as a unique identifier, you probably have[br]to start re-writing these something saner
0:24:59.481,0:25:03.901
because this is a wrong use of timestamp[br]anyway.
0:25:03.901,0:25:12.801
More Makefiles, the deeper they timestamp[br]in the upstream package the more you have
0:25:12.801,0:25:15.381
to start patching, so these kind of start[br]sucking a little.
0:25:15.381,0:25:21.021
We've made a lot of toolchain changes, some[br]already mentioned, some of them already
0:25:21.021,0:25:25.201
merged, see more in this link. Again,[br]details don't matter, just check it out
0:25:25.201,0:25:29.781
it isn't crazy, it's just working out[br]what's different.
0:25:29.781,0:25:35.061
In terms of the work done we've sent these[br]many patches: two patches a day,
0:25:35.061,0:25:37.900
which is not too bad, on average.
0:25:40.170,0:25:46.442
[Applause]
0:25:48.111,0:25:50.762
[Holger] I can't clap because I sent three[br]or something like that
0:25:52.510,0:25:53.742
[Lamby] Holger does three per day.
0:25:54.841,0:25:59.642
And this doesn't count other bugs we found[br]in the process of building packages, like
0:25:59.642,0:26:00.801
fail to build.
0:26:00.801,0:26:08.361
This is blue the ones that are open and[br]orange are done.
0:26:08.361,0:26:14.001
You can see that someone went a bit crazy[br]in February filing bugs and eventually they
0:26:14.001,0:26:17.201
were being fixed; slowly.
0:26:18.421,0:26:23.591
[Holger] And actually we filed more bugs[br]because the fail to build from source bugs
0:26:23.591,0:26:28.702
are excluded, I think we filed 300 FTBFS[br]in the last two or three months.
0:26:30.851,0:26:34.400
[Lamby] And those include fail to build[br]because of reproducibility things as well
0:26:34.400,0:26:36.142
but we haven't split them up.
0:26:40.022,0:26:46.641
[Lunar] What's left to be done because[br]Holger said "the graph is a lie".
0:26:46.641,0:26:58.241
The main thing that is blocking a lot of[br]work is dpkg. Right now the output of dpkg
0:26:58.241,0:27:09.261
will be not deterministic 100% of the time,[br]because of timestamps and at least the
0:27:09.261,0:27:15.381
file ordering. We also have a patch that[br]creates these .buildinfo files that we've
0:27:15.381,0:27:22.422
shown that works. It's not submitted yet[br]to dpkg because we need to agree on the
0:27:22.422,0:27:27.021
format. At least we have ftpmaster or[br]maybe dpkg, well we have a lot of people
0:27:27.021,0:27:29.500
and that's what we are going to do the[br]next hour.
0:27:29.500,0:27:38.560
Debhelper also has a few changes; the make[br]mtimes, debhelper might also not be
0:27:38.560,0:27:42.781
best place, maybe we want that in dpkg.
0:27:42.781,0:27:47.501
I've been trying to put patches in tar so[br]we can make it easier. It's complicated to
0:27:47.501,0:27:54.240
see where's the best place but so far we've[br]been doing our tests with this frame and it works.
0:27:54.240,0:27:59.961
[Holger] In our repository we have these[br]packages with these bugs fixed so when
0:27:59.961,0:28:03.623
you want to test reproducibility issues on[br]your own machine you need to use the
0:28:03.623,0:28:07.192
repository which has these patches applied[br]at the moment.
0:28:07.192,0:28:10.201
In pure sid you cannot create reproducible[br]packages.
0:28:10.461,0:28:18.201
[Lunar] I heard that the SOURCEDATEEPOCH[br]patch is in git already, so it's going to happen.
0:28:18.201,0:28:26.640
cdbs also needed to export SOURCEDATEEPOCH[br]and we are starting to do more infrastructure
0:28:26.640,0:28:34.381
work: Josch mainly and Akira on sbuild,[br]because we wanted to have this
0:28:34.381,0:28:40.421
srebuild script, where you give it a[br]buildinfo and it will do the rebuild and
0:28:40.421,0:28:47.101
it needs changes in build daemon for the[br]build path and also a couple of changes in
0:28:47.101,0:28:48.940
sbuild itself.
0:28:48.940,0:28:53.301
[Holger] And the script is not ready yet,[br]this "Finish" means it uses our repository
0:28:53.301,0:28:56.962
at the moment, we need to change it to only[br]use Sid and snapshot.
0:28:56.962,0:29:01.700
[Lunar] So there is the buildd issue that[br]we need to discuss
0:29:01.700,0:29:08.742
and we also need to see how we could include[br]or not, or somewhere give this buildinfo
0:29:08.742,0:29:12.501
control file to the world so they can[br]rebuild the packages, so it's not yet
0:29:12.501,0:29:14.421
clear where's the best place to store[br]them.
0:29:14.421,0:29:20.821
Because adding 22,000 files, some[br]people get cranky of this idea.
0:29:20.821,0:29:25.841
[Holger] It's more than 22,000 files, it's[br]22,000 source packages multiplied by
0:29:25.841,0:29:30.400
10 architectures; but there's a lot of[br]arch builds so that's probably 100,000
0:29:30.400,0:29:37.561
buildinfo files, multiplied by Stretch and[br]Sid, so it's 200,000 files or more on
0:29:37.561,0:29:40.001
the file servers and on the mirrors we[br]would like to have it.
0:29:40.001,0:29:43.881
That's the same amount of files which are[br]currently there. The mirror operators are
0:29:43.881,0:29:49.001
currently not happy, they will not take it,[br]so our current idea is just concatenate
0:29:49.001,0:29:54.681
all these files into one file that's 140 MB[br]uncompressed, 40 MB compressed.
0:29:54.681,0:29:56.441
That's easier to handle.
0:29:56.441,0:29:59.880
And then probably have a service[br]buildinfo.debian.org where you can
0:29:59.880,0:30:02.780
download individual buildinfo files if you[br]need them.
0:30:03.660,0:30:09.901
[Lunar] And so when we will be done with[br]all that we can maybe add a final patch
0:30:09.984,0:30:16.301
it would be to Debian policy, mandating[br]Debian packages be reproducible.
0:30:19.511,0:30:22.731
[Applause]
0:30:24.232,0:30:31.151
I can say again that the dream of mine is[br]that we would stop uploading .deb when
0:30:31.151,0:30:37.881
we upload a package, but instead just upload[br]the hash of the binary, have the buildd
0:30:37.881,0:30:43.051
build again this package and only if these[br]two match they can enter the archive.
0:30:43.051,0:30:47.864
So we are sure that at least the two[br]machines, the developer machine and the
0:30:47.864,0:30:50.521
build deamon agree that they've built the[br]same thing.
0:30:51.021,0:30:55.401
[Applause]
0:30:58.162,0:31:02.781
[Holger] I share this dream but I think[br]having this in policy is a mass requirement
0:31:02.781,0:31:15.920
sadly something only for Stretch + 1, but[br]I'm curious if we had fixed dpkg and
0:31:15.920,0:31:21.661
debhelper now, would you think we should[br]upgrade all these wishlist bugs to important now?
0:31:22.631,0:31:26.341
[Audience] Yes!
0:31:31.062,0:31:33.586
[Holger] We'll talk about this later soon.
0:31:34.322,0:31:36.642
[Lunar] But before that we actually have[br]work to do.
0:31:40.141,0:31:43.641
[Dhole] In order to fix your package, the[br]first thing you can do is go to
0:31:43.641,0:31:51.342
reproducible.debian.net/package, and you[br]can the web interface where you can see
0:31:51.342,0:31:56.190
notes on the package, we have tags to[br]identify different issues that make packages
0:31:56.190,0:31:59.180
not reproducible, with links to the wiki[br]about how to solve them.
0:32:04.811,0:32:08.742
[Holger] When you see this, you want to[br]click on this debbindiff link.
0:32:08.742,0:32:12.441
It's still called debbindiff not diffoscope,[br]this will show all the differences,
0:32:12.441,0:32:17.081
if there is a note. If the package is [br]unreproducible and there's no note
0:32:17.081,0:32:21.041
it will automatically display the[br]debbindiff, and if your package is fine
0:32:21.041,0:32:23.241
there's here a sun.
0:32:29.500,0:32:34.141
[Dhole] You can also see an entry in the[br]tracker, stating if your package is
0:32:34.141,0:32:35.481
reproducible or not.
0:32:38.751,0:32:45.601
You can also find information in DDPO and[br]DMD. You can find tips on the wiki it's
0:32:45.601,0:32:53.940
ReproducibleBuilds wiki, we are working on[br]a Howto to have detailed steps on different
0:32:53.940,0:33:01.141
issues and how to solve them. Lunar gave[br]a talk at CCCamp where there's many issues
0:33:01.141,0:33:05.462
really well explained and the solutions for[br]them.
0:33:05.462,0:33:11.261
You can also come to our irc channel which[br]is #debian-reproducible and ask for help
0:33:11.261,0:33:12.881
or go to the mailing-list.
0:33:14.241,0:33:21.231
In order to test locally if your package is[br]reproducible right now we are using a
0:33:21.231,0:33:29.401
script that uses pbuilder in a custom[br]configuration, you need to set up our
0:33:29.401,0:33:35.240
reproducible repository. In the Howto in[br]the wiki there's the steps on how to set up
0:33:35.240,0:33:38.861
the chroot and everything, it's documented[br]in the wiki.
0:33:38.861,0:33:44.282
Diffoscope is in unstable and today it's[br]going in Stretch.
0:33:44.282,0:33:53.961
We plan to add these scripts to rebuild[br]packages in different settings in debscripts
0:33:53.961,0:34:04.181
once dpkg is good, and we welcome you[br]tomorrow to the hacking session from
0:34:04.181,0:34:06.981
2 to 7 in Stockholm room.
0:34:10.461,0:34:15.201
[Lunar] That's for fixing your packages,[br]please do that. If you want to have even
0:34:15.201,0:34:18.742
more fun, then test your own package, join[br]us!
0:34:18.742,0:34:25.002
This is the past year of my life, it has[br]been awesome because the team has been
0:34:25.002,0:34:32.341
so great, it's been friendly atmosphere, lots of[br]new understanding so many things you didn't
0:34:32.341,0:34:39.241
want to learn about that you had to learn[br]about, and basically it feels very good to
0:34:39.241,0:34:46.462
be part of this actual changing the world[br]thing. It's just software but it has some
0:34:46.462,0:34:51.121
profound effect. I've been told that the[br]work we've been doing is being tossed
0:34:51.121,0:34:58.161
around in Cisco and Google and Facebook;[br]all these big dot com companies bla bla,
0:34:58.161,0:35:01.561
they actually want to do that as well even[br]though they are not doing Free Software,
0:35:01.561,0:35:03.401
which I find wired, but whatever.
0:35:03.401,0:35:09.701
So what do we do? We review packages, we[br]have these notes when we actually try to
0:35:09.701,0:35:13.031
identify, so when the maintainer comes[br]they don't have to think to much about
0:35:13.031,0:35:19.131
the problem and just fix it. We try to[br]identify common trends so when many
0:35:19.131,0:35:23.741
packages have the same problem we make an[br]entry and explain and maybe think about fixes
0:35:23.741,0:35:26.821
that could apply to the whole archive.
0:35:26.821,0:35:33.501
We work on this reproducible.debian.net[br]jenkins setup, the scripts.
0:35:33.501,0:35:41.441
We hack on the diffoscope tool, we make[br]strip-nondeterminism better, we propose
0:35:41.441,0:35:45.442
changes for the toolchains when there are[br]needs, some need a lot of patches,
0:35:45.442,0:35:59.322
most of the bugs we have reported on[br]individual packages have patches.
0:36:01.352,0:36:03.791
[Holger] Bugs have patches[br][Lunar] Yes!
0:36:04.261,0:36:08.801
And also we are actually writing some more[br]general documentation from the
0:36:08.801,0:36:15.182
understanding of these things we have been[br]having, we are preparing a reproducible
0:36:15.182,0:36:22.461
builds Howto to explain to the Free Software[br]world how they can do it so it's about some
0:36:22.461,0:36:26.541
of what Chris explained but also more[br]general consideration on what if you're
0:36:26.541,0:36:29.441
not Debian and you want your thing[br]reproducible when you distribute as an
0:36:29.441,0:36:35.720
independent vendor. So we want to work on[br]reference documentation so the whole world
0:36:35.720,0:36:37.421
can actually do that.
0:36:38.901,0:36:43.142
We do a lot of talks as you've seen and[br]it's been fun, and with all these
0:36:43.142,0:36:48.960
presentations we've made so far it's all[br]in git. And everybody is free to take one
0:36:48.960,0:36:52.941
of these slide decks and run with it[br]somewhere, translate it...
0:36:56.891,0:36:58.600
Questions?
0:37:01.240,0:37:04.161
We have to run with the microphone, because[br]there's no mic anymore.
0:37:14.221,0:37:17.201
[Question] I just wanted to make two quick[br]comments: so first of all diffoscope is
0:37:17.201,0:37:22.141
really awesome, not only for reproducibility[br]but also for example if you change your
0:37:22.141,0:37:27.400
debian/rules in some way and want to see if[br]the package is the same afterwards because
0:37:27.400,0:37:31.561
you just cleaned up a bit, that's really[br]awesome for that, so thank you.
0:37:31.561,0:37:37.481
And also I think the work you're doing now[br]is something that in 20 years time we're
0:37:37.481,0:37:41.340
going to look back towards it and think,[br]well, of course builds should be
0:37:41.340,0:37:44.481
reproducible, so thank you very much for[br]your work!
0:37:44.820,0:37:49.021
[Applause]
0:37:52.400,0:38:02.981
[Question] When reproducibility becomes[br]part of the Debian policy, will there be a
0:38:02.981,0:38:05.900
lintian --reproducible?
0:38:09.180,0:38:12.281
[Holger] I don't think lintian can detect[br]that because lintian works on the source
0:38:12.281,0:38:15.021
package and you need to build the package[br]for this.
0:38:15.681,0:38:20.580
[Lamby] Things that could be detected by[br]lintian from a static analysis point of view,
0:38:20.580,0:38:26.241
yeah I'm sure, like looking for gzip[br]without -n for example, but that wouldn't
0:38:26.241,0:38:28.941
be conclusive from lintian point of view.
0:38:29.361,0:38:33.061
[Lunar] One thing that I really wanted to[br]diffoscope at some point - the code is made
0:38:33.061,0:38:37.540
the way that it's possible - it's to have[br]hints so when it actually looks up
0:38:37.540,0:38:44.500
differences between two packages then you[br]can have an idea, suggest you: hey you need
0:38:44.500,0:38:49.800
to remove that timestamps, or you should[br]sort these keys. It's not done yet, but if
0:38:49.800,0:38:52.580
anybody wants to do patches it's totally[br]doable.
0:38:58.481,0:39:04.021
[Question] Thank you for the work, have[br]you thought about reproducible images?
0:39:04.620,0:39:06.001
[Holger] It's on the todo list.
0:39:07.701,0:39:15.061
Before images we need reproducible package[br]installation, and then we need reproducible
0:39:15.061,0:39:19.561
images like squashfs has some things which[br]are not reproducible, but the package
0:39:19.561,0:39:23.281
installation is not reproducible at the[br]moment because apt installs packages in
0:39:23.281,0:39:27.861
arbitrary order and then the post-inst[br]create for example users which get
0:39:27.861,0:39:32.682
user-ids in the order the packages are[br]installed, so for that to fix either apt
0:39:32.682,0:39:39.421
needs a way to install in a deterministic[br]order, but it's on the todo list file.
0:39:39.842,0:39:43.881
[Lunar] Pabs started a wiki page a couple[br]of months ago that is called reproducible
0:39:43.881,0:39:50.260
install. This is very important if we want[br]tools like Tails to actually be reproducible
0:39:50.260,0:39:54.740
so some people will work on that, we do[br]want to work on that.
0:39:54.740,0:39:58.541
[Lamby] It's quite a deep problem for[br]example d-i will install different stuff
0:39:58.541,0:40:02.261
depending on your hardware, so that's[br]immediately not reproducible.
0:40:02.261,0:40:04.681
It'd be great.
0:40:06.541,0:40:09.661
[Question] I've been working on a couple[br]of my packages to get them reproducible
0:40:09.672,0:40:16.001
build, but I was often wondering if I[br]should fix it in my package or actually
0:40:16.001,0:40:23.221
that it should be fixed in higher up and I[br]guess I've been adding some fixes to my
0:40:23.221,0:40:28.441
packages which may in the future even not[br]be needed anymore and then it's just
0:40:28.441,0:40:30.802
unnecessary code as well.
0:40:30.802,0:40:35.560
So how do you see where things should be[br]fixed and how should we as package
0:40:35.560,0:40:37.580
maintainers go about with this?
0:40:38.441,0:40:44.021
[Holger] There's many things which there's[br]the easy fix to whatever: set the timezone in
0:40:44.021,0:40:50.661
debhelper or better in dpkg to UTC, but[br]that will not fix the upstream bugs, so
0:40:50.661,0:40:56.560
actually it's better not to fix, set the [br]timezone or other things deterministically
0:40:56.560,0:41:00.721
in these tools but rather have them fixed[br]upstream, that's what we want.
0:41:00.721,0:41:06.941
Some things we will need to fix them in[br]dpkg to get a meaningful result but
0:41:06.941,0:41:11.662
basically we want rather these distributions[br]with just build from source which don't have
0:41:11.662,0:41:15.061
debian/rules and they just build with[br]upstream Makefiles, we want the fixes
0:41:15.061,0:41:17.321
to land there.
0:41:18.101,0:41:21.500
[Lunar] We've been experimenting for two[br]and this is a lot of trials and errors,
0:41:21.500,0:41:26.191
trying something, see how it fails, or[br]maybe we can do better than that and
0:41:26.191,0:41:30.021
changing. And I know this can be frustrating[br]at some point because you do changes
0:41:30.021,0:41:35.601
and they all become unneeded, but in the[br]end this is how we make stuff that matters.
0:41:35.601,0:41:40.981
And we move forward, it's not because we're[br]trying to make the big picture at once,
0:41:40.981,0:41:46.261
and I know in Debian we sometimes try to do[br]that, so we experiment and learn from it.
0:41:46.582,0:41:51.741
[Question] An example that I'm now looking[br]into is actually the documentation is built
0:41:51.741,0:41:57.761
for this package by looking in all the files[br]and generating but, for instances the
0:41:57.761,0:42:05.501
index file is sorted, but I guess upstream[br]would say: well, if you set some ordering
0:42:05.501,0:42:11.360
in your LC parameters you want this page[br]to be order as you want, instead of forcing
0:42:11.360,0:42:16.181
it in the sort, so I'm really wondering:[br]should I now upstream this or should
0:42:16.181,0:42:18.741
I just fix it in my rules because that's[br]the logical place?
0:42:20.571,0:42:29.361
[Lunar] Both. No, there's no good answer,[br]I'm quite a strong proponent on the idea
0:42:29.361,0:42:34.582
that if you use a computer you should be[br]able to talk and have the computer talk to
0:42:34.582,0:42:41.041
you in the language that you choose, so if[br]people want to have gcc error messages
0:42:41.041,0:42:45.321
in German, they should have it.
0:42:45.321,0:42:50.920
But local sorting, this is the kind of[br]LC_ALL that can be very local and that
0:42:50.920,0:42:54.181
you can do for just one tool, it's fine to[br]do that.
0:42:55.821,0:42:59.281
[Question] Do you have ideas on making[br]sources reproducible? Like upstreams
0:42:59.281,0:43:03.941
calling make dist, or this infamous[br]autogen.sh files?
0:43:06.742,0:43:12.461
[Lunar] I don't think that anybody in the[br]team has looked into that yet, source
0:43:12.461,0:43:22.661
files are easy to analyze way more than[br]binary packages so, it would still be great
0:43:22.661,0:43:29.781
to have easier ways; you have source[br]tarballs be byte for byte identical,
0:43:29.781,0:43:37.331
but it's not as an issue as it is for[br]binaries. If people want to look in that
0:43:37.331,0:43:39.041
they should.
0:43:43.561,0:43:48.701
[Question] Do you know a way to make git[br]archive build something reproducible?
0:43:50.441,0:43:51.832
[Lunar] Well pristine-tar
0:43:51.881,0:43:53.241
[Question] Yes, but without it.
0:43:54.461,0:43:58.301
[Holger] There's one tool. You want to use[br]a new one? Then write it.
0:44:01.681,0:44:04.902
Why not use that tool which does the job?
0:44:05.541,0:44:07.721
pristine-tar does it.
0:44:10.641,0:44:16.541
[Lunar] This is for source and so that's[br]another issue that what we are actually
0:44:16.541,0:44:17.801
currently working on.
0:44:21.751,0:44:25.911
[Holger] You're welcome to join the team and[br]extend our scope to sources.
0:44:28.582,0:44:30.641
[Lunar] How many questions, two?
0:44:33.052,0:44:35.540
Two more questions, two or three.
0:44:44.361,0:44:52.421
[Question] So if there is a couple of other[br]environment variables that could be set
0:44:52.421,0:44:59.241
in the environment to increase[br]reproducibility, where to put them?
0:44:59.241,0:45:07.743
In the rules file? Or in the generic build[br]environment of all packages, or where
0:45:07.743,0:45:09.680
should these things be placed?
0:45:13.442,0:45:20.000
[Lamby] It'd be nice if upstream fixed it,[br]so if we just change it in debian/rules
0:45:20.000,0:45:28.621
that's just only helping us, so often take[br]it upstream, would be the ideal solution.
0:45:28.621,0:45:30.631
Are you referring to something else?
0:45:31.901,0:45:40.131
[Question] For example many hashmaps have[br]randomized data in the hash function, so if
0:45:40.131,0:45:46.961
you have some code that relies on hash[br]order, at least some implementations of
0:45:46.961,0:45:56.991
hash functions are leaving them be seeded[br]rather than using something random for
0:45:56.991,0:46:02.681
a build thing, but you want the randomness[br]in your hash functions for normal users
0:46:02.681,0:46:10.941
because else your hashmaps get open[br]to attacks.
0:46:12.301,0:46:13.821
[Lamby] Correct, yes.
0:46:16.261,0:46:21.571
[Lunar] In these cases we send patches[br]adding sort everywhere for the keys and
0:46:21.571,0:46:27.741
it's solved. For very few cases, for Perl for[br]example you can set and environment
0:46:27.741,0:46:33.261
variable and some maintainers prefer to do[br]that. But usually we try to push these
0:46:33.261,0:46:35.900
changes upstream, because they are simple[br]enough and they like it.
0:46:35.900,0:46:38.941
Actually it makes testing easier to them.
0:46:42.261,0:46:45.141
There was one in the back, there.
0:46:53.281,0:46:56.111
[Lunar] That's the last question
0:46:56.341,0:46:59.801
[Question] Follow up question to what we[br]had here before.
0:46:59.801,0:47:10.041
You showed an open bug report against gcc[br]to support SOURCEDATEEPOCH to cover
0:47:10.041,0:47:20.401
the mdate and mtime timestamps, so I have[br]patches to patch them out in my packages.
0:47:20.401,0:47:24.362
Should I remove those patches and if so,[br]when?
0:47:26.361,0:47:30.162
[Lunar] Have you seen any more emails[br]from the gcc maintainers?
0:47:33.902,0:47:39.900
[Dhole] The mail is forgotten, I guess we[br]should ping it again, and see if they
0:47:39.900,0:47:49.501
reply, because what I read from the gcc[br]website is that only the replies from
0:47:49.501,0:47:54.861
maintainers are the ones that matter, and[br]I think no maintainer replied to the
0:47:54.861,0:47:58.162
message, so we should ping again.
0:47:59.482,0:48:02.560
[Question] That was just an example, my[br]question was more general.
0:48:02.560,0:48:08.821
At which time should I remove my patches[br]to fix things which were fixed higher up
0:48:08.821,0:48:12.420
in the toolchain? Or should I just leave[br]them in there?
0:48:13.082,0:48:14.221
[Holger] Once they are in Sid.
0:48:15.131,0:48:16.661
[Question] Ok thanks!
0:48:18.256,0:48:20.042
[Lunar] Ok, I guess we're out of time.
0:48:20.261,0:48:22.241
Thank you for listening.
0:48:22.660,0:48:25.901
[Applause]
0:48:25.901,0:48:28.861
[Lunar] Fix your packages!