| 15 Nov 2024 |
 emily | involving manual pkgrel bumps etc. | 11:20:25 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @emilazy:matrix.org
does openSUSE rebuild every downstream package for a one-byte security fix patch in OpenSSL that doesn't affect the headers or ABI? I'm not sure if they added an automated function reference table or something similar when using the open build service. This process may be done manually, but based on my past experience with OBS, it should not be automatic | 11:20:49 |
 p14 | Can we come back to what it would take to actually try and start implementing this? Is there a prototype repo or effort to try some of these ideas somewhere? | 11:21:08 |
| emily | OpenSUSE is just like us (crazy rebuilds, fancy automated QA service) | 11:21:09 |
| emily | In reply to @p14:matrix.org
Can we come back to what it would take to actually try and start implementing this? Is there a prototype repo or effort to try some of these ideas somewhere? it's in my head :) | 11:21:20 |
| p14 | Want to collaborate and try and prove it can be done? :) | 11:21:33 |
| p14 | I would try and use it and break it. | 11:21:49 |
| p14 | (and fix it) | 11:21:57 |
| emily | here's the sketch: for every derivation producing a shared library, you want to use llvm-ifs to generate stubs from the libraries. you put those in dev, say | 11:22:08 |
| p14 | Makes sense. | 11:22:17 |
| emily | downstream derivations do not consume the library output at build time. they consume dev exclusively | 11:22:23 |
| emily | and dev is ca-derivations | 11:22:32 |
| emily | (can you have only some outputs be CA? probably not. so it's a pain with Nix already) | 11:22:39 |
| emily | (but you can split it up into a separate derivation, etc.) | 11:22:44 |
| p14 | For the prototype is there a reason you can't make whole derivations ca, even if they are not reproducible? | 11:23:20 |
| emily | you then, as part of the final package fixed-point-taking, join up every package that depends on a stub with the corresponding actual library output, and patch up the executables to point to the real paths. (optional: fancy static dynamic loading stuff goes here for perf) | 11:23:21 |
| emily | that's pretty much it. rebuilds of build tools still rebuild a lot | 11:23:34 |
| emily | but if you change the implementation of a function in OpenSSL without adding or removing any symbols, and don't touch the headers, then the only rebuilds are executables that use OpenSSL and things depending on them | 11:23:54 |
| p14 | Well, you could imagine trying to make the build tool that does the patching as small and reproducible as possible. | 11:24:02 |
| emily | and the executable rebuilds are really cheap | 11:24:08 |
| emily | just some patching | 11:24:10 |
| emily | so if you eliminate OpenSSL from your build tools, that means that OpenSSL updates become ~free | 11:24:15 |
| emily | a few thousand seds, basically | 11:24:20 |
| p14 | Sketch makes sense. | 11:24:32 |
| emily | I wouldn't be opposed to helping trying to implement it, at least in the form of "oh, this is how you should handle X" | 11:24:53 |
| emily | I doubt Nixpkgs will ever adopt this system, though | 11:24:59 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @emilazy:matrix.org
here's the sketch: for every derivation producing a shared library, you want to use llvm-ifs to generate stubs from the libraries. you put those in dev, say Looks like libgl or vulkan-loader | 11:25:01 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | Makes sense | 11:25:04 |
| emily | sufficiently ambitious projects like this go in my "for the Nix successor" folder :) | 11:25:15 |
| emily | In reply to @aleksana:mozilla.org
Looks like libgl or vulkan-loader yeah, except we patch in the final location at build-time | 11:25:23 |
