Fetch dependencies? Aaaaaah! [LWN.net]

Fetch dependencies? Aaaaaah!

Posted Sep 13, 2021 18:56 UTC (Mon) by mirabilos (subscriber, #84359)
In reply to: Fetch dependencies? Aaaaaah! by karkhaz
Parent article: Cro: Maintain it With Zig

No, not that.

Downloading the source you actually want to build (if you verify it) is fine.

But during the actual build process, network access shouldn’t be available. I personally added this to pbuilder in Debian for Linux, using unshare(1). I don’t currently have a solution for nōn-Linux yet.

to post comments

Fetch dependencies? Aaaaaah!

Posted Sep 13, 2021 19:14 UTC (Mon) by karkhaz (subscriber, #99844) [Link] (4 responses)

I see. Well, that exists too. I can't remember details but I'm almost certain that LibreOffice does some bizarre thing where it fetches its various language packs from the server during the build.

Indeed you can see in the build() function of the PKGBUILD [1] that the autogen.sh script takes a "--with-gdrive-client-id" flag, which implies that it's pulling something out of Google Drive, and a few lines down it writes a touchfile called "src.downloaded". This is obviously a script written by upstream. So no idea how Debian deals with this. I think I've seen other awful stuff like this, but LibreOffice's build stood out in my memory as being exceptionally painful.

[1] https://github.com/archlinux/svntogit-packages/blob/packa...

Fetch dependencies? Aaaaaah!

Posted Sep 13, 2021 20:47 UTC (Mon) by Wol (subscriber, #4433) [Link]

How long ago was that?

Bear in mind, that one of the major differences between OpenOffice and LibreOffice in the early years was LO paid off a hell of a lot of technical debt, including a *massive* rewrite of the build system.

Which is why LO can now release new versions every few months, and I can build it at regular intervals on gentoo, while OpenOffice last I heard took 14 months to release a bodged fix for a major security problem because nobody could get the build system to build ...

Cheers,
Wol

Fetch dependencies? Aaaaaah!

Posted Sep 13, 2021 22:41 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

The gdrive client ID thing is because LibreOffice itself can interact with Google Drive: this configure option lets you bake a client ID to do that access into the binary. It doesn't access Google Drive during the build. It's not *that* crazy. :)

It does download a fairly big pile of tarballs: you can do this before the final make, but after configure runs, via 'make fetch': the tarballs can be kept between runs. This just means that your build system needs to be able to split configure and make apart and run them separately, and run things that allow network access in between: it doesn't mean that you need to allow network access during the configure or make phases.

Fetch dependencies? Aaaaaah!

Posted Sep 13, 2021 22:56 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

Almost.

Fetch them beforehand, by using package system means.

Backdoored configure scripts are a thing.

Fetch dependencies? Aaaaaah!

Posted Sep 14, 2021 11:07 UTC (Tue) by karkhaz (subscriber, #99844) [Link]

Thanks for these details. I did remember that LibreOffice failed to build when I blocked its network access but didn't have time to dig into it too deeply now, good to know that it doesn't download from GDrive for the build :)

However, I think the point still remains. Sure, there's a difference between the configure and build stage from an upstream perspective, but all of that is part of the "build" stage for a package manager. In particular, the Arch build system has a means to automatically check the hashes of all of the package sources that are declared in the "sources" array, before doing anything else. Obtaining source files later in the build process breaks reproducible builds and all the guarantees you get from that. Maybe the autogen script checks those hashes itself, and maybe it doesn't, but sidechaining the OS's own validation mechanisms doesn't really bode well.