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
Jonathan McDowell:
> [..]
>
> 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
Hi,
On Tue, Dec 06, 2016 at 10:41:34PM +, Jonathan McDowell wrote:
> 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
Jonathan McDowell:
> 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
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
Jonathan McDowell:
> 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
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
On 2016-12-07, Jonathan McDowell wrote:
> 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
On Tue 2016-12-06 17:41:34 -0500, Jonathan McDowell wrote:
> 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
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
Hi,
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
Daniel Kahn Gillmor:
> Hi all--
>
> On Mon 2016-11-14 12:13:00 -0500, Ximin Luo wrote:
>> A GPG signature with a 4096-bit key is about 800 bytes in base 64:
>>
>> http://ftp.debian.org/debian/dists/sid/ (has 2 signatures, if you use `gpg
>> --list-packets`)
>>
Hi all--
On Mon 2016-11-14 12:13:00 -0500, Ximin Luo wrote:
> A GPG signature with a 4096-bit key is about 800 bytes in base 64:
>
> http://ftp.debian.org/debian/dists/sid/ (has 2 signatures, if you use `gpg
> --list-packets`)
>
Chris Lamb:
> Ximin Luo wrote:
>
>> This minimal solution still depends on 3rd-party services being available to
>> host the files. A much better solution is for the FTP archive to *also* store
>> the signed buildinfo files, somewhere safe that can be recovered when needed.
>
> Totally ACK. Just
Ximin Luo wrote:
> This minimal solution still depends on 3rd-party services being available to
> host the files. A much better solution is for the FTP archive to *also* store
> the signed buildinfo files, somewhere safe that can be recovered when needed.
Totally ACK. Just to be clear, I was
Ximin Luo:
> [..]
>
> Now then, why does the FTP archive need to distribute buildinfo files at all?
> It can simply store the signed files and distribute the hashes. Then
> rebuilders
> (people that want to verify our reproducibility claims) can download the
> hashes
> from the archive, get the
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 having the Debian FTP archive distribute unsigned buildinfo files is an
OK intermediate solution, with a few tweaks:
1. the hashes
17 matches
Mail list logo
