Reproducible Builds for Debian
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 199 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32616 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Software developerProjective planeDistribution (mathematics)Group actionArithmetic meanMereologyMatching (graph theory)Computer programmingIntegrated development environmentFiber bundleField (computer science)BuildingInformationChemical equationEndliche ModelltheorieSource codeDivision (mathematics)Physical systemMultiplication signBounded variationFood energyDistribution (mathematics)Complex numberNeuroinformatikDialectInferenceFile archiverMalwareCompilerWindowProduct (business)Single-precision floating-point formatCuboidLatin squareDifferent (Kate Ryan album)Operator (mathematics)AreaBinary codeOnline helpFocus (optics)ResultantLevel (video gaming)Web browserMultiplicationStochastic processInformation securityBitSoftwareEmailGoodness of fitComputer fileService (economics)Scripting languageWikiLattice (order)Computer architectureSymbol tableProper mapLecture/Conference
09:11
Revision controlLatent heatIntegrated development environmentFrustrationObject (grammar)CASE <Informatik>TimestampElectronic mailing listMathematicsMultiplication signBitSoftwareFile archiverBinary codePhysical systemPressureStability theoryMoment (mathematics)Right angleStandard deviationComputer fileKernel (computing)Software developerWeb pagePatch (Unix)File formatOrder (biology)Substitute goodCollaborationismSymbol tableShooting methodNumbering schemeComputer configurationVapor barrierVariable (mathematics)Different (Kate Ryan album)Line (geometry)Default (computer science)Sheaf (mathematics)Raw image formatPoint (geometry)Projective planeMathematical analysisBuildingState of matterErlang distributionFreewareDirectory serviceEmailLibrary (computing)Concurrency (computer science)Distribution (mathematics)Single-precision floating-point formatElectronic signatureQuery languageBlogBounded variationField (computer science)Information securityVirtual machineDescriptive statisticsComputing platformDivisorCompilerProcess (computing)CodeModule (mathematics)String (computer science)Ocean currentFiber bundleLoginMereologyWeb browserSoftware bugRewritingMarkov chainStructural loadFormal languageScaling (geometry)Instance (computer science)Canonical ensembleFunction (mathematics)Windows RegistryDisk read-and-write headLocal ringScripting languageSystem callDistribution (mathematics)WikiSet (mathematics)Traffic reportingMiniDiscSource codeMedical imagingInformationGeometryFile systemBefehlsprozessorData storage deviceSoftware maintenanceResultantConfiguration spaceAsynchronous Transfer ModeFlagArmContext awarenessPresentation of a groupShared memoryRun time (program lifecycle phase)WordVideoconferencingDrop (liquid)Computer architectureCartesian coordinate systemOperating systemCuboidJava appletPublic-key cryptographyAndroid (robot)Deutsche Physikalische GesellschaftFormal verificationEstimatorFrequencyView (database)Direction (geometry)Connectivity (graph theory)Endliche ModelltheorieLevel (video gaming)RootVideo gameCategory of beingTuring testAreaComputer virusCovering spaceQuicksortTheoryFraction (mathematics)Irreversibler ProzessStreaming mediaForm (programming)MultilaterationCodierung <Programmierung>Figurate numberCellular automatonProteinLimit (category theory)SummierbarkeitPrincipal idealPredictabilityData structureReading (process)Decision theoryBootstrap aggregatingEuler anglesPattern recognitionSequelEvent horizonLattice (order)HypermediaComputer programmingCondition numberVarianceManifoldPower (physics)Overlay-NetzParticle systemFood energyObservational studyNumberSoftware testingType theoryNumerical integrationArithmetic meanVariety (linguistics)GradientMetropolitan area networkContent (media)Independence (probability theory)Greatest elementProof theoryEqualiser (mathematics)Ideal (ethics)Key (cryptography)Physical lawCoefficient of determinationAttribute grammarInformation technology consultingDigital photographyNegative numberBootingDialectSign (mathematics)Network topologyData managementLecture/Conference
Transcript: English(auto-generated)
00:03
Let's go. OK. Hi. So this is Farzam. This is a distribution dev room. Thanks to you for organizing the room over these two days. So I'm Lilina. I've been using Jibian for more than 10 years.
00:22
I became a Jibian developer in 2007. These days, I'm very active in the Tor project and mainly focused on that. But I'm still trying to do work for Jibian. Today, I'm going to talk about reproducible builds for Jibian
00:41
because this is a distribution I know, and that's what I studied. But it's also a huge project that would need cooperation from probably all distributions and maybe others are willing to also jump into the wagon. So we'll see what happens. So what are reproducible builds?
01:05
Reproducible builds is the idea is that multiple people using different computers in different places could, from a same source package, do the build process and get exactly the same binary packages
01:25
out of the source. Bit by bit in a tickle, like the same checksum. Why do we want to do that? We want, I mean, my main focus on this is to prevent targeted attacks.
01:43
It's way, way much easier to put a malware on one computer than on one million because if that one computer is the one of the Jibian developer
02:01
doing the build, or maybe the Jibian build daemon, then you get a window where you can insert the malware into a package that will be installed in many, many, many different boxes like Jibian, you know, our installation base is huge.
02:23
And it's going to be tricky to actually figure that there is this malware because usually when we do our security audits we do that on the source code. Especially given that we do free software and we have the source code. So we rarely study the actual binary
02:45
and prove that the binary matches the source code. So with independent parties reproducing the build we can get some good level of assurance that actually the build systems
03:01
are not compromised themselves. It's also interesting, like, sometimes you want to if you have a reproducible build it means that if the first time you built you forgot to, you didn't include the debugging symbols into the binary package then you can get daemon built after a while
03:23
and use that to debug after the initial shipment. And also for Jibian it's useful because of the multi-arc in Jibian now you can co-install packages
03:42
that are from different architectures but you need to have all the data files need to be exactly the same. So it's also interesting for this project.
04:00
For me, my interest into reproducible builds started with actually the work that has been done by Mike Perry inside the Thor project. Which is also work that has been done before as part of the Bitcoin community. Bitcoin people wanted to have reproducible builds
04:22
because they were handling money and people were very eager to know that the source code they were seeing were matching the binary. So Mike Perry did build on that and we now, for the Thor project, ship
04:43
the Thor browser bundle which is the easiest way to use Thor is built in a reproducible manner. This means that we have multiple developers in different areas all doing the same build and ensuring that the results match.
05:07
It's not a new idea. It's absolutely not a new idea. Well, after starting the project I got an email from Martin Uecker which told me like yeah, I actually
05:20
we had this discussion in 2007 like six years ago and I'm not sure how much he was knowledgeable with Debian processes but he suggested that we should actually do that that have identical reproducible builds.
05:43
Unfortunately, the reaction was not super enthusiastic like Neil Williams, for example didn't really like understood why or you had Manoj who said he would like be infeasible technically.
06:05
So yeah, but I wasn't aware of that and I was super enthusiastic with Mike's work on the Thor project and I was like, we need that for Debian and so last minute at the last Debian conference in Switzerland we made a birth of a fever
06:21
like a small meeting and I was surprised 30 people or more came and were all interested into the project and so we discussed what was the right approach and how we could do things other than the various problems and it was like 45 minutes really well spent
06:40
I hope and this led us to actually kick off the wiki page where we have all the project status so I mean probably something happened some Edward Snowden thing
07:02
I don't know but from 2007 where people were very enthusiastic from Martin Luther's suggestions to that birth it was like really I think that changed So how do you do reproducible builds?
07:22
Actually three things it's kind of simple I mean, first thing is that you record the build environment the idea is that you record like the compiler the rest of the system you record
07:42
what was used initially to perform the build then when you want to reproduce you just need a way to actually recreate that initial build environment and the last part is that to have build systems
08:00
that do not capture things that it should not capture from the environment they should not have variations that are not tied to the source code so recording the build environment is actually on Debian it's kind of
08:22
we don't have a proper tool but we have already ideas on how to do it there is something called dhbuildinfo which is actually record the environment but put the information in binary packages and not in source packages basically the problem is not really hard it's not a matter of discussing
08:40
where putting this information makes more sense more sense Reproducing the build environment is also we still need someone to hack a proper script like HackPBuilder or sbuild to do that we have a
09:01
service that is called snapshot.vbian.org which is awesome because we have an archive of every single binary packages that ever ran through the archive for several years so if the build environment requires a specific version of GCC then we can get it from snapshot
09:29
the idea is that the question is do we need to store the name of the packages in this version or do we need to store the actual binary of the compiler for example
09:40
for Debian we just need to store the version and the name of the package because we have snapshot and because also we want people to be able to reproduce the whole chain in the end and then you have the thing that is more painful is the various variations that are coming inside from the build systems themselves
10:03
so timestamps are captured like the current time build paths the file loader, the local many different things I think I have not seen them all yet to quickly run around is like
10:23
gzip for example if you, I'm not sure if you know but by default you store the timestamp of when the zip was made why? no need to we need to pass the flag that says gzip do not record the timestamp
10:42
all archives almost like rtar, zip, jar they all store also timestamps which most of the time is not useful information and prevents the second time when we try to reproduce then we have a different time right? so the archive is created with a different time and we have a variation
11:00
that is not needed javadoc writes timestamps on the comments that is hidden in the HTML page so if you are a developer really I told you I'm yet to find a convincing
11:23
use case for storing the time of your build in a binary package I mean for javadoc what you are interested into is to know which version of the software it is, which like I don't know, reference to the git head
11:40
commit but not the time, I can build an old version now and then I get like a new and it's all like this please don't do that can we go to questions later? I'd rather go to the end
12:04
also one thing that I discovered that is painful is that some build system uncodes the build path which directory the build happens? and one of them is the dwarf files like debug symbol for health for health
12:22
and they have these fields like ggvalue, hname and ggvalue that encode the build path which is also like an unneeded source of variation because for example in GBN we don't need that information when you have a binary package
12:40
the source is lost and there is no point in storing an arbitrary path in the binary package one fun thing is the file order problem so when you use ridger on directory sometimes you will get
13:02
abc but sometimes you can get cab depending on the order initially they have been written or the file system moved up the day so basically in some build systems they just do like for example all the files from this directory
13:23
and then you get a different archive because the files are different order or different listing files or plenty of those solutions is really simple like you just sort the output for what needs to be done you have fun things with local
13:41
for example if you are in the C local and you have extensilators like french things then that's already in and if you go to the french local then the A is like after the A so
14:00
also that's a source of variations that needs to be sorted out somewhere you also have some build systems that include like the username plenty of fun one way to solve all these variations is to cheat this is the way
14:21
we do for the top browser bundle like gitchen and also like bitcoin and other projects, you use a VM when you use a VM you have a standard VM you use the same kernel, it uses the same username it uses the same build path it uses the same hostname
14:41
like you squash all these variations just by using a VM and the other trick you can use is called leapfacetime leapfacetime is an LG preload library that we like to take calls to get time of day it became like super more advanced
15:01
recently the last edition was a mode where you can actually record a file where with every single get time of day initial code and the time that it returns and then replay that the next time
15:21
so I mean you can cheat that works, but we decided at the buff, at the devconf that we would take the hard path because we are Debian and we try to do things right I think but the idea is that we are going to patch things we are going to configure the toolchain
15:41
and patch the toolchain for example we should add a default option that would be like javadoc maybe and patch the actual system so they would pass the option to gzip so we would not record the timestamp all these little changes that would make
16:01
package reproducible without having the need to use a VM so that you can use any deviant system and just run a script like you do normally to build a package and boom, we produce we did
16:20
so I have results, we did some experiments using EC2 VM instances from Amazon Web Services which is usually used to do a large scale archive rebuild like to try I don't know the last rebuild that was done was to try for example ceiling
16:41
try building deviant language ceiling instead of gcc and see how it goes so we have this infrastructure that was founded by Lucas and also these days it is maintained by David Suarez which was really helpful so the idea is that
17:01
we are going to build and then rebuild the very same package and see if we get a similar result or not so how we do that? we build the package twice and so the build process is standard as build which means we set up a clintroot
17:20
we unpack the source code we install the buildups and rebuild and we do that again we set up a clintroot, we unpack source code we install buildups and rebuild and the only small difference we do between the two builds is that we pass the timestamp of the first build to dpkg
17:41
through an environment variable just to say first package was built at airpark and this means that in this context we have two variations out of the list that I've made we have time and we have the build path
18:01
both are different from the first build to the second build there are no changes in the hostname the username, uname, fileorder probably local but it's still like time is the end build path it seems like the hardest format I've seen so far
18:20
to perform the experiment we installed three custom packages in the shoot one is dpkg so we get a single timestamp for every file in the archive instead of having multiple calls to get time of day we only have a single
18:42
timestamp for every file in the archive and we reuse the very same timestamp if it's coming from the environment variable dpkg has been also modified to put files in the archive in stable order so we always get
19:01
abc there's a change to devhelper which modified dhtrip dhtrip is part of the devhelper that takes care of debug files and we use debugedit to mangle the build path
19:21
that usually gets encoded into the debug symbol and we also need to change because debugedit is not able to work with indirect strings in guar files but I'm not going to get into the details we have another option to pass to the C compiler
19:42
and we also have binotals which has been rebuilt with configure option which is minus minus enable deterministic archives which means that 8R is going to drop timestamp by default so that's only three packages three small patches
20:00
and we the thing is still running but last time I checked which was yesterday evening we had like over 5,000 source packages and 3,196 out of the 5,155
20:20
5,151 were actually identical for those who don't want to be the math that's 62% the first try we did was 24. I actually couldn't believe it that's
20:41
so Manoj said it was technically infosible I really now believe the concurrency some of them like for those who worked, like sorted by popcorn you have findutil, debuget busybox plenty of those and for the failures that I tried to sort out
21:01
which one, like why there was some package failing so that was from 10pm to midnight yesterday, so sorry for the rawness and things but the most of them I have still like build-ig mismatch which means some problem with
21:22
the build path that gets encoded into the debug symbol one way or another debugedit was written by Red Hat initially there's I mean there's really room for collaboration because this is not a specific problem to debug at all
21:43
there's some unknown that I need to check Manoli there were like more than a hundred of jar files we saw timestamp in jar file java archives hundred packages are like Haskell, so I need to
22:00
discuss with Joachim Reitner why is that PHP packages we had like a timestamp embedded in the registry I think we should just get rid of it there were some documentation issues, probably timestamps also in documentation there's
22:20
most of the Python build systems sometimes put the depends in different orders but they're the same so that's going to be easy to fix some R specific language, KDE documentation, there's mono that I don't know how to deal with too there were like
22:40
some darkbook also timestamps Perl man pages also timestamped zip files probably a couple of others most of these are like the good news is that we can probably for not that much more work switch to 62% to maybe 80% or at least that's what I believe
23:01
when I sorted that out so yeah most of these issues I've listed are probably not Debian specific and I've seen that other distributions were also interested in doing that there was a blog a blog post on the security blog from Red Hat to discuss reproducible
23:22
builds for Fedora I know that OpenSUSE has something that is called build compare that is doing also some kind of reproduction I'd be interested in figuring out the details and NixOS is also very very interesting to doing that if you don't know NixOS I suggest you look it up
23:43
and I hope more distributions we get interested in that we can convince upstream to for example remove timestamps from archives more easily or share patches if we need to we'll see we'll see how it goes
24:02
that's I'm done we have a microphone back here so if we're going to do any questions I want to pass the mic around so that they end up on video for the folks
24:20
playing at home so who has the first question? there are like 8 million geeks in here and not one question, come on so please check the wiki page subscribe to it there's also a main list
24:41
if you want to subscribe yeah, please so at the beginning of your presentation you said that compromising one host is a danger to get the same binaries and then you said to solve this issue we are creating a VM to have the same environment but who is making this VM? because you have a single VM for everyone what I want to do for DBM is that we don't have a VM
25:02
that's why it's harder to do something I'm sorry? for DBM, the idea is to avoid to create a VM that's why it's harder because we need to patch more and more and more things ok, thank you
25:24
keep your hand up so I know where I'm going so how confident are you that there aren't any compromised packages in snapshot? that at some point
25:41
hopefully we will be able to just bootstrap everything but that's a different issue I mean, we need at some point we need to have the reproducible build system working and then we can start ensuring the trust of the world will change I mean, both efforts should be bound separately
26:01
Could we kill two birds with one stone when we're dealing with the debug symbols? because one of the problems I have is that when I'm debugging, I end up installing lots of debug packages and then I have all of them, the symbols are all over the place and I have to just do endless substitutes in GDB we could kill that problem at the same time
26:22
as making reproducible builds absolutely, that's why debugedit was written for Red Hat initially because Red Hat has a policy that source packages get into usr slash src and so they mangle the DWARF path because then you can just
26:41
extract the source package and it's going to be right at the right place for GDB to work so I think we should do that in Debian 2 yes talking about your problem is if you are generating one binary
27:02
but have the same signature everywhere you are not obviously sure that everything is built using the reproducible builds do you aim at having the same before making your build? because if you have some libraries on runtime you have to be sure that also these libraries have the same signature everywhere
27:20
no, we assume that if the initial build was done with libglib 12 then if we run libglib 12.4 then if we run libglib 12.4 then we are going to have the same I'm not sure I got your question right
27:40
your system works if everything on your local system is made using the reproducible builds we use standard Debian packages the idea is to use standard Debian packages how can I say that I understood that your aim is being sure that several developers almost everywhere in the world
28:01
have the same binary signature or front binaries that you want to test the build system produces an analytical binary for each of them but this binary will load some libraries and you have to be sure that all these libraries have also the same signature unless you are not sure what you are running if you want to have trust in the system fully
28:22
it's a gradual process when you talk about security it's always important to have in mind the cost benefit ratio it's what I said it's the cost of compromising one system
28:41
that is going to be a developer system is less than the cost of compromising a million systems and it's the same compromising one Debian package is more than the cost of compromising the second problem is impairing the trust of the worldwide verification process I agree but it's a gradual approach
29:05
every package that gets reproduced or built is something harder to compromise for an attacker every one of them we are going to get it also security related how can you trust the compiler?
29:21
that's also a different problem that's trusting trust and some people are working on that I'm not going to get into the details I'm not saying this is the solution I'm saying this is part of the solution
29:41
Hi, I'm involved in building an Android operating system so during the build process we actually have Java applications that are signed by a private key and that are then bundled into a whole system image and my whole problem is how can I bring reproducible builds if I cannot share
30:02
my private key so what's the solution to that? Ideally you probably need to have an intermediary step people reproduce everything except the last step but they have to be able to verify that the only last step
30:21
is that you're only the one able to run which is including the private key is something that is not going to put my word into the rest of the system but I'd say you have to use special tools in that case so I wondered if you've done any analysis
30:41
of what proportion of an actual installed system how far can you get if you only choose to install reproducible packages? are we near we're nowhere near being able to have a build daemon that contains only reproducible packages? I sorted the logs at midnight yesterday so I don't have an answer yet
31:01
but it's a very interesting question we should have a metric of that if someone wants to write a udd query that would take a list of packages and give us the percent of a build daemon that would be covered by this list of packages
31:21
that would be awesome you have already tried it on embedded systems like ARM or something like this I know there are many problems on CPU with bugs and you got so different bytes on different machines with the same source and the same
31:42
same environment so we did the build on ng64, I don't know I think I mean it's Debian I mean we have we try to have all these variations that's possible between architectures I hope it will work please do so if you can
32:07
are you planning one day to add verification process that will verify that the packages binary packages that are published they really correspond with the source packages
32:21
so something we've been discussing in Debian for as long as I've been interested in Debian is binary is the end of binary uploads so when a Debian developer uploads a package in Debian they upload both the source code and the binary for their architecture
32:41
that's how it's usually done the problem is that sometimes they are like we use the standard build environment and so they have a binary package that no one can rebuild I'm not talking about reproducible like identical rebuild but just rebuild from source
33:02
so we've been discussing in Debian for ages to just prevent developers from uploading binary packages at all just take the source and then have the build daemon do the binary packages but then people argued that if we do that, people are not going to test their packages at all
33:21
so we should not. What I want to do with this is that developers would not upload the binary packages, they would just put the checksum of the .deb file into the changes and then the buildd will rebuild and ensure that it matches
33:41
and then we have a trust that at least you know it's either the buildd has been compromised or the developer system has been compromised or if there is a mismatch or both does that answer your question?
34:01
Hello How close are we to getting these small patches back into Debian? and do you have a rough estimate for when we're going to see reproducible builds by default, out of the box are there any barriers or any controversial
34:20
bits in the patches so far? I have quite frustrating discussions with Guillaume over so far, the DPG main here I'm not sure he's interested into this at all so I hope there's going to be enough build pressure I mean 62% right? it's not a completely crazy idea we can do it
34:41
the patches are I mean you can review it I find them like ok the debug edit thing is more complicated we need either someone to probably patch do some changes to debug edit to improve it or to
35:03
write to rewrite debug edit in another language I tried to I tried to work on debug edit and I failed the code is too hard for me but yeah, it's doable I think at least if you want to see
35:21
if you go on the wiki page we have a user tag so you can see all the bugs that have been reported so far as part of the reproducible builds project and every single package maintainer I said please, can you take that patch it's going to make your package reproducible and they took it I have no rejection so far
35:41
except for the most speed editing things so I mean yeah, I hope if you guys could work a little harder on asking your questions in the order you are in the room that would be really great I just want you to get some exercise so, in Fedora we have one particular reproducible build problem
36:01
that I'm not entirely sure is solvable because what we have is when we build our live images or our ISO images these are all coming from prebuilt packages really the only thing that is being done is that they are being turned into an ISO image and one of the things that we have identified every once in a while since we are always pushing on the edges of what you can fit on a disk
36:21
we discovered that there is a drive geometry problem that we hit where actually creating the ISO image the same exact set of packages with the time stamp faked out will still sometimes produce a package that is one sector larger
36:40
because of the way the drive the sectors on the disk line up so, how do you work around that? That's a very good question I hope you find out I mean this is going to be a collective effort it's not going to happen, right? I mean, we have the adversary is the NSA
37:03
or something as big as the NSA right? So, I mean everyone together Who's next? Anybody?
37:21
What Debian release are you focusing your efforts on? Is it general? It's development work It's unstable I mean, the the process of getting changes like that into Debian is you get as many packages as you can to fit the scheme you want
37:42
and then you propose a change to the Debian policy but you want proposing a change to the Debian policy before you get like, I don't know, 95 or 90% is going to be hard and then also there is the release goals but I'm not aiming to have Debian reproducible
38:02
at least on a large scale before like at least two major releases I think 4 or 5 years is not, I think, crazy given the amount of like small amount of change that needs to be done and for how many people need to be involved
38:20
unless someone is working full time on this for a year and then we can get much faster May I ask another question? How do you store the build environment settings? You said that you wanted to store them either in the source package or in the binary So my idea is to store them in the dot changes file
38:42
which is the listing of the binary packages and source packages with the checksum it's like a description of an upload and I think we can just stick in there So, I know that Debian people will know where to talk about this kind of thing
39:01
in Debian, but people from other distros, is there like a mailing list or something that they should sign up to? There's a wiki page there, but is there more than that? So, we have a reproducible build mailing list at Aliaf It's like listed in the very top of the wiki page. I'd be happy to see more people from other distros who
39:21
subscribe and we exchange ideas or problems on the mailing list I don't have I know but if we have enough discussions here maybe we come up with something or we, I don't know I mean, the Debian mailing list has very very low traffic at the moment so if that's not like
39:40
if it's okay for everyone to be on the Debian mailing list then just join this one Thank you Considering that you can't here, considering you can't build everything reproducible like for example non-free will there be like a section or a tag
40:01
where you can non-free can be reproduced it's not going to be fully reproducible from source or maybe it's going to be reproducible from source, you can audit, but you can't change Okay but assuming there will be a few packages which can't be reproduced to a certain state
40:22
will there be a system that you can choose your system just get packages where you can build reproducible? I mean we could have a dead tag and we could use things like that but my hope is that we get everything I don't see a reason that we can't come to that because, for example
40:41
it takes much longer to get everything reusable and in the meantime you could have a system which is already has this objective I mean, it's only the beginning if you want to come with patches and stuff, please join us
41:04
It's just a suggestion to the other guy maybe we could have a non-reproducible archive, like the non-free archive at some point potentially I mean it's deviant, right? it's
41:22
it's easier to push large scale changes in a small fashion and discussing major changes that's why it's harder to prove that, yeah, we can do it if I understood correctly you have to get one platform at Amazon that does the job we did one experiment
41:41
yes, and my question is maybe by your experience, are you afraid of discovering a new item factor that puts your 62 into 10% because you have made some assumptions on this platform, but making another platform elsewhere the platform we use is SBuild so it's the standard way that deviant packages are
42:00
automatically built at the moment so I mean that's the target, right? at least for me that's the target how you want to protect external cannon modules that you build at the machine directly so I don't think there's a solution for that or is that right? I don't understand
42:22
I mean, I understood what you meant you can load cannon modules you have an external module with DKMS or something like that that you build at the host machine you can't protect that right, but you can protect that the source code has not been tampered before being delivered to the user
42:42
I mean, that's already something we have about five more minutes, so probably about two, maybe three more questions depending on how efficient the questions are down here so you said you could
43:01
there's a dev tag if you put a dev tag reproducible builds maybe some people will start using it and want to contribute and to fix the last package that they planned on and you would get more developers at the end? yeah maybe but we're not dead there yet
43:20
I mean we have patches so, like I said the question about how far we are getting these patches in DBL is very relevant because basically my situation right here having this result is that I want to discuss again with Guillaume and other DPC-AG developers
43:40
what is the proper patch to get into DPC-AG and if we have a disagreement on it I want to run it by the tech committee and if the tech committee says that we can't have this kind of patches into DPC-AG and that the DPC-AG developers won't have patches like this then I'm going to stop this report
44:00
at all because you can't go against the will of a project but the idea is now to get more people involved all these reports, they need to be sorted they probably all of these there are patches that can already
44:22
be written and submitted and probably are going to be accepted from many tools if people want to hack on JAR if people want to hack on Javadoc if people want to hack on Epidoc if people want to hack on Debugged if people want to hack on Mono software
44:41
on OCaml software, on Erlang software on PHP all these are not right now reproducible and they should be so there are plenty of work that we can do whether or not and that is going to also benefit everyone in the Free Software community is it even enough?
45:01
so there's work to do and it's going to be quite interesting do you expect any specific problems with the package to the kernel packages? or is it just another package? so the good thing is that there are some people quite external to the Debian distribution but I've been trying to guide them a little bit
45:21
they have a project called Manpo and they've been working on reproducing the kernel and they have a few patches for the kernel already I hope they will be able to push them upstream I haven't looked at them their work that much yet but I know they have a package
45:41
that contains Debian source GR security and that can be reproduced in their environment one more or we're done, ok great one last thing please come talk to me if you're interested
46:01
I'll be at the tall project corner of the Mozilla booth for the next two days please thank you very much