notaplumber

notaplumberon Ask HN: What are some underrepresented open source projects that need support?

Of course there is some overlap.

Is there some place I can learn about this project? The website isn't very illuminating.

That's not likely to happen for both licensing and technical reasons. CDDL is not an acceptable license. And OpenBSD also has no extant framework for loadable kernel modules, nor any desire to add one (increasing attack surface).

OpenBSD doesn't support sendfile(2), which might account for performance issues in some cases, but certainly not twice as long.

Do you have a link to the bug report you undoubtedly filed when observing this?

https://www.openbsd.org/innovations.html

A lot more than just security-- albeit that is one of the primary focuses of OpenBSD, encompassing everything from researching new mitigations to secure coding practices.

If it helps to put things into perspective, NetBSD is closest relative to OpenBSD, the latter having forked over 23 years ago. The last time FreeBSD and OpenBSD shared the same tree was at Berkeley. In fact, NetBSD, FreeBSD and OpenBSD independently merged the final release from Berkeley, 4.4BSD-Lite2 in 1995.

Linux users generally don't understand what it means for each major BSD being fundamentally distinct operating systems, including separately developed kernels, drivers, userland utilities, with their own developer/user communities.

notaplumberon OpenBSD: pledge

No, it's a system call, not a wrapper utility. This is for developers, not users or sysadmins.

That doesn't change the reasons stated in the proposal email. Even if the final legwork was orchestrated by individual contributors, it's clear that the reasons were to appease corporations and not the community at large.

It would be unlikely for any open source project to begin such a massive undertaking to re-license, from an already permissive license, without at least some corporate incentive/initiative to do so. No doubt lawyers were paid.

I understand what you're saying, but it is also being disingenuous.

You're correct that were architectural reasons initially for why Apache httpd 2.0 not considered, but the license also played a significant role in later years, when it became obvious that Apache 1.3.x was showing its age.

nginx was initially considered, but the upstream wasn't receptive to patches that OpenBSD worked on, including a chroot(2) support and security patches, i.e: reallocarray to protect against arithmetic overflows. At the time, Nginx cared more about it's Nginx PLUS offering and less about the community.

> This is a complicated topic that deals with legal issues and our primary goal is to unblock contributions from specific corporate contributors.

You were saying?

http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536...

It's stated as much in the initial proposal.

"1) Some contributors are actively blocked from contributing code to LLVM."

> These contributors have been holding back patches for quite some time that they’d like to upstream. Corporate contributors (in particular) often have patents on many different things, and while it is reasonable for them to grant access to patents related to LLVM, the wording in the Developer Policy can be interpreted to imply that unrelated parts of their IP could accidentally be granted to LLVM (through “scope creep”).

https://www.openbsd.org/policy.html

This isn't a new policy. It's largely the same reason OpenBSD shipped with a fork of Apache 1.3.x for many years before ultimately writing their own httpd(8). The Apache 2.0 intertwines US Contract law with Copyright law, and that is considered wholly "not permissive enough".

"In addition, the clause about the patent license is problematic because a patent license cannot be granted under Copyright law, but only under contract law, which drags the whole license into the domain of contract law. But while Copyright law is somewhat standardized by international agreements, contract law differs wildly among jurisdictions. So what the license means in different jurisdictions may vary and is hard to predict."

Mark Kettenis' formal objection on behalf of the OpenBSD project: http://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.h...

Theo de Raadt: https://news.ycombinator.com/item?id=12617881

These objections have been largely glossed over by the LLVM community. It's no secret that a handful of corporations are pushing for this change, and not the best interest of the open source community. Especially the larger ones using LLVM, like *BSD. LLVM is already under a permissive BSD-like license (NCSA), as pointed out by jwilk: https://news.ycombinator.com/item?id=18700258

OpenSSL is similarly attempting the same thing with newer versions of OpenSSL, which they went about in a particularly legally dubious way: https://lwn.net/Articles/717996/ (For context, OpenBSD maintains LibreSSL).

[0] https://github.com/openbsd/src/commit/e688c2b0648a80551cf735...

And considering all the interesting work that OpenBSD is doing to Clang, i.e: retguard [0] [1], ROP gadget reduction framework [2]. Ignoring the fact that two major open source *BSD operating systems use and ship LLVM/Clang as their default system compiler. Their entire system compiled with clang, LLD as the default linker for an increasing number of supported platforms. A ports tree with between 10,000 (OpenBSD) to 30,000 (FreeBSD) ports compiled with Clang, maintaining patches upstreams won't take..

.. You might think that objection would be listened to more readily, or do the interest of a handful of corporations hold greater weight?

