Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bootstrappable Builds: How and Why

lwn.net

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Bootstrappable Builds: How and Why

#21

Post by lrvick »

charcircuit wrote: post #14

So much time has been wasted by the open source community on pointless projects like this. >Reproducible builds allow people to "have more confidence that the binary you are using, which is actually executing on the computer, corresponds to the source code". The developer signing the build provides sufficient guarantees. Reproducible builds is another waste of time that the open source community has fallen for instea…

> The developer signing the build provides sufficient guarantees.

There are tons of documented cases of people resorting to physical attacks to obtain valuable cryptographic signing keys stored in full in one place.

https://github.com/jlopp/physical-bitcoin-attacks

I can only guess the people painting targets on their backs that big are woefully unaware of it, or living in deep survivors bias.

Trusting control of the entire internet to the laptop memory holding the PGP signing key that signs debian packages of GCC was always an insane thing to do, and still is.

Imagine what happens when one of those maintainers decides they like bribes or do not like being hit with rubber hoses.

Quorum signing of full source bootstrapped deterministic builds completed on independently owned and geo-distributed hardware produced by different vendors is currently the only viable solution to greatly reduce the incentive to coerce maintainers.

Re: Bootstrappable Builds: How and Why

#22

Post by charcircuit »

moring wrote: post #18
charcircuit wrote: post #14

So much time has been wasted by the open source community on pointless projects like this. >Reproducible builds allow people to "have more confidence that the binary you are using, which is actually executing on the computer, corresponds to the source code". The developer signing the build provides sufficient guarantees. Reproducible builds is another waste of time that the open source community has fallen for instea…

Just for perspective, the people working on his are pursuing their hobbies and sharpening their programming skills. In contrast, you are using your time to whine about it on the internet.

People can still pursue their hobbies and sharpen their programming skills by working on more productive issues that exist. While you could call my comment whining, if it is able to change maybe even one person's opinion on the utility of this work it could help lead to a bigger reprioritization of people's time allowing for more important issues that affect real users to be addressed instead.

Re: Bootstrappable Builds: How and Why

#23

Post by lrvick »

XorNot wrote: post #19
Panzerschrek wrote: post #4

Are chain-of-trust attacks real? Is it necessary to make so much effort to avoid what supposedly never happened?

I worry less about chain of trust and more about continuity of business: it's not enough to be a able to stay running, you need to be able to keep delivering features which means your build infrastructure and data needs to be local. I.e. if someone cuts all the undersea fiber optics, what do we do? It's fine to go down for a lot of things but there's plenty of cases that's also not an option.

This is absolutely one of my reasons. When the internet goes down I have every line of code that built my system from zero right here.

Re: Bootstrappable Builds: How and Why

#24

Post by lrvick »

charcircuit wrote: post #20
lrvick wrote: post #17

Earlier quoted context omitted.

The XZ attack was not in version control. It was on the human-built tar files published to Github Releases which no one reviews. Trust in a single person. Distros paranoid about supply chain attacks like stagex build directly from (ideally well reviewed) VCS snapshots for all modern software. Our defense-in-depth approach to supply chain security would have prevented the XZ attack because we never trusted the vulnera…

The threat actor had access to the source control so he could have just as easily put it there too. Even if you caught it by being so diligent about reviewing it (not many people are in practice), it would not have been caught due to the reproducible builds or bootstrapping work.

> The threat actor had access to the source control so he could have just as easily put it there too.

And yet they did not because that would be much much higher risk of getting caught, given lots of people pay attention to high-performance-impact code like xz changing, and it would have been obvious in code review .He had to hide it and take advantage of distros being lazy about supply chain trust and modify the code -after- review.

Most supply chain attacks in the clear are detected.

Suffice to say, it was viable defense for this attack before anyone had seen it used before, that worked as intended.

Security engineering is about preventing attacks before they happen. If we normalize full source bootstrapped deterministic and quorum signed builds, then the internet is no longer vulnerable to a $5 wrench attack like it is right now.

Re: Bootstrappable Builds: How and Why

#25

Post by tux3 »

moring wrote: post #16
tux3 wrote: post #13

Earlier quoted context omitted.

For one plain text is a bit more convenient to view, edit, and talk about on line. And as you move up towards more complex capabilities, you can start adding simple features like comments and basic text macros to give a name to your common opcodes The bootstrap aims to use a progressively more capable language at the same time that the size of the next object to review increases. Otherwise we could just dump a curren…

Opcode mnemonics is something that a tool can show when you inspect a binary. You will need to go up the ladder a lot before the source code is more expressive than a disassembly. Comments are a good point though, but since they do no affect the semantics, they could be provided as a separate file that does not have to be reproducible (since compromised comments are at worst misleading or confusing). The GCC example…

People are doing that with lisps and schemes, but then the interpreter keeps growing. People start to want more expressivity, it needs optimizations so that you don't go mad trying to write a compiler with it and needing to wait 15min between test runs.

