search

GrapheneOS / hardened_malloc

Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-based platforms. It will gain more portability / integration over time.
https://grapheneos.org/
MIT License
1.3k stars 97 forks source link

Packaging for desktop linux distributions #236

Closed monsieuremre closed 11 months ago

monsieuremre commented 11 months ago

The releases are tarballs which are universal, so obviously this is a good choice. And since this project is mainly suited and kind of made for grapheneOS, it is very understandable that the usage on desktop linux systems is not a priority. Tho it is true that desktop operating systems do not come even nearly close to being as secure as something like graphene OS, there are some who are willing to put the effort to make use of as much as hardening as possible, like Qubes and Whonix. And 'hardened malloc' just happens to be a colossal massive step towards having your system hardened against unknown vulnurabilities. Packaging hardened malloc as .deb and .rpm would not only cover the most common linux systems, it would make it very very easy for distributions to package it, and way more easier for users to install it themselves. It is not the most easy to maintain thing for the user to manuall build something with every release, or jumping similar hoops.

What do you think of the idea of making the releases available as .deb and .rpm packages as well? I think you should most definetely consider this.

If you think the target audience is too limited and/or this falls outside the scope of this project, you should still look into making these available as make targets. This would just require having a spec file for example for the rpm build. If there was a way to directly build the rpm package, that would still be something very big. I personally can try adding rpm packaging support directly to the project. Kicksecure already packages this as a .deb, and I am very sure the developers there would be more than willing to have this functionality upstream. So I doubt there will be much work on your end aside from of course examining and approving what we will add to make rpm and deb targets directly buildable within the project. Would you be willing to merge such requests upstream?

thestinger commented 11 months ago

We only make tags and write release notes for them. GitHub non-optionally generates a tarball for tags to allow downloading the sources without using Git.

Packaging isn't as simply as you're implying since it would have to be done per operating systems rather than per packaging format.

The best way to integrate it into an OS is really building it into libc along with adding other important libc hardening features and compiler features.

RoyalOughtness commented 5 months ago

@monsieuremre FYI, I maintain a copr for it for secureblue here