Re: Buildinfo in the Debian archive, updates
On Thu, Dec 08, 2016 at 09:58:00AM +, Ximin Luo wrote: [Signature field for build-info] > If we go down this route (and it's looking pretty good IMO) then I > agree that we don't need to store the binary hashes in Packages.gz. > But we should store a hash of each Buildinfos.xz in the Release files > (that are signed), so there is a cryptographic "route" from what is > signed by Debian, to what is signed by the builders. Yes, completely agree - it was always my intention that the Buildinfo hashes should be in the signed Releases file, to provide a trust path from the usual archive keys. > Are you all coming to the meeting next week? We should figure out some > way to divide up this work. I'm not very familiar with the dak code > atm, some pointers would be nice. Sadly I haven't been able to spare the time necessary to attend. J. -- Don't do it! ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Buildinfo in the Debian archive, updates
On Wed, Dec 07, 2016 at 11:00:00AM +, Ximin Luo wrote: > Jonathan McDowell: > > I was under the impression that each set of binary artefacts from a > > build would be accompanied by a single buildinfo file describing the > > environment used. This would be signed by the original uploader, and > > then there would be the possibility of further people attesting to > > that pairing of buildinfo + binaries, rather than providing an > > entirely separate set of buildinfo (+sig) information that produces > > the same binary. > > > > Is there a requirement that the archive is capable of storing > > multiple buildinfo files, rather than just multiple buildinfo > > signatures, for a given set of binary artefacts? > > > > Yes, buildinfo files are expected to be different, even for multiple > builders that successfully reproduced the same binary hashes. The > Binary: fields would be the same, but the other fields might be > different. This is a good thing from a security perspective. > > For more details on why you can read the draft here: > > https://anonscm.debian.org/cgit/reproducible/buildinfo-spec.git/tree/notes/buildinfo.rst My reading of that is that ideally buildinfo files would describe T, the minimal information required to rebuild reproducibly. However limitations in knowing exactly what T is for a particular package mean that you currently record U', a superset of T, and that by recording multiple of these you hope to be able to converge towards T. I'm not sure this argues for being able to support multiple sets of buildinfo information for a single set of binary artefacts within the context of the Debian archive. J. -- Is this real - that's the first thing I think every morning. signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Buildinfo in the Debian archive, updates
On Tue, Dec 06, 2016 at 06:21:09PM -0500, Daniel Kahn Gillmor wrote: > I'd be wary about this "multiple such fields" bit. it seems likely that > different buildinfo files will not match each other, even if the > *output* is reproducible. This is because buildinfo files can capture > some things that do not have an impact on the resultant binary > artifacts. I was under the impression that each set of binary artefacts from a build would be accompanied by a single buildinfo file describing the environment used. This would be signed by the original uploader, and then there would be the possibility of further people attesting to that pairing of buildinfo + binaries, rather than providing an entirely separate set of buildinfo (+sig) information that produces the same binary. Is there a requirement that the archive is capable of storing multiple buildinfo files, rather than just multiple buildinfo signatures, for a given set of binary artefacts? J. -- This isn't an office. It's Hell with fluorescent lighting. This .sig brought to you by the letter J and the number 14 Product of the Republic of HuggieTag signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Buildinfo in the Debian archive, updates
On Tue, Dec 06, 2016 at 09:24:20PM +, Holger Levsen wrote: > On Mon, Nov 14, 2016 at 02:57:00PM +, Ximin Luo wrote: > > This email is a summary of some discussions that happened after the > > last post to bug #763822, plus some more of my own thoughts and > > reasoning on the topic. > > I think that given our last mail on this bug was >4 weeks ago, it's > mostly important we reply to the bug at all now… > > > I think having the Debian FTP archive distribute unsigned buildinfo > > files is an OK intermediate solution, with a few tweaks: > > > > 1. the hashes of the *signed* buildinfo files must be referred-to > > for each binary package, in Packages.gz > > I actually think thats too much to ask for right now. we should > *propose* this now as a 2nd step, but right now the first step should > be that those .buildinfo files are stored *at all*, for later > consumption. The storage of the hashes of the signed buildinfo files in Packages.gz seems to be in order to deal with the fact that the signature is not available elsewhere. If dkg's suggestion of using ECC signatures is followed then some quick checking shows a signature size of 165 bytes (when ASCII armoured). This seems sufficiently small to me that you could just map it into a Signature: field at the end of the buildinfo stanza within buildinfo.xz, with the bonus that at some point that would allow for multiple such fields, all within the archive mirror network. The max permitted size of such a field could be something configurable by ftp-master, so if that they wanted to allow full RSA based signatures they could set it to ~800 bytes, or limit it to ECC at < 200 bytes. > Thinking again, I think we should not outline stuff for the 2nd step > right now, just the very 1st, which is saving the files at all, > somewhere on the local disk (of ftp-master.d.o). Saving them into the projectb is probably the way to go. I started looking at the dak code to do this back at DebConf, then stopped when it looked like I was going down a different path to what was desired. I had hoped to try and pick this up again before the meeting next week but haven't found a sufficient block of time yet. J. -- OK, if we can't have a tour, can we at least have a look around? signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Bug#763822: Moving towards buildinfo on the archive network
On Sun, Aug 21, 2016 at 04:01:00PM +, Ximin Luo wrote: > Jonathan McDowell: > > On Sat, Aug 20, 2016 at 03:13:00PM +, Ximin Luo wrote: > >> Note that the builder is a *distinct entity* from the distribution. > >> It's important to keep the *original* signature by B on C. It breaks > >> our security logic, to strip the signature and re-sign C using (e.g.) > >> the Debian archive release keys - because the entity in charge of this > >> release key is not the one that actually performed the build. Doing > >> this, would allow malicious builders to re-attribute their misdeeds to > >> look like it's the fault of Debian. > > > > Debian already does this in the context of the fact that Package files > > etc are signed by the archive key. It's possible to go and grab the .dsc > > file to see who did the file build, but day-to-day no one is using these > > to verify the binaries they receive. I care more that Debian stands > > behind the packages I download than being able to verify individually > > who build each of the packages I'm running - there's no meaningful way I > > can attribute trust to *all* of the people who packaged something I have > > installed. > > > > You have this backwards. > > "Being able to verify individually who build each of the packages I'm > running" > > is *exactly* what is required to *not* have to > > "attribute trust of *all* of the people who packaged something I have > installed." > > and that is one major (probably the main) goal of R-B. > > Now that I point this out - do you agree, No. What lets me not care about who actually built the packages and have to attribute trust to them is that I have the build information, which allows me to verify I get exactly the same output from the provided source. The signatures over these do not allow me to trust the binaries I receive in any additional fashion. If I trust the statement "I built package using source and build information " from an individual, without doing any verification that this is true, it doesn't give me much over "I built package using source ". I have to do the build myself to ensure what I have been told is true. Where, to me, signatures become more interesting is when it is possible for multiple different people to attest they build a set of source using the same information and got exactly the same output - but only if I actually trust all the entities who are doing that signing. > and does it change your mind on anything you previously said? Fundamentally I still think build information without the signature of the builder is information that it would be useful to have accompanying the Debian archive. It seems you do not believe this is worth anything as it loses the signature which provides a chain back to the origin. I do not, at present, have a good solution for the extra information and conditions you want within the context of the Debian archive. J. -- ] http://www.earth.li/~noodles/ [] 101 things you can't have too much [ ] PGP/GPG Key @ the.earth.li []of : 49 - Bandwidth. [ ] via keyserver, web or email. [] [ ] RSA: 4096/0x94FA372B2DA8B985 [] [ ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Moving towards buildinfo on the archive network
On Sat, Aug 20, 2016 at 03:13:00PM +, Ximin Luo wrote: > Jonathan McDowell: > > Having been impressed by the current status of reproducible builds > > and the fact it looks like we're close to having the important > > pieces in Debian proper, I have started to have a look at how I > > could help out with this bug. I've done some poking around in the > > dak code, and think I have a vague idea of how to achieve what I > > think is wanted. > > > > First, it is helpful to describe what I think is wanted. What I > > think we need is the archive network to have, alongside the binary > > packages it contains, details of exactly how to build those > > binaries. This is, I believe, the information contained in the > > .buildinfo files. > > > In our newest discussions, this purpose is secondary. The primary > purpose of buildinfo files is to record what *one particular builder > actually did in order to produce some output*. Or, equivalently: > > | A buildinfo file, abstractly, is a *claim* C by some builder entity B that > | "I executed process P with env/input I to produce output results R". > > This latter form is slightly easier to reason about, in terms of > security properties. We securely bind the claim C (the contents of the > buildinfo file) to the entity B using a cryptographic signature. I think the problem here is it's not clear (on either side) who "we" or "our" means. Different people want different things from reproducible builds, or have different opinions about relative priorities. As a *minimum* I think distributions should be providing the information of how a particular binary was produced. I suppose what it sort of maps to is "I executed process P with env/input I to produce output results R" (though, of course, distros already provide R; that's the binaries shipped). You've used all the letters I might want to refer to it by, so let's call it Z. The claim, C, is a signature over Z by B. It's useful extra information, but it's not required for me to ensure that the source I have build the binaries I have. > Note that the builder is a *distinct entity* from the distribution. > It's important to keep the *original* signature by B on C. It breaks > our security logic, to strip the signature and re-sign C using (e.g.) > the Debian archive release keys - because the entity in charge of this > release key is not the one that actually performed the build. Doing > this, would allow malicious builders to re-attribute their misdeeds to > look like it's the fault of Debian. Debian already does this in the context of the fact that Package files etc are signed by the archive key. It's possible to go and grab the .dsc file to see who did the file build, but day-to-day no one is using these to verify the binaries they receive. I care more that Debian stands behind the packages I download than being able to verify individually who build each of the packages I'm running - there's no meaningful way I can attribute trust to *all* of the people who packaged something I have installed. > Now back to the "secondary" purpose: > > Using these information "B claims C", other reproduction programs > (that we're also developing) can attempt to actually reproduce the > binaries described. It would do this, by (1) reading the buildinfo > file (2) recreating _some_ of the environment stored in C, and (3) > executing the process, and see if it gives R. You don't need the signature to validate the reproducibility. > The "_some_" in clause (2) is currently up-for-debate, but the > important thing is that this can be changed in the future *without > affecting already-produced buildinfo files*. It may even well be the > case that in the future we'd want to support different values for > "_some_" for a given reproduction tool. > > The main point is that, this is not a concern of the producer nor > distributor of the buildinfo files. I.e.: you guys (the FTP team) only > have to care about making these signed-claims available to be > downloaded by users, and it is up to the users to run a tool that > "interprets" these claims for purposes such as actually attempting > reproduction of a binary. To clarify: I am not a member of the FTP team and do not claim to represent them. I am a DD who was present at the DebConf talk about reproducible builds, was impressed by how far it's come, and asked how I could help get what was missing and still required into Debian. > In this way, we achieve full end-to-end security properties > (verifiability of build) between the producers (builders) and > consumers (users). Distributors only need to care about a