That compound if your lisp interpreter is itself running as a bytecode for an extremely simple VM interpreter.

I don't think it's a bad idea, but you will quickly end up with a growing pile of esoteric code and binary that only you really understand

Re: Bootstrappable Builds: How and Why

#26

Post by fjfaase »

charcircuit wrote: post #14

So much time has been wasted by the open source community on pointless projects like this. >Reproducible builds allow people to "have more confidence that the binary you are using, which is actually executing on the computer, corresponds to the source code". The developer signing the build provides sufficient guarantees. Reproducible builds is another waste of time that the open source community has fallen for instea…

I have developing software in C(++) since 1990, but I did learn some new things about the language when developing a C compiler for a live-bootstrap variant not using the GNU Mes compiler.

Re: Bootstrappable Builds: How and Why

#27

Post by cyberclimb »

lrvick wrote: post #17
charcircuit wrote: post #15

Earlier quoted context omitted.

>We almost had a major backdoor in OpenSSH deployed worldwide, caught at the 11th hour. Which was not caught by any of the reproducible work people had done. Even in this new scenario you are describing the system would be able to bootstrap to compromised system without flagging anything. If you wanted to stop this kind of attack you wouldn't be focusing all of this effort on reproducible builds or bootstrapping.

The XZ attack was not in version control. It was on the human-built tar files published to Github Releases which no one reviews. Trust in a single person. Distros paranoid about supply chain attacks like stagex build directly from (ideally well reviewed) VCS snapshots for all modern software. Our defense-in-depth approach to supply chain security would have prevented the XZ attack because we never trusted the vulnera…

I thought the attack itself was version controlled via a tracked blob file used in a unit test. I believe the attack was performed by running the test suite (which modified the source code) and then compiling?

If that's the case, then anyone that ran the tests prior to building from source would be vulnerable if my understanding is right

Re: Bootstrappable Builds: How and Why

#28

Post by charcircuit »

lrvick wrote: post #21
charcircuit wrote: post #14

So much time has been wasted by the open source community on pointless projects like this. >Reproducible builds allow people to "have more confidence that the binary you are using, which is actually executing on the computer, corresponds to the source code". The developer signing the build provides sufficient guarantees. Reproducible builds is another waste of time that the open source community has fallen for instea…

> The developer signing the build provides sufficient guarantees. There are tons of documented cases of people resorting to physical attacks to obtain valuable cryptographic signing keys stored in full in one place. https://github.com/jlopp/physical-bitcoin-attacks I can only guess the people painting targets on their backs that big are woefully unaware of it, or living in deep survivors bias. Trusting control of the…

Reproducible builds and bootstrapping doesn't stop physical extortion of shipping a new compromised version either.

Re: Bootstrappable Builds: How and Why

#30

Post by moring »

tux3 wrote: post #25
moring wrote: post #16

Earlier quoted context omitted.

Opcode mnemonics is something that a tool can show when you inspect a binary. You will need to go up the ladder a lot before the source code is more expressive than a disassembly. Comments are a good point though, but since they do no affect the semantics, they could be provided as a separate file that does not have to be reproducible (since compromised comments are at worst misleading or confusing). The GCC example…

People are doing that with lisps and schemes, but then the interpreter keeps growing. People start to want more expressivity, it needs optimizations so that you don't go mad trying to write a compiler with it and needing to wait 15min between test runs. That compound if your lisp interpreter is itself running as a bytecode for an extremely simple VM interpreter. I don't think it's a bad idea, but you will quickly end…

The more I think about it, the more I think that bootstrapping the build isn't actually the huge problem it first seemed to be. There are practical problems to solve, but they CAN be solved.

In contrast, how can you make sure that the actual payload code hasn't been tampered with? It is written in a high-level language, but it gets stored and viewed on devices that have backdoors in their CPU microcode and huge OSes that can hide god knows what. The author can sign the code, but that doesn't tell anything other than it was really the author who signed it and the code hasn't been modified afterwards -- if the author's system was compromised, the code can contain backdoors before being signed. So you need to validate the (signed or not) code to be correct, but you're doing so on an untrusted system. It goes on and on.

You'd probably need the code to be verified, then signed, by a trusted party on a trusted system. THAT signature then means the payload hasn't been tampered with, and can be trusted after it gets built on your trusted system (and this is where the bootstrap problem happens, and gets solved).

All this is obviously still glossing over the problem how to obtain hardware you can trust.

...edit: But if you have all that, then you don't need a complex bootstrapping anymore. A trusted actor can verify, or even build, a trusted system by hand on trusted hardware, sign it, and then you can use that (binary!) as long as you run it on your own trusted hardware and verify the signature first.

The bootstrapping then becomes a tool to ensure reproducibility, but is no longer needed for trust.

Post reply on HN