Live data from Hacker News

Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

arstechnica.com

21–30 of 38 posts

Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

#21

Having 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 everyon…

Honestly, pfSense has been a bit suspect for a while due to less than forthright development.

OpnSense is the truly open source alternative and is a solid option. It was started in protest of pfSense’s less open behavior.

Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

#22
post #18
post #15

Earlier quoted context omitted.

> 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

There's some discussion happening now and I do expect to see some process changes coming out of this. It's tricky. The review you link does nominally follow the process of creating a review and having some discussion, but there isn't much actual code review happening there.

Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

#23
A note on the article it lists as one of the code flaws "Validation functions which simply return true".

That got me thinking what's so bad about returning true? What should they be returning?

Then I realized that what article must is trying to complain about is: "Validation functions which ALWAYS return true".

Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

#24
post #12

When 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 (…

You also have NetBSD. WireGuard is going to be available with release 10.0 and the default MTA is Postfix. NetBSD is a low profile BSD, but very capable.

Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

#25
post #21

Having 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 everyon…

Honestly, pfSense has been a bit suspect for a while due to less than forthright development. OpnSense is the truly open source alternative and is a solid option. It was started in protest of pfSense’s less open behavior.

Thanks. I will have a look!

Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

#26
post #15
post #6

This 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.

The core group had a chance to state this when they were asked for a response. This one word could’ve come from any of the FreeBSD devs contacted by the author. Instead back came either nothing or a general statement without any real message.

Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

#27
Good that folks on FreeBSD have proper controls that stopped the problem before it was released, and shame on Ars Technica for bringing completely irrelevant 10+ year old eviction dispute into an article about technical issues as if it were relevant. This bullshit needs to stop. I mean I get that the guy may have some issues, and burnout is a very real thing, and if the code is low quality then it needs to be addressed, but it shouldn't be "oh and also his code is bad because of 10-year old story that has nothing to do with the code in question". We really can do without this stuff, and if they just dropped that whole section, the article would be much improved.

Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

#28
post #16

Earlier quoted context omitted.

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.

As someone who is totally not aware of this: Why is everybody so horrified about sendmail being included in an OS?

Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

#29
post #27

Good that folks on FreeBSD have proper controls that stopped the problem before it was released, and shame on Ars Technica for bringing completely irrelevant 10+ year old eviction dispute into an article about technical issues as if it were relevant. This bullshit needs to stop. I mean I get that the guy may have some issues, and burnout is a very real thing, and if the code is low quality then it needs to be address…

Calling the story "eviction dispute" is quite an understatement. They served 4 years jail sentence for sawing huge hole through tenants' living room and forging threatening letters as if they were coming from tenants.

The story is relevant, because:

1. It was already out there in the public. Skipping it completely would be unprofessional.

2. It gives a possible explanation for low code quality.

3. The developer in question is open about his past.

4. Person who went so far as resort to destruction and deceit in the physical world, could easily cut corner in the code review process:

https://reviews.freebsd.org/D26137

https://news.ycombinator.com/item?id=26596108

Re: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

#30
This is an incredibly good piece of journalism. It gives tangible examples of the issues found, puts it in context of prior work done by the developer, features first-hand verification of the claims made against the code; the author reached out for comment to all the parties involved.

I'm also consistently impressed by the quality of comments at Ars Technica whenever I visit the site.

This convinced me to subscribe. We need more journalism of comparable quality.

Post reply on HN