RFC: In guix compile the GUI sequentially from everything else? #29914

1. 
   maflcko commented at 3:07 pm on April 19, 2024: member

   Compiling the GUI pulls in quite a few dependencies, which could theoretically include backdoors that are leaked into bitcoind (or other non-GUI utils) as well.

   A possible mitigation would be to compile the GUI in a separate guix container from the rest of the binaries. The downside would be that the node library, and the depends dependencies of the node library would have to be compiled twice, but the overhead may be worth it?

   (I won’t be working on this, but I wanted to keep track of this in a brainstorming issue, as the topic has repeatedly come up)

2. maflcko added the label Brainstorming on Apr 19, 2024
3. maflcko added the label Build system on Apr 19, 2024
4. 
   laanwj commented at 4:33 pm on April 22, 2024: member

   FWIW in #29923 i’ve removed all the GUI specific build-time dependencies except for Qt itself.
5. 
   maflcko commented at 5:47 am on April 23, 2024: member

   FWIW in #29923 i’ve removed all the GUI specific build-time dependencies except for Qt itself.

   Nice!

   qt is still a massive blob (and possibly a large attack surface for backdoors), so I guess sequential builds could still be considered, but the priority would be less urgent after 29923.

6. 
   laanwj commented at 7:27 am on April 23, 2024: member

   Sure, and there may still be other reasons to have seperate build step; the idea of fully static binaries for the non-GUI utilities was raised again at CoreDev. This is not possible with the GUI as it necessarily needs access to the dynamic linker. And as this might require different compile and linker flags, this would also effectively need two seperate builds.
7. 
   fanquake commented at 11:00 am on April 24, 2024: member

   fully static binaries

   Yea. I think I’m just going to start PR’ing related changes, so we can move forward with static builds separately from the GUI, and keep all it’s deps / build tools out of the env.

8. 
   fanquake commented at 3:47 pm on February 18, 2026: member

   It seems like what we would end with is something like:

   • Guix env with minimal manifest (bitcoind & utils only) tooling
   • Build depends with NO_QT=1
   • Build bitcoind and utils
   • Exit Guix
   • New Guix env with minimal manifest + Qt tooling/deps + any packaging tools (+ previously built bins)
   • Rebuild all of depends (likely forced given profile/env has changed) with QT=1
   • Build bitcoin-qt & bitcoin-gui
   • Build installers / perform packing
   • Exit Guix env

   Some other thoughts:

   • We’d (given static builds) end up with different sets of flags when building bitcoind + utils and bitcoin-qt / bitcoin-gui.
   • The security and symbol check scripts would need to be refactored to accomodate different binary types. i.e static vs not.
   • Building the installers (i.e windows) seems doable, as we can manually run NSIS on the bins. I’m not sure if that becomes easier, or harder if we migrate to CPack (a todo according to cmakelists).

Contributors
maflcko laanwj fanquake

Labels
Brainstorming Build system