Slashdot Mirror

On August 23, 2018 - Theo de Raadt with OpenBSD even recommended disabling HT in BIOS. His e-mail below.

https://marc.info/?l=openbsd-t...

What the fuck happened to Linus ?

Remember when he had some balls and some common sense in this context ?

https://marc.info/?l=linux-ker...

Can we please get that Linus back ?

So as far as I'm concerned, the discussion is about "how to work together DESPITE people being different". Not about trying to make everybody please each other. Because I can pretty much guarantee that I'll continue cursing. To me, the discussion would be about how to work together despite these kinds of cultural differences, not about "how do we make everybody nice and sing songs sound the campfire" . . . Because if you want me to "act professional", I can tell you that I'm not interested. I'm sitting in my home office wearign a bathrobe. The same way I'm not going to start wearing ties, I'm *also* not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords. Because THAT is what "acting professionally" results in: people resort to all kinds of really nasty things because they are forced to act out their normal urges in unnatural ways.

I think "Don't be a massive dick to anyone else" is probably sufficient as far as code of conduct goes. Yes it's vague, but any precise set of rules to govern behavior is going to be incomplete and subject to all manners of pettiness.

Regardless of how much I dislike Google and other big Internet corporations, and how much would I like to have better alternative to Chromium, I read a mailing list post by a guy I trust with software-related stuff - Theo de Raadt of OpenBSD fame - saying "Firefox is YEARS behind (Chromium), unless they change their strategy" in terms of security:
https://marc.info/?l=openbsd-m...
I sincerely hope they will change the strategy. Until then it's Chromium for me.

Lustre is most definitely *not* dead. The removal from staging was a bit of an unfortunate event, but work on getting it cleaned up for re-submission to the kernel is continuing.

I miss a real email about once a year from SPAM filters in Gmail, and it's usually a shady email. I literally never check my Gmail SPAM just because.

Seriously?

