4 ms·
I would advise taking any claims from HardenedBSD about HardenerBSD with a huge grain of salt. The main code author behind HBSD has a history of his patches to
by tachion 8y ago
I would advise taking any claims from HardenedBSD about HardenerBSD with a huge grain of salt. The main code author behind HBSD has a history of his patches to FreeBSD being rejected due to very poor implementation, coding errors, poor quality and not understanding OS and security features design and reasoning and not accepting their reviews and not listening to his peers. He is however very good at getting himself and HBSD a lot of PR attention for bold security claims, but has a very poor record when it comes to quality code.
This list is also not very accurate either: his ASLR patches to FreeBSD were rejected due to quality issues, then they were applied to HBSD. The lack of mark for base sandboxing is another one, where FreeBSD had Capsicum sandbox available for few years now and a lot of base is now Capsicum sandboxed, with more and more coming with every release. I could go on here, but that should give you the picture.
Take this advice with grain of salt as well - I'm a FreeBSD developer, so I might be biased.
- yjftsjthsd-h 8y agoSounds a bit like the grsecurity situation on Linux; someone wants to patch the system to be more secure, but in a very specific way and with a tendency to break existing programs and with questionable code quality, leading to mainline refusing to merge their patches without major reworking, which leads to the developer making the patches their own thing while loudly proclaiming that the mainline is terrible and insecure.