Follow

Apple's increasing requirements (now notarization) are making it more and more difficult to distribute binaries for open source software

if this requires proprietary tools running on MacOS, this is the end of the gitian deterministically built binaries for that platform

@devrandom @orionwl github.com/bitcoin/bitcoin/iss

Full disclaimer: I've been procrastinating for months on actually studying this topic.

@devrandom every program that is distributed for MacOS (even outside their app store) needs to be seen by apple first, or users get a scary warning

it's the way to total centralized control of what software people run on their platform

in any case, it's an extra hassle for making native applications, and the question is how this interacts with deterministic distributed build, esp. if attaching apple's signature happens in a secret way, or if they check if a blessed x-code compiler was used

@kekcoin @devrandom who knows, one problem is that they *could* do that

note that the deterministic build process as it is now (dongcarl has some better ideas on this youtube.com/watch?v=I2iShmUTEl) doesn't protect against backdoored *software* (like compilers), only individual backdoored build machines, by being able to cross-verify

anything that makes the process dependent on proprietary software running on a single computer, compromises this

@orionwl @devrandom will watch video later. Tldr on why current process doesnt protect against a backdoored compiler?

@kekcoin @orionwl @devrandom To produce a compiler, you need... a compiler. So somewhere you have to trust someone's compiler (this is called the "trusting trust" problem; see Ken Thompson). The solution being worked on by various people, which Carl Dong hopes to adopt for Bitcoin Core, is to create a tiny compiler of about ~500 lines of well-documented assembly and use that to bootstrap building more advanced compilers from well-audited source code, which then build the rest of the toolchain.

@harding @orionwl @devrandom Right. I have been excited about {deterministic|reproducible} builds' potential to solve the Ken Thompson hack. As I see it, the reproducability of a certain binary build is indeed "only" part of the solution - making trust transitive.

The full solution requires bootstrapping the trust and creating a "trust transition" path from bootstrap to final product.

(Still have yet to watch the video, damn you lack of time).

@orionwl @kekcoin @devrandom
I find the whole section "Speeding up builds with substitute servers" in the README (GH PR 15277) quite odd and contra-dictionary

If you want to bootstrap to eliminate (as much as possible) the element of trust, then it makes no sense at all to use some 'random' person's Docker image 🤦‍♂️ or dongcarl's substitute server.
Using *Debian* to download packages would make more sense as that's almost entirely reproducible.
Bootstrapping is about verifying, not convenience

@FreePietje @kekcoin @devrandom there's different compromises that people are comfortable with, the idea is to accommodate anything from bootstrapping from TTL gates, to those that trust a quorum of people to have done some level of bootstrapping and compared results

I agree that the current situation with gitian of "just trusting an ubuntu image" isn't desirable, but it's still a lot better than no distributed deterministic build, trusting one person and their build machine.

@orionwl @kekcoin @devrandom
What is/are TTL gates?

I think the initiative itself is great and/as I see it as a further step up from reproducible builds.
On second thought, if the Docker image is only a preconfigured environment from which to *start* the whole bootstrapping process, then my doubt/critique probably isn't justified.

FYI: new policy requires a source-only upload before it can transition to testing (and thus can land in the next stable). Thus .debs are build on Deb infra.

@orionwl @kekcoin @devrandom
If you go for bootstrapping, that is inherently time consuming, but you've explicitly chosen for that (for good reason). So you should also bear the consequences.
Similarly, if you go for a source distribution like Gentoo, you know it'll take you longer then using a binary distribution like Debian.

I do think it's odd that Ubuntu is chosen over Debian as Ubuntu has done weird stuff in the past (Amazon). Debian has enacted various things that bitcoin core aligns with

@FreePietje @orionwl @devrandom

> Ubuntu has done weird stuff in the past

Like recommending users to install Bitcoin Unlimited via snap when trying to run Bitcoin Core.

@kekcoin @orionwl @devrandom
There is also an important legal and commercial difference. Ubuntu has a headquater and therefor can be legally required to do things which are not in the best interest of its users. IANAL but I don't think Debian can be compelled to such things.
Canonical is a commercial company and its goals also don't have to align with their user's.
Similar potential issue is also present with Docker images, which are hosted by a commercial company.

Sign in to participate in the conversation
unidentified instance

(instance image by мøтħer ¢røω)