notaplumber

And it's just a port of the kernel wg(4) driver from OpenBSD, which was contributed by the Wireguard developers. It shipped in the OpenBSD 6.8 release in October. FreeBSD hasn't included it in a release yet.

https://svnweb.freebsd.org/base?view=revision&revision=36816...

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

If you want a great firewall, try OpenBSD. That's where pf(4) came from, and is actually maintained. Not even FreeBSD has an up-to-date version. Also despite being the basis for the success of their product, and in their product name, pfsense/Netgate and its CEO "gonzo" have been actively hostile towards to the OpenBSD project and developers for many years.

https://www.openbsd.org/faq/pf/

Very recently as well. It's nice to see some rapid progress, certainly coming together. Good to hear the Ethernet is working on the M1 Mac Mini. Do you happen to know what device it is?

Very few drivers have been written, beyond handling low-level SoC stuff. The ones that have been are explicitly mentioned in the linked article, stuff like USB which leverages existing Linux code.

No keyboard, no trackpad, no GPU drivers (besides an unaccelerated framebuffer, setup and left by iBoot). There's some indication of Wi-Fi support, as it's a Broadcom FullMAC device (brcmfmac on Linux). But yeah, I'd say unusable without a USB hub and a myriad of external devices. Again, said as much in the article.

So no then.

Is it encrypted by default yet?

KVM is the kernel virtualization module on Linux, QEMU handles the userland side support, all device emulation. The kvm binary on Linux is equivalent to running qemu-system-* with -enable-kvm. Newer versions of QEMU also support the '-accel kvm' argument but also adds other acceleration backends, such as '-accel tcg' (slower), '-accel haxm' (Intel/Windows), and finally '-accel hvf' for Apple's Hypervisor.Framework. This work here is extending that existing support from only Intel VT-x to also cover ARM Silicon, factoring out common code and API differences made by Apple.

This project is certainly covered under the Ancient UNIX licences.

"Later, in January 2002, Caldera International (now SCO Group) relicensed (but has not made available) several versions under the four-clause BSD license."

https://en.wikipedia.org/wiki/Ancient_UNIX

Nobody is going after a v7 Unix port, the sources for ancient Unix are widely distributed on TUHS (The Unix Heritage Society, tuhs.org) and such.

Another option might be pkgsrc, I'm sure someone's already looking at it.

https://www.pkgsrc.org/

File descriptor passing has been a common technique used in privilege separated design, used quite extensively in OpenBSD software. Other notable examples include Google's Chrome browser. It's quite telling how it's not mentioned once in this article.

Combined with OS security features like pledge(2) on OpenBSD, which has separate sendfd/recvfd promises, and unveil(2), an unprivileged process can have its access to the filesytem and other system attack surfaces (system calls, ioctls) removed completely or restricted and only be able to act on file descriptors passed by a privileged parent.

https://man.openbsd.org/pledge.2

https://man.openbsd.org/unveil.2

A skeleton example of a common style for OpenBSD privsep daemons, which uses 3 processes

https://github.com/krwesterback/newdctl

https://github.com/krwesterback/newd

This uses OpenBSD's imsg(3) API, an abstraction around the underlying Unix sendmsg/SCM_RIGHTS functionality, along with other IPC abstractions.

https://man.openbsd.org/imsg_init.3

https://github.com/tmux/tmux/blob/master/compat/imsg.c

https://github.com/tmux/tmux/blob/master/compat/imsg.h

AMDGPU It was significantly larger than the entire OpenBSD kernel sources. The dev/pci/drm directory ballooned to around ~130M. As of 6.8/-current, it's now 191M. It was under ~20M before May of 2019, prior to it first being committed.

This driver is I believe part of the common codebase that AMD upstreamed to the Linux kernel, it's shared with its proprietary driver on other platforms.

Browsers having unfettered access to users files is something which should be mitigated against on all platforms, not fleshed out into an ill-conceived feature, it goes in complete contrary to browser sandboxing efforts in Chrome itself for different process types (renderer/gpu/utility), but also work like OpenBSD has done with pledge(2)/unveil(2).

