FreeBSD shipped sendmail , for how many years? Is it actually still in ports?
Last I checked (FreeBSD 12.x), sendmail was still the default and included with the base install.
Buffer overruns, license violations, and bad code: FreeBSD 13’s close call
11–20 of 38 posts
Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call
#12When I was younger and had more time, I loved the BSDs. FreeBSD seemed so coherent, I loved the ports collections etc. And FBSD had a reputation for good code. From 2000-2004 I ran FBSD exclusively on my servers. Then slowly, FBSD seemed to start to splinter. First Matt Dillon took off for DragonflyBSD and then I started using Linux more. When I needed a firewall, I chose OpenBSD because Theo seemed to have a tight (some would say too tight) grip on the project.
When FBSD integrated ZFS, I took a look and decided that while I love that file/storage system, FBSD itself had turned more into a lesser version of itself. Perhaps this was due to more pressure from Linux, and fewer developers/contributors.
This entire Wireguard debacle has pretty much turned me off ever using FBSD again. From the inclusion of Sendmail as the default MTA (really? over Postfix) to the lack of development control outlined in this article, I can't trust it.
Perhaps Theo's strategy was the better path.
Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call
#13Earlier quoted context omitted.
Ars seems to be calling all open source software insecure. I’m not saying they are wrong but what’s the value in their article? Is it gotcha journalism, or are they warning us not to trust bsd based systems in general. The article starts as a gotcha piece but concludes by saying there’s no review in place to catch these problems.
> Ars seems to be calling all open source software insecure > The article starts as a gotcha piece Haha, that’s the problem. You, Netapp, value saving face so very much that you are incapable of constructive response to well-meaning, fair, and honest criticism.
Not netapp and I don’t use or endorse their products. I just don’t like angry mobs or journalism that uses angry mobs as a business model. Too much anger and retribution in the world, not enough forgiveness or compassion. If this code was up for review for months and nobody noticed the printf debugging code in the crypto then I’m sorry but blaming this one bad person seems gratuitous to me, and shortsighted. Are concludes the article by saying this is a bsd/open source problem. How does that help anyone?
Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call
#14Having deployed Netgate PFsense hardware at my last 3 startups words cannot express how disappointed I am in this. I have also recommended them to others. I understand that mistakes happen, but I feel their response was utter garbage. Unfortunately I am done with them and will have to find another option for the future. We need a project to put a web GUI on PF on OpenBSD (while I can sort the .conf files, not everyone can).
Thank you to Jason Donenfeld (Wireguard), Kyle Evans (FreeBSD) and Matt Dunwoodie (OpenBSD) for jumping in and fixing this in a week!
Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call
#15This does not paint FreeBSD in a good light. “you either have a commit bit (enabling you to commit code to FreeBSD's repositories) or you don't. It's hard to find code reviews, and there generally isn't a fixed process ensuring that vitally important code gets reviewed prior to inclusion. This system thus relies heavily on the ability and collegiality of individual code creators.” From my perspective, this whole thin…
> Or is this just how it is on FreeBSD?
It's not. We do a lot of code review, and it's done publicly. It's easy to look at the commit logs. I find it telling that the article doesn't spend even one word trying to delve into our code review practices. This case was an aberration.
Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call
#16FreeBSD shipped sendmail , for how many years? Is it actually still in ports?
Last I checked (FreeBSD 12.x), sendmail was still the default and included with the base install.
OK... With sendmail still in the base install, why is anybody talking about new security or code quality problems?
Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call
#17This does not paint FreeBSD in a good light. “you either have a commit bit (enabling you to commit code to FreeBSD's repositories) or you don't. It's hard to find code reviews, and there generally isn't a fixed process ensuring that vitally important code gets reviewed prior to inclusion. This system thus relies heavily on the ability and collegiality of individual code creators.” From my perspective, this whole thin…
Ars seems to be calling all open source software insecure. I’m not saying they are wrong but what’s the value in their article? Is it gotcha journalism, or are they warning us not to trust bsd based systems in general. The article starts as a gotcha piece but concludes by saying there’s no review in place to catch these problems.
This is just incorrect. Nowhere in the article does the author, Jim Salter, generalize about all open source software. When someone in the comments did make that leap, Salter pointed out that if these had been closed-source projects the bad code would have been put into production and no one would have known better.
Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call
#18This does not paint FreeBSD in a good light. “you either have a commit bit (enabling you to commit code to FreeBSD's repositories) or you don't. It's hard to find code reviews, and there generally isn't a fixed process ensuring that vitally important code gets reviewed prior to inclusion. This system thus relies heavily on the ability and collegiality of individual code creators.” From my perspective, this whole thin…
> Or is this just how it is on FreeBSD? It's not. We do a lot of code review, and it's done publicly. It's easy to look at the commit logs. I find it telling that the article doesn't spend even one word trying to delve into our code review practices. This case was an aberration.
As a FreeBSD user, that's good to hear :)
Has there been any discussion about why the process failed in this case, and what is going to be done to make sure something similar doesn't happen in the future?
This is the review for the original commit, in case anyone is interested: https://reviews.freebsd.org/D26137
Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call
#19Earlier quoted context omitted.
Last I checked (FreeBSD 12.x), sendmail was still the default and included with the base install.
OK... With sendmail still in the base install, why is anybody talking about new security or code quality problems?
The sendmail of today is not the sendmail of the 90's.
Sure, I'd prefer postfix, but if you're just sending local email out for system checks or whatever, sendmail's okay.
Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call
#20Earlier quoted context omitted.
Ars seems to be calling all open source software insecure. I’m not saying they are wrong but what’s the value in their article? Is it gotcha journalism, or are they warning us not to trust bsd based systems in general. The article starts as a gotcha piece but concludes by saying there’s no review in place to catch these problems.
This is just incorrect. Nowhere in the article does the author, Jim Salter, generalize about all open source software. When someone in the comments did make that leap, Salter pointed out that if these had been closed-source projects the bad code would have been put into production and no one would have known better.
You’re right. I misread the original to be general criticism of open source, but the author made his statement specific to FreeBSD release 13.
“Neither Netgate's responses, FreeBSD Core's, nor the off-record responses we heard from independent FreeBSD community members lead us to believe that there was in fact any process in place that could reasonably have been expected to catch this issue prior to it going out into the world in 13.0-RELEASE”
But it would help if he made it clear why he felt this criticism was specific to FreeBSD release13. It sounds to a naive reader like a critique that could apply to much of open source software. The author didn’t say that, but it’s a reasonable extrapolation to make.