Live data from Hacker News

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

arstechnica.com

31–38 of 38 posts

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

#31
post #28

Earlier quoted context omitted.

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?

Historically, there were a ton of vulnerabilities in sendmail. 1980’s C code, etc. Also, I will say its configuration format (“sendmail.cf”) is awful, though generally nobody works with it directly. FreeBSD uses “m4” to build the configs, for example.

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

#32
post #26
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.

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.

That's fair. At the time, though, it wasn't clear that the author's angle was that FreeBSD doesn't have a culture of doing code reviews. We do, and I don't think one has to look very hard to see that.

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

#33
post #28

Earlier quoted context omitted.

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

Historically, there were a ton of vulnerabilities in sendmail. 1980’s C code, etc. Also, I will say its configuration format (“sendmail.cf”) is awful, though generally nobody works with it directly. FreeBSD uses “m4” to build the configs, for example.

Thank you!

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

#34
post #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.

netbsd also has the biggest, most cruftly code base and least developers. fwiw

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

#35
post #32
post #26

Earlier quoted context omitted.

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.

That's fair. At the time, though, it wasn't clear that the author's angle was that FreeBSD doesn't have a culture of doing code reviews. We do, and I don't think one has to look very hard to see that.

Well, at least once code was committed without being thoroughly reviewed. Clearly FreeBSD’s development process needs some refinement to ensure that the entire code is actually reviewed during a code review.

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

#36
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 qu…

Most important part first:

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

This is a very dangerous delusion. It implies that producing flawed code requires some kind of moral blemish, a flawed character, a bad person. Truly upstanding citizen and high moral character would never submit a buggy code, but one can't expect otherwise from a criminal.

Nothing could be further from the truth. In my decades-long experience reviewing what must be by now megabytes of code, the code quality has absolutely no relationship to the moral character. Best people can produce - and regularly do produce - very flawed code (very much including myself, of course), and even excellent coders can be busy, tired, have temporary slip of attention, be wrong about particular API or language construct, mistaken, suffer from a burnout or a work-life issue... Even at their best, people produce flawed code all the time - that's why we have code reviews in the first place! It's not to weed out "that kind of people" who try to sneak into our pristine cohorts - it's because producing good code is hard, and producing flawless code all the time is nigh impossible to do by a single person. A concerted effort of multiple smart people over time is required to achieve even imperfect, but acceptable quality - and perfection is still an unattainable goal. It's a hard work, and it can't be done alone - nothing to do with character flaws.

And yes, left to their own devices, even the best people are subject to cognitive biases and fallacies - that's why it's impossible to effectively review one's own code and you need peer review. Not because you're suspected in being a criminal or at least a sloppy coder - but because you're human and as such, your best effort will never be perfect, especially not at scales modern code is produced.

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

Nonsense. Nobody expects every article about a person to include their complete biography. People expect including relevant stuff and throwing out irrelevant one. What is unprofessional is brining in irrelevant details to smear the character of a person to prejudice the reader against him from the start (that's why this BS goes first and the substantial part goes later). Instead of trusting the reader to judge on substance, the hack first creates an emotional prejudice which would cloud the mind of the reader and make a pre-formed opinion before the substantial part ever begun.

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

#37
post #32
post #26

Earlier quoted context omitted.

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.

That's fair. At the time, though, it wasn't clear that the author's angle was that FreeBSD doesn't have a culture of doing code reviews. We do, and I don't think one has to look very hard to see that.

The FreeBSD organization should not have had to be told what issues this incident raises, so this response raises one more flag about how the organization is handling it.

This defensiveness in FreeBSD's response, this reaction of minimizing rather than facing up to the seriousness of the problem revealed here, the attempt to redirect the conversation towards anything but the specific issue, only reinforces the impression that FreeBSD may not be ready to deal with it effectively.

Of course, as FreeBSD is open source, its users are in no position to demand anything, but any potential user may, and should, attempt to determine how likely it is meet her needs in all respects.

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

#38
post #8
post #2

So some Twitter grand inquisitors, whose names always seem to appear if individuals are targeted, discovered some unpleasant details about someone's past. Code quality (especially when written under pressure) is unrelated to that and I've seen horrible code from from model citizens who check all the Twitter boxes of goodness. It seems very dangerous to contribute to open source these days if you are not in the right…

At least bad opinions on Twitter are not a crime... and you know, perhaps Ars shouldn’t bring it up, but it’s hard when they themselves refer to it as a personal set back. But even though I absolutely believe everyone deserves a second chance, I really find it hard to sympathize with a person who does what is alleged, doesn’t apologize ( as far as I have heard ), attempts to flee the charges, then has the gull to lam…

Adults rarely change their essential character. Most criminals guilty of substantial predictable harm to others are unethical people. Those who integrate with society successfully learn not to do stupid destructive things. They are not likely to stop being terrible people.

Anyone who would try to drive people out of their homes by destroying them while they live in them is a terrible person without redemption.

His inability to turn away money to do work he had no intention or capability to complete just demonstrates this.

Perpetual punishment is pointless but everyone has a right to know the kind of person they are dealing with.

Post reply on HN