On OpenBSD, all processes of chromium, including the main browser process are tightly pledged and unveiled by default, write access to the users home directory is limited to only a few paths (~/Downloads), and a few config directories. As a consequence, users are rather forcibly taught safer usage pattern of copying files into the unveiled paths when uploading, which as Bob Beck alludes to in his slides below, is a reasonable compromise to every website having access to your ssh keys.

https://www.openbsd.org/papers/bsdcan2019-unveil/mgp00022.ht...

https://github.com/openbsd/ports/tree/master/www/chromium/fi...

Precisely. OpenBSD developers have committed John's diffs.

Contributing to OpenBSD, not committing. He is not a committer.. yet.

> I believe the best chance we have of doing that, is by gluing together the binary interfaces that've already achieved a decades-long consensus, and ignoring the APIs.

Yeah, this isn't going to fly for OpenBSD, which doesn't have ABI stability, programs are expected to use libc. Program for the API, not the ABI. The author is clever, but misguided.

Sorry, poor choice of words I guess. I mean it's embedded within the filesystem. If you had root or serial access to the device, then you could probably very easily replace it, but at that point you could also just write the firmware anyway. The checks are only important for flashing via the Web UI.

I think they were replying to me about the Linksys/Cisco routers, but it is similar in that the public key is contained on the filesystem and prevents flashing any firmware not signed with it. What's worse is they added this after the fact to several models in later firmware versions, making it impossible to downgrade to older unsigned versions.

Unlike with yours, no decryption script is required, gnupg can decrypt them as-is.

At least a few models of Linksys/Cisco home routers I own had their firmware "encrypted" using GnuPG. They had the extension .gpg.img but could simply be decrypted with:

$ gpg --output decrypted.img --decrypt <model><ver>.gpg.img

binwalk can handle the rest.

It looks like they mainly did this for verification, as there is an RSA public key embedded on the device. It unfortunately does make it nearly impossible to flash any modified firmware such as OpenWRT, which is very frustrating. I say nearly as I haven't fully investigated the models that I own. Some routers have a emergency recovery flash method that may bypass the PGP check, I recall older D-Link models having a web flasher integrated into u-boot.

Nope. It's in the article. Just insert the key and ssh-add -K. I wouldn't be surprised if other SSH agents (e.g. Apple) added a UI to do this.

You can, that's exactly what resident keys in this article is referring to.

Once all of those platforms have a more recent OpenSSH, you can ssh-add -K to add keys to your SSH agent.

You still do?

EDIT: I see it now.

This is simply not true. For a lot software you will get 1.3 automatically, for example mutt and irssi pick it up just fine. The existing APIs will work and LibreSSL will prefer TLS 1.3 over 1.2 if clients/servers support it.

OpenSSL offers some additional APIs for certain TLS 1.3 features, but are hardly mandatory.

To those wondering, LibreSSL has its own TLS 1.3 implementation. Client support shipped in LibreSSL 3.1.1.

https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.1.1-...

https://www.openbsd.org/papers/bsdcan2019-tls13.pdf

Yes.

https://github.com/libressl-portable/portable/issues/595#iss...

Saying something is pledged has a very specific meaning. And in this context, has no relevance to the discussion as none of the perl components in base make use of these bindings.

No it's not. It has language bindings for pledge(2), which is different. There can be no one size fits all pledge for an interpreted language like perl, as programs can make arbitrary calls to anything they want. But those programs can use pledge, as long as they consider the requirements of the runtime itself.

http://man.openbsd.org/man3p/OpenBSD::Pledge.3p

Yeah, this confuses me. Gigabit is available in several places in North America. I had to check the date on the article.. posted 20 hours ago. Yep. Still confused.

This type of separation would be better served with having multiple chrome user profiles. Like one for "work" and one for "home".

Indeed, that part is accurate. It would be technically interesting if the tech demo was a part of UE5 source release. I'm not familiar if they've done that in the past.

UE5 is not open source, it is shared source or "source available". Assuming it follows the model of UE4.

https://en.wikipedia.org/wiki/Source-available_software