Let's take Linus, he somehow still uses Gmail. I'm too small a fry to send him pull requests, but I did make an April first one. (The mail archive web display mangles UTF-8 but it's correct in the actual mail, pretty vital for this actual patch set.). See Linus' complaint. Here we have correspondence from someone who had just participated in a two-way thread with Linus (something about modversions), the mail is GPG signed by a key one indirect node away, the mail being a well-formed pull request of the kind he gets tons of every day.

How do you get a MORE valid mail for this particular recipient? (Aside of runes support in the tty layer not being an entirely reasonable feature.)

I hear him complain about having to fish a pull request out of Gmail's "spam" roughly monthly, and that's only cases when he bothers to mention this and I happen to read that particular response (reading the entirety of LKML is not humanly possible).

Thus, Gmail is so bad in the false positive department that I don't think it's usable. Even worse, when it discards a mail this way, it doesn't notify the sender the way any sane server is supposed to!

I miss a real email about once a year from SPAM filters in Gmail, and it's usually a shady email. I literally never check my Gmail SPAM just because.

Seriously?

Let's take Linus, he somehow still uses Gmail. I'm too small a fry to send him pull requests, but I did make an April first one. (The mail archive web display mangles UTF-8 but it's correct in the actual mail, pretty vital for this actual patch set.). See Linus' complaint. Here we have correspondence from someone who had just participated in a two-way thread with Linus (something about modversions), the mail is GPG signed by a key one indirect node away, the mail being a well-formed pull request of the kind he gets tons of every day.

How do you get a MORE valid mail for this particular recipient? (Aside of runes support in the tty layer not being an entirely reasonable feature.)

I hear him complain about having to fish a pull request out of Gmail's "spam" roughly monthly, and that's only cases when he bothers to mention this and I happen to read that particular response (reading the entirety of LKML is not humanly possible).

Thus, Gmail is so bad in the false positive department that I don't think it's usable. Even worse, when it discards a mail this way, it doesn't notify the sender the way any sane server is supposed to!

Please note, that just because it receives a microcode update, doesn't mean it's secure. The processors are still buggy as hell.

...or not:

* https://www.linuxfoundation.org/blog/the-2-6-32-linux-kernel/
* http://www.kroah.com/log/linux/longterm-proposal-08-2011.html
* https://marc.info/?l=linux-kernel&m=122375909403298

The 2.6.x series is still actively and heavily used in a commercial embedded router sector (ex. Asus, Netgear, Tenda, Linksys (now Foxxcon, was Cisco/Linksys), Huawei). Broadcom is still maintaining/updating wireless binary blob drivers for 2.6.22 and 2.6.36, both for MIPSr1/MIPSr2 and ARM/ARM7 archs.

This bug has been known and reported about since early November

November, nothing. Theo de Raadt called Intel "a nasty x86 architecture which barely has correct page protection" in 2007. He was right.

https://marc.info/?l=openbsd-m...

https://www.theregister.co.uk/...

What makes you think that open source software is somehow any better?

As the Shellshock and Heartbleed bugs have proven, just because source code is available it doesn't mean that anyone actually looks at it. When major open source software projects have serious bugs in them that go undetected for years or even decades, it's doubtful that a well-hidden backdoor would be found.

Then there are projects like systemd and GNOME 3, which have introduced a lot of new code into many Linux systems. Has all of this code undergone a strenuous security review? I very much doubt it!

Even the OpenBSD project, which is perhaps the most stringent and careful open source project out there, has had scares in the past.

So I don't think we should consider open source software to be any better. It could very well be much worse.

already being worked on see here

Those are not the real sources, just selected quotes. The Bleeping article links to the real sources which are de Raadt's announcements. Here and here.

Those are not the real sources, just selected quotes. The Bleeping article links to the real sources which are de Raadt's announcements. Here and here.

Some of the contributors are upset about the way that this license change is being pushed through. See

http://marc.info/?l=openbsd-tech&m=149028593819547

There's always going to be a difficult one looking for any angle to complain and obstruct.

Some of the contributors are upset about the way that this license change is being pushed through. See

http://marc.info/?l=openbsd-tech&m=149028593819547

Not really: http://marc.info/?l=git&m=1156... .

Git hashes objects (commit, trees, blobs, tags) instead of individual tags. If you managed to somehow create, say, a commit with the same SHA1 as another existing in a repository pushes to it would be simply ignored.

It's arguably a major Bug in Git if the Git software keeps track of an object Solely by Hash, and lazily assumes that the Hash
uniquely identifies a specific version of the file, And that assumption turns out to be false, and data corruption or tampering can be caused as a result.

I disagree, this is not a bug. It is perfectly reasonable to use a crypto hash to uniquely identify objects within a SCMs, given that one of their properties is that they provide uniformly distributed IDs over a very large space. Statistically the chance of running into a SHA1 collision under normal git usage is so low as to be practically zero - you have a (much, much) better chance of experiencing repo corruption due to cosmic rays hitting your HDD or memory.

Anyway, git's failure mode is not horrible either in that scenario: http://marc.info/?l=git&m=1156...

The invoker servlet and its default mapping /servlet/* isn't present in old nor current specs. It is not a JEE standard or was. It was a feature many JEE containers copied mainly because Tomcat at that time was the reference implementation (The invoker servlet class was on the tomcat package namespace not on the javax.servet one) , a very bad idea. It is not present in modern containers.

Since 2002 is known that having it enabled was a bad idea. But you know, enterprise software is badly updated.

https://marc.info/?l=openbsd-t...

So one bug was in code deemed dodgy in external peer-review and the other was in code not really needed. Right.

Actually, it has been hacked, and it's relatively easy to do.

[citation needed]

http://marc.info/?l=qmail&m=14...

OTOH, OpenBSD's kernel is about 10X the size of Xen (where the BSD mantra of 'correctness' has a much tighter focus). As isolation mechanisms go, I trust Xen before any monolithic kernel. The upshot is that Xen also gives me the rich features (incl. drivers) of Linux and Windows.

Awwwww, you are so cute. You trust Xen more than kernel xyz? Really?

First of all, please read this.
Then take a look at this.

There are, let's see... right now, 35 CVEs assigned to the Xen project, in 2015 alone? 40 CVEs in 2014?

Compare and contrast with the number of CVEs published for OpenBSD. And the number of patches available for the latest version (5.8) of OpenBSD.. Here is a hint: 99% of these patches do not imply your machine is going to be ''owned'' by someone exploiting the bugs found. Yes, even the OpenSMTPD patches are pretty mild.

You can keep your Qubes OS, thank you very much, I'll stick to OpenBSD, despite all its defaults and warts.

Words of wisdom to meditate:

You've been smoking something really mind altering, and I think you should share it.

x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

(Source.)

Say what you will of this guy, he has got a point. Virtualization is great, but not for security. Period.

No, this only affects SSL certificates using the SHA-1 hash. Git isn't using the SHA-1 hash in a way where generating a collision would have security risks so there is no reason why anything has to change for Git.

Quoting a post from the old article quoting another article quoting an old answer from Linus on the issue:

[...] it's not really a big deal.

.
A quick description of OpenNTPd's constraints is here.

you might want to read this interesting thread including a message from the lead opensmtpd developer.

To me the fact that the devs wanted an audit on top of the code review that's already done shows that they are indeed quite serious about security. Given how hard it's historically been to secure mail servers I think the devs are doing the right thing with opensmptd, so speaking for myself I'll certainly continue to use it.

Well, wasn't that what happened with Dual_EC_DRBG?

We can never know for sure, but empirically, I really don't think Dual_EC_DRBG ever pinged on NSA's --- or any other state intel actor's --- radar. At least not before EC vulnerabilities became public knowledge. Its use by default in the RSA BSafe toolkit meant that products using that toolklit would be vulnerable. And YES, that was a rich prize. BSafe may have been part of a program to seed a backdoor towards, say, a particular target state or industry.

BUT... there is for me an irreconcilable problem with that theory. I ran an ISP in those crazy early days when administrators were faced with a choice of whether to 'drop in' a BSafe object library under license (prove USA blahdy-blah) or compile the SSLeay/OpenSSL source, which was by no means as smooth and functional as it is today. But even pre-2000 it was obvious that the whole world was going the OpenSSL open source route as soon as it was stable.

Given that OpenSSL's populary was increasing by leaps and bounds... and yet, the OpenSSL FIPS Object Module v2.0 had a bug that prevented Dual_EC_DRBG from being used. *IF* the back door was being actively exploited by some state actor, they would have noticed this right away and it would have been a trivial matter (and top priority) for some helpful volunteer to emerge from the shadows and toss in a fix for it. Maybe even a soft-sell for epileptic curves. But this did not happen. Ergo, circumstances more closely resemble a situation in which NOBODY, including NSA, cared.

Remember that intel agencies are padded with the same bloviating internal memos as any organization, and love to take 'credit' for a thing to show their prowess whether or not the thing is actively being used. Maybe a good part of Snowden's trove are empty boasts.

He has never been (a dick) (and may will never be).
It's just that his style is not suited with someone, and he/she quits. This is just normal.

The kind of stories about "Linus bullying" has appears four or five a years, but each times, there are people jump out and claim, likely they never ever read these stories before (not about you). So each topic about "Linus bullying", the *same patterns* of discussion appear again and again.
BTW, there was a Slashdot user (he is/was also "a newbie" kernel developer) said that Linus is very nice and friendly toward newbies, unexperienced developers.

He was clearly described the style of discussion (as he described, say louder not insult):
https://www.kernel.org/doc/Doc...
or here,
http://arstechnica.com/busines...
or here,
http://arstechnica.com/busines...
Some may say that he is rude, but in fact, I see he's straight, but his words were putted out of the context. Remember the "F you, Nvidia! (and pointed finger)" incident, he right after added "Don't get me wrong...", but the later usually never mentioned. But the progress of Nvidia action later proved his style works.

While Sarah seemed to be allergic with the style (see the chains of discussions):
http://marc.info/?t=1373580445...
started with Linus' shouting:
http://marc.info/?l=linux-kern...
appeared in story:
http://linux.slashdot.org/stor...

Or, the Linus' "victim" does not have problem with his style:
start with:
https://lkml.org/lkml/2013/2/2...
"victim" respond:
https://lkml.org/lkml/2013/2/2...
appeared in:
http://linux.slashdot.org/stor...

He has never been (a dick) (and may will never be).
It's just that his style is not suited with someone, and he/she quits. This is just normal.

The kind of stories about "Linus bullying" has appears four or five a years, but each times, there are people jump out and claim, likely they never ever read these stories before (not about you). So each topic about "Linus bullying", the *same patterns* of discussion appear again and again.
BTW, there was a Slashdot user (he is/was also "a newbie" kernel developer) said that Linus is very nice and friendly toward newbies, unexperienced developers.

He was clearly described the style of discussion (as he described, say louder not insult):
https://www.kernel.org/doc/Doc...
or here,
http://arstechnica.com/busines...
or here,
http://arstechnica.com/busines...
Some may say that he is rude, but in fact, I see he's straight, but his words were putted out of the context. Remember the "F you, Nvidia! (and pointed finger)" incident, he right after added "Don't get me wrong...", but the later usually never mentioned. But the progress of Nvidia action later proved his style works.

While Sarah seemed to be allergic with the style (see the chains of discussions):
http://marc.info/?t=1373580445...
started with Linus' shouting:
http://marc.info/?l=linux-kern...
appeared in story:
http://linux.slashdot.org/stor...

Or, the Linus' "victim" does not have problem with his style:
start with:
https://lkml.org/lkml/2013/2/2...
"victim" respond:
https://lkml.org/lkml/2013/2/2...
appeared in:
http://linux.slashdot.org/stor...

Marc Espie said the error exists in FreeBSD's PAM implementation.

Marc Espie's post, linked from the article: http://marc.info/?l=openbsd-mi...

"Okay, let's admit that the *portable* version of openssh wasn't programmed in a way that's paranoid enough about the failure modes of pam."

Lots of hemming and hawing about how PAM sucks and is easy to screw up, and maybe it is, but the bug still exists in OpenSSH code and that's where it was patched:

https://anongit.mindrot.org/op...

That's because your parser's broken.

No, my parser is fine. Your's matches your usename - that is just a pseudonym, right?

... but still, if PAM is configured with OpenSSH, a PAM bug may sometimes be mis-identified to be an OpenSSH bug

Then it's not an OpenSSH bug. (and that's not English)

No matter if it's a PAM bug or an OpenSSH bug, a but report which points out a vulnerability is good thing for the community

(assuming the coward means "bug report"). No - it's a waste of limited resources. Big scare about an insecurity in OpenSSH which did not exist

"King Cope" posted to the Full Disclosure mailing list Fri, 17 Jul 2015 21:23:36 +0000 (UTC) (according to my email system) with an exploit

ssh -lusername -oKbdInteractiveDevices=`perl -e 'print "pam," x
10000'` targethost

and "a patch for openssh-6.9p1 that will allow to use a wordlist and any passwords piped to the ssh process to be used in order to crack passwords remotely.". By applying the patch it allows an attacker to try as many attacks as possible within the gracetime (2 minutes). The best case scenario allows an estimated 10000 attempts in that time period.

I only read it because he's usually good for a laugh, or, as is this case, a face-palm.

Which might brute force a very short (stupid) password that would fall to a small, lucky, dictionary attack. Which is why BP is to use a key.

He mentions in that email that it has been "tested against a new FreeBSD 10.1 system and older FreeBSD versions such as version 6.2.".

something that will allow the users to tighten up their configuration to deny that bug from being able to function in the first place

Tighten up what? Their SSH configurations? It is a bug in PAM that is restricted to small range of BSD versions.
Tightening up SSH, which is already as tight as it can be against the exploit unless you deliberately loosened it (as Sex Conker would recommend - but he's an idiot). Default configurations already stop the exploit (no root ssh login, all ssh logins with keys).

The exploit would only affect insecure systems that use piss poor password security - and even then only on a limited number of BSD systems.

That belief is a broken as the idea that if there's a story a cigarette lighter exploded, which causes a panic about cigarette lighters, and calls for a recall of them - turns out to be a case of someone in petrol soaked pants being injured when the cigarette lighter in their pocket exploded as a result of them falling out of a building and landing on their arse. Unfortunately they had a box of matches in the back pocket which exploded on impact, setting fire to their pants - the heat of the flames caused the cigarette lighter to explode.

The moral of the story is not - oh the panic about cigarette lighters exploding was a good thing.
It would have been a "good thing" if that energy was spent on warning people of the dangers of wearing petrol pants and falling out of windows.

It would be a "good thing" if people focused on the actual bug in PAM instead of trying to justify their earlier panic (the sky is not falling).

The coward that wrote that gibberish you're defending , who is obviously not you, is referring to what bug report?Hint: there was none, just another of King Cope's self-promoting and inflated security exploits (he also thinks robots.txt is a security hole). You fell for it, get over it.

.
http://marc.info/?l=openbsd-te...

We have received several emails asking if we are impacted by the latest CVE-2015-1793. We are not impacted. The code related to that CVE was added after we forked 1.0.1g and we did not merge these changes from upstream. This CVE only concerns newer OpenSSL releases.

'I'm not interested. I'm sitting in my home office wearign a bathrobe. The same way I'm not going to start wearing ties, I'm *also* not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords. Because THAT is what "acting professionally" results in: people resort to all kinds of really nasty things because they are forced to act out their normal urges in unnatural ways'. Linus Torvalds July 2013

Ok, I'll bite. m:tier, a two-person company worth about 100,000 Pounds Sterling, that has been around for 6 years is your poster child? A company that has a single reference on its web site for a, and I quote:

We have been using the M:Tier CompliantBSD complete Desktop and Office solution since 2008 to provide an extremely secure and stable environment for up to 350 users across diverse geographical locations.

And somehow you want us to believe this is evidence that BSD is competitive on the desktop with over a billion Windows installations, or 66 million Macs in use?

I think you just proved my point. When everyone else has thought about what to run and made their decision, a billion chose Windows, 66 million chose a Mac, and a few hundred chose OpenBSD. OpenBSD has so few users, it has trouble keeping the lights on, literally.

There is a fleetingly small number of companies with BSD on the desktop, virtually all are involved with supporting BSD in the data center (including m:tier), and they all involve a very small number of folks.

FreeBSD outperforms Linux only in certain scenarios. In most common cases you would hardly find any difference. Otherwise.

It is not the problem that Linux network stack sucks. The problem is that linux-netdev people believe that Linux network stack is already perfect.

AND. The biggest problem is with the certain Linus Torwalds who insists on perfect design for any net redesign.

That's why we still do not have interrupt polling/interrupt throttling or anything like pf.

That's why we have the technically perfect ip - but totally unusable to literally any human being. And the iptables with near O(n) performance.

It's basically the same story as with the sound subsystem. As long as the design is good, it doesn't matter that the end result sucks.

Don't worry, similar driver modification was proposed for inclusion – https://lkml.org/lkml/2014/10/... . But Linux maintainers didn't took it. Instead, original driver was adjusted to work with FTDIs ”bricked” by Windows driver: http://marc.info/?l=linux-usb&...

Linux is not fun anymore.

Nope.
Nothing unintentional about it.
http://marc.info/?l=linux-usb&... - a patch submitted to do the same on linux.

The maintainer of the USB susbsystem responded
'Funny patch, you should have saved it for April 1, otherwise people
might have actually taken this seriously :)'

https://marc.info/?l=oss-security&m=141157106132018&w=2

Who needs Windows anyway? Theo de Raadt himself has said: "The
entire world went to POSIX".

OMG I'M REPLYING TO A FOUR-DIGITER!!!!

What's the problem?

A lot of these people have shit colored glasses bolted to their skulls. Combine this with an irrational hate for anything corporate and there you go; petulant little office trolls emoting on Slashdot.

Theo et al. have and are publically seeking for both individual and corporate support for both the OpenBSD Foundation and LibreSSL, and are specifically seeking a "Stable Commitment of Funding."

Unlike some of the malcontents that haunt Slashdot, they actually spend their time writing open source code. As such, they are painfully aware that large scale open source work is not actually the exclusive product of self funding trust fund rebels.

The implementation didn't work anyway and it looks like they disabled it. Announcement on their mailing list.

That's not quite right either. The open-source releases of OpenSSL certainly do not ship with any implied FIPS certification. OpenSSL does offer FIPS validation for a specific build as part of their commercial support program. They say "Support for the FIPS Object Module, including assistance with building a validated module for a specific platform (if possible) is available with the Premium plan". It is not correct that these versions are exactly the same code as the ones first certified long ago.

There was an interesting post to the openssl annoucement mailing list about Flaws in Dual EC DRBG that sheds some more light on this area. It says: "The OpenSSL FIPS module is commonly used as the basis for rebranded proprietary validations (we call these 'private label' validations)", "FIPS 140-2 validations are expensive and difficult, taking on average a year to complete and we have to wait years between validations", and "Even if we wanted to fix it our options are severely constrained by the fact that the CMVP process forbids modifications of any kind (even to address severe vulnerabilities) without the substantial time and expense of formal retesting and review."

All this implies there absolutely are later versions of OpenSSL with FIPS certification out there. You just can't get one without significant input from the commercial end of the OpenSSL Foundation.

http://marc.info/?l=openssl-de...

This was the first patch sent to openssl-dev after the heartbleed revelations. Although in this case it's a misplaced "goto err", it could have been a "goto fail".

Is there a case for using goto once every decade? Sure. But not 6740 times.

Safer != Perfect

Open Source is not perfect. It also does not help when you have large commercial institutions RELYING on the source code in a security critical role under constant attack by well-funded adversaries, AND the developers of said open source code are so pitifully underfunded, AND the commercial proprietors that cause said open source library to become a high-value target are only willing to invest in features, and not improvements that would lead to better quality and lesser likelihood of serious bugs.

Safer != Perfect

Open Source is not perfect. It also does not help when you have large commercial institutions RELYING on the source code in a security critical role under constant attack by well-funded adversaries, AND the developers of said open source code are so pitifully underfunded, AND the commercial proprietors that cause said open source library to become a high-value target are only willing to invest in features, and not improvements that would lead to better quality and lesser likelihood of serious bugs.

$30,949 is how much the OpenBSD Foundation received in donations in 2013.

And yet... I heard OpenSSL itself gets at most $2000 in a typical year. Despite tens of thousands of banks, retailers, hardware manufacturers, software manufacturers, all relying on their code in a security critical fashion to support their business activities. The MOST the OpenSSL project gets in contributions is a mere shilling?

And no real support for high quality code review, maintenance, and release management. Just support for adding feature bloat.

$30,949 is how much the OpenBSD Foundation received in donations in 2013.

And yet... I heard OpenSSL itself gets at most $2000 in a typical year. Despite tens of thousands of banks, retailers, hardware manufacturers, software manufacturers, all relying on their code in a security critical fashion to support their business activities. The MOST the OpenSSL project gets in contributions is a mere shilling?

And no real support for high quality code review, maintenance, and release management. Just support for adding feature bloat.

Yes, there are some people who are incapable of compiling their own software who will have to wait until the patch comes through. Those people shouldn't be managing security for a large website (or any website really, in an ideal world).

Nonsense. I'd want only vendor supplied fixes applied, unless the vendor is so slow as to be incompetent (but then, why would you be using them?)

Why? Because user applied fixes tend to be forgotten, and if the library isn't managed by the package system (you've uninstalled the package you're overwriting, right?) you might miss subsequent important updates.

An example from a far from fuckwitted user:
http://marc.info/?l=sqlite-use...

Yes, the author of the SQLite library fell pray to this very issue. Let the package manager track packages.

Of course, you could also build binary packages from source, but then that assumes the upstream source packages have been patched, or you're happy to patch the source packages yourself.

This has already been answered here: http://marc.info/?l=openbsd-mi...

And OpenBSD is going strong, too. It's more relevant than ever, giving the increasing importance of security these days. That's why they just raised $100,000 in direct user funding.

Oh, yeah, that's right ... they had a Bitcoin Billionaire come to their rescue.

What exactly are you trying to get at?

BSD-licensed software is doing great these days. FreeBSD 10.0 was just released a few days ago, offering some superb functionality that we don't even see offered by any Linux distributions yet. Part of that is their seamless integration of LLVM and Clang. In case you missed it, there was a story here on Slashdot earlier today about how LLVM/Clang are making Richard Stallman himself shit one brick after another. LLVM/Clang are starting to crush the living hell out of GCC.

NetBSD is still found in all sorts of networking gear and other embedded situations. And OpenBSD is going strong, too. It's more relevant than ever, giving the increasing importance of security these days. That's why they just raised $100,000 in direct user funding. And their OpenSSH offering is used on basically every Linux system these days, too.

Then there's OS X, which is a heavy user of BSD software. Their contributions to LLVM/Clang have helped push it mainstream. And their operating system long ago eclipsed Linux in terms of desktop usage share, and is now encroaching on that of Windows.

And then there are all sorts of projects on GitHub that are licensed under the BSD license, or the nearly-identical MIT license. It's rare to see a *GPL license being used for new projects there.

These are excellent times for BSD-licensed software projects. They're doing better than ever, and they're continually providing more and more value, and more and more freedom, to their users constantly.