I appreciate you pointing this out. While it's okay to "steal" art style towards developing one's own, it also feels great to attribute credit to the source of inspiration. None of us are anything without those who came before.
I don't think that they "stole" it. Just a nice tribute to the artist that also fits the theme. I am a fan of Louis Wain's work and just felt like sharing.
On the Linux side these are called "vti" devices, and they're simpler to use than most other methods, and also the default when interacting with cloud service providers IPSec gateways.
What’s up with this seeming resurgence in interest in IPSec? Did Jason politically/socially mess up? Or are people realizing IPSec solves some novel problem outside the scope of WG?
I think it's great there is new attention to OpenBSD's IPSec stack. IPSec is still widely used and is the defacto VPN tech for many large corporations, even if wg is simpler and easier to deploy. IPSec tends to be built-in to enterprise routers, but I'm not sure if wg is.
I think VPNs for general use are just increasingly popular as many people have privacy concerns, many governments are interested in or actively regulating internet speech, getting around geoblocking and copyright restrictions, etc. (not to mention, very aggressive advertising by commercial VPN providers). Remote working has probably increased use as well.
IMHO they really need a two-step release process for changes to pf.conf syntax. In the first step you get a warning when running the service about a deprecated syntax, then drop it. Over the last 20 years I’ve been bitten multiple times by changes to pf.conf which not only breaks your firewall, but invalidates entire published books on pf, countless articles, tutorials, etc.
I read some quote from the BDFL once where he said something about breaking changes being good because you’re “in a better place” but I feel the BC breaks are too aggressive to rely on pf directly in anything but small commercial applications. If you want to to tinker and break your home network fine.
This is why the upgrade guide says to actually read the changelog; they tell you the changes. I've only been bitten once, and it was because I didn't read first.
>> Read through and understand this process before attempting it. For critical or physically remote machines, test it on an identical, local system first.
>> Read configuration and syntax changes and the package upgrade instructions. There were several configuration changes and changes in packages that may require planning before starting the upgrade.
For OpenBSD at least, every release has equal weight and always increments by 0.1. There isn't a distinction between major and minor releases like other projects have. There are patches/errata, but those don't bump the version.
Theres a reason they call it an system upgrade, and not a patch or update. Blindly upgrading anything important without rtfm is just plain irresponsible, yet OP has used openbsd for 20 years and keeps making the same mistake over and over; typically you don't do that.
I still miss buying CD sets. I understand why the project doesn't do it anymore (lots of effort and time, similar to why VAX was dropped), but it sure was fun getting them in the mail and using official discs to install.
OpenBSD supports Ubiquiti's octeon processor. I thought it would be neat to run my router on a non-x86 CPU, but I don't have personal experience with these boxes yet.
I'm curious to hear others' answers to this question as well. I've been looking into building my own OpenBSD based home router and so far thinking a Protectli Vault [1] would fit the bill.
I was recently looking at some Banana Pi boards, but I'm not sure if any of them other than the R1 will run OpenBSD. HardKernel's ODROID-H3 is tempting, but the cases are not great looking.
I ran such a topology for a while, aka "router on a stick". I had a two-port trunk link to a cheap Cisco small business switch, it worked great. It could also have been easily virtualized with a single virtual NIC, but I don't like virtualizing my router anymore, hah.
It should be completely possible using only the official install media, then and now. To do this today, download the AMD64 install74.img (like an ISO, but for flash media), write the image to a USB disk, connect to the APU1/2 via serial, plug in the drive and power up the APU, then follow the installation script.
Once booted, run fw_update and syspatch to make sure the firmware and system is up-to-date.
I love how OpenBSD continues to support and fix issues on a wide variety of hardware. I personally run it on various machines, from Pentium MMX (1997), AMD K6-3 (1999), to modern machines. 486 support was dropped just a couple releases ago, and was supported longer than VAX.
> Fix a bug in the handling of SCSI drives in the bootloader on the luna88k architecture.
> Correct undefined behavior when using MS-DOS filesystems, fixes imported from FreeBSD.
> On arm64, use the deep idle state available on Apple M1/M2 cores in the idle loop and for suspend, resulting in power savings.
> Update AMD CPU microcode if a newer patch is available.
OpenBSD has a reputation for being super secure but are there any big organizations that actually use it for security critical applications? A quick search shows outdated or non-related results.
I've seen it used before commercial security/networking appliances got "good" (generally pre-2010ish), but I think its use has diminished. I was a huge OpenBSD user back then as the networking (routing/firewalling/etc) was so simple AND powerful. I stopped when screenOS and later Juniper matured to the point where updates were just uploading firmware and hardware upgrades were just dumping the old configs in.
I knew it was deployed at a few non-tech oriented fortune 500 companies (eg not banks or tech firms) as last as 2016, but I've been out of that market since.
It's like a scene from some movie, there's a hacker in a dark room, connects to some machine deep inside of mega corp and the login prompt comes on screen...
Connected to 123.4.002.312
Welcome to OpenBSD 6.2!
login:
Hacker: Dammit, it's an OpenBSD system. We'll never get in!
OpenBSD is secure in the default install; it's just that their default install has basically had everything turned off since forever.
Mind you, that was a great improvement over things like Windows NT, but "this is super secure as long as you don't do anything with it" is not as incredibly useful as it sounds like at first.
I like having to install the things I really want, which gives me a chance to consider the security implications of them, instead of having many things pre-installed and I don't know what the total risks are. And nothing else I know of has gone since ~1996 with only 2 of the worst kind of security holes (i.e., remote exploit of something I didn't even need, but was installed by default).
In the base install are many useful things (including a web server IIRC, though the port is not exposed by default), and those are audited and have that excellent track record.
Then when you install extra things, they are usually limited by what user they run as, and usually have pledge/unveil run (limiting access to predetermined/approved syscalls and parts of the file system) so they can't break other things if compromised.
I have read that many security innovations [1] get implemented in OpenBSD soon, like W^X [2]. But I don't know enough about OpenBSD and I would like to hear as well if any organization uses it for mission critical applications.
Given the world runs on Linux servers, its pretty obvious that is probably the most secure.
Outside black boxes like M$ and Apple, FOSS OS level seems quite secure. How often do you see Linux malware caused by OS in the wild? Sure you install wordpress and never update it and get a cryptominer installed, but its not like anyone is pinging a server with a picture and an overflow error is causing a Pegasus exploit.
Actually it makes their point. Linux is super widely used, meaning it has millions of eyes on its codebase and it's a very high value target for both attackers and security researchers. OpenBSD is just a LOT less used, meaning that there might be latent security problems that no one bothered to uncover. It's very easy to have less CVEs when you are used less, that's why I have some doubt about the "secure" reputation it has.
High quality code reduces instances of vulnerabilities, which is great. But code vulnerabilities are only one of the many factors in assessing security.
To be considered a secure operating system, you need to have more mechanisms in place to protect against various threats, and the OBSD developers actively resist that. I'm familiar with their innovations and solutions, and I think they fall far short.
> Packets sent over loopback got their checksums calculated twice.
In the output path they were filled in and during TCP/IP input all
checksums were calculated again to be compared with the previous
result.
Avoid this by claiming that lo(4) supports hardware checksum
offloading. For each packet convert the flag that the checksum
should be calculated to the flag that it has been checked successfully.
Keep the flag that it should be calculated for the case that it may
be bridged or forwarded later.
A drawback is that "tcpdump -ni lo0 -v" reports invalid checksum.
But that is the same with physical interfaces and hardware offloading.
https://news.ycombinator.com/item?id=37899319