We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Reproducible Builds for Debian

00:00

Formal Metadata

Title
Reproducible Builds for Debian
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
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
How can we enable multiple parties to verify that a binary package has been produced untampered from a given source in a distribution like Debian? With free software, anyone can inspect the source code for malicious flaws. But most distributions provide binary packages to their users. We would like them to be able to verify that no flaws are introduced during the build process. The idea of "deterministic" or "reproducible" builds is to enable anyone to reproduce a byte-for-byte identical binary packages from a given source. A research effort started last summer towards reproducible builds for Debian. After several small tweaks to core Debian tools, a massive rebuild in September reached 24% of builds resulting in identical binaries out of 5000+ source packages. The process uncovered challenges about both the reproducibility of the build environment and about the build processes themselves. We will review them, along with possible solutions and what remains to be done
65
Thumbnail
1:05:10
77
Thumbnail
22:24
78
Thumbnail
26:32
90
115
Thumbnail
41:20
139
Thumbnail
25:17
147
150
Thumbnail
26:18
154
158
161
Thumbnail
51:47
164
Thumbnail
17:38
168
Thumbnail
24:34
176
194
Thumbnail
32:39
195
Thumbnail
34:28
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
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)
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.
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
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?
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
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.
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
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.
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
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
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
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
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.
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
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
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.
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
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.
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.
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
or something as big as the NSA right? So, I mean everyone together Who's next? Anybody?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
I'll be at the tall project corner of the Mozilla booth for the next two days please thank you very much