hachyderm.io is one of the many independent Mastodon servers you can use to participate in the fediverse.
Hachyderm is a safe space, LGBTQIA+ and BLM, primarily comprised of tech industry professionals world wide. Note that many non-user account types have restrictions - please see our About page.

Administered by:

Server stats:

8.9K
active users

#openbsd

108 posts89 participants5 posts today
Replied in thread

@torproject @ZDNet TBH, I'd always recommend people to use @tails / @tails_live / #Tails if they want a secure and private OS.

  • Shure in theory one could do more #secure with #OpenBSD, but that's neither easy to use for non-#IT-folks nor easy to onboard people into.

Tails by contrast just comes with #TorBrowser, @thunderbird and other nifty tools preconfigured from the get go and allows people to get started, regardless if it's a #journalist or someones' grandma who may not have her own dedicaded machine but instead uses an external SSD/HDD to just boot into her desktop and not rely on the #malware-laced #Internetcafé's #Windows installation...

Not to mention it avoids a lot of #pitfalls that other distros like @kalilinux will deliberaltely keep open because their goals are diametral to that.

Replied to Jadi

@jadi This "#OpenBSD is secure!" claim always annoyed me a lot, mainly because it doesn't tell anything: #Security in IT can only ever be defined in a context of #threat models. Without that, it's meaningless. Somewhat recently, I discovered this:

isopenbsdsecu.re/

I should warn it uses some sarcasm and other confrontative language in some parts, unfortunately. But it seems to be a pretty professional analysis and assessment of (mostly) the "mitigations" OpenBSD provides in an attempt to counter "typical" attacks by at least making them harder.

I should also add that I consider this a very interesting and helpful read, and still consider OpenBSD a great project that came up with lots of great stuff (I recently used their #bcrypt code after doing some research on password hashing, for example). And I don't agree with every single criticism on that page either. I just think it's important to build assessments whether something "is secure" on a serious analytical foundation.

isopenbsdsecu.reIs OpenBSD secure?

Running #openbsd or #linux with ~native CPU speed on macOS using #qemu

qemu-system-aarch64 \
-machine virt -cpu host -accel hvf \
-m 2G \
-drive file=edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on \
-drive file=edk2-arm-vars.fd,if=pflash,format=raw \
-drive file=disk.qcow2,if=virtio,format=qcow2 \
-audio coreaudio,model=virtio \
-monitor none \
-device virtio-gpu \
-device qemu-xhci \
-device usb-kbd \
-device usb-tablet \
-cdrom cd77.iso

mnvr.in/linux-qemu

mnvr.inRunning Linux using QEMU on macOS | mnvr.inARM64

un dia perdido (no en realidad porque estoy aprendiendo) no pude instalar #openBSD en dos net del gobierno, y la net que pude instalar (una olivetti con atom tambien y 1g) se me rompio el boton de prender y fue, tendré que desarmarla y veremos si vuelve arrancar....

OpenBSD boots and works - but it seems the trackpad isn't moving. I'm sure I can fix it as it's correctly detecting it, but I'm now testing FreeBSD.
It immediately throws a kernel panic, but this seems to the the problem:
bugs.freebsd.org/bugzilla/show
So, 15-CURRENT boots and works. I'll probably burn a 14-STABLE usb pen and continue with that.

bugs.freebsd.org274014 – hmt.ko kernel panic - Asus Expertbook B5602

The easy solution is just to use Tailscale. But I am setting up my own #Wireguard mesh network.

There are scripting languages and/or configuration management systems which can help here!

Working on my Wireguard Mesh Network generator here: codeberg.org/snonux/wireguardm and for the first time, it works (generating a Wireguard full-mesh network across 8 hosts and 3 Operating Systems (#FreeBSD, #RockyLinux #OpenBSD)).

Will blog about it soon (as part of my f3s series: foo.zone/gemfeed/2024-11-17-f3)

Summary card of repository snonux/wireguardmeshgenerator
Codeberg.orgwireguardmeshgeneratorMesh generator for https://foo.zone/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.html

Let me introduce you to aceBSD! Yesterday, while I was out grocery shopping, I saw a special offer on a final unit, and I had already been thinking for a while about getting a mid-range laptop to take with me to conferences, on trips, etc. Something small, practical, with an HDMI port, and capable of running at least one of the BSDs decently. After some careful thought, I decided to go for it today.

It's an Acer Swift Go 14 - with an Intel i5, 16 GB of RAM, and a 512 GB NVMe SSD. What I really like is that it’s compact and has a high-definition OLED screen, a good keyboard, and for the rest... we’ll see. I just used Clonezilla to make a backup of the preinstalled Windows (I didn’t even boot into it...) and I’m now installing OpenBSD. I had to disable VMD (from a hidden BIOS menu) because otherwise the installer wouldn’t detect the NVMe. It also seems to detect the Wi-Fi, but I’m proceeding with a USB-C Ethernet adapter just to be safe.

I got it at a good price, so this could be the ideal solution. Fingers crossed, and… we’ll see!

I'll keep posting about this adventure, with the hashtag #aceBSD

#OpenBSD -current has replaced its own aging (freedesktop.org compatible) pkg-config(1), originally written in Perl by ckuethe@, espie@ & jasper@, with the more modern and actively maintained pkgconf implementation.

tb@ modified src/usr.bin/pkgconf/*: import pkgconf 2.4.3

Our homegrown Perl-based pkg-config cannot cope with the giant DAGs [Directed Acyclic Dependency Graphs] arising in modern software, especially from the abseil-cpp and protobuf family. Waiting minutes for configure to complete in some ports is just awful.

Thus we're switching to the sanely-licenced, widely used pkgconf, which is actively maintained, written in a sensible dialect of C, and does not suffer from these performance issues.

Work that should happen in tree during this cycle:

  • see what we want to do with our old manual and pkgconf's
  • add pledge and unveil.

Initial work done by espie during or right after p2k23, support from many.
ok semarie

The old pkg-config implementation has now been unlinked from the build, but not yet removed from the tree.

tb@ modified src/usr.bin/Makefile: switch from pkg-config to pkgconf

leave the old pkg-config in the tree for now.

#sydbox-3.33.0 is released, This work continues the sandbox category rework: "rmdir" category is now split from the "delete" category and the #landlock categories have been refined to be more #openbsd #pledge like. The tool syd-lock also got a rework so landlock categories may be used with that too while the old, easyinterface is still available so your scripts will not break! See the release announcement for more information: is.gd/eVxsBt #exherbo