[rb-general] Regarding "Zero Install" manifests

[Anders Björklund]

Ximin Luo wrote:
> Hi Anders, do you have a specific proposal to suggest for us here?
> The ideas all sound good but I'm not sure what the overall system
> you're suggesting should be.
> 
> At the moment we already *have* buildinfo files (i.e. signed
> manifests), and the next step is to figure out what sorts of logic we
> should add to say, `apt-get` so that users get a good sense of "how
> reproducible" the packages that they're installing are.

Oh, when I asked my question I got the impression that there was no
standardized output format (that would contain any checksums etc)

Looking at the docs, I saw only generic explanations but no formats:
https://reproducible-builds.org/docs/checksums/
https://reproducible-builds.org/docs/embedded-signatures/
So that is why I gave an example of such a format that does exist ?


Looking at https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles
it seemed rather specific to Debian and I didn't see any contents ?

The idea was for a single format that would describe the binaries.
Wouldn't hurt if it was something like how git describes the code ?


> This article is quite long, are there specific points in it that
> you'd like to discuss?

Not really, it was just to give some backgrounds of the project...

> I would say that this is slightly inaccurate. Even if "distributions"
> didn't exist as a middle-man, different pieces of software would have
> to co-operate to make sure they are co-installable without
> interfering with each other, and various other technical
> compatibility issues.
> 
> The easiest way to do this is to have a standards-body, which is what
> distributions *are*. I agree that the fact there are 4-5 different
> standards (deb, rpm etc etc) is not a great situation, ideally we
> would have one standards-body. The body itself can be politically
> decentralised and Debian is already like that, it's really not so
> hard to get stuff into Debian.

I think we're also back to downloading stuff off the Internet again ?
(curlpipesh seems to be live and well, GitHub does binaries, etc...)

> Yes, distributions as a whole, have some economic power as Thomas
> describes, but I don't see how the rest of what he's proposing really
> "solves" these issues. For example the later suggestion of naming
> things like "gimp.org-gimp-2.4.3" is still very much centralised
> according to the DNS system. The names are longer, and hence there's
> less chance for conflict, but then people will just move to getting
> shorter snappier domain names, then name their programs something
> generic like "main" so we'll end up with things like
> "gimp.org-main-1" which is not that much better than just "gimp".

Yeah, this was discussed at great lengths with the 0alias command.
(it allows you to add a wrapper, to the longer URL style address)

>> It is much better to checksum the binaries (than e.g. the
>> tarballs), because then the _same_ files can be distributed in lots
>> of ways...
> 
> Distributing the same files in different arrangements, could in
> theory activate a backdoor in one arrangement but not the other.
> 0install has a hash for each whole-arrangement as well, so there is
> no security issue there. However, I'm just pointing out that the only
> benefit of "hashing each file" would be for potential deduplication,
> not security.

Keeping the checksum of the files rather than the archive they came in,
offers the possibility to verify this checksum. I think it is handy ?

And yeah, the possibility for deduplication and caching is also nice.
Even for distributed variants of those, or delta updates, or whatever.


But nowadays I'm mostly using Docker images anyway, I suppose that
is _another_ standard for describing the binaries... (e.g. the OCI)

They just recently changed to a content-addressable format, though.
https://github.com/moby/moby/wiki/Engine-v1.10.0-content-addressability-migration

/Anders