[Reproducible-builds] concrete steps for improving apt downloading security and privacy

Hans-Christoph Steiner hans at guardianproject.info
Mon Sep 22 20:06:55 UTC 2014



Elmar Stellnberger wrote:
> Am 22.09.14 um 01:52 schrieb Paul Wise:
>> On Mon, Sep 22, 2014 at 2:04 AM, Elmar Stellnberger wrote:
>>
>>>     A package with some new signatures added is no more the old package.
>> That is exactly what we do *not* want for reproducible builds.
>>
>>> It should have a different checksum and be made available again for update.
>> The Debian archive does not allow files to change their checksum, so
>> every signature addition requires a new version number. That sounds
>> like a bad idea to me.
> Yes, that is something we definitely do not want.
> Nonetheless it would still be an issue to have the package and the signatures
> in one file because we usually need them together. My only idea to realize this
> in spite of the said objection would be another proposal:
> Put the .deb and the signatures into one .ar called .sdeb and make tools like
> dpkg work on .sdebs or on .deb + signatures respecively. Whenever someone
> offers some packages for download that will be in the form of .sdebs while
> official debian repositories may separate both kinds of files. User interfaces
> like http://debtags.debian.net/search/ could then generate .sdebs on the fly
> to satisfy petted users.

I think we're starting to nail down the moving parts here, so I want to
outline that so we can find out the parts where we agree and where we disagree.

* I hope we can all agree that the package itself should not change once it
has hit the official repos.

* I believe we can achieve what we want without taking a shortcut and
introducing a new core package type (.sdeb .debs or whatever).  We can figure
out how to do this with the .deb file.  Personally, I would accept a new
package type after a thorough exploration of keeping .deb fails to deliver,
but not before.

* There should be at least one verification build before a package becomes
official.

* Then there needs to be a channel for people to submit the results of their
own builds.  That could be only positive results or only negative results, or
both.

* the .buildinfo file should contain all info needed to reproduce the build,
given a standard Debian build environment

Anything I left out?

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81



More information about the Reproducible-builds mailing list