Hacker Newsnew | past | comments | ask | show | jobs | submit | slome's commentslogin

The openbsd foundation raised around 5 million, half of which has been spent. Curiously they aren't as transparent as they once were.

You mention nvidia support, others are hopeful for a better filesystem and wifi as well.


> .. wifi as well.

OpenBSD has supported 11ac for several years, and has the iwx(4) driver for modern Intel WiFi cards. There's also support for Broadcom FullMAC, bwfm(4), which is on e.g: Apple Silicon machines.

HaikuOS also has a port of OpenBSD's iwm/iwx drivers.

FreeBSD just recently announced they've started porting the OpenBSD iwx driver.. from Haiku.

https://freebsdfoundation.org/blog/laptop-support-and-usabil...


> The openbsd foundation raised around 5 million, half of which has been spent.

Citation needed, they've raised nowhere near that amount.

https://github.com/bob-beck/foundation-web/commit/483266cece...

https://www.openbsdfoundation.org/campaign2024.html


Not OP, but they've raised $4,974,668 since 2014 (done by adding up all the thermometers at https://github.com/bob-beck/foundation-web), and I'm excluding anything prior.

That's certainly what they meant ;)


Thanks, very misleading..


Thanks for the insight. I had never considered this even though i researched quite some oddities in UTF-8 parsing myself over the years. It's the gift that keeps on giving when it comes to ways to breaking things in software, i find. Time to go over my code again.


OpenBSD only implemented loading AMD firmware two days after AMD published updated microcode to fix Zenbleed. Which makes me believe they were not among the "major kernels", vendors or other entities that got a heads up of this vulnerability which happened over two month prior.

Whether they were last to be in the know or not, i applaud them for being one of the first to have patches out for their latest two stable releases (7.2 and 7.3).


Don't know if it was still the case, but OpenBSD would not get early vuln info because they wouldn't sit on embargoes and would patch right away.


This is untrue. OpenBSD pushes to release as early as possible, but if they're on an embargo, they've respected it.


Technically correct I suppose - https://isopenbsdsecu.re/mitigations/embargoes_handling/

But they do have a relatively difficult history with embargoes. This isn't criticising them BTW - although I don't use OpenBSD any more I still have a soft spot for them and respect for everything they've achieved.


Rather difficult, in the sense that people continue spreading falsehoods about their relationship with embargoes, which makes it difficult to participate in responsible disclosure.

See this thread for examples.


Eh, it's more or less true. OpenBSD violated the KRACK embargo in 2018. They decided to publish for the benefit of their users, and fuck everyone else.


Incorrect. They had explicit permission from the researcher involved to commit when they did. Here's the full discussion, if you want to read it yourself.

https://marc.info/?l=openbsd-tech&m=152909822107104&w=2

More directly, from the KRACK FAQ: As a compromise, I allowed them to silently patch the vulnerability.

https://www.krackattacks.com/#openbsd

It's also worth noting that Microsoft violated the embargo as well: On this topic, it is also worthwhile to mention that Microsoft pushed their fixes on patch Tuesday on 10 October 2016 [1]. That's before the agreed disclosure deadline, albeit quite close in time.

Quite rightly, nobody is suggesting that nearly a decade later, we should be keeping Microsoft off responsible disclosures as a consequence.


I mean, I just disagree with that interpretation of 2018 events. The embargo deadline was extended, OpenBSD violated that. They refused to play ball with the coordinated extension. The researcher is orthogonal to that. Their actions in 2018 are certainly not universally celebrated as a good way to participate in an embargo.


You don't get to extend an embargo unilaterally. Now that there's a new uniform 90 days the conversation looks different.


They asked for permission from the coordinator and got it. It's that simple. There's nothing open to interpretation here.

The next time you coordinate a disclosure, you can run it differently.


Why do people blame OpenBSD but not the coordinator is beyond me.


This subject of this article is OpenBSD; it's reasonable to be discussing OpenBSD. I'm not saying that guy is blameless.


It's possible they knew just enough to know that they needed to implement firmware loading, without knowing the full details of the vulnerability.


Author doesn't know why this supposed bug can't be fixed and makes a quick assumption. Later on he asks the reader for insights. Crazy.

Just ask the developers directly via the official mailing list [1], or send a bug report as you are invited to do by the developers [2].

[1] https://www.openssh.com/list.html

[2] https://www.openssh.com/report.html


This allows Mozilla to trim away some of the cruft and have more time available to focus on actually improving Firefox for people living in this day and age. There will always be someone who feels left behind but to me this decision is a no-brainer.


There will also be a lot of people actually left behind, but of course there will always be people who don't care about it


Goto prepare it for modern users


You can run debian without systemd [1]. I've been running debian sid - the "unstable"/rolling development version - with sysvinit for over 3 years now and it has been a good experience.

[1] https://wiki.debian.org/Init


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: