# Ars Technica article focused on Wireguard regarding FreeBSD



## sidetone (Mar 27, 2021)

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

40,000 lines of flawed code almost made it into FreeBSD's kernel—we examine how.




					arstechnica.com
				




This article is kind of negative, but I don't know what to make of it. The title says it's about FreeBSD, but it's really focused on something related to Wireguard for criticisms of FreeBSD. Overall, Wireguard wasn't implemented into FreeBSD 13.0 Release. It's weighing heavily on something that almost happened.

Is it supposed to be about code quality and software related issues or veer off from that as well?

It writes about code quality of an implementation of Wireguard: that it printed odd character output on router consoles, authentication always returned true, and that there were buffer overflows.

It says it's a drastic problem of how GPL2 code was almost committed to the FreeBSD 13.0 kernel. As for FreeBSD base, GPL2 programs haven't been a problem for past use of GCC compiler, Binutils in base and modules. The difference of one piece of licensed code in the kernel as opposed to base or extra modules may be a big deal.


Ars Technica usually makes great and informative articles. However, it seems like it's leaning heavily on implementation of Wireguard's problems for something that didn't happen.

I normally wouldn't post something like this, except because it's from Ars Technica about FreeBSD. Negativity isn't good, but then again, it is something that may need to be seen from here.


----------



## Crivens (Mar 27, 2021)

There was also something on The Register about this.


----------



## Deleted member 30996 (Mar 27, 2021)

I used to run a pfSense router on a Dell tower with a P4 and 2GB RAM. It was an electricity hog and when I got better hardware dropped it.

It all makes perfectSense now and never would have worked out anyway:



> pfSense is a federally registered trademark of Electric Sheep Fencing LLC.
> 
> I'm on the lamb but I ain't no sheep


----------



## tuaris (Mar 27, 2021)

Yes it seems that they painted FreeBSD in a very negative light with that 'news' piece.   The quality and content of their articles has been on a decline for the last few years.  They've become just like any another main stream outlet that's more interested in generating views instead reporting on the news, while not caring who they hurt in the process.

Also... does anyone else think Netgate sounds/looks too much like Netgear? I suspect there will be some conflict between those two in the future.


----------



## Beastie7 (Mar 27, 2021)

The article highlights issues with holes in the projects governance. A single committer (who happened to belong to a company with questionable business practices) manages to dump 40k lines of unvetted code into HEAD just on a whim. Something is wrong right there with that margin of freedom.

This is a sound article.


----------



## eternal_noob (Mar 27, 2021)

Beastie7 said:


> A single committer (who happened to belong to a company with questionable business practices) manages to dump 40k lines of unvetted code into HEAD just on a whim.


A criminal (served 4 years and 4 month)
A coward (fled to Italy to avoid prosecution)
A misanthropist (attempting to illegally evict tenants from a building he had bought)
A psychopath (forged extremely threatening emails appearing to be from the tenants themselves)

I'd revoke his commit bit.


----------



## Phishfry (Mar 27, 2021)

Gee I wonder why it is not a good idea to run current...
I think this episode makes the case perfectly. -CURRENT can be a mess.
Did this code make it into -STABLE as well?


----------



## zirias@ (Mar 27, 2021)

Beastie7 said:


> The article highlights issues with holes in the projects governance. A single committer (who happened to belong to a company with questionable business practices) manages to dump 40k lines of unvetted code into HEAD just on a whim. Something is wrong right there with that margin of freedom.
> 
> This is a sound article.


Agreed so far, what happened is shocking and FreeBSD was lucky this was spotted and (after some discussion) removed before 13.0-RELEASE.

Still I don't agree with the tone of the article. It's written in a way that just presumes there are severe structural problems (which would imply something about the general quality of FreeBSD), although it's impossible from the outside to judge how deep this issue reaches. It could just as well be a case of coincidental failure in multiple processes.


----------



## zirias@ (Mar 27, 2021)

Phishfry said:


> Did this code make it into -STABLE as well?


It made it into releng/13.0 and was only removed 9 days ago here: https://cgit.freebsd.org/src/commit/?h=releng/13.0&id=4c6c8f51fdb7e2b3870ec5a6fa5dce51ad3b25a5 (IOW, it was still present up to `13.0-RC2`)

Yes, this was pretty close…


----------



## drhowarddrfine (Mar 27, 2021)

Meh. Sort of. 

Internal issue that was caught as it should have been and was designed to. No harm, no foul (sort of). The system worked. Didn't make it to RELEASE. 

These online rags have to have something to stir up emotions whether they actually affect you or not. This affected no one outside of the development core. Interesting for FreeBSD developers and users only.


----------



## drhowarddrfine (Mar 27, 2021)

Just looked at the comments. If that's their core audience then Ars has stepped to a new low. It reminds me that there was a reason I no longer read it. Have more important things to do.


----------



## zirias@ (Mar 27, 2021)

drhowarddrfine said:


> Internal issue that was caught as it should have been and was designed to. No harm, no foul (sort of). The system worked. Didn't make it to RELEASE.


You mean the very final stage worked. Code like this normally shouldn't even make it to a -BETA. Maybe stopping that in stable/13 would have been a normal thing.

So, see above, I agree something pretty worrying happened. I don't agree with the implicit conclusions made by ars.


----------



## kpedersen (Mar 27, 2021)

I have noticed that Wireguard has been implemented in other operating systems very quickly considering the complexity of it. These are reported to be of a better quality but I would be surprised if there aren't issues further down the line for them.

If this weaker implementation wasn't spotted, would it of harmed FreeBSD 13? Or would issues only arise if you attempted to utilise Wireguard?


----------



## zirias@ (Mar 27, 2021)

kpedersen said:


> If this weaker implementation wasn't spotted, would it of harmed FreeBSD 13? Or would issues only arise if you attempted to utilise Wireguard?


To me, that's kind of the same, so I'd answer yes to both. Sure, you have to actually enable a wireguard interface to expose yourself to the problems, but they seem to include remote-exploitable in-kernel buffer overflows, so DoS is for sure, and remote intrusion is pretty likely. And if this code is there in a -RELEASE, someone will use it, because it's -RELEASE, right?


----------



## Phishfry (Mar 27, 2021)

kpedersen said:


> Or would issues only arise if you attempted to utilise Wireguard?


Good point. Was the kernel module being built or just something sitting in the source tree.
Looking at the removed 45K lines it went very deep into the source code.

I have not seen the phab page for the review process on this. That must be interesting.
I did find this online:


> and they have yet to submit their work through the normal FreeBSD Phabricator process for review.


----------



## Phishfry (Mar 27, 2021)

That was wrong. Here is the phab page.





						⚙ D26137 Wireguard merge
					






					reviews.freebsd.org


----------



## Mjölnir (Mar 27, 2021)

eternal_noob said:


> A criminal (served 4 years and 4 month)
> A coward (fled to Italy to avoid prosecution)
> A misanthropist (attempting to illegally evict tenants from a building he had bought)
> A psychopath (forged extremely threatening emails appearing to be from the tenants themselves)


Are you sure this is the very same person?  I remember that I found two names sound similar, but are not the same when Phishfry posted a newspaper link about that guy.  So this might be a mistaken identity?

On topic, I wonder why this stuff was not send off to be an external kernel module in the ports(7) tree right from the start, like e.g. pefs(8) or the DRM *-kmod.


----------



## eternal_noob (Mar 27, 2021)

Mjölnir said:


> Are you sure this is the very same person?


I don't know him but this is what the article says.


----------



## Mjölnir (Mar 27, 2021)

What's interesting to note about that discussion on _Phabricator_ is that some critical questions were simply ignored.  EDIT Now I have strange thoughts about that _"daylight saving timezone mismatch"_ that was communicated to be the reason for the delay of the scheduled _Office Hours_ last week.


----------



## Phishfry (Mar 27, 2021)

Mjölnir said:


> Are you sure this is the very same person?


I am not. I pulled that link because it seems to me that people deserve a second chance. Getting too personal as well.

That phab review seems to be lacking the normal gurus you would see there like emaste or other top code crunchers.
The fact that two commiters passed it before rejection looks bad too.


----------



## sidetone (Mar 27, 2021)

It's odd that this publication hasn't ran any stories on FreeBSD, then it has two stories of FreeBSD and Wireguard before Release 13.0.

_(Edits:

Referring to https://arstechnica.com/gadgets/202...on-its-way-to-freebsd-and-the-pfsense-router/ and https://arstechnica.com/gadgets/2021/03/freebsd-kernel-mode-wireguard-moves-forward-out-of-tree/

I was wrong about this claim of there being only two stories there, use "site:arstechnica.com/gadgets freebsd" in the webbrowser. There were more articles there about FreeBSD.)_

I used to learn a lot about newer technologies from Ars Technica.

The author can make his points, but it seems biased. The author makes 1 good point, that standards can be improved. Aside from that, it seems like the author is going overboard by associating which didn't make it to a release with all of FreeBSD. It's overly blaming for something which didn't happen. Organizations and people make mistakes, and sometimes they're fatal. The tone is as if FreeBSD has been irresponsible and careless, which goes too far. FreeBSD has done a lot of things right.

I don't know if the committer had a conflict of interest. Also, Wireguard was being proposed to be put in near the last minutes. The right choice was made to postpone it, and I recognized this then. There was some fans of wanting to see it in FreeBSD. I thought it would have been cool, but I know the value of not rushing anything in at the last moment. Code being rushed in the last weeks or months isn't good, even without this current hindsight, because there can be mistakes not related to this. Before knowing about this problem, it was a right choice to move last minute software to a future release, but maybe not anymore.

Someone made a comment that PFSense kept Wireguard out when fans wanted it for a long time, but only brought it in, when it made an appearance into FreeBSD current. I haven't used PFSense, but it's harsh of the amount of fallout it will get from this problem.


----------



## Phishfry (Mar 27, 2021)

Beastie7 said:


> A single committer (who happened to belong to a company with questionable business practices) manages to dump 40k lines of unvetted code into HEAD just on a whim.


I want to disagree with this. Netgate 'sponsored' a FreeBSD commiter to author a Wireguard kernel implementation.

So while Netgate gets bashed all they did was pay a developer to bring a new feature to FreeBSD.
How they ended up as the culprit is beyond me. They were trying to get us faster speeds as the userland implementation is slow.
Imagine trying to contribute to a charity and getting bashed for it. That is what is happening.

I have no ties to them but I use both pfSense and OPNSense. I go back and forth between the two.


----------



## zirias@ (Mar 27, 2021)

Phishfry said:


> How they ended up as the culprit is beyond me.


Well, it's not like they forced FreeBSD to include the code, and tales about conflicting interest for some committers who are also employess are speculative, so: agreed on your reasoning.

Still, what they did is pull not-yet released code back into their product and sell it, and later complain when issues with the implementation were pointed out. That's probably not the best way to do it. Yep, "business value"…


----------



## Phishfry (Mar 27, 2021)

I know they have a checkered past but I still think we need to consider that they are a FreeBSD outfit.
They want the same thing we want.
They are a 'For Profit' business selling open source. That is a tough market.
True Jim has ruffled many feathers. Maybe that is why the review had few participants.


----------



## Deleted member 30996 (Mar 27, 2021)

sidetone said:


> Someone made a comment that PFSense kept Netguard out when fans wanted it for a long time, but only brought it in, when it made an appearance into FreeBSD current. I haven't used PFSense, but it's harsh of the amount of fallout it will get from this problem.


That's not the way I remember it. I was a member of the forums in 2014 and nothing was said about it back then.

They were faithfully following FreeBSD in pfSense v. 2.2 when I last used it. It wasn't till after I left word went round they were switching something about the OS, for the worse, and this must have been it.

You can tell which way the article is leaning by the image at top. The fact their "spectacular buffer overflow" features a pfSense installer and the question of who that makes look bad must be of question.


----------



## Crivens (Mar 27, 2021)

kpedersen said:


> I have noticed that Wireguard has been implemented in other operating systems very quickly considering the complexity of it. These are reported to be of a better quality but I would be surprised if there aren't issues further down the line for them.


The professional thing for them would be to brew up some cup, shut up, lock up and do a verrry close look at the thing. Maybe there is crud they didn't see?


----------



## Mjölnir (Mar 27, 2021)

More please.  IMHO this topic deserves a serious discussion.


