I poked around but couldn’t find an answer: how does this handle glibc not supporting static linking? Does it just use musl libc? And how old of a kernel can these run on?
I saw it mention Kakoune, which I think uses the C library, so I assume this must have been addressed.
The dependencies and compilation processes vary depending on each package.
Also, it’s not necessarily true that glibc does not support static linking, it does.
But extensive usage of dlopen & other libs does mean, extra work (& some work around is needed).
For C-based packages, I prefer using musl, specifically within an Alpine container where all necessary static libraries are pre-installed.
For Kakoune, the src is here (uses alpine): x86_64-Linuxaarch64-Linux
As for how old of a kernel, these binaries can run on,
I have tested a few of them on a CentOS 7 Docker Image(> glibc-2.28 >Kernel 3.10.0-123)
This means, the binaries should run on pretty much everything.
This however does exclude static-pie binaries and pkgs that specifically rely on some new kernel features as it is part of their function.
If glibc uses dlopen (even when linked statically) then that sounds like it has a run-time dependency on something. I assumed loading that dependency would fail on, say, a fresh Alpine install (where no glibc is present).
But I haven’t tried in a while, so hopefully things have improved!
To give a tldr; everything is as transparent as can be (Build is run on GitHub-Actions & Logs are always Publicly Available/Auditable), so are the scripts.
The only thing not addressed is perhaps Signing, however this was deliberate since signing would add additional metadata to the binaries (Some of the binaries are directly pulled from GitHub Releases of their respective repos, modifying these binaries will result in their checksums being changed) which I considered redundant since there’s both SHA256 & B3SUM (generated at build time) for everything. dbin verifies that the checksums match when you install any pkg.
In the end, you can always distrust everything & decide to do everything on your own.
For this, you can read the Dockerfiles, manually build them and then run the build environment to compile your own binaries on your own system. And finally, point dbin to use your own repo.
Nice! I wonder if anyone has tried running it on https://github.com/oasislinux/oasis
I poked around but couldn’t find an answer: how does this handle glibc not supporting static linking? Does it just use musl libc? And how old of a kernel can these run on?
I saw it mention Kakoune, which I think uses the C library, so I assume this must have been addressed.
The binaries are pulled from: https://github.com/Azathothas/Toolpacks (I am the author)
The dependencies and compilation processes vary depending on each package. Also, it’s not necessarily true that glibc does not support static linking, it does. But extensive usage of
dlopen& other libs does mean, extra work (& some work around is needed).For C-based packages, I prefer using musl, specifically within an Alpine container where all necessary static libraries are pre-installed. For Kakoune, the src is here (uses alpine): x86_64-Linux aarch64-Linux
I have a somewhat rough build notes at: Docs/BUILD_NOTES.md
I recommend checking the build-recipe (because it differs pkg by pkg) for whatever pkg you are curious about: https://github.com/Azathothas/Toolpacks/tree/main/.github/scripts
As for how old of a kernel, these binaries can run on, I have tested a few of them on a CentOS 7 Docker Image
(> glibc-2.28 >Kernel 3.10.0-123)This means, the binaries should run on pretty much everything. This however does exclude static-pie binaries and pkgs that specifically rely on some new kernel features as it is part of their function.If glibc uses dlopen (even when linked statically) then that sounds like it has a run-time dependency on something. I assumed loading that dependency would fail on, say, a fresh Alpine install (where no glibc is present).
But I haven’t tried in a while, so hopefully things have improved!
How is this Nix related?
Apologies, couldn’t find anything related to package mangers, and the nix tag had
package manager, distribution, and related systems like guix.This is my first submission, So I should have been more careful. I have edited and removed the tag, Thanks!
Indeed; I think that’s meant to mean “[Nix] package manager, [NixOS] distribution, and related systems like guix.” Not necessarily super clear.
How’s the security, in terms of preventing rootkits and having signed and reproducible packages?
I can’t speak for other sources
dbinuses, but the primary one is my own Toolpacks RepoI have a Security Section in the
READMEthat addresses most of your questions: https://github.com/Azathothas/Toolpacks#-security-%EF%B8%8FTo give a tldr; everything is as transparent as can be (Build is run on GitHub-Actions & Logs are always Publicly Available/Auditable), so are the scripts.
The only thing not addressed is perhaps Signing, however this was deliberate since signing would add additional metadata to the binaries (Some of the binaries are directly pulled from GitHub Releases of their respective repos, modifying these binaries will result in their checksums being changed) which I considered redundant since there’s both
SHA256&B3SUM(generated at build time) for everything.dbinverifies that the checksums match when you install any pkg.In the end, you can always distrust everything & decide to do everything on your own. For this, you can read the Dockerfiles, manually build them and then run the build environment to compile your own binaries on your own system. And finally, point
dbinto use your own repo.