OpenBSD will undoubtedly be forced to fork LLVM 8, and likely have to take on the burden of asking individual developers to dual-license contributions they backport going forward. This will place them in a similar position they had with GCC, since the GPLv3 license change.

[1] https://github.com/openbsd/src/commit/9866f44de26a847eaed067...

[2] https://github.com/openbsd/src/commit/c0f0c565f0b312e55b410b...

Mark Kettenis formal rejection on behalf of the OpenBSD project: http://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.h...

notaplumberon FreeBSD 12.0 is now available

Can you explain what BBR is? Thank you.

I hand wash my dishes.

But yes-- I certainly do expect to be able to run a shell on any computer that I own. It's nice to hear that iOS devices are just another appliance for the affluent majority.

https://opensource.apple.com/source/xnu/xnu-4570.71.2/bsd/ke...

https://opensource.apple.com/source/xnu/xnu-4570.71.2/bsd/ne...

You will find RCS tags for OpenBSD/NetBSD/FreeBSD littered throughout the kernel source tree, some files even retaining original SCCS ids from 1980's CSRG days.

    $ grep -R "\$OpenBSD:" | wc -l
    24
    $ grep -R "\$NetBSD:" | wc -l
    138
    $ grep -R "\$FreeBSD:" | wc -l
    162
    $ grep -R "\$KAME:" | wc -l
    73
    $ grep -R "WIDE Project" | wc -l
    87
    $ grep -R "The Regents" | wc -l
    427
    $ grep -R "Berkeley" | wc -l
    919

This isn't "userland (POSIX) API layer + the odd device compatibility layer", far from it.

Don't presume to know who you're talking smack to, when it's clear you have absolutely no idea what you're talking about.

> Thing is, with pledge you never really know what the promises actually are, or if they make sense, in that you cannot work around them.

This makes no sense. Of course you know what the promises are, they're in the source code. You can also use ktrace/kdump(1) or even strings(1). The names of the promises are obvious and their intention is clear. There are subsets of POSIX.

> The assumption that with Capsicum you wouldn’t be able to sandbox stuff is blatantly false.

That is not what I said, I was specifically correcting your misinformed statement regarding pledge(2) and those programs that explicitly permit exec, like shells. Capsicum has no solution for this, and as such these programs cannot be sandboxed on FreeBSD.

Huh? FreeBSD has never included the Capsicum patches for chromium in ports.

Google not accepting this upstream is a separate issue, albeit regretful, OpenBSD maintains the pledge/unveil patches and users benefit from this work today, whereas FreeBSD users cannot run Capsicum-ised Chrome.

Capsicum patches are also considerably more intrusive, and their intention and protection is less clear.

> The difference is that while Capsicum provides you with very solid, ...

... That nothing uses. And even their flagship research example, Chrome, has never made it into the FreeBSD ports tree.

OpenBSD has pledge(2)/unveil(2) for Chrome.

This weak argument from FreeBSD people is getting rather tiresome.

You can only call fork/exec if it's part of the pledge(2) promises, which you can later drop with subsequent calls to pledge. And with unveil(2) or even chroot(2) you can also place further restrictions on which binaries can be executed, and in which directories.

Systems like Capsicum would have you not be able to sandbox those programs at all. Users are left unprotected. So yes, if you pledge(2) a shell. It can call exec, but directly it can't call socket/connect(2), and the reduction of kernel attack surface is still significant. Software using privilege separation can safely leverage this.

That's interesting, indeed-- it is unfortunate that developers have no ability to circumvent these restrictions even for local development.

It makes owning such a device even more baffling, sounds incredibly useless to me. I didn't know iOS was such a trash fire.

And Mach was a modified 4.2BSD kernel adding microkernel aspects. It was literally written as a drop in replacement for BSD.

The kernel also includes code from BSD, source is available, including from FreeBSD/NetBSD and OpenBSD. For example, the network stack is BSD code. It also includes OpenBSD's pf(4).

For example, there was a recent ICMP vulnerability in XNU, that later affected FreeBSD. So please reconsider posting misinformation in the future.

I feel like I'm a bit out of the loop here, getting a local shell on an iOS device was one of the immediate benefits from Jailbreaking. It was even a native iOS binary, usually bash or Korn Sell, along with sshd. No need for such an elaborate Linux ABI transposing layer, as the iOS kernel supported enough Unix to run this stuff fine. But even if the iOS SDK/libc has since dropped certain functions or POSIX headers, the kernel undoubtedly still supports it.

If this software could be developed and installed, cross-compiling a native Unix toolchain, either from the open source code distributed by Apple, or the BSDs, or even GNU, should be just as easy to pull off.

So what gives?