----------



## eternal_noob (Mar 27, 2021)

My cat told me that a greedy criminal (ab)used his commit rights to make some quick money.

Any references to historical events, real people, or real locales are used fictitiously. Other names, characters, places, and incidents are the product of the author's imagination, and any resemblance to actual events or locales or persons, living or dead, is entirely coincidental.


----------



## drhowarddrfine (Mar 27, 2021)

sidetone said:


> It's odd that this publication hasn't ran any stories on FreeBSD, then it has two stories of FreeBSD and Netguard before Release 13.0.


Noticed it, too. Like television "news", it's to stir up emotions not report real problems that concern you. Once a theme loses drawing power, they move on.


----------



## Mjölnir (Mar 27, 2021)

How come that Mr. Marcy Macy got a commit bit?


----------



## Beastie7 (Mar 27, 2021)

drhowarddrfine said:


> Noticed it, too. Like television "news", it's to stir up emotions not report real problems that concern you. Once a theme loses drawing power, they move on.


Except that it did report a real problem.

There are no checks and balances with commit privileges, no proper code review channel. Why am I donating to a project where one developer is allowed to dump shitty code just before a release of a *professional *operating system. It does beg the question, where else is this crap happening?

Seeing this type of behavior certainly doesn’t help with my pre-existing frustrations with the system. Maybe if we had 11ac I wouldn’t be so triggered.


----------



## sidetone (Mar 27, 2021)

FreeBSD will survive this, and also adapt to it. I hope Pf Sense survives it too. Sometimes they say negative publicity is good publicity, but not for software or a lot of things.

It's really that fans and those who thought it was a good replacement wanted it in Pf Sense. That's part of why it got so far. It making it to CURRENT was a litmus test for Pf Sense, and it got in that OS too soon. However, I remember reading that.

I don't know about Wireguard, if it's good it deserves another chance, but its code needs independent review. Maybe reviewed code can be on a third party repository platform independent of OS, only added from an upstream repository once its there. That would only be from those who desire Wireguard, or want a parallel derivative that follows behind Wireguard's upstream. Kind of like how Xenocara follows Xorg. If it was a simple to make error by the company, then all of this isn't needed. I wonder if OpenBSD will do a rewrite of it, (a fork is more likely if this didn't happen) as they host other projects.

Ars Technica ran an article on a vulnerability on OpenSSL days ago: https://arstechnica.com/gadgets/202...ty-flaw-that-allows-hackers-to-crash-servers/. It's a similar vulnerability as found in Wireguard: that authentication was bypassed. Now I realize there was already another thread about this as HeartBleed.

This comes to mind. The Linux kernel likely won't have problems much larger than this. But a lot of GNU and GPL code is going to have a lot of issues. If GNUTLS has an issue, it will be one like any of the BSD's had recently, and perhaps not be much worse than that.


----------



## richardtoohey2 (Mar 27, 2021)

Any reason you keep calling Wireguard by the name Netguard?  Is there some background story?

On another of your points, so far as I know, OpenBSD worked closely with the Wireguard developers before Wireguard "landed" in OpenBSD.


----------



## Phishfry (Mar 27, 2021)

Mjölnir said:


> How come that Mr. Marcy got a commit bit?


See this:
2018 Q2




__





						FreeBSD Quarterly Status Report
					





					www.freebsd.org


----------



## drhowarddrfine (Mar 28, 2021)

My point has been, and always will be, that the most important thing that happened is ... nothing.

The second most important thing that happened is that a gap in the development process will be closed.

This howling over the quality of this operating system due to this only shows the aptitude and ineptitude of those doing the howling. These are the rantings of the unknowing and those who wish to make themselves feel superior by pointing out the failure in others while succeeding at nothing themselves. Pointing out failure that, essentially, caused no harm and did nothing is the lowest form of person. Such as most of the commentors on Ars  and typical posters on reddit.

I also wish to say that I refuse to let this make me feel bad or feel bad about FreeBSD. It does not affect me. I doubt it affects anyone here, either. And I am positive that no one sitting in any corporate office or outside of Ars and these forums has mentioned it in any meaningful conversation they had today.


----------



## sidetone (Mar 28, 2021)

richardtoohey2 said:


> Any reason you keep calling Wireguard by the name Netguard?  Is there some background story?
> 
> On another of your points, so far as I know, OpenBSD worked closely with the Wireguard developers before Wireguard "landed" in OpenBSD.


I made a mistake. I must have mixed up WireGuard and Netgate.

The problem is around Macy's commits: whether that was honest human error, carelessness, intentional or problems that were difficult to be foreseen. Not the original code of WireGuard. Netgate simply wanted WireGuard in Pf Sense, and used FreeBSD as a litmus test.

It's saying it was too close for comfort for going into a FreeBSD release. It was in development, where it's well known that, that's not for production systems. FreeBSD current is known for being for testing grounds. Stable is kind of like this way too. The tone of the article is: everyone involved screwed up badly and has a stain on them from this.

Damage was done for Pf Sense and Netgate. It looks like their intention wasn't for bad code to get in. They asked someone who had a reputation for being a good developer and had commit privileges, alternatively the article says he had problems unrelated to software development. Maybe they'll update their release to be without WireGuard. Wireguard's reputation was also hurt from this.

I also question the author's level of expertise for making conclusions, and the associations made. IE, implications of GPL2 code making into the kernel of a development branch, as some GPL2 code is accepted in base. FreeBSD had GPL2 code in its base before, such as GCC, Binutils and modules/drivers. If that's a big deal, that's easily an honest mistake, because a lot of modules in FreeBSD are GPL2, and someone simply moved something from modules to the kernel.

Often, program code isn't portable. Maybe the committer tried to get it in before a release, and ended up adding code to get it in, then made a mistake by moving a FreeBSD module (where GPL2 is allowed) to kernel (where it doesn't belong). Maybe other code was added, as FreeBSD's base is rather slim, and a lot of ports and Linux program builds aren't slim, to simply get it to work. As a separate example, a lot builds with GNU make, but more compatibility work is needed to get BSD make to work. The case isn't about which make was used (as this was a common example), but other software (BSD make was obviously used). However, FreeBSD did replace GNU's binutils for FreeBSD 13 with Elf utils. Adding a bunch of software can make programs work, but the core issue is compatibility issues to make it work with what's in base.

Update:




__





						WireGuard: fast, modern, secure VPN tunnel
					

WireGuard: fast, modern, secure VPN tunnel




					www.wireguard.com
				





> License
> The kernel components are released under the GPLv2, as is the Linux kernel itself.
> Other projects are licensed under MIT, BSD, Apache 2.0, or GPL, depending on context.



GPLv2 getting into the development kernel was an honest mistake, where they didn't keep track of everything. All the WireGuard author has to do if they choose, is dual license kernel components which they are the full author of that are needed to go into Pf Sense and FreeBSD.

The harsh criticism that Macy criticized someone else for using GPL code, then did it himself goes overboard. I was likely an honest mistake.

About Macy: What are squatter rights and basic tenant protections in California? Tenants deserve rights, and I say leniency. Squatters are arguably another topic. This is why I wondered heavily how much relevance of what someone did outside of software, had to do with committing code. Sometimes it matters.


This problem has a lot to do with trying to get code in before a release. The insinuation is that Macy intentionally put bad code in. Maybe he did, as the author implies, but that we don't know right now. It's more than likely, Macy's insertion of GPL code into the FreeBSD development kernel wasn't intentional.

This is why it's good not to rush things in to a newly coming release.

When more information comes about, the article itself may be a minor stain on Ars Technica more than on FreeBSD. Not for saying more standards need to be implemented, but for the approach it took.


----------



## Mjölnir (Mar 28, 2021)

Phishfry said:


> See this: 2018 Q2
> 
> 
> 
> ...


Can you elaborate?  I searched for "WireGuard", "NetG", "marcy" (case-insensitive), found none.
EDIT Rollback: found my mistake, should have searched for "macy" instead.  Looks like he's not frightened of different architectures & domains of CS.  Good.  Multi-talented unsiversal interests, seems to be ablke to quickly get into the topic; great.  Where can I find the tests that were ideally written before trying to weave that non-trivial code into the FreeBSD kernel?  Starting to investigate...


----------



## a6h (Mar 28, 2021)

On FreeBSD part:
It didn't bite the RELEASE. thus I see no problem.

On Article itself:
Obviously It's a hit piece. Typical of red tops, like Arstechnica.

On Arstechnica:
Last time (_many years ago_) I've heard of Arstechnica, it was at _Steve creepy Gibson Show_. He was constantly reading articles from Arstechnica
-- the only thing he is good at it, i.e. reading articles and blogs, beside fear-mongering and gossip.
A rule of thumb: If he likes it, you should avoid it.


----------



## zirias@ (Mar 28, 2021)

vigole said:


> On FreeBSD part:
> It didn't bite the RELEASE. thus I see no problem.


It was on a releng branch up to the second release candidate. For code with such horrific issues, this *is* a problem. Someone will have to think about ways to prevent that from happening again.


vigole said:


> On Article itself:
> Obviously It's a hit piece.


Well, kind of, indeed.


vigole said:


> _Steve creepy Gibson Show_.


Not sure whether you're talking about this lunatic running GRC with these "awesome" secunakeoil tools?


----------



## a6h (Mar 28, 2021)

Zirias said:


> It was on a releng branch up to the second release candidate. For code with such horrific issues, this *is* a problem. Someone will have to think about ways to prevent that from happening again.


I won't argue with that. That was from Normal user point of view, i.e. people like me!, Not as a FreeBSD developer, because I realy don't know what's the implication.



Zirias said:


> Not sure whether you're talking about this lunatic running GRC with these "awesome" secunakeoil tools?


Yes, exactly. Mr. Windows XP Raw socket (1) and WMF (2)

(1) https://www.theregister.com/2001/07/09/steve_walks_on_water_youre/
(2) https://www.zubairalexander.com/blog/microsoft-disputes-wmf-backdoor-claim/


----------



## a6h (Mar 28, 2021)

By the way, what happened to "*Ban the Box*"?
How does his arrest record have anything to do with anything? We've been told repeatedly, by similar media outlets that "_Box_" is bad, and #banthebox
Who am I kidding!


----------



## sidetone (Mar 28, 2021)

It depends. The article did overreach by passing off harsh assumptions as absolute truths without knowing everything.

If someone goes though life by being a lying cheating scumbag, or goes around causing drama. Let's say, someone defrauded others, stole, embezzled, stabbed people for money, and makes their living by lying and robbing. Also if the person is cruel, even if it has nothing to do with committing code. Ok, something like that would matter.

In this case it's different. There's a separation between what that person did and the committed code. Were they squatting, or was he trying to kick out people who tried to pay their rent? If they were squatters, Macy still took the wrong approach.


I already pointed out about being criticized excessively over the GPL code in question, and how that would be an easy mistake to make. It didn't make it to release anyway.

The biggest issue is about trying to get code into a newly coming release. This will always cause problems, no matter the intent. There may be more, but this is what we know for sure.


----------



## zirias@ (Mar 28, 2021)

vigole said:


> I won't argue with that. That was from Normal user point of view, i.e. people like me!, Not as a FreeBSD developer, because I realy don't know what's the implication.


All I contribute (so far?) is in the ports tree, so… this still worries me, because it was very close and _should_ have been caught much earlier. Although I assume such an incident is a singular one.


----------



## zirias@ (Mar 28, 2021)

Here's an official core@ statement: https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057127.html


----------



## drhowarddrfine (Mar 28, 2021)

And if you also notice on the mailing lists that it's not mentioned anywhere which just how much the media can blow things out of proportion among the amateurs and hobbyists with nothing else to do with their time. 

I'm not downplaying the incident. I'm, again, saying it's an internal issue just like any other issues that come up in the course of time and it will be dealt with accordingly. Business as (somewhat) usual.


----------



## _martin (Mar 28, 2021)

Zirias Thanks for posting the link, you spared me some googling time. 
I like the Ars Technica article. It pointed out to a problem. It's similar to a near collision in aviation. Nothing really happened but one has to pay really close attention to it and avoid it in the future. 
Core team is aware of this, they addresses it and I've no doubt some improvements will come out of it.


----------



## obsigna (Mar 28, 2021)

