3 ms·
Yesterday, out of sheer coincidence, I thought, you know what "lets check out OpenBSD again". Went to the homepage, saw the last 6.6 release was 6 months ago, a
by genr8 6y ago
Yesterday, out of sheer coincidence, I thought, you know what "lets check out OpenBSD again". Went to the homepage, saw the last 6.6 release was 6 months ago, and thought Hmm thats kinda old. Trawled around on the mirror sites to download it, and found version 6.7 files were there - a full day early! Not even timezones could explain it. Release date: May 19. So I downloaded it.
I made my first router with OpenBSD back in 2001, for a job, it was great! But I got fired for it, because the boss didn't understand how to use a command line...
I really love the OpenBSD documentation myself though.
And how the whole system is made a way that they want you to understand what its doing. And a certain nostalgia over all the familiar components that still feel the same. Its like a time machine. I was transported to the year 2001 when I made that first router all over again, or earlier. It has that familiar smell to it. Like a grandma cooking with the same recipe for 25 years. Initial Version 1.1 = 18 October 1995
Now I'm going to investigate using OpenBSD as a GUI desktop, but I have concerns about Xenocara/X11/Xorg/Xfree86, (idk what to call it) being insecure: root perms, keyloggers, etc. Can anyone speak on that ? Has OpenBSD been fixed itself, or is it still using the same flawed codebase. Are there plans to move to Wayland?
- gen3 6y agoI can’t really speak to the security of the desktop components, but I just wanted to chime in and say that I tried the same thing recently. I use KDE, and the version that ships on OpenBSD is old. From what I get, if you want KDE you use FreeBSD, and if you want Gnome you use OpenBSD.
- MintelIE 6y ago>I have concerns about Xenocara/X11/Xorg/Xfree86, (idk what to call it) being insecure: root perms, keyloggers, etc. Can anyone speak on that ? Has OpenBSD been fixed itself, or is it still using the same flawed codebase. Are there plans to move to Wayland? No, of course not. At this point no implementation is secure enough to compete with Xenocara anyway. OpenBSD isn't shooting to be a Linux desktop OS, so if you want Wayland, Pulse, SystemD, and the like you'll simply just have to stick with the fast-moving experimental OS's where they test new, unproven things like those listed above. Is there even any software for Wayland yet?
- floatboth 6y ago> Are there plans to move to Wayland? As far as I know, the difficulty on OpenBSD would be input. The Wayland world relies on evdev, so they either have to patch it to use their interfaces, or implement evdev. On FreeBSD, we have a lot of devices supporting evdev :) Including the next generation HID stack: https://github.com/wulf7/iichid https://github.com/wulf7/iichid (currently external, but would be merged into the system eventually) Also there's device discovery, for which we use https://github.com/FreeBSDDesktop/libudev-devd https://github.com/FreeBSDDesktop/libudev-devd to pretend to be udev, but I suspect the OpenBSD people might not like solutions like that :D (Actually, does OpenBSD even have anything devd-like that provides hotplug notifications?)
- genr8 6y agoVery helpful thank you. I believe you are correct on all fronts. Does anyone know if "their interfaces" prevent the Xorg/Xinput keylogger "bug" as is, even without EVdev or Udev? The man page seems like it does use Xinput, but it also mentions Xwayland https://man.openbsd.org/xinput.1 https://man.openbsd.org/xinput.1 So I think that if Wayland does work, that interface would take care of the issue. I am in the middle of something else or I would try and figure it out myself, but it would take a long time.
- floatboth 6y agoNo, the "xorg keylogger" issue has nothing to do with the low level stuff (evdev is how the windowing system gets info from the kernel, udev is how the windowing system enumerates devices and gets hotplug notifications). The "xorg keylogger" issue is a fundamental property of the X11 protocol, it's between the server and clients — all clients get enormous amounts of access to all kinds of global state over the X11 socket.
- asveikau 6y ago> Went to the homepage, saw the last 6.6 release was 6 months ago, and thought Hmm thats kinda old. OpenBSD has done a release every 6 months for ~23 years. I really don't understand comments around here where they look at a repo and say "hmmm, no updates in a while, it must be bad". There is really crappy software that updates frequently. It isn't evidence of anything. Many people are capable of committing total garbage every week, and this would satisfy your check. OpenBSD with its 6 month release schedule does pretty well by comparison with a lot of other projects. > but I have concerns about Xenocara/X11/Xorg/Xfree86, (idk what to call it) being insecure: root perms Pretty sure that X doesn't run as root on OpenBSD.
- genr8 6y agoI didnt say it was bad... I said, I was surprised given there is a 6 month schedule, that I randomly decided to check exactly 1 day before said schedule, and yet it was still secretly available. I don't think it runs as root either, I'm more concerned about xinput and keyloggers running as my normal user being able to snoop on even sudo/su prompts running as root in a GUI terminal window running as my user. You know about this right? https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html https://theinvisiblethings.blogspot.com/2011/04/linux-securi... Wayland was supposed to prevent this, but I don't think its going well on OpenBSD. Does OpenBSD have a solution for this?
- asveikau 6y agoAh ok. I misunderstood for a common comment trope I see around here. Apologies. Yes I am aware that it's relatively easy to write a keylogger for X.
- upofadown 6y ago>root perms My X server under OBSD is currently running as the _x11 user. >keyloggers I haven't heard about anything like that for X. Wouldn't any attempts to sandbox the ttys mess things that used them up in various ways? X is at heart a terminal oriented system. What are you trying to accomplish here? Normally it turns out that it is fairly futile to attempt to isolate tasks running as the same user from one another under the Unix security model.