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

[Hans-Christoph Steiner]

Jérémy Bobbio wrote:
> Hans-Christoph Steiner:
>> I still strongly disagree.  Very very few people care enough to learn a
>> separate process.  For security to be usable, it needs to be as transparent
>> and automatic as possible.  APKs and Android have demonstrated that you can
>> have this kind of system working well.
> 
> Comparing .deb and APKs is misleading when talking of tools. A given
> .deb will have dependencies. APKs are self-contained.

That is only true to a small degree.  Many APKs depend on other APKs to
provide "Activity" or "Service" instances that respond to "Intent" messages or
are accessible via "AIDL" interfaces.  For example, if your app wants to
interact with OpenKeychain as a OpenPGP provider, then OpenKeychain must be
installed.  Android is fundamentally built around the idea that apps rely on
each other provide chunks of functionality.

It is true that APKs basically never use shared libraries from other APKs, but
that is largely because Android is a very different OS than UNIX, Windows,
etc. If you are thinking of Android as some kind of Linux distro, you will be
quite misguided in understanding how it actually works.


> This makes `.deb` hard to use without a repository for anything
> substantial. I would assume that's why Ubuntu developed the Click
> package format.

Check out apt-offline, it makes this process easy.  That's just one example.
The problem is that if the apt cache is more than two weeks old, you can no
longer even install .deb files that were previously verified and stored in the
apt cache.  This is why I'm interested in signatures embedded in the .deb as
something separate from the apt signatures.

I also regularly download individual .deb packages when I need a to use a
newer one in my old stable setup.  That is vastly easier to use than apt
preferences, even when considering that I have to manually check the checksum.


>> They've made the whole process easier by requiring the upstream
>> developer be the manager of the signing. I think setting up a similar
>> role in Debian will be quite beneficial, and dak and the package
>> maintainer are natural roles to be the signer.
> 
> With the current .buildinfo signing scheme, we require the Debian
> maintainer to provide a package that can be built reproducibly. Then we
> can require a proof of that reproducibility from the maintainer, any
> other maintainers, and any number of buildds. These assessments that a
> build can be properly reproduced can come after the initial upload. We
> can only do that if the .deb files do not change after they hits the
> archive.

.buildinfo sounds great for managing the reproducible build process and an
unlimited number of build verification signatures, that sounds fine by me.
Then anyone who wants to verify the build themselves can use the tools for
that process, and those tools can handle the .buildinfo file without the user
having to know about them.

But .buildinfo is not a replacement for the embedded signature with an
immutable signature.  They solve different problems.  This embedded signature
idea is not really directly related to reproducible builds, but dkg started
this thread here so I responded.

.hc

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