Now, I took a breath and tried to understand what WireGuard is about, and how it would be superior to traditional VPN’s. So I started my search on Wikipedia — and just stopped it already here:


> *Acclaim*
> WireGuard aims to provide a simple and effective virtual private network implementation. A 2018 review by Ars Technica observed that popular VPN technologies such as OpenVPN and IPsec are often complex to set up, disconnect easily (in the absence of further configuration), take substantial time to negotiate reconnections, may use outdated ciphers, and have relatively massive code bases of over 400,000 and 600,000 lines of code, respectively, which hinders debugging.[6]
> 
> WireGuard's design seeks to reduce these issues, aiming to make the tunnel more secure and easier to manage by default. By using versioning of cryptography packages, it focuses on ciphers believed to be among the most secure current encryption methods, and at the time of the Ars Technica review had a codebase of around 4000 lines of kernel code, about 1% of either OpenVPN or IPsec, making security audits easier. WireGuard was praised by Linux kernel creator Linus Torvalds, who contrasted it to OpenVPN and IPsec as a "work of art".[7] Ars Technica reported that in testing, stable tunnels were easily created with WireGuard, compared to alternatives, and commented that it would be "hard to go back" to long reconnection delays, compared to WireGuard's "no nonsense" instant reconnections.[6]


So, Ars Tecnica tells us that the traditional VPN systems are effectively not working. What is Jim Salter of Ars Tecnica talking about? IPsec is complex to setup and disconnects easily? Of course, if you are a dumb-ars, everything is complicated, and normally you are disconnected anyway, with or without IPsec or for what it matters with or without OpenVPN. BTW: The number of lines of IPsec in the FreeBSD kernel is `wc -l /usr/src/sys/netipsec/*` = 20092.

And why does Linux’s WireGuard got 4000 lines and for FreeBSD, according to the very same[6] Jim Salter, 10times as much hit our kernel, which would be actually 2times of the total IPsec code.

Then one of the best ciphers –– Curve25519, ChaCha20 (sounds like haha120) —  created by one guy (Bernstein) who knows exactly two categories of people, namely himself and idiots.

The big question remains, why do we want this piece of fuzz. Wiki and Ars need to get the numbers and the facts straight, and then the next time when our IPsec connection drops (every this and then when Easter and Christmas are celebrated on the same day) we perhaps got some time and sufficient inspiration to start to think about on why WireGuard may become important to our life some day.


----------



## Deleted member 30996 (Mar 28, 2021)

sidetone said:


> If someone goes though life by being a lying cheating scumbag, or goes around causing drama. Let's say, someone defrauded others, stole, embezzled, stabbed people for money, and makes their living by lying and robbing. Also if the person is cruel, even if it has nothing to do with committing code. Ok, something like that would matter.
> 
> In this case it's different. There's a separation between what that person did and the committed code. *Were they squatting, or was he trying to kick out people who tried to pay their rent? If they were squatters, Macy still took the wrong approach.*


You pointed out the difference but failed to make it immediately afterward. 

I see his private life in regard to how he conducted himself as a Committer as irrelevant. It's how he conducts himself in an ethical manner as a Committer. He seems to have had some problems in that area of Trust and tighter oversight may be called for.

Look at all the crazy things I've talked about doing in my private life. Didn't I still write a Tutorial to help people, keep it updated and try to help when I can? And, for the most part, haven't I conducted myself in a Ethical manner?

I don't agree with the way he conducted himself in his private life. If he would have been my Landlord and tried that business he would have got his butt kicked by a 64 year old man. I'd have gone to jail and what would happen to my good reputation here? 

What should happen?


----------



## Snurg (Mar 28, 2021)

Zirias said:


> Still I don't agree with the tone of the article. It's written in a way that just presumes there are severe structural problems (which would imply something about the general quality of FreeBSD)


There are, I know from personal experience, but will not detail for good reasons.



Phishfry said:


> See this:
> 2018 Q2
> 
> 
> ...





			
				FreeBSD Status Report 2018 Q2 said:
			
		

> Matt Macy's (mmacy@) commit bit *was restored under the mentorship of Sean Bruno (sbruno@)*.


I have read some things that Sean Bruno wrote in the course of time, found it "interesting" (however, forgot in which way I found it "interesting"), and I guess I will look again to get an idea what his role may be.



Trihexagonal said:


> I don't agree with the way he conducted himself in his private life. If he would have been my Landlord and tried that business he would have got his butt kicked by a 64 year old man. I'd have gone to jail and what would happen to my good reputation here?


My respect for you would increase even more.
That criminal imho should never even have been allowed a commit bit.
Not to speak of getting his commit bit restored under sort of "mentorship", after he managed to get his commit bit revoked.



Trihexagonal said:


> What should happen?


Imho Just what happens when a near-catastrophical nuclear incident happened:
Not only examining the present nuclear infrastructure, identifying and remedying the weak points, but also examining the safety culture and working procedures.


----------



## Deleted member 30996 (Mar 28, 2021)

sidetone said:


> He faced consequences for what he did in life. At a certain point, what someone does in their life applies to what they do in software. In many cases, like this one, his personal life, and commit bits are two different things.
> *
> *
> We have to hear both sides of this story, and this ends up becoming a discussion not even related to software or anything computer related. I don't feel like doing that, yet, I may not resist and respond.


Nothing personal, sidetone, but I see that logic as flawed.


----------



## Deleted member 30996 (Mar 28, 2021)

Snurg said:


> Not to speak of getting his commit bit restored under sort of "mentorship", after he managed to get his commit bit revoked.


I suspect that's where Netgate influence played a part.


----------



## PMc (Mar 28, 2021)

vigole said:


> By the way, what happened to "*Ban the Box*"?
> How does his arrest record have anything to do with anything? We've been told repeatedly, by similar media outlets that "_Box_" is bad, and #banthebox
> Who am I kidding!



Look at it from a different angle: people are worried because some code with security issues might have made it into a dotzero-Release.
They are not worried about code quality in general, they are just worried about their security, their own ass.
But they realize there is nothing they can do, there is nobody they could fire, there is no contract they could cancel. So they start looking for somebody to blame, for whatever crazy non-reason - because they have no better clue. They behave like Dilbert's manager.

That's bad enough and it wont' help. I don't know how California law treats tenants, but in some contries there is a serious problem, being practically impossible to get rid of them even when they rot the building. So there may be two sides to that story, and the conclusion might just be that there is a guy who takes action to get something done, which not necessarily is a bad trait - and it is entirely unrelated to coding quality anyway.

So, concerning the coding quality. A company would be oblidged to do something useful with their money in order to satisfy their customers, and this is (more or less) a self-regulating circuit. But FreeBSD is no company, and we cannot just move some money from development to testing. Things are done on best-effort, and so your security is built on a promise which is normally kept, but there aren't any guarantees. You have to live with that. (In  commercial software there would be guarantees, but when it comes bad and your stuff is stolen, they are mostly useless.)

What worries me more is that there is a company, and that company puts money on the table to get some code done. Now their business equates their business, and so I wouldn't care about it at all, as I don't need to buy their products.
But it is FreeBSD where that code ends up. And one one side such is an important benefit to FreeBSD, but on the other side FreeBSD might become an instrument of foreign stakeholders with whatever agenda. And that is what I would worry about - much more than criminal records of anyone.


----------



## Crivens (Mar 28, 2021)

Personal conduct has little to do with skill and ability. See Ersoy (? Not 100% sure) for more on that. That guy could be a millionaire from his prize money in mathematics, but is more or less homeless and roams the globe. And he is reported to be socially challenged like RMS. But one heck of a math wizz.

So if someone deserves a commit bit should not be tied to anything but his skill - or we must sooner or later lay down where the line is between conduct and f.e. skin color or religion. Only factor should be skill, nothing else.


----------



## sidetone (Mar 28, 2021)

Trihexagonal said:


> Nothing personal, sidetone, but I see that logic as flawed.


You're either misunderstanding, or you're not explaining yourself. I agreed with you on part about how, what Macy did as for that's software is DIFFERENT than what he did as a landlord. It's when things become extreme, as if he was a serial killer, or a total slimeball who stabs and robs people, where we wouldn't want him as a committer or want nothing to do with his software contributions regardless of his ability or even if he had perfect discipline on submitting code. When what someone does in their life, when it matters to something as software commits, only matters when either because we want nothing to do with him, or because his ethics in his real life will influence what he does as a software contributor.

The author of the Ars Technica article conflated unrelated facts, and didn't provide the whole story, just slammed Macy for associations.

Macy also got a criminal record for what he did, and he probably lost his property, when he fled for Italy. That's his real life punishment. His reputation as a committer is a different topic, that has nothing or little to do, with what kind of landlord he was.

Squatter's rights in some places are ridiculous. Like I said, someone off of the street can break into a home, occupy it, and have rights to live there. The property owner doesn't have rights to kick out the burglarizers or trespassers. It can be to the extreme, where, when the property owner finally gets them out, they smear shit on the walls. This is how ridiculous squatters rights are. It can be even, someone filing a false police claim on someone they live with. Then, when the person comes back from jail, the property owner has THEIR personal possessions damaged disrespected, thrown out, and CAN'T ENTER THEIR OWN HOME. It takes time to kick the squatter out, and damage is done. NOW, I KNOW that these were leased tenants who didn't do this, but it shows the crazy amount of leeway some tenants have to be unwanted. What was the reason the landlord wanted them out? Was it because they were horrible tenants, or didn't pay their rent for a year? Or was it because he wanted to build a parking lot.


----------



## PMc (Mar 28, 2021)

sidetone said:


> The FreeBSD Foundation is a non-profit corporation/company. It has a lot of ability for what it has, but it doesn't have the funding like a major for-profit.


The FreeBSD Foundation was created in order to have a legal entity that can sign contracts. It was not intended to act as the general manager (aks supernanny) of the project. 

