The mupdf PDF reader has been patched to make use of pledge on OpenBSD.
475 karma · joined July 23, 2014
Companies are temporary entities, even though they don't like to think of themselves as such. Companies get bought or go bankrupt.
So when I buy a device which only loads signed code, there is no way to know who is going to be able to sign code for my device in the future. I'm also out of luck if I ever want to run my own or someone else's code on my device.
The attack surface is completely dependent on the actual code being signed, so the signature doesn't provide any security benefit to me. And in case there were 3rd party code which is more secure than the vendor code I cannot run it.
From the perspective of the company, the signature provides vendor lock-in and planned obsolescence in return for a relatively small effort of maintaining code signing infrastructure. So there's only an advantage but no disadvantage. The only possible disadvantage is that I am less likely to buy the product, but regular consumers won't know the difference so the company can ignore me.
Omitting hardware components which would help with repair efforts or debugging problems is just as unfriendly. But I understand there can be a huge cost benefits during mass production.
Legend:
PHY: think of this as "wifi radio"
HT: "High Throughput" aka 802.11n
"Clause 20": HT PHY specification
"Clause 19": 802.11g PHY specification
"Clause 18": 802.11a PHY specification
"Clause 17": 802.11b PHY specification
STA: any 802.11 capable device
[[[
20.1.1 Introduction to the HT PHY
Clause 20 specifies the PHY entity for a high throughput (HT) orthogonal frequency division multiplexing (OFDM) system.
In addition to the requirements found in Clause 20, an HT STA shall be capable of transmitting and receiving frames that are compliant with the mandatory PHY specifications defined as follows:
— In Clause 18 when the HT STA is operating in a 20 MHz channel width in the 5 GHz band
— In Clause 17 and Clause 19 when the HT STA is operating in a 20 MHz channel width in the 2.4 GHz band
]]]
Translation: All of 11a/b/g are a proper subset of 11n.
11ac is 5GHz only. I assume it's backwards compatible to 11a but I haven't read the 11ac spec.
The real reasons are that 11a is still good enough for many use cases, and that OpenBSD's wireless developer department is seriously understaffed (apply by sending a patch).
Apart from reverse-engineering yet more hardware and writing more drivers, there is not much the OpenBSD project can do about this.
Fixing the root cause would be best. Vendors who do such things must be convinced to stop doing them.
If vendors also released freely available documentation for the hardware (read: freely accessible manuals for driver developers, no NDA required to read) then end users of free software could live in a world where wireless not working would be the exception.
I had this done during youth, never had it reapplied since, and so far, now heading towards my mid-thirties, never had an issue with my teeth. And, of course, I regularly brush my teeth about once or twice a day.
My dentist checks once a year to see how far the sealant has worn off. I could get it reapplied if necessary but not for free this time. I'll strongly consider paying up though when faced with the choice since this treatment worked out very well for me.
Their problems are rooted in abuse of power.
http://www.theguardian.com/world/ng-interactive/2015/nov/11/...
http://www.theguardian.com/world/ng-interactive/2015/nov/12/...
http://www.theguardian.com/world/ng-interactive/2015/nov/13/...
The attacks are horrible and a security system which effectively prevents them would be just as horrible.
This problem won't be fixed without a major shift in paradigm on either side. Perhaps not in our lifetime but oh how nice it would be...
Check the recent C-state work by guenther@. apmd and cpu freq scaling has recently been fixed for multiprocessor system.
But these things can take time to work on new machines. Unlike Linux and Windows, we don't get device drivers written for us by Intel employees in time for their product launch.
I wonder what answer you expect. A "yes"/"no" answer?
How could anyone answer this question in a meaningful way? How are people supposed to know what kind of performance you need, and for which application? How are people supposed to even judge whether the proposed reference point (Linux) performs well for you?
In the end, the best answer you'll get will always be "try it and see for yourself"...
Diverting ports builds to /home is a hack that works around the wrong choice made during install (which will invariably happen when you first start out, that's ok -- be prepared to reinstall with better parameters once you learn more about what you need).
Anyway, like it or not, in the OpenBSD community, working diffs, especially ones that fix a security issue, are the best way of winning an argument. You can try to blog about it but you probably won't be taken as seriously. So if you really care to convince the community from the outside and everything else has failed, and you can't code C youself, find a friend who can and ask for help.
If they don't reply after a few attempts, or give unsatisfactory answers, try mailing Theo. He acts as arbitrator in such situations.
If even that doesn't help, your last option is to write good fixes yourself, and keep submitting them as diffs to tech@ until you're either banned from posting to the list (at which point you should just give up) or your diffs end up being commited.
If library bumps happened, the packages might take a while to catch up, though.
What I do is I build a release with patches I'm interested in (my own or other people's). After upgrading my machines to that release I try `pkg_add -u`. If that complains about libraries, I just wait a day or two for a new set of packages to come out and try again. Sometimes I cheat and compile the missing library in a slightly backdated src checkout, or fetch it from a system that happens to have a copy of the right .so file.
If all that is too complicated, or if you want -stable instead of -current, try mtier.
The real problem is that the OpenBSD community didn't realise the state of things internally, because gilles and eric were trusted to not fuck up. This happens, since not everybody has time to follow every corner of the tree all the time. But when focus on a particular area is needed we can do it.
It's good that Jason pointed out these problems, however the manner in which this was done creates huge public exposure which puts pressure on all of us (especially gilles and eric) to produce results very quickly while we prefer moving slowly and being careful because that produces better results in the long term.
You can't really divorce UNIX from C.
The only other language option for an smtpd server in OpenBSD base would have been Perl, and I bet people would complain about that just the same.
And perhaps we wouldn't be able to review it properly if it was written in Perl. Perhaps Marc Espie could. But OpenBSD has plenty of people on the team who are well trained at auditing C.
I'll be doing my part and read some smtpd code during an 8h train ride tomorrow. I already read one file and found one bug in it and told gilles about it. That's how this works. Changing the language won't magically fix anything.
Essentially, vmm is to OpenBSD what KVM is to Linux. And yes, a KVM compatible interface can be built, as Mike mentioned.
And note that this is about system locales which mostly concerns libc APIs. Applications are still free to support additional character sets via other means (e.g. iconv).
For some problems a locale may not be the best answer. For instance, during these conversations I learned that Japanese android phones expose filenames as Shift-JIS which cannot be listed by ls(1) when the phone's filesystem is mounted in OpenBSD. In my opinion what's needed is not a system locale that switches everything to Shift-JIS but a translation layer which presents filenames as UTF-8 to the rest of the system. Perhaps a fuse filesystem module which links to libiconv in userspace to perform the necessary translation, and presents the result at an auxiliary mount point.
We have a hackathon coming up with devs committed to making UTF-8 work in more base utilities. If that works out, and the most sore points of latin1/koi-8/etc users have been adequately addressed, 5.9 will ship with only the UTF-8 locale (and of course the default "C" locale -- ASCII).
If this approach turns out to be wrong because we cannot get regressions fixed, 5.9 will ship like 5.7 and 5.8 (with UTF-8 and single byte locales).