While I agree that it would be about time do replace for example NTP and sendmail with DragonFly (dntpd, dma) or OpenBSD alternatives (openntpd, opensmtpd) and that the FreeBSD project is caring about compatibility in the wrong places sometimes, I think the article is out-right wrong by saying a lot of these things are per default.
For example sendmail per default isn’t used in a way where they are easily attackable, ntpd to my knowledge isn’t activated by default and a regular FreeBSD installation will give you pages to both enable/disable daemons and enable security related features.
On the topics of firewalls. The decision to fork pf reading through its history wasn’t exactly out of a whim and while I wished it wasn’t done, acting like it simply was not updated is wrong.
The part on periodics I guess is taste and actually I do find those logs interesting and they for example tell you about packages with security issues. OpenBSD’s approach to emails is more quiet, which can be nice (if you are sure things work) and to my knowledge Debian does the same. I’d however agree that they might be from a different time. If you don’t like them, all you need to do is setting the config option for them to no.
periodics themselves are pretty useful. It’s nice that your typical package (postgres, Let’s encrypt clients, etc.) come with ready to enable sane configs where you don’t have to write your own script to run with cron and figure out what makes the most sense for how frequently to run them. Or worse, having random scripts writing random stuff into the general crontab, maybe without even mentioning that.
I agree that swap should be encrypted by default and it’s a shame how many operating systems don’t do that. However, FreeBSD per default asks you on encryption.
And some other parts (freebsd-update, etc.) I agree with or are a bit of a taste/philosophical discussion topic. Some of these, like an alternative to freebsd-update would likely be welcome.
As fort ports and poudriere. I am a huge fan of poudriere and in most instances I set it up. It’s three or so simple commands. I really wished there was something similar in Linux-land. There’s also some competing projects and alternatives for users. You can just configure pkg to use it locally from the file system or use it remotely. And all you have to do is provide static files over one of various protocols. It even gives you a completely static dashboard to view over HTTP telling you about the state.
So while I strongly agree that FreeBSD should be less conservative on some fronts and dare to change defaults, I also don’t think they are walls, you can’t overcome. So suggest changes on the mailing lists and get feedback. Pretty sure that most mentions of “bad design” in the article would welcome changes. I’d much rather have enjoyed to read a discussion on these, to also hear responses to the raised issues. There’s verifiable wrong information (about things being the default mostly), which kind of doesn’t help being intermixed with all the problems in there. I am also uncertain that this is the right way to spark a discussion, compared to bug reports with fixes or mailing list posts. The snarky comments don’t help either.
If it’s meant to be a list of issues, stuff to change, why not make a list of the, link to a mailing list post or bug report and document the status?
And some other parts (freebsd-update, etc.) I agree with or are a bit of a taste/philosophical discussion topic. Some of these, like an alternative to freebsd-update would likely be welcome.
Yes please, I want pkg base! (Unfortunately, David’s talked a lot about how much the refactoring work in base to make this happen would suck…)
Who’s David ?
I’m one of the people working on pkgbase (and using it for more than two years now on all my machines) and I don’t understand what you mean …
That was a link to the .txt version, it’s now .html.
This link gets shared around every now and then, and my response is always the same: there is some useful insight, but there’s also information that’s so outdated it provides no value, outright misinformation, and self-contradiction. Some of the technical points are fair, and should be and are being addressed. But the commentary is often laughably wrong. The document seems more focused on advancing an agenda than a good-faith effort at improving security in FreeBSD.
Remember that line from the beginning of this page?
FreeBSD takes security very seriously and its developers are constantly working on making the operating system as secure as possible.
I think it’s safe to say that’s a big lie.
The FreeBSD Foundation sometimes gets over a million dollars in yearly donations, so you might be wondering why the project can’t get any of this stuff right. Well, it seems they’ve got other plans for how to use your money.
There are so many things wrong with these statements.
A million dollars isn’t that much for a project as big as FreeBSD. If this person is so concerned with security then they would want more money thrown at development work.
In the “how to use your money” link, this person links to mailing list drama regarding the Code of Conduct. This person is somehow implying that the million dollars is being directed towards the Code of Conduct (obviously not) and that the implementation of a proper Code of Conduct is a waste of time/money (very obviously not).
The implication here is that somehow this work on the Code of Conduct somehow damaged FreeBSD’s security work and practices (huh??)
My first (and only) experience with FreeBSD happened because I received a GitHub issue where one of my open source projects didn’t compile on FreeBSD due to a missing include. I downloaded the FreeBSD ISO and spun up a VM.
After installation and setup, I downloaded git, cloned my project, and fixed the issue. So far so good.
But then I had to set up my git user, which is when I found out that FreeBSD’s TTY doesn’t support the ‘ø’ in my name. Great. After some googling, I found out that there’s no workaround other than to install X11.
So I did that. But even though I had set up a Norwegian keymap with setxkbmap, I still couldn’t enter the ‘ø’ in xterm.
In the end I had to do some ridiculous hack to get it working. I think what ended up working was to install Firefox and navigate to a website containing ‘ø’, and copy-paste it to xterm. Or maybe I have up on getting the terminal to remember and edited the vim config in a text editor. Or maybe I have up entirely and manually made my changes on the host Linux system. I honestly can’t remember, it’s been a few years. But that experience told me that FreeBSD isn’t for me.
And yes. I know that you can work around this. There are, potentially, non-American FreeBSD users. But the fact that they just don’t seem to care at all about this stuff told me more than enough about their priorities; people with my kind of name aren’t in their target market.
It doesn’t surprise me that all other FreeBSD defaults are similarly fucked up.
On the contrary, we do care very much about this sort of thing - we want to make sure that folks have a good, “low friction” experience with their first exposure to FreeBSD. I’m interested in both making sure that this works in general, as well as reproducing the specific case you encountered. Would you kindly let me know what FreeBSD version you tried, and which VM software you were using?
I don’t know what would be the problem with X11 then, but FreeBSD ports does not change Xorg’s default configuration, nor does FreeBSD change Vim’s default configuration.
If you had not time traveled from 2013, it would be useful to submit the console bug to FreeBSD, and submit the second bug to Xorg. Or maybe Vim.
You can use kbdmap to set up the keyboard in the console; e.g. with US-International you can get é with “alt + ’ + e”. ø isn’t in US-International it seems, but you can select a Norwegian keyboard and get ø, or modify the standard US-International layout to add it. As mentioned, this has worked since 2014, and getting Unicode support was a major reason for working on it in the first place; the old syscons was from the early 90s when things like multibyte encodings weren’t really on the radar.
IIRC it asked for this during installation too, but not 100% sure as it’s been a while. I think even the old “sysinstall” installer asked for it (but that has been replaced years ago).
I haven’t seriously used FreeBSD since 2015 or so; I just checked the handbook’s Localization - i18n/L10n Usage and Setup chapter and tested it in my QEMU VM just to verify it works (it does).
Setting up UTF-8 inside Xorg and xterm on FreeBSD is pretty much identical to Linux, and is something that has worked for decades.
I appreciate you had a frustrating time, but “lemme just do this real quick” on an unfamiliar system is often frustrating, for many different tasks. Your rant is misplaced and misinformed.
I’m honestly not a fan of FreeBSD for a variety of reasons (despite being a longer time user), but I also don’t necessarily agree with this article. I’m definitely not a fan of the weird agenda being put forth about spending/management/whatever.
I agree with what’s been said above about the situation with ntpd and sendmail being less than ideal, and would prefer some alternatives (I only lean more towards the OpenBSD alts because I have no experience with Dragonfly).
One of the bigger frustrations for me is the firewall situation. Normally I stick with pf, even though the syntax is ancient, since I’m more familiar with it, and if I’m doing NAT, I don’t have to deal with natd (altho I hear that that’s changed in ipfw-land). tbh I frankly hope that one day, FreeBSD just picks one firewall (I’d guess ipfw) and drops the rest.
The sysctls and loader options I find incredibly frustrating, esp since the discoverability is incredibly bad. A lot of these aren’t documented (at least anywhere I can find). I don’t find sysctl -d -a to be great usability, esp since the descriptions are too short and poor. How is a user expected to find out about any of these, esp the undocumented sec mitigations? Why have them if they’re not documented?
Also tbh, I find the lack of encrypted swap as well as the lack of privsep in some core utilities to be less than ideal.
A lot of the recommendations here I think should be carefully considered, but I am constantly surprised that some of these things are not default in FreeBSD, and that the discoverability story for a bunch of these is so bad. That said, I don’t agree with a lot of the drama and message of the author here.
While I agree that it would be about time do replace for example NTP and sendmail with DragonFly (dntpd, dma) or OpenBSD alternatives (openntpd, opensmtpd) and that the FreeBSD project is caring about compatibility in the wrong places sometimes, I think the article is out-right wrong by saying a lot of these things are per default.
For example sendmail per default isn’t used in a way where they are easily attackable, ntpd to my knowledge isn’t activated by default and a regular FreeBSD installation will give you pages to both enable/disable daemons and enable security related features.
On the topics of firewalls. The decision to fork pf reading through its history wasn’t exactly out of a whim and while I wished it wasn’t done, acting like it simply was not updated is wrong.
The part on periodics I guess is taste and actually I do find those logs interesting and they for example tell you about packages with security issues. OpenBSD’s approach to emails is more quiet, which can be nice (if you are sure things work) and to my knowledge Debian does the same. I’d however agree that they might be from a different time. If you don’t like them, all you need to do is setting the config option for them to no.
periodics themselves are pretty useful. It’s nice that your typical package (postgres, Let’s encrypt clients, etc.) come with ready to enable sane configs where you don’t have to write your own script to run with cron and figure out what makes the most sense for how frequently to run them. Or worse, having random scripts writing random stuff into the general crontab, maybe without even mentioning that.
I agree that swap should be encrypted by default and it’s a shame how many operating systems don’t do that. However, FreeBSD per default asks you on encryption.
And some other parts (freebsd-update, etc.) I agree with or are a bit of a taste/philosophical discussion topic. Some of these, like an alternative to freebsd-update would likely be welcome.
As fort ports and poudriere. I am a huge fan of poudriere and in most instances I set it up. It’s three or so simple commands. I really wished there was something similar in Linux-land. There’s also some competing projects and alternatives for users. You can just configure pkg to use it locally from the file system or use it remotely. And all you have to do is provide static files over one of various protocols. It even gives you a completely static dashboard to view over HTTP telling you about the state.
So while I strongly agree that FreeBSD should be less conservative on some fronts and dare to change defaults, I also don’t think they are walls, you can’t overcome. So suggest changes on the mailing lists and get feedback. Pretty sure that most mentions of “bad design” in the article would welcome changes. I’d much rather have enjoyed to read a discussion on these, to also hear responses to the raised issues. There’s verifiable wrong information (about things being the default mostly), which kind of doesn’t help being intermixed with all the problems in there. I am also uncertain that this is the right way to spark a discussion, compared to bug reports with fixes or mailing list posts. The snarky comments don’t help either.
If it’s meant to be a list of issues, stuff to change, why not make a list of the, link to a mailing list post or bug report and document the status?
Yes please, I want pkg base! (Unfortunately, David’s talked a lot about how much the refactoring work in base to make this happen would suck…)
Who’s David ? I’m one of the people working on pkgbase (and using it for more than two years now on all my machines) and I don’t understand what you mean …
Previously submitted 6 years ago: https://lobste.rs/s/6ih126/freebsd_lesson_poor_defaults (6 comments)
It’s the same URL, I am not sure why the dupe detector did not catch this.
That was a link to the .txt version, it’s now .html.
This link gets shared around every now and then, and my response is always the same: there is some useful insight, but there’s also information that’s so outdated it provides no value, outright misinformation, and self-contradiction. Some of the technical points are fair, and should be and are being addressed. But the commentary is often laughably wrong. The document seems more focused on advancing an agenda than a good-faith effort at improving security in FreeBSD.
That’s correct, the original link was to a .txt document that now redirects to HTML, which is why I was confused.
There are so many things wrong with these statements.
A million dollars isn’t that much for a project as big as FreeBSD. If this person is so concerned with security then they would want more money thrown at development work.
In the “how to use your money” link, this person links to mailing list drama regarding the Code of Conduct. This person is somehow implying that the million dollars is being directed towards the Code of Conduct (obviously not) and that the implementation of a proper Code of Conduct is a waste of time/money (very obviously not).
The implication here is that somehow this work on the Code of Conduct somehow damaged FreeBSD’s security work and practices (huh??)
My first (and only) experience with FreeBSD happened because I received a GitHub issue where one of my open source projects didn’t compile on FreeBSD due to a missing include. I downloaded the FreeBSD ISO and spun up a VM.
After installation and setup, I downloaded git, cloned my project, and fixed the issue. So far so good.
But then I had to set up my git user, which is when I found out that FreeBSD’s TTY doesn’t support the ‘ø’ in my name. Great. After some googling, I found out that there’s no workaround other than to install X11.
So I did that. But even though I had set up a Norwegian keymap with setxkbmap, I still couldn’t enter the ‘ø’ in xterm.
In the end I had to do some ridiculous hack to get it working. I think what ended up working was to install Firefox and navigate to a website containing ‘ø’, and copy-paste it to xterm. Or maybe I have up on getting the terminal to remember and edited the vim config in a text editor. Or maybe I have up entirely and manually made my changes on the host Linux system. I honestly can’t remember, it’s been a few years. But that experience told me that FreeBSD isn’t for me.
And yes. I know that you can work around this. There are, potentially, non-American FreeBSD users. But the fact that they just don’t seem to care at all about this stuff told me more than enough about their priorities; people with my kind of name aren’t in their target market.
It doesn’t surprise me that all other FreeBSD defaults are similarly fucked up.
On the contrary, we do care very much about this sort of thing - we want to make sure that folks have a good, “low friction” experience with their first exposure to FreeBSD. I’m interested in both making sure that this works in general, as well as reproducing the specific case you encountered. Would you kindly let me know what FreeBSD version you tried, and which VM software you were using?
FreeBSD’s console started supporting UTF-8 since 2013 (as a default in 2014). https://wiki.freebsd.org/Newcons
I don’t know what would be the problem with X11 then, but FreeBSD ports does not change Xorg’s default configuration, nor does FreeBSD change Vim’s default configuration.
If you had not time traveled from 2013, it would be useful to submit the console bug to FreeBSD, and submit the second bug to Xorg. Or maybe Vim.
You can use
kbdmapto set up the keyboard in the console; e.g. with US-International you can get é with “alt + ’ + e”. ø isn’t in US-International it seems, but you can select a Norwegian keyboard and get ø, or modify the standard US-International layout to add it. As mentioned, this has worked since 2014, and getting Unicode support was a major reason for working on it in the first place; the old syscons was from the early 90s when things like multibyte encodings weren’t really on the radar.IIRC it asked for this during installation too, but not 100% sure as it’s been a while. I think even the old “sysinstall” installer asked for it (but that has been replaced years ago).
I haven’t seriously used FreeBSD since 2015 or so; I just checked the handbook’s Localization - i18n/L10n Usage and Setup chapter and tested it in my QEMU VM just to verify it works (it does).
Setting up UTF-8 inside Xorg and xterm on FreeBSD is pretty much identical to Linux, and is something that has worked for decades.
I appreciate you had a frustrating time, but “lemme just do this real quick” on an unfamiliar system is often frustrating, for many different tasks. Your rant is misplaced and misinformed.
I just checked Norwegian keyboard input on my ~FreeBSD 13 laptop:
I was definitely switching to a norwegian keyboard in the TTY. It just didn’t work.
I have never “set up UTF-8 inside Xorg and xterm” in Linux. Linux systems all default to UTF-8. Systems which don’t are simply broken by default.
So maybe you did something wrong?
I am so tired of this rant culture. It was a mistake to come back.
That’s really shitty and I’m sorry that happened to you.
I’m honestly not a fan of FreeBSD for a variety of reasons (despite being a longer time user), but I also don’t necessarily agree with this article. I’m definitely not a fan of the weird agenda being put forth about spending/management/whatever.
I agree with what’s been said above about the situation with ntpd and sendmail being less than ideal, and would prefer some alternatives (I only lean more towards the OpenBSD alts because I have no experience with Dragonfly).
One of the bigger frustrations for me is the firewall situation. Normally I stick with pf, even though the syntax is ancient, since I’m more familiar with it, and if I’m doing NAT, I don’t have to deal with natd (altho I hear that that’s changed in ipfw-land). tbh I frankly hope that one day, FreeBSD just picks one firewall (I’d guess ipfw) and drops the rest.
The sysctls and loader options I find incredibly frustrating, esp since the discoverability is incredibly bad. A lot of these aren’t documented (at least anywhere I can find). I don’t find
sysctl -d -ato be great usability, esp since the descriptions are too short and poor. How is a user expected to find out about any of these, esp the undocumented sec mitigations? Why have them if they’re not documented?Also tbh, I find the lack of encrypted swap as well as the lack of privsep in some core utilities to be less than ideal.
A lot of the recommendations here I think should be carefully considered, but I am constantly surprised that some of these things are not default in FreeBSD, and that the discoverability story for a bunch of these is so bad. That said, I don’t agree with a lot of the drama and message of the author here.