But, like all adminstrative entities, it tends to be imagined as the "one in charge". This is the reason why administrative entities in general tend to always grow (usually without doing much good on the matter itself, because they weren't designed for that).


----------



## Snurg (Mar 28, 2021)

Crivens said:


> So if someone deserves a commit bit should not be tied to anything but his skill - or we must sooner or later lay down where the line is between conduct and f.e. skin color or religion. Only factor should be skill, nothing else.



So I'd be curious what was the exact cause that led to Matt Macy's commit bit being revoked the first time, and for which reason it got reinstated later?
While Matt Dillon's was not, even though everybody knows his skills are probably far superior compared to the big majority of developers?


----------



## tingo (Mar 28, 2021)

IIRC, the most common cause is "commit bit taken in for safekeeping" - in other words, the committer has been absent from FreeBSD project work for a long time, or that the committer self asks for the commit bit to be taken in, because of ENOTIME to work on FreeBSD.


----------



## Deleted member 30996 (Mar 28, 2021)

sidetone said:


> You're either misunderstanding, or you're not explaining yourself.


You seem to be contradicting yourself in those two statements and the one I pointed out before.

Though that may well be my brain full of toxins misunderstanding you. I can hardly make my own thoughts coherent in writing at times. And though my writing ability has come back since posting it's a short term stay.


----------



## troublemaker (Mar 28, 2021)

> Several FreeBSD community members would only speak off the record. In essence, most seem to agree, 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.



I am sorry, I don't have insights into the FreeBSD development process, but I was wondering if this is true. If it is, can someone explain what Phabricator is?


----------



## Mjölnir (Mar 28, 2021)

Crivens said:


> So if someone deserves a commit bit should not be tied to anything but his skill - or we must sooner or later lay down where the line is between conduct and f.e. skin color or religion. Only factor should be skill, nothing else.


No.  Writing tests/constraints that unconditionally `return true` are not among the skills that I would consider the most wanted for a kernel developer.  Together with that criminal record (self-justice driven by mere greed) and what he wrote afterwards, e.g. calling others _"envious no-doers",_ while seeing himself as a mover & shaker, shows a certain mindset that is a very dangerous character trait to any engineering task.  It takes some good amount of serious guru meditation to overcome such serious personal disablilities.  IOW these so-called _soft skills_ are equally important as the hard skills that define a gifted SW-engineer/programmer.  Shame on those who granted the _commit bit_ to him & maybe others of that same yukky mindset.


----------



## Crivens (Mar 28, 2021)

Mjölnir said:


> No.  Tests/Constraints that unconditionally `return true` are not among the skills that I would consider the most wanted for a kernel developer.


And right you are. On that alone that bit should be revoked.

I don't care if he identifies as a tea kettle, that has nothing to do with his coding abilities.


----------



## drhowarddrfine (Mar 28, 2021)

Reiser was good at what he did, too.


----------



## zirias@ (Mar 28, 2021)

I do remember tales of a certain _ReisswolfFs_.

"Reißwolf" is a pictorial german word for a shredder, consisting of "reißen" (tear) and "Wolf" (wulf)…


----------



## drhowarddrfine (Mar 28, 2021)

Zirias ReiserFS


----------



## zirias@ (Mar 28, 2021)

Read the small print and guess the reason for that naming


----------



## jardows (Mar 29, 2021)

I wonder how much hand wringing the author and commenters over there did regarding the development system for Linux that allowed code that broke hardware into an actually released version of the kernel and major distribution? With customer's computers physically broken and requiring system board replacements for a fix, it certainly should have risen to a greater scandal for the Linux community than a bad code getting into a pre-release version of FreeBSD then subsequently removed. Strange that I can't find any articles from Ars regarding that (may just be my bad searching skills).

My TLDR version of the incident:
Bad code got pushed into late pre-release.
Code review caught the bad code before it made it into release.
Review is happening to make sure bad code doesn't so easily make it that close to a release version.

But, the FreeBSD world is on fire, the OS is crumbling, and will soon be relegated to the dustbin of history, according to the article and commenters there.


----------



## zirias@ (Mar 29, 2021)

jardows said:


> I wonder how much hand wringing the author and commenters over there did regarding the development system for Linux that allowed code that broke hardware into an actually released version of the kernel and major distribution?


Although it's a horrible story, it's just whataboutism in this context. I don't care how bad Linux is, I care how great FreeBSD (normally) is.


jardows said:


> Bad code got pushed into late pre-release.


Well, it got pushed into the development branch, but made its way unopposed up to 2nd release candidate.


jardows said:


> Code review caught the bad code before it made it into release.


No, raised eyebrows from "outside" did that.


jardows said:


> Review is happening to make sure bad code doesn't so easily make it that close to a release version.


That's the normal/expected course of things. Seems it didn't work too well here.


jardows said:


> But, the FreeBSD world is on fire, the OS is crumbling, and will soon be relegated to the dustbin of history, according to the article and commenters there.


The article implying _pars pro toto_ in a matter-of-facts style is yet another thing.


----------



## richardtoohey2 (Mar 29, 2021)

Zirias said:


> No, raised eyebrows from "outside" did that.


Yes, for me, this is the key part of it.  It didn't (so far as I can see) get stopped by any FreeBSD developers, and that is an issue.

But I don't think there's any point ranting and raving or pointing fingers or getting personal about it.  It does seem like a bit of a failure and it _could_ have affected FreeBSD badly.  _Luckily_ it didn't. But something a bit stronger than luck is desired, and it seems that message is taken on board: https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057127.html

It's a volunteer project (mostly) - how are *you* helping improve things? The more people trying the BETAs and RCs and the more people actually reviewing code - the better. But I suspect most of us here (including I freely admit, myself!) will mutter something about skills and time and slink away leaving the hard work of reviews to the same tired core of people.


----------



## Snurg (Mar 29, 2021)

There are definitely problems.
I now worry, how far is it allowed/acceptable to constructively discuss what one thinks or worries about, _*only* quoting source links from freebsd.org_ after doing hours of research in official pages, mailing lists archives, and phabricator?


----------



## Phishfry (Mar 29, 2021)

troublemaker said:


> can someone explain what Phabricator is?


From the Wiki: Phabricator is a FreeBSD-hosted service that provides pre-commit code review workflows.

A website where a developer proposes a change or addition to FreeBSD with code changes on display.
There are commiters who are summoned by 'Herald' the phab bot for code review and some commiters will set themselves as a reviewer.
So the code review should provide fixes for code style and function.
The code author has to fix code to pass go at each stoppage..
Then when enough reviewers approve it the code gets commited to HEAD.

So phab is a code fixup and review process.
Our code collabration tool.


----------



## drhowarddrfine (Mar 29, 2021)

On Saturday, I saw one comment about this on one of the mailing lists by someone who brought it up questioning why no one was talking about it. I didn't see any comments by anyone *anywhere *else that mattered. Probably no one on technical locations is talking about it cause no animals were harmed, no people were killed, it didn't affect 99% of anyone and the issue is being addressed by and for those who actually work on such things.

You don't do anything today that you didn't do last week. You won't do anything next month that you aren't doing now (except possibly experiment with WireGuard). All in all, when wg gets implemented, you'll be very happy and no one will be crying over spilled milk.


----------



## mark_j (Mar 29, 2021)

drhowarddrfine said:


> My point has been, and always will be, that the most important thing that happened is ... nothing.



You're kidding right? Sure, you're right, nothing happened but it wasn't through review or testing, but rather luck that the author of wireguard looked at the code and made it public. It's a bit like looking down the barrel of a gun and squeezing the trigger just hoping someone else has removed the bullet.

I call that BAD systemic practices and horrible non existent quality control.

I think this, as the article implies, leads to the larger question of "what else has FreeBSD missed?"

Obviously, FreeBSD has limited resources, but something this big, this complex, and ANYTHING involving crypto, should spend a long, long time in code review, testing and QA. Period.


----------



## sidetone (Mar 29, 2021)

The odds aren't astronomical that the author of his own program, knowing it was being ported to important OS'es, would look at it.

Perhaps, the amount of eyes watching it, were also a high amount, as there were a lot of fans of those who wanted to see WireGuard in FreeBSD and PF Sense. There was a lot of encouragement to get it in by fans for some time, and putting it in at the last minute will always be prone to problems.


----------



## mark_j (Mar 29, 2021)

jardows said:


> I wonder how much hand wringing the author and commenters over there did regarding the development system for Linux that allowed code that broke hardware into an actually released version of the kernel and major distribution? With customer's computers physically broken and requiring system board replacements for a fix, it certainly should have risen to a greater scandal for the Linux community than a bad code getting into a pre-release version of FreeBSD then subsequently removed. Strange that I can't find any articles from Ars regarding that (may just be my bad searching skills).
> 
> My TLDR version of the incident:
> Bad code got pushed into late pre-release.
> Code review caught the bad code before it made it into release.



Code review was not by core but by the developer of wireguard. If he hadn't made it public, and FreeBSD 13 was out today, it would have that wireguard code in it.
They (core) escaped this by luck rather than good systems being in place.


----------



## drhowarddrfine (Mar 29, 2021)

mark_j said:


> You're kidding right? Sure, you're right...


You are agreeing that I am right and that is true--nothing happened. Thank you. How it got to that point is an issue that needs addressing as I have stated more than once. Going on and on about something that did not happen is pointless and time consuming for us and this thread that is only a concern for forums and Ars but nowhere else that matters.



mark_j said:


> I think this, as the article implies, leads to the larger question of "what else has FreeBSD missed?"


This is a horrible question to ask and I've seen it asked on the amateur forums and Ars, too. Every project everywhere has something that was missed and had close calls where one can ask that same question. Again, it's pointless to ask and only worrisome to those who only want to make themselves feel superior.


----------



## drhowarddrfine (Mar 29, 2021)

mark_j said:


> If he hadn't made it public, and FreeBSD 13 was out today


And, again, none of that happened.


----------



## mark_j (Mar 29, 2021)

Mjölnir said:


> No.  Writing tests/constraints that unconditionally `return true` are not among the skills that I would consider the most wanted for a kernel



I know, seriously? This is just horrible in every way. I note some people raised concerns about all the #ifdefs in there, yet none said, "hey, pull this code until it can be reviewed/cleaned up."
I guess this is where someone like Linus would do exactly that.

 I don't know the politics of this but can another core member "revoke" code for review? If they can't, they should.

I must add, I don't see this as a catastrophe UNLESS they (core) do not learn from this.


----------



## mark_j (Mar 29, 2021)

drhowarddrfine said:


> You are agreeing that I am right and that is true--nothing happened. Thank you. How it got to that point is an issue that needs addressing as I have stated more than once. Going on and on about something that did not happen is pointless and time consuming for us and this thread that is only a concern for forums and Ars but nowhere else that matters.



But by luck rather than good management. If you think luck is a way to control a software project, then, well good luck running it, you'll need it.



drhowarddrfine said:


> This is a horrible question to ask and I've seen it asked on the amateur forums and Ars, too. Every project everywhere has something that was missed and had close calls where one can ask that same question. Again, it's pointless to ask and only worrisome to those who only want to make themselves feel superior.



Well at the risk of seeming superior this is pure nonsense. Luck has no place in a software system. Why test at all, if luck will determine your outcome. Let's just wait and see? Maybe someone will find my bugs, maybe they won't or maybe my code is bug free? Hey, I'm feeling lucky today, let's place 40,000 lines of unaudited code in the kernel and cross our fingers. We have a saying here: "She'll be right, mate!".

You seem unwilling to believe the HUGE difference between missing poor code through mistakes and poor code through negligence. This is the latter. If you can't see the difference, then I cannot explain it any more clearer it seems.


----------



## Mjölnir (Mar 29, 2021)

Please compare the following two occurrences:

When I filed in a (truly minor) bug report recently (PR 253861), I was kindly asked to write a test to asure it could not happen again (because the genuine author is too busy commiting more flaws like that?).  So, to proceed with an already existing minor bug, the reporter is requested to provide tests... versus:
FMLU that guy from the _WireGuard_ project (Jason A. Donenfeld) wrote a bunch of tests for the FreeBSD in-kernel implementation, when several dozens kLoC have already been commited...  So, to commit dozens of kLoC that conforms to numerous commonly accepted _worst-practices_ of C programming, all you need is mentorship from Sean Bruno.  Just let the others write the tests.
Farewell & _bon voyage_, almighty _free BeaSD_, and rest in peace.


----------



## drhowarddrfine (Mar 29, 2021)

mark_j said:


> But by luck rather than good management. If you think luck is a way to control a software project, then, well good luck running it, you'll need it.


Which has nothing to do with what I said. The system works. It works well. In this case, a hole was found--a bug in the system. The bug will be fixed but the software was never released. In the meantime, nothing happened.

You are now stating FreeBSD's code, due to this one issue, is managed by luck which is a preposterous statement.


----------



## troublemaker (Mar 29, 2021)

Phishfry said:


> From the Wiki: Phabricator is a FreeBSD-hosted service that provides pre-commit code review workflows.
> 
> A website where a developer proposes a change or addition to FreeBSD with code changes on display.
> There are commiters who are summoned by 'Herald' the phab bot for code review and some commiters will set themselves as a reviewer.
> ...


Ah thanks for that.
So putting the committer as reviewer doesn't look very helpful, but from what you write I understand there are more reviewers.
And that is the normal process? So basically I can assume that the code that goes to HEAD is reviewed (not by the committer), and therefore the problem in this case is a failed review?


----------



## eternal_noob (Mar 29, 2021)

troublemaker said:


> I can assume that the code that goes to HEAD is reviewed, and therefore the problem in this case is a failed review?


According to the article, "the landlord from hell" closed reviews without addressing the problems and completely ignoring them.



> Slightly tangential note, but my questions to mmacy@ about original
> wireguard commit (and ZoL, FWIW) or Phabricator comments had not been
> answered; *I also recall reviews being closed in "not accepted" state
> by him.*  While I appreciate the heavy-lifting, developers should be
> ready to explain and sometimes defend their work on public forums.







__





						git: 74ae3f3e33b8 - main - if_wg: import latest fixup work from the wireguard-freebsd project
					





					lists.freebsd.org


----------



## troublemaker (Mar 29, 2021)

eternal_noob said:


> According to the article, "the landlord from hell" closed reviews without addressing the problems and completely ignoring them.
> 
> 
> 
> ...


Uhmmmm.... okay, so if i get it correct:

every commit is reviewd by someone other than the committer
the committer decides when the code is done, and when it's fine to put it into HEAD
Does that mean that the reviewer(s) can still point out that there is dangerous code committed in the release?
Okay, maybe not ideal, but it would still be fine.


----------



## eternal_noob (Mar 29, 2021)

The fact that a committer can close any review as "not accepted" is the main problem here. I mean, code reviews are there for a reason.


----------



## troublemaker (Mar 29, 2021)

eternal_noob said:


> The fact that a committer can close any review as "not accepted" is the main problem here. I mean, code reviews are there for a reason.


True that, but if the reviewers are aware that the review has been closed they can still do something.
Which is, I believe, what happened.
I mean, personally I would not allow code to be committed without reviewers approval. But the current way (again, if I get it correctly) would still do the job.
What surprised me is that Ars Technica speaks of unreviewed code, basically saying that it's kind of normal. But that doesn't look true. So basically I am looking at the generic situation now, not only at this specific case.

EDIT: Sorry, something else: 40000 lines of code is a hell of a review.


----------



## Mjölnir (Mar 29, 2021)

troublemaker said:


> EDIT: Sorry, something else: 40000 lines of code is a hell of a review.


Don't worry, FMLU much of that is was
	
	



```
#ifdef LINUX
... dead code ...
#endif /* LINUX */
```


----------



## Snurg (Mar 29, 2021)

I'd like to quote danfe in the phabricator review:


			
				danfe said:
			
		

> On a larger scale, is adding another pile of crypto bits necessary?  Would it be feasible to use existing crypto framework instead?  I've heard Linux folks eventually forced the author to rewrite this _zinc_ thing of his as a simple wrapper over kernel crypto API.  What's the situation in our case?


Just scroll through the code and see yourself what an insane amount of redundant garbage code could have been thrown out in case the system crypto could have been used...
I _didn't find any reaction to danfe's comment_, and this puts me in a pensive mood.



tingo said:


> IIRC, the most common cause is "commit bit taken in for safekeeping" - in other words, the committer has been absent from FreeBSD project work for a long time, or that the committer self asks for the commit bit to be taken in, because of ENOTIME to work on FreeBSD.


I am not aware of exact times when he had commit bit and when not.
He had it unrevoked apparently most or all the years he spent in prison.

After he left prison, he constantly changed his contact emails. That is highly unusual and warrants the question why.
Maybe his admission that he had not yet cleaned up the consequences of his crime more than a dozen years ago, when being interviewed by ArsTechnica, explains a lot. Especially when one looks at his slow identity change from "Kip Macy" to "Matthew Macy".

Further, I found very interesting info from April 2016, possibly connected with the FreeBSD 12 /boot/kernel and /boot/modules video driver disaster, where he seems to have been involved (no idea to which degree, though).

His last public activity as kmacy was on Nov 18, 2016 (note sbruno's next comment indicating that project seemed finished).
In the quarterly report 07/2017 is indicated that there was work going on with Macy.
The next mention at Jul 25 2017 on site:freebsd.org was then by the apparent client, _already mentioning him as mmacy_, but including the old account kmacy in the rewievers list.
Then, February 2018, his commit bit was reinstated, this time on his new account mmacy.

He was also, together with Sean Bruno, responsible for the botched Intel ethernet driver merge, which led to many driver functions becoming inaccessible (even though they are still being listed in the respective manual pages).

But the most delicious thing above all is probably his _special kind of involvement_, which also might partly explain why there are so few messages from him in public, which I personally find somewhat unusual for a "typical" developer.

His "working relationship" to the Core Team possibly might be characterized best by his own words in the phabricator:


			
				Matt Macy said:
			
		

> *I've been asked* to ...



What puts up the question what motivated him to join in 2005?
What made him such a valuable asset for the Core team, after power relations had settled after the FreeBSD God Wizard Matt Dillon was sent into the desert?
Was he a volunteer?
Or was he a hired helper _with special permissions to bypass the normal due development course_, either for vendors/sponsors or other things that nobody of the core team wanted to do themselves?

I wish there were more transparency, so there would be no need to lift up the rugs to look what's under them.


----------



## troublemaker (Mar 29, 2021)

Mjölnir said:


> Don't worry, FMLU much of that is
> 
> 
> 
> ...


In the FreeBSD code?
Interesting.

Well, I am aware that there are better ways, but I am not going to tell the FreeBSD guys how they have to manage their code.
I am good if that code reaches the HEAD, as long as it's taken out right after that.


----------



## obsigna (Mar 29, 2021)

sidetone said:


> . . ., as there were a lot of fans of those who wanted to see WireGuard in FreeBSD and PF Sense. There was a lot of encouragement to get it in by fans for some time, and putting it in at the last minute will always be prone to problems. . . .


This boils it down, what actually happened. Like a bus full of soccer fans and the bus driver prevented an accident in the last minute by kicking in the balls of the fanatics who had their grip already on the steering wheel.


----------



## Jose (Mar 29, 2021)

mark_j said:


> You're kidding right? Sure, you're right, nothing happened but it wasn't through review or testing, but rather luck that the author of wireguard looked at the code and made it public.


No luck involved. Another Freebsd committer reached out to Donenfeld (lead author of Wireguard) with concerns about the implementation. 
The two of them plus an Openbsd developer that worked on the Openbsd WG implementation then worked together to come up with an alternate implementation.


----------



## Jose (Mar 29, 2021)

eternal_noob said:


> A criminal (served 4 years and 4 month)
> A coward (fled to Italy to avoid prosecution)
> A misanthropist (attempting to illegally evict tenants from a building he had bought)
> A psychopath (forged extremely threatening emails appearing to be from the tenants themselves)
> ...


So there's no possibility for rehabilitation, ever? Why don't we just throw everyone in prison forever for every crime?

Yes, what he did is despicable, especially the part where he ruined his parents. People don't often change, but I believe that hard time at San Quentin is the kind of wake-up call that could make someone change.

Also, Macy was heavily involved in moving the ZFS implementation to Openzfs. Are you going to stop using ZFS on Freebsd 13?


----------



## PMc (Mar 29, 2021)

Mjölnir said:


> Please compare the following two occurrences:
> 
> When I filed in a (truly minor) bug report recently (PR 253861), I was kindly asked to write a test to asure it could not happen again (because the genuine author is too busy commiting more flaws like that?).  So, to proceed with an already existing minor bug, the reporter is requested to provide tests... versus:
> FMLU that guy from the _WireGuard_ project (Jason A. Donenfeld) wrote a bunch of tests for the FreeBSD in-kernel implementation, when several dozens kLoC have already been commited...  So, to commit dozens of kLoC that conforms to numerous commonly accepted _worst-practices_ of C programming, all you need is mentorship from Sean Bruno.  Just let the others write the tests.


Now we get nearer to the issue.
There is a German saying: "die kleinen fängt man, die großen läßt man laufen". (look it up in a translator)

I very much believe that your PR was thoroughly written and well considered. Now the common sense of all this discussion seems to be that we need more thorough QA procedures. The discomfort with these is that they create additional (and often mostly formal) work before something is accomplished (and that work then gets pushed around, as in Your case). But if something is big enough and the right people are involved, it still can bypass the checks&balances.

One main difference between free software and commercial software used to be that free software is more agile (that was true long before "agile" became a buzzword): it once took me 23 hours to get a fix into the HEAD of sendmail, it took more than a year to get a fix into a big commercial unix.
The reason for that, as I think, was that in the free software those people were in charge who were concerned with the software - often those who had written it in the first place, while in business people in charge were concerned mainly with the business. (And this is a difference that you cannot overcome with "agile" methodology - which is why "agile" is mostly BS.)

But now a generation has passed, and the projects have become way too big for anybody to overlook it all, and also the old guys, who would be able to still overlook a good part of it, have retired.
That seems to me the actual issue; and as it seems, formal checks+balances, while not a really good solution, is the best that mankind has come up with for such kind of problems. And I honestly do not really know how to solve this.


----------



## kpedersen (Mar 29, 2021)

eternal_noob said:


> A criminal (served 4 years and 4 month)
> A coward (fled to Italy to avoid prosecution)
> A misanthropist (attempting to illegally evict tenants from a building he had bought)
> A psychopath (forged extremely threatening emails appearing to be from the tenants themselves)
> ...



It may be a hard pill to swallow but even if a mass murderer wrote a good bit of software, it shouldn't really be rejected because of the person. Respect their skills, not their *ahem* life choices.

Sure, if the source code is a poor quality or makes a dialog appear telling you to be very nasty to your tenants, then that is a different matter...

But I guess I am a little bit cold when it comes to this stuff. I probably blame the fact that the UK is built entirely upon murder and torture that I have given up XD


----------



## Jose (Mar 29, 2021)

PMc said:


> One main difference between free software and commercial software used to be that free software is more agile (that was true long before "agile" became a buzzword): it once took me 23 hours to get a fix into the HEAD of sendmail, it took more than a year to get a fix into a big commercial unix.


One of my most bitter professional memories is of when I discovered that I had introduced a regression into a release candidate. I further realized that this regression was only going to affect our largest and most important customers.

I approached management about making a simple change of a few lines to avert this problem. I was rebuffed because the process had to be followed. It was too late in the release cycle to make any changes. A few weeks later a super-hot customer escalation landed in my lap. Fortunately I had a code fix ready.

It seems at some point in most large companies the process becomes more important than the result. The means become more important than the ends after a certain kind of manager starts to get hired. Managers who care more about covering their ass than getting things done.

It's one of the reasons why I've tried to stick to smaller companies throughout my career. They have other pathologies, but I don't find them as obnoxious.


PMc said:


> The reason for that, as I think, was that in the free software those people were in charge who were concerned with the software - often those who had written it in the first place, while in business people in charge were concerned mainly with the business. (And this is a difference that you cannot overcome with "agile" methodology - which is why "agile" is mostly BS.)


Don't get me started on the "agile" nonsense. There's so much ridiculousness there. I'm only going to quote a former colleague that liked to say "you don't run a marathon by breaking it up into a series of sprints".


----------



## a6h (Mar 29, 2021)

Update:
Ars' moved the article from feature section to the bottom of their blog page. Probably, they've received enough clicks from the clickbait. Ready for the next target.
Also, the writer -- I forgot his name, he's a blog writer for Ars -- RT some FreeBSD-related tweets on his twitter. Some sort of fair and balance signalling, I assume?!


----------



## mark_j (Mar 29, 2021)

drhowarddrfine said:


> Which has nothing to do with what I said. The system works. It works well. In this case, a hole was found--a bug in the system. The bug will be fixed but the


At the risk of a circular argument: It has everything to do with what you stated. There is no *system* unless your *system* is luck.

This is not some bug in a switch on ls(1), this is software designed to provide a secure connection from one server to another. It suffers from buffer overflows, for goodness sake, and by virtue of good luck it was found before it was placed into production. It should never have been anywhere near a release candidate. The software's not even alpha quality.





drhowarddrfine said:


> software was never released. In the meantime, nothing happened.
> 
> You are now stating FreeBSD's code, due to this one issue, is managed by luck which is a preposterous statement.



No, I am not saying that. Read what I said.


----------



## Deleted member 30996 (Mar 29, 2021)

vigole said:


> Some sort of fair and balance signalling, I assume?!


Closing the barn door after the chickens got out.


----------



## Jose (Mar 29, 2021)

mark_j said:


> At the risk of a circular argument: It has everything to do with what you stated. There is no *system* unless your *system* is luck.


At the risk of repeating myself, *no luck was involved*. Another Freebsd committer had misgivings about such a large commit with so little review and he sought and found help auditing it in the broader FOSS community.

Now the hard work of that committer and his two colleagues is being exploited by Ars Technica to sell ads on the Web. It's disgusting.

Edit: Exploitation with a nice side of scapegoating. Let's all enjoy a good, juicy two minutes hate on Macy.


----------



## Deleted member 30996 (Mar 29, 2021)

Wait a minute... I thought we were the Goat.


----------



## zirias@ (Mar 29, 2021)

Jose said:


> At the risk of repeating myself, *no luck was involved*. Another Freebsd committer had misgivings about such a large commit with so little review and he sought and found help auditing it in the broader FOSS community.


Even *if* the initiative came that way (I can't verify) – you wouldn't sell that as the correct and safe procedure for such things? It was in -RC2, which is the final _mandatory_ RC, so removing it thereafter was indeed the _very_ latest possible moment. Luck is a factor, at least with this timing.


Jose said:


> Let's all enjoy a good, juicy two minutes hate on Macy.


Whatever this article does… the takeaway for FreeBSD isn't fingerpointing towards Macy. He obviously "failed" _here_, but no single failure should lead to a near-desaster in a release. So, just forget that article, it's bad style in many ways, but don't forget the incident, so it won't repeat.


----------



## mark_j (Mar 29, 2021)

Jose said:


> No luck involved. Another Freebsd committer reached out to Donenfeld (lead author of Wireguard) with concerns about the implementation.
> The two of them plus an Openbsd developer that worked on the Openbsd WG implementation then worked together to come up with an alternate implementation.


Nope not as I understand it.
See Kyle Evans post: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+archive/2021/freebsd-arch/20210321.freebsd-arch

To quote Donenfield to Kyle Evans after he pulled the entire code out of the tree: "I think what you describe is a great plan. I think everybody realizes
at this point that the original code base from the original author never should have been merged."

So the process is flawed, it was lucky that Evans found these bugs. The fact Evans thinks now it is best outside the main, is evidence that this code should never have got to where it did, a release candidate. Quality control of security-scale software needs more than what FreeBSD just showed for Wireguard.


----------



## Mjölnir (Mar 29, 2021)

FWIW I guess we'll have this covered in it's own Office Hours.  From yesterday's <freebsd-hackers>:
	
	



```
[...] This incident highlights the need to do this work more
proactively, and to maintain a robust, multi-layered development process
that can catch problems as they fall through the cracks.

Over the next month the FreeBSD Core Team will lead a discussion on
appropriate pre-commit testing, static analysis, code review, and
integration policies to avoid a repeat of this situation and to continue
improving FreeBSD's code quality. We know there will be challenges in
key areas, such as third-party device drivers, and components of the
system where fewer developers have sufficient expertise. The FreeBSD
Foundation has full-time staff members participating in significant code
review today, and is committed to supporting the needs identified by the
Core team and the developer community for this effort.

We look forward to input from the community on our proposals for updated
policies as we move forward, maintaining high code quality as a core
value for FreeBSD.
```
I'm not sure if I should seriously suggest to add an interview done by a team of professional, highly skilled psychologists to check the so-called soft skills, before granting a commit bit to a developer.


----------



## a6h (Mar 29, 2021)

Mjölnir said:


> I'm not sure if I should seriously suggest to add an interview done by a team of professional, highly skilled psychologists to check the so-called soft skills, before granting a commit bit to a developer.


That would be great! But I'm more in favour of a _department of inquisition_.

I won't draw a conclusion, but I wonder which departments made ASA to issue this statement:

ASA: The ASA Statement on p-Values: Context, Process, and Purpose
APA: P-values under question
more:
Nature: Scientists rise up against statistical significance
Nature: 1,500 scientists lift the lid on reproducibility


----------



## Snurg (Mar 30, 2021)

mark_j said:


> Quality control of security-scale software needs more than what FreeBSD just showed for Wireguard.


What kind of *security clearance* would a guy get who is in debt over both his ears, has proven that he has zero loyalty, zero sense of responsibility, would even (literally) sell his mother, is willing to do heinous crimes to satisfy his greed?

How responsible is it to push such code into a release candidate, not caring a s**t about the consequences he causes for his clients Netgate and FreeBSD, just for getting his payment early, due to his apparently pressing financial situation?

Wouldn't such a guy be the dream for organized crime or (foreign) services?
Smuggling in an innocuous bug with hidden backdoor for a relatively small bakshish, shouldn't be this an easy thing for a money-starved greed-motivated person without any sense of responsibility?

*Would such a guy get clearance for a job in a security-aware organization for their most-security-relevant software?*


----------



## Mjölnir (Mar 30, 2021)

vigole said:


> That would be great! But I'm more in favour of a _department of inquisition_.


Blaming s/o who's code is cluttered with `#ifdef`'s and constraints unconditionally `return true` has _nothing_ to do with inquisition.  As noted above a few times, critical questions on _Phabricator_ were simply ignored, as well as the offer to help by e-mail.  IIRC the average LoC a developer writes is 8/day (!!!).  40 kLoC were commited in just a few month, meeting every notion of _C's worst practices_.  All that together is just another proof of an obnoxious, yukky character.  Period.


vigole said:


> I won't draw a conclusion, but I wonder which departments made ASA to issue this statement:
> 
> ASA: The ASA Statement on p-Values: Context, Process, and Purpose
> APA: P-values under question
> ...


I welcome your critical mind, but I can't relate any of this to the issue.  Please elaborate.


----------



## richardtoohey2 (Mar 30, 2021)

Not the same thing at all, but malicious activity affecting PHP and their processes: https://www.theregister.com/2021/03/29/php_repository_infected/


----------



## Jose (Mar 30, 2021)

mark_j said:


> Nope not as I understand it.





> ...
> Fortunately, two weeks before FreeBSD 13.0 was due to be released,
> FreeBSD core developer Kyle Evans emailed the list about integrating
> wireguard-tools (wg(8) and such). In the ensuing discussion I mentioned
> ...





			[ANNOUNCE] WireGuard for FreeBSD in development for 13.y – and a note of how we got here


----------



## mark_j (Mar 30, 2021)

Mjölnir said:


> FWIW I guess we'll have this covered in it's own Office Hours.  From yesterday's <freebsd-hackers>:
> 
> 
> 
> ...


And with regard to this issue, this is exactly what we should see; the core developers reacting to an obvious failure of process.

This is not an individual developer's issue, this is about processes and procedures.
I know open source walks a fine line between keeping people interested ("we just want to code") and staving off software failures but better processes are obviously required.
I do sympathise with Kyle Evans; he's caught in the middle of a fiasco.


----------



## Jose (Mar 30, 2021)

Mjölnir said:


> I'm not sure if I should seriously suggest to add an interview done by a team of professional, highly skilled psychologists to check the so-called soft skills, before granting a commit bit to a developer.


Yeah, and then immediately disqualify anyone the "highly skilled" psychologists approve.


----------



## mark_j (Mar 30, 2021)

Jose said:


> [ANNOUNCE] WireGuard for FreeBSD in development for 13.y – and a note of how we got here


Sigh, you miss the point. It's in RC, not some branch somewhere being developed, it's in RC.
"In the ensuing discussion I mentioned that we really need to get the actual if_wg kernel implementation up to snuff". So, someone waited for someone else to trigger what could have eventually gone to release? Ok, if that's not luck then it is horrendous software control.


----------



## Jose (Mar 30, 2021)

mark_j said:


> I do sympathise with Kyle Evans; he's caught in the middle of a fiasco.


Yeah, me too. I understand why Donenfeld had to make a big deal out of this, but I can see how Evans got stuck in the middle of a bad situation. That is a bummer.


----------



## a6h (Mar 30, 2021)

Mjölnir said:


> I welcome your critical mind, but I can't relate any of this to the issue. Please elaborate.


My point is that psychologists are not in a position to make a decision who should be on a team or not. It's up to other team members, e.g. Core and Committers. Of course based on whatever criteria they're comfortable with. It's up to them. Team decides whether _Terry Davis_ belongs to the team or not. Especially in volunteer based open source projects. At least scientists and engineers gave us Maxwell's equation, and UNIX kernel. What are psychology achievements? -- beside calling people lunatics, and lock them up in booby houses.


----------



## Morris (Mar 30, 2021)

I have to say that I see some quite unhelpful ad hominem attacks on the messenger here.

Ars Technica’s Jim Salter is not just some writer that wants to score some points here. You could argue he is not even a writer. Principally he is an IT guy, a sysadmin and consultant working in the storage space. He just happens to have a good pen too, unfortunately rare in the IT sector.

That good pen has made him able to write very compelling articles about ZFS and OpenZFS in particular that will have made thousands consider FreeBSD as their operating system.

Will ZFS and non-ECC RAM kill your data?
ZFS tuning cheat sheet
A detailed look at Ubuntu’s new experimental ZFS installer
ZFS 101—Understanding ZFS storage and performance
OpenZFS 2.0 release unifies Linux, BSD and adds tons of new features
By making complex elements of ZFS understandable to a wider audience he has done more for FreeBSD than most of us on this forum and definitely more than I ever did (or will be able to). When I read this article I read it as written by someone who cares about FreeBSD because he has to work with it on a daily basis. His favourite open source NAS, XigmaNAS, is developed on top of FreeBSD.

I think he was just as surprised as I was to see that code that is demonstrably poor made it so far in the release process for FreeBSD 13 without any alarm bells. Many of the issues should have been filtered out in the review stage.

He could have done what many other journalists have done and just follow the narrative from one side and join in the mud slinging. Instead he chose to have the actual code checked to see if the claims were true. He spoke to many players, not only NetGate, or only Jason Donenfeld, or only Kyle Evans, or only Matt Macy. He tried to get a clear picture of what really happened.

Now, you can do two things. You can either become defensive and pretend the code wasn’t sloppy at all. Or claim that a committer shutting down parts of the review process himself is not a problem. Or deny that demonstrably bad code making it all the way into a second Release Candidate of an actual major RELEASE is a problem. Or deny that there are some unfortunate conflicts of interest between commercial parties, committers, reviewers and the community. Or deny that the FreeBSD community lacks the people, the finances or the time to do as much as it would like.

You can also try and turn this into an ‘OpenSSL moment’, a code quality disaster that became a turning point. One that will make the corporate giants that depend on FreeBSD realise that they have mostly been getting something for nothing and that it’s in their interest to make sure that the FreeBSD review process is in good health. Perhaps it requires more than just an occasional financial donation to the Foundation, perhaps donating staff time to have some of their developers do a couple of hours of ‘review service’ a month is more helpful.

I prefer to see it as the latter and hope FreeBSD comes out better from this. Hopefully a year from now we can look back and see that the project needed this crisis to come out stronger.


----------



## drhowarddrfine (Mar 30, 2021)

Morris None of that has anything to do with the issue except it was a discovery of a failure of process (and not bad code or anything else). FreeBSD has been doing quality, commendable work for over 25 years but some are wanting to pretend this one ugly bug in that process disqualify everything accomplished so far. To use this as a reason to disrespect all this work is shameful, though my complaint is more against the writers who think along those lines.


----------



## Deleted member 30996 (Mar 30, 2021)

Mjölnir said:


> team of professional, highly skilled psychologists to check the so-called soft skills, before granting a commit bit to a developer.





Jose said:


> Yeah, and then immediately disqualify anyone the "highly skilled" psychologists approve.


Let's strike a happy medium. I volunteer. 

My resume:

Psycho Psychologist
Is there any doubt of my qualifications?

Manipulative Bastard
Probably qualify as a Magnificent Bastard but I like to keep it on a personal level..

Morally Ambiguous Doctorate
Is that going to ba a problem? I can never tell.

Xanatos Speed Chess
Anything you say can and will be used against you.

I believe my work speaks for itself.


----------



## Mjölnir (Mar 30, 2021)

drhowarddrfine said:


> Morris None of that has anything to do with the issue except it was a discovery of a failure of process (and not bad code or anything else).


Actually, it seems to be _also_ about code quality.


drhowarddrfine said:


> FreeBSD has been doing quality, commendable work for over 25 years but some are wanting to pretend this one ugly bug in that process disqualify everything accomplished so far. To use this as a reason to disrespect all this work


IMHO that is your personal feeling. Where can I read that in the Ars Technica article?  You keep denying that this incident revealed a serious underlying problem.


----------



## zirias@ (Mar 30, 2021)

Mjölnir said:


> You keep denying that this incident revealed a serious underlying problem.


Yes, and that should not be denied, otherwise, there might be a next time, and there might be less luck involved.

But: the article assumes/suggests the problem is a structural one. We can't know that. It should be analyzed, of course.


----------



## eternal_noob (Mar 30, 2021)

Zirias said:


> the article assumes/suggests the problem is a structural one. We can't know that.


Of course it is a structural problem if a committer can close any review as "not accepted" on his own.


----------



## zirias@ (Mar 30, 2021)

eternal_noob said:


> Of course it is a structural problem if a committer can close any review as "not accepted" on his own.


I don't think so. You don't have to enforce every rule technically. It _should_ of course ring alarm bells when something like this happens. So, it didn't (immediately) in this case, but that doesn't necessarily mean the problem is structural. It _could_ be a hint, but the team has to analyze that…


----------



## Jose (Mar 30, 2021)

Morris said:


> I have to say that I see some quite unhelpful ad hominem attacks on the messenger here.


Oh, the irony!


Morris said:


> Now, you can do two things...


I reject your false choice. The first Ars article on the subject was good and informative. The second one is a pure exercise in muckraking and concern trolling. Salter delivers a clinic on the latter here:


> FreeBSD is an important project that deserves to be taken seriously. Its downstream consumers include industry giants such as Cisco, Juniper, NetApp, Netflix, Sony, Sophos, and more. The difference in licensing between FreeBSD and Linux gives FreeBSD a reach into many projects and spaces where the Linux kernel would be a difficult or impossible fit.


And the muckraking takes the form of splashing the seamy details of Macy's criminal past all over the Internet. And I'm supposed to worry about _ad hominem_ attacks against Salter? Please.

He and Ars saw a way to turn a quick back by publishing all the saucy details of this melodrama, and to score some points with the Linux fanboi crowd by muttering darkly about what this must say about the quality of the Freebsd project overall.

FOSS development is messy sometimes. All kinds of soap operas can be written about it. I'm sticking to my guns. The process worked. No bad kernel-mode code was released. We're going to get a high-quality in-kernel Wireguard implementation, and the code review process is going to get some love.

I reject the Freebsd is doomed nonsense. Go read early 2000s Slashdot if you need a shot of "BSD is dying!"


----------



## drhowarddrfine (Mar 30, 2021)

Mjölnir said:


> You keep denying that this incident revealed a serious underlying problem.


So my calling it an ugly bug in the process that needs fixing is denial? I've said, perhaps three times in this thread that it's a problem with the process.


----------



## grahamperrin@ (Mar 30, 2021)

drhowarddrfine said:


> … the lowest form of person. Such as … typical posters on reddit.



That's certainly *not* true of /r/freebsd.

I spend far more time in Reddit than here because sadly, discussion of -CURRENT is forbidden.


----------



## Snurg (Mar 30, 2021)

grahamperrin said:


> That's certainly *not* true of /r/freebsd.


I can confirm this, having read some threads there.


grahamperrin said:


> I spend far more time in Reddit than here because sadly, discussion of -CURRENT is forbidden.


Really, forbidden?


----------



## grahamperrin@ (Mar 30, 2021)

Topics about unsupported FreeBSD versions
					

The FreeBSD Forums cater primarily to end-users and systems administrators. As such, the Forums focus almost exclusively on FreeBSD versions that are officially supported according to the official FreeBSD website. Since resources are scarce, the FreeBSD Forums strongly suggest that anyone asking...




					forums.freebsd.org


----------



## Mjölnir (Mar 30, 2021)

Snurg said:


> I can confirm this, having read some threads there.


OOH, good to know, but OTOH, I feel strong reluctance even to _read_ that site to check your findings 


Snurg said:


> Really, forbidden?


I'm not a _mod_, but I'd strongly guess when you post about _CURRENT_ on-topic (or in _"off-topic"_), noone will complain.  IIUC the forum's goal is to provide a helping hand to users, and naturally that's not about developer's revisions -- the mailing lists are for that.  _STABLE_ is allowed, and even then, you're kindly requested to @least read/follow the respective mailing lists.


----------



## grahamperrin@ (Mar 30, 2021)

Thanks, but I learnt long ago to largely stay away. The message seemed loud and clear, that FreeBSD -CURRENT was unwelcome in any context in the FreeBSD Forums. I ceased showing my version of FreeBSD in my signature, and so on.


----------



## zirias@ (Mar 30, 2021)

grahamperrin said:


> Thanks, but I learnt long ago to largely stay away. The message seemed loud and clear, that FreeBSD -CURRENT was unwelcome in any context in the FreeBSD Forums. I ceased showing my version of FreeBSD in my signature, and so on.


This doesn't seem to be the intention. It's just to make clear not to look for _support_ regarding -CURRENT.

Of course, with these forums largely structured as "support forums", there's not much room left where -CURRENT would be considered on-topic  But that's still different from "forbidden".


----------



## drhowarddrfine (Mar 30, 2021)

grahamperrin said:


> I spend far more time in Reddit than here because sadly, discussion of -CURRENT is forbidden.


Then you should be on the mailing lists (and I know you are) not reddit. I don't think I've looked at the place in five years or more and my IQ went up 30 points.

Maybe things are better now but I've made that wrong choice before.


----------



## a6h (Mar 30, 2021)

grahamperrin said:


> I spend far more time in Reddit than here because sadly, discussion of -CURRENT is forbidden.


Forums is targeted at end-users, i.e. RELEASE users
1. John is using or going to use the system, as is.
2. John has some questions and/or problems about that.
3. To John, FreeBSD is a production system.

Consequently, Forums is not a place for following discussions:
1. Whether OS is dead, alive or have a future.
2. How to change, improve or destroy it.
3. Why it's not this, or not that.

CURRENT is forbidden, because
1. CURRENT != production. That's the whole point.
2. /src goes bad, OS goes south. You should know enough, looking for a way out.
3. Thus, we have mailing-lists, the de facto centre of such discussions.


----------



## Mjölnir (Mar 30, 2021)

`sed 's%John%(failure|???|gh_origin)%g'`
`sed 's/such discussions/the universe/'`


----------



## zirias@ (Mar 30, 2021)

vigole said:


> CURRENT is forbidden


But … it _isn't_  At least, that's too simple and isn't stated that way anywhere in forum guides and rules.

What's stated clearly is that no support for -CURRENT is given and questions seeking for help with it aren't welcome … and _that_ makes sense, as you explained.

Some general discussion in the "off topic" area (that isn't exactly off-topic IMHO, just more discussion than support character) about -CURRENT would probably be fine. The important question is, does it also make sense? As soon as technical questions are touched, of course the mailing list is the much better place, cause a lot of people read and write there and you will find the necessary knowledge.

But I think you _could_ come up with something touching -CURRENT that could make sense here. Just as one scenario I can come up with spontaneously: There is a forum about porting software. If you want to do a _full_ build test of your ports, you will need -CURRENT. Depending on the context, mentioning this could be helpful – of course, for questions about it, it's "move to the mailing list" again.


----------



## a6h (Mar 30, 2021)

Mjölnir said:


> `sed 's%John%(failure|???|gh_origin)%g'`
> `sed 's/such\ discussions/universe/'`


Yes. That's the best way to describe it. Nice 




Zirias said:


> But … it _isn't_  At least, that's too simple and isn't stated that way anywhere in forum guides and rules.


You're correct. It's not as strick as the way I've described it. That's why it's a good thing I'm not a Mod. If I was, people were getting ban, left and and right. Member numbers never pass 3 digits!


----------



## troublemaker (Mar 30, 2021)

I finally found some official information:

https://docs.freebsd.org/en_US.ISO8859-1/articles/committers-guide/pre-commit-review.html

I see 2 things:



> All non-trivial changes should be reviewed before they      are committed to the repository.





> Code review can be an iterative process, which continues      until the patch is ready to be committed.  Specifically,      once a patch is sent out for review, it should receive an      explicit “looks good” before it is committed.



Which all makes sense to me.
So basically this guy totally neglected common sense official guidelines. Not good.
Not sure why this hasn't been made more formal with the use of some tools; maybe it's a way to play nice when developers are actually willing to be nice.
Okay, maybe I would request reviews for all changes, not just the non trivial ones, but in general I don't think it's a problem with the process per se. They do the right things, it's just how they implement them in the process.
Even having some respect for the basic concepts of the agile philosophy, I would say some things should be a bit stricter. Unfortunately you can't always expect nice guys.


----------



## mark_j (Mar 30, 2021)

grahamperrin said:


> Thanks, but I learnt long ago to largely stay away. The message seemed loud and clear, that FreeBSD -CURRENT was unwelcome in any context in the FreeBSD Forums. I ceased showing my version of FreeBSD in my signature, and so on.


I would expect overall support is really the domain of the mailing lists for current. If you *need support* for current, you're probably not supposed to use it. If you want to *give feedback* for current then PRs and mailing lists are your destination.

I think that's the determination for the forums' rules (as I see it).


----------



## sidetone (Mar 30, 2021)

This is in the off topic section in terms of a production or stable release, and it's enough the topic of FreeBSD about FreeBSD as a whole. That guideline is about asking help or for technical information. It encourages mailing lists for technical help about CURRENT, because not enough users who use CURRENT are on the forum. It didn't say CURRENT can't absolutely be asked about here.

It's about FreeBSD. It's going to be discussed, maybe also here because this is the forum where common users use it, because there's a lot of chatter about it.

It got as far as STABLE anyway, if it were a purely technical discussion.


----------



## mark_j (Mar 30, 2021)

troublemaker said:


> [...snip...]
> So basically this guy totally neglected common sense official guidelines. Not good.


Yes. The fact he was able to is the problem.


troublemaker said:


> Not sure why this hasn't been made more formal with the use of some tools; maybe it's a way to play nice when developers are actually willing to be nice.
> Okay, maybe I would request reviews for all changes, not just the non trivial ones, but in general I don't think it's a problem with the process per se. They do the right things, it's just how they implement them in the process.
> Even having some respect for the basic concepts of the agile philosophy, I would say some things should be a bit stricter. Unfortunately you can't always expect nice guys.



This I made indirect mention about a while back. It's the format of the FreeBSD core that's the issue, in that there's not one director or controller. Compare this to Linux, where Torvalds will just say yay or nay to such a thing.

This is not to say the way FreeBSD is run is bad, it's just different and autonomy is preferred. However, there needs to be, it seems, a better approach to getting stuff into the main branch without sufficient auditing. How this is achieved depends on the core team and also what the other developers are willing to accept. All code has reviewer(s), but is this sufficient? It seems this code was working to a number of people's satisfaction, sans the obvious bugs found at the last minute.

Finally, you cannot impose something onto a team of volunteers (mainly) that you would in a paid, work environment. You cannot implement such things as "agile philosophy" on a project like this.

In fact, pet peeve here, I've seen too many of these approaches in my working lifetime; they're junk (or maybe I'm too cynical - or both!).
<rant>I draw the analogy of a basketball coach, with 5 great 3-point shooters and no one over 6'4", attempting to play the post game. In other words, you work with the people and the business you have, not the approach of some 'guru' who had a book published as the next big thing.</>

I apologise, I digress.


----------



## sidetone (Mar 31, 2021)

It could be simply, here's what's wrong, and FreeBSD and PF-Sense need better code review policies in their base.

The committer is going to lose the commit bit anyway if it hasn't already happened, after all of this.

GPLv2 code going from base to kernel would be an easy mistake to make, and getting help from the WireGuard author could have prevented this. As far as I know, the only reason the module was GPL was so the committer could make it work with Linux, and the commiiter had an interest in it working on FreeBSD. As a few have said, it didn't make it to the 13.0 release. Also, rushing things into a coming Release will always be prone to problems.

FreeBSD and PFSense also seemed to have gotten the message from the mistake.


----------



## Mjölnir (Mar 31, 2021)

sidetone said:


> It could be simply, here's what's wrong, and FreeBSD and PF-Sense need better code review policies in their base.
> 
> Instead, the author drags FreeBSD, PF Sense and WireGuard through the mud to get to his written agenda of FreeBSD needs better code review policies in its base. [...]
> 
> ...


Now as a reaction to your post I re-read that article again (3rd time).  Sorry for the harsh wording: *your post is **close to complete BS*... worst that I could find was that the author states:


> How did so much sub-par code make it so far into a major open source operating system? Where was the code review which should have stopped it? And why did both the FreeBSD core team and Netgate seem more focused on the fact that the code was being disparaged than its actual quality?


Well, these are in fact legitimate questions, right?!  Are you mixing up your personal aversions against _"such extremes as squatter's rights"_ while at the same time calling for justice for one of those guys who kick each other's ass* to get a seat next to one of the math cracks in a univ's test?  *Did you verify if the tenants were perfectly legal tenants with a valid legal contract or squatters???*
Enough.  Your post is simply ridiculous.  In no line in that article I can find FreeBSD is _"dragged through the mud"_.  It points out a serious problem and provides hard facts that you can prove yourself.  Yes, it might seem to be yellow press style if you're a hardcore disciple of _the almighty free BeaSD_, but it does not contain any wrong infos FMLU.  Please carefully & thoroughly check your biases.
* This is just wild guessing without proof.  I do not know MM's marks/grades in math.
EDIT +hardcore before _"disciple of the almighty free BeaSD"_


----------



## Mjölnir (Mar 31, 2021)

sidetone said:


> The author didn't post both sides of the story. What you accused me of, the author is guilty of. *This is my point*. I didn't say, Macy was right, I said, both sides of that story weren't presented by the author, when I know there are extremes. Did the author who used the ad hominem do that? So then the author wants us to assume, that directly relates to the next point about software.


???  I can not follow.  It all happens inside your brain.  Your (not-so-free, because we all have a history) decision.


sidetone said:


> I also didn't say, there wasn't a coding problem. I'm for method of review being improved, which FreeBSD got the message. I said, this got blown out of proportion for something that didn't hit release.


If you didn't hear the bells ringing: it was in a _release candidate_ revision.  FreeBSD 13-RC _something_.


sidetone said:


> said that FreeBSD and PfSense got dragged through the mud.


FreeBSD dragged through the mud?  Nowhere.  The article explicitely states that contract to implement _WireGuard_ into the FreeBSD kernel was without a deadline (which is highly questionable in consideration of what happened).


----------



## sidney (Mar 31, 2021)

Beastie7 said:


> The article highlights issues with holes in the projects governance. A single committer (who happened to belong to a company with questionable business practices) manages to dump 40k lines of unvetted code into HEAD just on a whim. Something is wrong right there with that margin of freedom.
> 
> This is a sound article.


Totally agree!  As a retired Oil & Gas industry Internal & Joint Venture Audit Mgr for 2 major oil companies, I'm sure that FreeBSD's image would benefit exponentially if the honchos would admit that their swamp needs draining - not *now*, but *right now!*  A re-evaluation and  restructuring of all internal controls is absolutely essential.  Been *there!* Seen *the very same thing!* with corporate IS depts.  OpenBSD may be silently positioning themselves in the wake of the mis-management? 

Everybody can have a bad hair/code/whatever day!  But proper internal controls will pick that up in jig time!!
BTW, I'm no developer or power user. Just an amateur enthusiast with my confidence in FreeBSD's commitment to clean code shaken.


----------



## Mjölnir (Mar 31, 2021)

I'm accusing you of nothing but to be biased & acting in reflex to protect your beloved pet.  Your pet cat was unveiled to be a monster, a cruel killer occasionally, so you try to protect your pussycat.  That's my oversimplified model of what happens to many of us disciples when we read that article.


> And why did both the FreeBSD core team and Netgate seem more focused on the fact that the code was being disparaged than its actual quality?


And rightly so.  I'm going to ask exactly that question when we'll have an _Office Hours_ on that topic.  I'm <subcomandante@freenode>.  Sidenote: that last e-mail I quoted from <markj@>  did read:


> Dear FreeBSD Community,
> 
> In light of the recent commentary on FreeBSD's development practices,
> members of the Core team would like to issue the following statement. [...]


and not


> [...] the members of the Core team [...]


or


> [...] all members of the Core team [...]


----------



## Snurg (Mar 31, 2021)

*Guys, please don't get personal.
We should all be friends, as we love FreeBSD* 

Being still curious, and trying to understand, I searched and read around a bit more.



mark_j said:


> Yes. The fact he was able to is the problem.


It was accepted by two users, a gmail address user and grehan, the maintainer of the PowerPC port, even though constantly new crashes and other serious problems surfaced.
This was sufficient to push the crap code on Nov. 29.
But there was no thorough code review.
Basically some installs and "works for me, except of the crashes".

FreeBSD developer danfe (Alexey Dokuchaev) joined the review on Nov 30, after it landed in -HEAD, looked at the code and immediately commented, but got ignored.
Until the bug fixing stopped when the review finally got closed by Matt Macy on Mar. 12, two testers continued to post lengthy bug/crash reports, which indicated that there were serious problems in many places.



mark_j said:


> This I made indirect mention about a while back. It's the format of the FreeBSD core that's the issue, in that there's not one director or controller. Compare this to Linux, where Torvalds will just say yay or nay to such a thing.


_I couldn't find any hint that possibly people in the core team involved themselves in actual review._
No idea why, if wireguard was considered as an "important addition".
Blind trust in Macy, or fear of getting sprayed with s**t if/when the bomb goes off?
Or fear of being considered as a "nest polluter" if one dares to insistently criticize the obvious problems of a pride project ?



mark_j said:


> All code has reviewer(s), but is this sufficient? It seems this code was working to a number of people's satisfaction, sans the obvious bugs found at the last minute.


...when others started to actually look into the code.
Donenfeld, Kyle Evans and Dunwoodie intensively worked for almost two weeks, when on Mar. 15 Donenfelds' mail went out, which initiated the public popping of the Wireguard bubble.
So internally the bomb must have exploded not later than around end of February/beginning of March.

*Now I am asking myself:
Was the import of the pfSense Wireguard fixes the wakeup call that triggered the chain of remedial events?*

Because, it revealed the quantity and seriousness of the bugs fixed by Netgate until then.
I guess this could have been the time in which the formation of the already-mentioned three-men-emergency team occurred, when Kyle Evans looked at Matt Macy's work, had his OMFG moment, and contacted Donenfeld and Dunwoodie.

Look at the impressive list, which indicates which plenty of surprises can be found in Matt Macy's work:



			
				List of Wireguard bugfixes imported from pfSense said:
			
		

> Merge the following fixes from https://github.com/pfsense/FreeBSD-src
> 1940e7d3  Save    address    of ingress packets to allow wg to work on HA
> 8f5531f1  Fix connection to IPv6 endpoint
> 825ed9ee  Fix tcpdump for wg IPv6 rx tunnel traffic
> ...



This list gave keywords for the ArsTechnica article recherche, and it was easy to find a lot more issues.
So I don't think that ArsTechnica should be blamed.

Instead it should be asked, _what led to such poor oversight of a such-promoted addition implementation work_?
Which reforms could work preventing such happen again?

How can such investigation be done in an open way, so nobody does feel fear of speaking out?
I find revealing that the developers the ArsTechnica author spoke with, wanted to stay anonymous.
_Fear of being open, this is not good._

The current handling of the issue reminds me much of the handling of the meltdown accidents in the Leningrad NPP in 1975, then again in Chernobyl 1982, and finally again in 1986, this time so massive that it could no longer be covered up.
The absolute secrecy was the cause that the same mistake was being repeated several times, at a big cost.

So, imho the first step reforming things should be to ensure nobody needs to be afraid to speak out, even when it might anger some brass hats.
Otherwise there cannot be true collective brainstorming.


----------



## mark_j (Mar 31, 2021)

sidetone said:


> It could be simply, here's what's wrong, and FreeBSD and PF-Sense need better code review policies in their base.


Yes.


sidetone said:


> Instead, the author drags FreeBSD, PF Sense and WireGuard through the mud to get to his written agenda of FreeBSD needs better code review policies in its base.


I don't think he does, BUT, he does try.
He alludes at a conflict of interest between Long and Netgate and FreeBSD and then presents no evidence of this, AT ALL.

He quotes "Several FreeBSD community members would only speak off the record. In essence, most seem to agree, you either have a commit bit (enabling you to commit code to FreeBSD's repositories) or you don't."

I am not sure why the "community members" would want to "speak off the record" about commit bits. Seriously, this is just junk journalism at its finest. This story is more opinion than fact and we all know about opinions!

In fact, public information about commit bits is easily found. For example, expiry of bits and commit bits in general. Sheez, that was secretive stuff, hey?




sidetone said:


> According to the Salter, Macy is on the Most Wanted List. Knowing there's such extremes as squatter's rights, we didn't get both sides of the story. It goes to say, he's a criminal who threw old people down the stairs, then jumping to the next thing about software, without providing a rational relation of two separate subjects. As if the author has a personal vendetta against the committer. The committer is going to lose the commit bit anyway if it hasn't already happened, after all of this.



Putting aside the morals of Mr Macy, Salter does make the point that Macy was distracted by this. But, this is a lame excuse by Macy. Salter's reporting of it only seeks to downplay Macy's part. It's Macy's code, he has to be responsible for it. It was a bit of a mess, but more than that it was not reviewed sufficiently by either Netgate or FreeBSD. That's the troubling part.



sidetone said:


> GPLv2 code going from base to kernel would be an easy mistake to make, and getting help from the WireGuard author could have prevented this. As far as I know, the only reason the module was GPL was so the author could make it work with Linux, and the author had an interest in it working on FreeBSD. As a few have said, it didn't make it to the 13.0 release. Also, rushing things into a coming Release will always be prone to problems.


Because Macy copy/pasted large chunks of GPL, it would have been a problem. This all points back to Macy's integrity as a coder.
It's almost impossible to review code and look for contrary licensing, you just have to rely on the author to be ethical.


----------



## sidetone (Mar 31, 2021)

I read it again with better understanding of the different actors. It's less biased than I originally made it out to be.

Donnefield and others pointed out problems with the implementation into base of stable. It got that far, but the problems were known. Not as it were a completely hidden problem, that was easy to remove it due to known problems.

It would have been better if Macy didn't decline help by the WireGuard author to get it ported.

Edit:
It seems it's the way this information is presented to grab attention.

I also looked at the linked story about Macy as a landlord. He legally tried to get the tenants out for some time. Some laws about that are extreme. After that didn't work, he started doing illegal things to condemn the building after that didn't work. If the laws are, someone has 6 months or a few years notice to move out, or gets a discount on a few months rent that's perfectly good. If the laws are that, the landlord can't lose the tenants absolutely at all for a good reason, then... I don't judge so harshly. As I pointed out, some laws about this are extreme.

Macy made the wrong decision. For that, he lost half a million dollars, got a criminal record and was extradited from Italy for jail time.


----------



## Snurg (Mar 31, 2021)

mark_j said:


> In fact, public information about commit bits is easily found. For example, expiry of bits and...


So it looks to me like that the Core team left him his commit bit even through his four years in jail, while others get booted after 18 months without making a commit. Interesting!


----------



## Mjölnir (Mar 31, 2021)

Snurg said:


> So it looks to me like that the Core team left him his commit bit even through his four years in jail, while others get booted after 18 months without making a commit. Interesting!


This for itself is no problem IMHO.  In contrast, a prisoner has plenty of time, and to do s/th useful can be vital in there.


----------



## grahamperrin@ (Mar 31, 2021)

drhowarddrfine said:


> … you should be on the mailing lists (and I know you are) not reddit. …


Why _not_ discuss -CURRENT on Reddit?

The mailing lists have pros and cons. As far as I know, freebsd-current is still limited to plain text only.

Reddit supports Markdown, images (in opening posts), and so on – don't forget the popular and very highly rated Reddit Enhancement Suite.

The absence of support for Markdown is another reason for me spending so little time here.


----------



## drhowarddrfine (Mar 31, 2021)

grahamperrin Cause most redditors are children under 18 years old and never use FreeBSD even though they post there. On the mailing lists you'll find everyone using FreeBSD and most do as a career or a FreeBSD developer.


----------



## grahamperrin@ (Mar 31, 2021)

drhowarddrfine said:


> … most redditors are children under 18 years old and never use FreeBSD even though they post there. …



Two pages back: 



> That's certainly *not* true of /r/freebsd.


----------



## grahamperrin@ (Apr 1, 2021)

troublemaker said:


> I finally found some official information:
> 
> https://docs.freebsd.org/en_US.ISO8859-1/articles/committers-guide/pre-commit-review.html


That's an outdated edition of the Guide. Instead: 









						Committer's Guide
					

Introductory information for FreeBSD committers




					docs.freebsd.org
				




For clarity: 

https://docs.freebsd.org/en/articles/committers-guide/#pre-commit-review

Similarly, the first edition of the Ars Technica article referred to an outdated edition of the FreeBSD Handbook. In an e-mail to the author, I briefly explained and requested a correction, he was "happy to oblige".




troublemaker said:


> I see 2 things:
> 
> > All non-trivial changes should be reviewed before they are committed to the repository.
> 
> … totally neglected …



For clarity: that (the first of two things) was not totally neglected.


Some problems with the the noise of controversy: 

basic facts are overlooked
where there's reading between the lines, there's the danger of imagination being misrepresented as fact *and then* echoed (or up-voted) without challenge.


----------

