I am not sure if memory-safety is the biggest issue in sudo design. I find the fact that it is a setuid binary a much bigger issue because a bug can possible result in privilege escalation.
I found an alternative implementation that doesn't rely in being a setuid binary like systemd-run0 much more interesting from a security perspective, but I am no security expert.
Right, but now the vector for privilege escalation will have to be a logic bug in memory-safe sudo instead of either a memory corruption (see CVE-2021-3156) or a logic bug. It’s hard not to see this as a major improvement.
Being a setuid binary means that sudo also suffers from
attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate. Depending on how sudo authenticates phishing attacks or password reuse from another breach can be used to escalate privileges.
Why not? The way Windows does it should work in theory I think?
Maybe you can't realistically do it on Linux, because Linux doesn't care about desktop security and doesn't have the kind of privileged GUI that you need.
Windows is a bit different I suppose. Many pieces come together to make it kinda work there.
* Privileged gui to display and approve what will run as you mentioned. In Linux, non-privileged gui is used to request permission to do... something.
* Executable verification. Let's say someone with user level permissions swaps out the program you wanted to run for a malicious one. The replacement would not pass certificate checks which would be revealed in the privileged gui. Maybe you could supply an old version with known vulnerabilities though idk?
* Kinda commandline parameters verification. In Linux-land you can pass parameters to the program those could be intercepted with user-level permissions. In Windows this would be displayed in the privileged gui. However! The parameters are only visible if you click "show more" which I would guess <1% of people actually do.
As an example of the last point I tested making a shortcut to cmd.exe and used Run As Administrator. Then I changed the shortcut to C:\Windows\System32\cmd.exe /c calc and again did Run As Administrator. Opens calculator instead of command prompt with identical approval gui (except with show more).
The way Windows does it is users are prompted to elevate permissions, and can be tricked into clicking "Yes," just like users can be tricked into using sudo.
But the entire threat model we were discussing was that the user might be tricked:
Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate
That's why the OP said that's not an enforceable security boundary. If the user is capable of attaining superuser privs, you can trick them, regardless of how attaining those privs is implemented.
Going back to the topic of the discussion, making sudo more resilient prevents a whole class of possible bugs (see CVE-2021-3156). You may not like sudo, but it is very commonly used to manage access, prevent accidental errors, or improve accountability on Linux servers and workstations. It is not going away. Therefore, improving sudo is a worthwhile goal and a thing to be celebrated.
>sudo more resilient prevents a whole class of possible bugs
Good, but this doesn't fix the easiest way to escalate privileges as an attacker through sudo. Memory safety doesn't help people who run "curl | sudo bash" to install a random program from the internet.
>It is not going away.
But if work is done it could become very niche and eventually stop getting new usage over time.
> help people who run "curl | sudo bash" to install a random program from the internet.
I don't think you can help those people, unless you seriously lock down the machine to the level of iPhone. Neither Android nor Windows have "sudo" for example, and yet they can get malware just fine... all the difference is instead of the password, user clicks on confirm button a few times.
I advice to (1) think about how you use sudo (2) think what would you replace it with and (3) think how the replacement can be abused by malware.
Here is one example:
(1) Today I used "sudo" to run docker: "sudo -Eg docker docker run..."
(2) the sudo-less replacement would be to add myself to docker group, or switch to rootless docker
(3) If I add myself to docker group, malware can trivially escalate by starting a privileged container. If I switch to the rootless docker, I am weakening security boundary between my primary user and the docker containers I run.
how do they solve sudo's problems though? Exchanging "sudo" with "require-root-capability" or "start-privileged-session" will still have many of the same logic problems.
Unless you mean something like "capabilities are always inherited, and there is no way to increase them", which would mean that sudo-like scripts are impossible, and you need to start all-new session as root user for admin actions. Good news, it's already possible in linux - just don't install "sudo", and maybe set up SELinux to disallow all escalation. Turns out no one wants to do this though.
there's no god-mode who can do everything. there's no universal kernel level. micro means only minimal things happen in the kernel or at root level, like routing messages.
even windows understood that those times, when they did split Administrator from System. linux followed then with system users for certain services.
but capabilities only allow certain calls at certain times. there's no setuid 0, only cap this and cap that for this admin user for a certain time range.
BTW, SElinux is the default on a proper linux like Redhat. I use it daily. I also have to adjust the ssh caps, not just the firewall settings. Everybody wants that, just not the debian nobs.
There is omitted detail here. Capabilities are a great way to determine access control (IMO, they are essential in general as a user-facing model too). However, that still leaves the question of who gets what capabilities. For the network service to be able to hand out network capabilities, it itself must have at least as much authority, and it had to get that authority from some other source of capabilities. There must be some privileged component that forges all capabilities, and actually distributes enough authority to make the system usable. For example, as soon as a human user becomes relevant, the system's user-avatar must be able to command authority, in a way that may seem sweeping. This could mean directly or indirectly changing which program is the network service, which means the ability to influence all networking activities, which is no small authority.
An agent logically has all the capabilities necessary to do what the agent should be able to do. The sum of capabilities of an agent indicates "the worst that can happen" if the agent is malicious. It makes sense that if a network service is malicious, all networking activities can be subverted. Still, the storage activities shouldn't be subverted, and of course the network service wouldn't have the storage service capability. However, if a user is malicious, anything could go wrong that the user is normally trusted to not make go wrong. Correspondingly, the user must have an expansive sum of capabilities.
Capabilities are themselves simple, but that is the mechanism perspective. Access control policy is an entirely different beast, and any mechanism at best minimizes the risks.
This all sounds very reasonable as long as servers/services are involved. Linux has capabilities for this purpose, and systemd goes a long way towards the vision you describe - daemons which do not need root and instead get all capabilities from the supervisore process.
However, were were talking about "sudo" and this is purely interactive tool (I am sure some people run sudo non-interactively, but we can all agree it's a bad security practice). So, how does this nice capabilities vision mesh with the idea of "administrator user"?
From what I see, it's not much different. Instead of "sudo" which verifies user identity+permissions and then gives out "root" or some other user, we have some other hypothetical tool ("become-admin"?) which verifies user identity+permission and gives out powerful system-changing capabilities. Frankly, I don't see much difference - it's the same security model either way.
(A related argument I've seen is "you should not need sudo for common tasks like update software or configure network" - but on modern Linuxes, you don't need sudo for that already, this is done via dbus + polkit calls. No "proper microkernels" required, that is already deployed everywhere.)
Design the system so that you do not need users to escalate to root. Find each use case where a user may want to use sudo and then come up with an alternate way to accomplish that action from a regular account.
That would just elevate each regular account to be a root account. There is no other way to make things like modifying files directly under / possible, or to change system configurations. You can lock everything down instead, then you have Android, but then you have certainly not enabled everything a user can do with sudo.
Sounds like you don't want a Linux system, but rather a Chromebook. Have you seen https://chromeos.google/products/chromeos-flex/ ? Install it on your computer and you get Android-like security model, including only verified software and lack of "sudo" or any sort of root access.
A Chromebook is a Linux system. My concern is with Ubuntu improving their security posture. Telling Canonical to give up on Ubuntu and switch everyone over to ChromeOS is not something that I predict would work.
And system updates don't need sudo on desktops, it is not 1990's anymore... GUI apps like software-properties-gtk use dbus with polkit auth to upgrade software without any involvement of "sudo" or giving root access to users.
Using GNU/Linux at all is. Choosing to use such an operating system and then also choosing to do your updates from a terminal emulator is even further off the beaten path.
The beaten path is the defaults. Windows and MacOS particularly.
>"Being root" is just another name for the last option.
No, it's not. Take for example ping. If we want users to be able to always be able to use ping does that mean they need to be root? No, it doesn't. A privileged part of the OS can handle doing the raw socket and the unpriviledged user can talk to that part of the OS.
The key point is that some operations that require privileges are okay to expose to a user, but giving the user privileges for everything is dangerous.
I think the opposing view is that moving away from sudo is substantially more effort and would break basically everything to accomplish "the same" thing as robustifying sudo (for some very loose definition of "same")
I don't see how this attack is related to the setuid binary. No matter what method you provide to the user to elevate their privileges, they can be tricked into doing it. If it was provided by a daemon, built into systemd, or anything else, the problem would be the same.
There's value in always starting processes from a known-secure environment rather than attempting to transform a user's arbitrary environment into a secure one.
How is that any different than a daemon that has a parser error in its message handler, except that the daemon could be misconfigured to listen on a network socket?
The original unix process abstraction was extremely simple; the entire spec is a few pages.
The problem is that Linux keeps adding more and more levels of Rube Goldberg machine to its security model, so now literally no one understands how a default minimal install of, say, Ubuntu works.
Adding a magic daemon that runs stuff as root to this pile of complexity probably won’t help. Ripping out almost all the cruft that’s accumulated over the years, and adding back something sane (maybe BSD jails) would work a lot better.
Assuming static linkage (which sudo has to assume), there’s really not much to parse. It should just be dealing with a null-delimited list (argv) and the caller’s environment variables (which it just needs to ignore and clear by default).
(Though it doesn’t clear the environment unless I’m missing something - they should probably replace the call to execvp with one to execvpe, and add a null pointer to the end of the argument list).
The problem of setting up root’s environment and parsing the command line is left to the shell in both solutions (the thing I linked doesn’t indirect through a root login shell).
There’s also the config file, but that’s the same for both.
Similarly, the system could be running some SEL derivative or be using a capability system that causes non-standard behavior from system calls, but the daemon has the same problem.
So yes, I am not saying that privilege escalation bugs are impossible if you have a different architecture, but like Lennart argues is that it makes them much more difficult to happen, especially because creating a proper setuid is difficult. Also there is a bunch of things that makes sudo especially tricky to implement correctly.
I apologize, I do not bookmark these issues, but maybe I should start doing that? In any case, you will find logic bugs which may raise the question "is it really worth the rewrite?".
Not universally, but often it introduces logic bugs that the original project did not have. I guess it heavily depends. In this case, I think it may do more harm than good. Just use "doas" or something. FWIW, I trust "sudo" more than "sudo-rs".
> This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components. Sudo-rs is developed by the Trifecta Tech Foundation (TTF), a nonprofit organization that creates secure, open source building blocks for infrastructure software.
Ubuntu continuously updates itself without permission, killing apps and losing previous state. You have the Javascript based Gnome window manager that is always bugging out. The Ubuntu packages, drivers and kernel are laughably behind Debian and even further behind mainline. Ubuntu continues to morph into something I don't believe in.
That all said, Rust is not a smoking gun for incorrect application logic. It could still happily incorrectly execute stuff with the wrong permissions or blow something up badly. I think it's also a bad idea to offer it as a drop-in replacement when clearly features are still missing since a long time [1].
> That all said, Rust is not a smoking gun for incorrect application logic. It could still happily incorrectly execute stuff with the wrong permissions or blow something up badly.
This side steps the issue which is "Does Rust help you make software more correct?" No one is arguing that Rust is perfect. There are plenty of bugs in my Rust software. The question is only -- are we better off with Rust than the alternatives?
> I think it's also a bad idea to offer it as a drop-in replacement when clearly features are still missing since a long time [1].
Your example is the Github issue page?
Look -- I agree that, say, uutils/coreutils missing locales may frustrate some users (although I almost never use them). But "close enough" is more the Unix way than we may care to realize. But especially in this instance, because sudo is not POSIX (unlike locales which are). A distro is free to choose any number of alternatives.
Ubuntu wants to lay claim to "the Rust distribution" and it's hard to blame them when Linux wants to lay claim to "the Rust kernel".
> This side steps the issue which is "Does Rust help you make software more correct?" No one is arguing that Rust is perfect. There are plenty of bugs in my Rust software. The question is only -- are we better off with Rust than the alternatives?
There is a lot of embedded knowledge in existing implementations, Rust deals with just one small class of bugs but drops a lot of this knowledge in the process.
I would generally be in favour of just introducing better memory management to C/C++ and hard enforcing it in particular repositories.
> There is a lot of embedded knowledge in existing implementations,
Agree. The question whether to rewrite and/or whether to use any new implementation should take this fact into account.
> Rust deals with just one small class of bugs but drops a lot of this knowledge in the process.
Hard disagree. Rust explicitly deals with several very important classes of bugs (memory safety and concurrency), and also aids correctness via other helpful design features like tagged unions and immutability by default. But Rust, the language, does not drop any knowledge in the process, though any decision to rewrite in any language may drop some knowledge, and/or may create new bugs, in the process.
> I would generally be in favour of just introducing better memory management to C/C++ and hard enforcing it in particular repositories.
This is really easy to say, but in practice it just hasn't worked out, and there is loads of empirical evidence to back that up.[0] It is not as if market incentives don't exist to create better C/C++ code.[1] If you have a way to do it better, I have no doubt Google, half a dozen other hyper-scalers, and the US government will pay you handsomely for your solution. But, at this point in time, if this is the solution, I'm afraid it's time to put up or shut up.
> This is really easy to say, but in practice it just hasn't worked out, and there is loads of empirical evidence to back that up.[0] It is not as if market incentives don't exist to create better C/C++ code.[1] If you have a way to do it better, I have no doubt Google, half a dozen other hyper-scalers, and the US government will pay you handsomely for your solution. But, at this point in time, if this is the solution, I'm afraid it's time to put up or shut up.
It really wasn't too difficult to get high reliability for memory management in C/C++ which is also concurrency safe (I have active projects running for years like this). The difficulty was enforcing it so that you are reduced to a subset of the language and it has to be followed with discovery at compile time.
The trap I'm concerned we are falling into is the "just re-write the C/C++ project in Rust". I still believe the solution is in enforcing better practices at compile time.
> Entirely untrue. It may happen, but there is zero consensus to port Linux to rust. Not even the tiniest bit.
... But I did not say there was a consensus to port Linux to Rust? I'm sorry you misunderstood.
Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust? I believe that there are many reasons why Linus chose to give Rust for Linux a chance. I believe at least one of those reasons is mindshare. If Linux chose not to experiment with Rust drivers, then that mindshare might go somewhere else.
>> Ubuntu wants to lay claim to "the Rust distribution"
Notice, Ubuntu is doing a similar thing. Canonical isn't porting all of Ubuntu to Rust. It is picking and choosing bits which they can, and would like, to move to Rust. Why? Probably for similar reasons. They want to seen as friendly to the Rust mindshare.
Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust?
This isn't a thing. Linux isn't laying claim to any such assertion.
If you want to know Linus's reasons, then read the LKML. He's quite open in all of his thoughts in this regard, and it has nothing to do with labeling Linux 'the Rust kernel'.
I don't know if this is some weird sort of advocacy, or you're just listening to a lot of over the top rust people, but nothing you're saying here is real.
>> ... I believe that there are many reasons why Linus chose to give Rust for Linux a chance. I believe at least one of those reasons is mindshare. If Linux chose not to experiment with Rust drivers, then that mindshare might go somewhere else.
Again, very sorry you misunderstood me. However, I am now pretty certain one of your difficulties is that you stop short of reading my next sentence, and then my next sentence after that. See my quoted comments above. I made very clear these are strictly my beliefs.
> If you want to know Linus's reasons, the read the LKML.
Perhaps when I said "I believe" I was being too subtle about what "my beliefs" are or what "beliefs" mean.
I hope you would agree -- just because one has expressed certain technical reasons/desires does not mean that there were not any unexpressed social reasons/desires, or what philosophers also call "higher order volitions" (long term volitions, or volitions about volitions), for one's actions.
Now -- I do not know but I do believe there may be social reasons for Rust being adopted in the Linux kernel, because I have read the LKML and I have reasoned about why Linux is experimenting with Rust drivers from things Linus and others have said.
Feel free to disagree, of course, but, in the future, please make more of an effort to avoid mischaracterizing me again.
> Drop the "mischaracterising" routine. You're asserting specific things, so expect to get challenged when they're nonsense.
If I said "Coca Cola wants to lay claim to being the best cola soda in the world", I'm sure you would also say to me: "Patently untrue. Where exactly in Coca Cola's public statements are we to find that statement?!", instead of, perhaps reflecting, and asking yourself -- is that a reasonable belief for one to hold, given Coca Cola's marketing?
If I am not conforming to your expectations, perhaps it is because your expectations that need a reset.
Ubuntu wants to lay claim to "the Rust distribution" and it's hard to blame them when Linux wants to lay claim to "the Rust kernel".
You stated this as fact, as an active statement and goal. It isn't. At all. It's made up fantasy.
Trying to reframe things after, by changing that statement into "oh, that's just an idea I had!" and then blaming others, is invalid and dishonest.
You seem to want to blame others for your made up, untrue statements being challenged. Give it a rest. Your attempts to blame shift will gain no traction here.
You stated something as fact that is not. You were wrong to do so. You are wrong to blame me for pointing it out. You are wrong to continue complaining.
> You stated something as fact that is not. You were wrong to do so. You are wrong to blame me for pointing it out. You are wrong to continue complaining. You are wrong. Clear?
Ugh. Well, I suppose it must seem very unfair to live a life without the benefit of figurative language and/or subtextual meaning. Know that I'm praying for a cure.
> Ubuntu continuously updates itself without permission...
It does default to installing security updates automatically. However, this is completely configurable.
It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective.
If you want different behaviour, just configure it as you wish.
> The Ubuntu packages, drivers and kernel are laughably behind Debian and even further behind mainline.
This just isn't a reasonable description of reality.
Unless you're referring to an Ubuntu LTS, in which case, of course it is: that's the entire point of Ubuntu LTS, and Ubuntu users have the choice of using the six monthly non-LTS releases if they want more up-to-date packages, which Debian users do not have.
> It does default to installing security updates automatically. However, this is completely configurable.
Man, but have you personally tried to disable it?
Did you stop apt-daily.service apt-daily.time apt-daily-upgrade.service and apt-daily.timer? Did you repeat the same but masking and disabling those services. Don't forget to repeat that for unatended-upgrades.service. Even after that whenever our CI fails an apt-get we have a pstree output to figure out what other dark pattern canonical came up with.
This whole debacle made me consider RedHat for my next install, and I use Ubuntu for almost 2 decades. It became unreliable in servers.
Dont get me started on the lack of security updates on "multiverse" packages which starts to include more and more packages and thus LTS means less and less. This is not innocent but so you buy Ubuntu One.
Their answer will be "just make your server robust to restarts bro", not really understanding the fact that some stuff simply cannot be restarted. We have Ubuntu desktop running a robot arm (not our choice of OS, but the manufacturer). Mid-operation snap decides to kill the robot that would otherwise be happy operating away and sending stats to the cloud.
I'm personally moving to Debian. It's 99% how Ubuntu used to be and most Ubuntu stuff is just a .deb that is relatively compatible.
> Man, but have you personally tried to disable it?
Sure. It's just a one line change in the configuration file (/etc/apt/apt.conf.d/50unattended-upgrades). Or, if you're doing a mass deployment, just don't install the unattended-upgrades package.
> figure out what other dark pattern canonical came up with
The mechanism is inherited from Debian. It isn't Canonical's architecture.
If you want to hack internals to do things in a more complicated way, then that's up to you, but you can't then complain that it's unnecessarily complicated.
> Sure. It's just a one line change in the configuration file (/etc/apt/apt.conf.d/50unattended-upgrades). Or, if you're doing a mass deployment, just don't install the unattended-upgrades package.
That answer shows you have not seen that pattern fail.When that fails or is overwritten by an update, remember my comment.
Ironically you just added another way to configure a simple thing, proving my point.
> It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective.
A better default behaviour would be to alert the user and allow them to choose to indefinitely defer by "accepting the risk". Some setups, rightfully or wrongfully, have a very long running time and cannot be restarted.
> If you want different behaviour, just configure it as you wish.
I'm not sure if it changed, but they made it extremely difficult on purpose. You can stop snap from updating, but then lots of other things also break.
> This just isn't a reasonable description of reality.
> A better default behaviour would be to alert the user and allow them to choose to indefinitely defer by "accepting the risk".
That would be terrible UX and is exactly contrary to Ubuntu's philosophy, which is to do the right thing by default.
The alternative is to bombard the user with questions that they're generally not in a position to understand, and force them to receive an education on stuff that doesn't matter to most users before they can use their computer.
> That would be terrible UX and is exactly contrary to Ubuntu's philosophy, which is to do the right thing by default.
Even in Windows (or at least it used to be), the decision to perform an update now was a user decision. Just killing off applications without warning is the worst UX ever. Randomly killing stuff off is the opposite of what I want my OS doing.
> The alternative is to bombard the user with questions that they're generally not in a position to understand, and force them to receive an education on stuff that doesn't matter to most users before they can use their computer.
It doesn't have to be like that. It could be: "Do you want to update now? The following programs are affected and will be restarted: X, Y, Z. [Learn more]" The answers could be "Yes", "Remind me on next boot", "Remind me later" (offers common delays, i.e. 1 hour, 1 day, 1 week).
What is should never do is take the power away from a user. I saw an Ubuntu user's system restart their snap programs in the middle of delivering a conference presentation without warning. That was the worst way that could have been handled.
I meant "smoking gun" from a cyber security perspective, i.e. the conclusion or the final part of the investigation. "magic bullet" would also work here too though.
You seem to have inferred the wrong meaning of "smoking gun" and that's why your usage above doesn't make sense.
There's no valid reason cyber security people would take a well known idiom and repurpose it as you imply, and a quick Google suggests they haven't done this.
Not sure what OP was referring to, but snaps are indeed a ridiculous problem.
There's no control of when snaps update, Ubuntu has explicitly said they will never add this.
There was no way to disable snap auto-updates until just last year(-ish?) when Firefox finally announced they would no longer support snaps and started telling people how to tear them out and replace them with native packages or Flatpaks. Low-and-behold, Ubuntu suddenly got the feature to disable automatic snap updates. After saying explicitly they would never allow it for years, and telling high-uptime users to instead block snap daemon network access via the firewall to avoid it.
apt won't on its own, but if you're using the official images there's probably a service running that's calling it, probably for security patches etc.
The bigger problem is upgrading packages deliberately but being surprised by the results. My team's current favorite is the upgrade process itself suddenly having new interactive prompts breaking our scripts.
> My team's current favorite is the upgrade process itself suddenly having new interactive prompts breaking our scripts.
This is how dpkg and apt have worked in Debian and Ubuntu pretty much since their inception. Look into debconf, dpkg and ucf configuration to learn how to integrate these with your automation. The mechanisms for this have existed for decades now and have not substantially changed in that time.
If you're installing software from Debian/Ubuntu repos, you can only use aptitude or apt to my knowledge. Other tools give you the ability to install DEB files you already have, and manage what's on your system currently.
And aptitude and apt are both well known for never having had a "stable" scriptable interface. In fact they themselves tell you that their commands are not stable and should not be used for scripting, despite no alternative mode or application existing.
Recently Ubuntu moved to apt 3 as well, which massively overhauled the tool from apt 2. All those scripts people wrote to use apt 2 (because there was no alternative) broke recently when they now had to use apt 3.
Ubuntu continuously updates itself without permission, killing apps and losing previous state
I've never seen this happen and I've run Ubuntu in production for years. Apt does not auto-update unless it's configured for unattended upgrades — and both Debian and Ubuntu allow you to configure unattended upgrades in apt. And unattended upgrades via apt should not kill running user processes or cause data loss.
The Ubuntu packages, drivers, and kennel are laughably behind Debian.
This is just plain wrong — even for the steelman argument of Debian unstable or testing, which are not intended for general use. Debian unstable and testing are on kernel 6.12. Ubuntu 25.04 is on kernel 6.14.
Debian stable, meanwhile, is on 6.1. Ubuntu has the far more-recent kernel.
I don't know what you mean by "drivers" — there aren't separate drivers on Linux from the kernel; they're shipped in the kernel. Ubuntu's are also more recent than Debian, since the kernel version is more recent.
With respect to packages, obviously I can't check every package version, but e.g. coreutils in Ubuntu are on 9.5, released in March 2024; systemd on Ubuntu is a version released this year (and until last month Debian unstable and Ubuntu were identical); gcc is identical; etc. While Ubuntu occasionally lags Debian unstable, it's not by much.
If you compare to actual Debian stable, it's not even close. Debian stable is ancient.
And ultimately... Why are you using Debian unstable? It's called "unstable" for a reason. It receives basically no testing. Even the "testing" version is more stable, and that's not intended to be stable at all and doesn't necessarily receive security updates. Ubuntu is less-stable than Debian stable, but far more up-to-date; Debian testing is less-stable than Ubuntu... And usually still not even as up-to-date. Debian unstable is basically untested; if you want that you'd be better served by a rolling release distro like Arch where the packages are going to be way more up-to-date anyway.
The Debian wiki cautions against treating unstable or testing releases as general purpose, so I truly don't think even this steelman is viable. [1] In fact, they refuse to even call Debian unstable a "release" since there are no release practices associated with it and the code is effectively untested.
Ubuntu is nowhere near my favorite Linux distro, but claiming it's more out of date than Debian is just FUD.
Debian is very very stable — at least, Debian stable is — and people love it for that. But the tradeoff is that everything in it is ancient. If you want something that's like Debian, but more up-to-date but slightly less stable — that's Ubuntu. If you want a rolling release, that's Arch. (And of course, there are even more-different distros like NixOS or ostree-based ones; there's the Red Hat universe of RHEL and the closer-to-bleeding-edge Fedora; etc etc.) Using Debian unstable is either a magnanimous act of sacrifice in order to help test future Debian versions, or it's self-harm.
Personally if I wanted to use a Debian-derivative on the desktop, though, I'd probably use System76's PopOS, which is basically a cleaned-up Ubuntu with some nice GNOME extensions. I'm more curious in the future to try out ostree-based distros, though, like the various Fedora Atomic ones, since they have nice rollbacks without the user-facing complexity of NixOS.
I have the hardware for a new home server waiting to be set up (as in, I don't need a new home server i'm just messing around, so once in a while i log in and configure one more service).
I tried the latest Ubuntu and it seems to be targeted at either containers or desktops. Everything I wanted to set up networking wise was a pain for my little non standard configuration.
Ended up wiping it and installing Debian instead.
As for this Rust thing, first question that comes to my mind is what features are missing from this new godly impervious to hackers by default implementation.
After years of working with Ubuntu on desktops and servers, I can tell you that for a server Ubuntu will probably always be the wrong choice.
Ubuntu seems to find it necessary to always invent some new way of doing a standard thing. Like how they use netplan for networking, a tool they invented themselves for a task that already has industry standard options available, is missing basic features those alternatives have, and adds nothing the alternatives don't also have (including any better usability).
They do this all the time, and have to eventually be dragged into the modern era when they finally get sick of having no community support for their one-off inferior tool.
In particular I'm just waiting for snaps to finally die. But at least that has some technical possibilities the alternatives don't, they just aren't functionally available in snaps yet. In another 20 years, if Ubuntu keeps at it with their unconfigurable, hardcoded, private snap registry and slow limited advancement snap portals-equivalent implementation, they might even have half as much functionality and packaged tools as Flatpak current has today.
---
If you want a decent server, Debian is a better option, even though they have some finnicky choices, and its enough like Ubuntu you might have some cross-ober familiarity.
Some of the old standbys like Fedora aren't good options because of their frequent update schedule and lack of long term support, but there are also some very good niche options if you can dig a lot more.
Also worth noting: if you want to keep the server working, you should plan on pretty much everything being in containers. It adds some complexity to what you're doing, but keeps each little experiment isolated from the others and avoids polluting the global system.
When there's Debian, Ubuntu is moot for servers and personal use (for power users at least).
One of my former colleagues used to install Ubuntu servers. I replace them with Debian when I get the chance. I was already blacklisted for Snap, so I can't re-blacklist them for going uutils and sudo-rs, and that's sad (as in Bryan Cantrell's famous talk).
> we do not need a flame war or chain of comments about what RMS' valid points were, when he was being (tremendously but unintentionally) offensive, and when he was merely being overly pedantic
If your intention is to not start a flame war, you might want to avoid contraversial topics such as the obviously manufactured canceling of RMS by the-powers-that-be.
Yeah, I remember that. That canceling was exactly what I referred to. I didn't mean to imply that the canceling was fake by putting it in the quotes, but that it was intentional and orchestrated. I've removed the quotes to avoid further misunderstanding.
Android uses the Linux Kernel, but iirc (correct me if I'm wrong), it doesn't come with the required application to make it Unix and hence is not the Linux operating system. That would mean it's only using the same kernel as the Linux operating system?
Idk, just speculating to maybe get the thought process
> That would mean it's only using the same kernel as the Linux operating system?
There's no "Linux operating system". Linux is the name of the kernel. Android is an operating system, GNU/Linux is, things like BusyBox/Linux are. They're all operating systems that use the Linux kernel.
Linux is a perfectly good operating system. If you're motivated enough, you can boot Linux straight into your software without any other dependencies at all. Linux operates the system just fine all by itself.
There's this weird definition of "operating system" which means "some sort of platform with a shell and little commands like cp, ls, etc.". That's just what POSIX tells people an operating system is, not the ultimate truth. It doesn't have to be that way.
Uh, didn't I say exactly that? Gnu/Linux Is just collegially known as "Linux" and the operation system suffix made it clear what he was talking about. I didn't come up with the usage of the term, I was merely trying to interpret their words.
there's competing specs, holy wars, etc. but POSIX is kind of like what you're describing. popular distros are usually mostly-but-not-completely compliant.
Politics is just everything. "No politics" usually means, "Opinions which conflict with mine are unwelcome" or at best the small-C conservative idea that the status quo has existed forever and so whatever happens to presently be the case is just how things should be.
In your own comment you mention "actually the best outcome" but that's a matter of politics, doubtless you have different ideas about what "best" would be than I do, and I appreciate that perhaps you've never considered that anybody other than you could be right, but you might want to take a moment to think again.
The point is that they seem to have conflated opinions about what policies are correct for general real-world issues, with those that are specific to the task of programming.
> "No politics" usually means
No; "no politics" usually means "please do not attempt to bring up topics that relate to decisions made by governments, and instead stay focused on topics directly related to the project at hand".
> or at best the small-C conservative idea that the status quo has existed forever and so whatever happens to presently be the case is just how things should be.
I have never understood how this argument makes sense to anyone. Obviously, "changing the status quo" is a policy position in a way that "not changing the status quo" isn't. The argument is effectively that it's impossible to just not care about something, for any given thing. I refute this by noting that an effectively unlimited number of policies can be proposed, yet I am not constantly thinking about politics.
> but that's a matter of politics, doubtless you have different ideas about what "best" would be than I do, and I appreciate that perhaps you've never considered that anybody other than you could be right, but you might want to take a moment to think again.
Again, I can't fathom how this line of argument makes sense to anyone. "Politics" is, quite simply, understood by the overwhelming majority of people in such a way that determining "best outcome" for a computer program not used in any government capacity is obviously not a political matter.
Or else: in your view, what does "should `sudo` do X in Y situation?" have in common with "should country X go to war with country Y?" ?
> Politics is just everything. "No politics" usually means, "Opinions which conflict with mine are unwelcome" or at best the small-C conservative idea that the status quo has existed forever and so whatever happens to presently be the case is just how things should be.
Everything is political in the same way that everything is offensive and everyone is evil. As in, you're welcome to go around saying that, but don't expect people to find this to be an enlightened perspective.
You've always encountered this, it just not (until recently) had a _whole language_ to migrate to. It's this strong impulse to do things the "right way" which is a very good instinct, but always has the danger of becoming "rigor theater". It's the same any time anyone proposes to "just" port to a new framework, or runtime, or platform, or language.
A little while ago I realized with a start that it's been years since I've heard anyone angrily insist on calling it "GNU/Linux", when that was constant background noise during the Slashdot era. One of those old fights that just faded away, I guess.
A lot of the userland _isn't_ GNU any more, people use a lot of alternatives for once much more dominant GNU tools, and people use a lot more commandline tools which have no relation to GNU. Systemd took over and for containers there's no init. Plenty of alternative libc implementations as well.
GNU is nowhere near as dominant in the non-kernel code that people run any longer.
And a lot of the GNU zealots who were particularly interested in getting credit with naming got old.
That's true. I find myself still saying GNU/Linux where it's relevant (e.g. when referring to the userland, or a compatible userland) but it's not as contentious as it used to be, which is a nice breath.
GNU sort of lost its way around GPLv3 (it gives cloud services a free pass, but not locally run software, which is the opposite of letting users control what their computer does).
That killed most of the “user freedom” enthusiasm of the early days. These days, there’s the AGPL, but that’s mostly used like the BSL (“if you want to use AGPL in production, pay us”), than for bootstrapping freedom-respecting compute environments.
If you disagree, show me an AGPL userland that’s appropriate for daily-driving.
I’m slowly migrating off Linux to the BSDs these days. The politics seem less destructive to the user experience with them.
I think it is not that local code does not get a free pass by itself but the combination.
By letting cloud services that use GPL software stay closed source it actively encourages development of cloud based tooling in a commercial context and users end up getting forced to sign up with and connect to a closed source cloud service they have even less control over than traditional locally running closed source software.
I think Stallmans motivation for the FSF includes a story about modifying a driver for a printer to support new features. Now imagine if that printer had a cloud based interface and imagine how the GPL would help Stallman add features for a new printer to it. It doesn't, if he wanted to fix the interface he would have to reverse engineer it from scratch. 40 years of FSF and it lets a decades old trend run circles around its goals.
> By letting cloud services that use GPL software stay closed source it actively encourages development of cloud based tooling
This is why AGPL was invented. You might use my AGPL code in your cloud service, but you need to provide the source code you are running to your clients. You are not allowed to keep any secret sauce secret from your users.
MIT and BSD (and plain GPL) don’t protect users again abuses like this.
V3 is incompatible with selling bootloader locked software stacks (pretty much all consumer hardware these days).
Concretely, I can’t do this local thing: Take GPLv3 software, build a board, link the software to vendor blob firmware (~ all current hardware requires this step), flash it to a ROM on the board and sell it to you with a copy of the GPLv3 software’s source code.
I can take the same vendor blob, add a TCP stack, and have your device shell into a copy of GPLv3 software with closed source modifications running in my data center.
This has massive negative consequences for users of GPLv3-reliant IoT crap and cloud services.
I think they just want to ditch GNU tools and lots of young, low level programmers want to use Rust (same rationale for Linus accepting Rust code into the kernel).
I mean, I don't necessarily use rust a lot and it's not even possible to "use" in most cases in my domain (machine learning engineering)... But to say that it's religious is just weird. It would have been super easy to portray as religious every push for better engineering practices in other fields, in fact I bet that it would've happened if the internet was common back when people were doing exactly that for say, civil engineering or mechanical engineering.
It is almost always the case that proposed changes to the technology stack of a project is intrinsically political. Unless every participant is equally proficient with the new thing as the old thing, then the proposed change is a de facto power play which will change the balance of power and experience and consequently usher in a reorganization.
This is why so many Linux developers resists the addition of Rust or C++.
"Religious" isn't being used to refer to people rewriting tools in Rust.
It's used to refer to people zealously commenting on message boards that every single tool ever built should be rewritten in Rust, and if you aren't rewriting your tool in Rust, you're an idiot.
> It's used to refer to people zealously commenting on message boards that every single tool ever built should be rewritten in Rust.
Ok, but between me, GP and the article, who said that? Where are the Rabid RIIR fans?
And before you misquote me, I said, why wouldn't you rewrite stuff in Rust, if the status quo is ridden with bugs, and safety issues? And why shouldn't a Linux distro switch to it if they desire.
>Ok, but between me, GP and the article, who said that? Where are the Rabid RIIR fans?
The person you replied to said: "The religious element of rust programmers seems more extreme than other languages."
You interpreted that in a way that ended up with you asking "What is religious about rewriting tools in Rust".
I clarified that the typical way "religious element of rust programmers" is interpreted is not the act of rewriting tools, but the proselytizing about rust on message boards. I then gave an example of what that proselytizing typically looks like (which was not a claim that you said something like that).
That is the "religious element" being referred to. The proselytizing is the religious element, not the act of rewriting tools in Rust.
(The meme "Rust Evangelists" didn't manifest out of thin air because people hate memory safety or whatever -- it's because people are really, really passionate about Rust, and are vocal about that passion)
> The proselytizing is the religious element, not the act of rewriting tools in Rust.
Ok. Where is the proselytizing taking place in the article?
Is the sudo-rs did work, the proselytization? Where is it?
> The meme "Rust Evangelists" didn't manifest out of thin air
That's not how memes work. It's just something that appeals to some group that spreads it. It can be true, false and fabricated out of thin air.
What if I told you, that "What if I told you" meme isn't what Morpheus says to Neo? The scene itself is so divorced from meme it doesn't carry much resemblance (here https://youtu.be/L8H9DqkrkcY)
>Ok. Where is the proselytizing taking place in the article?
It's not? It's like you're picking random words out of my comment to quote without bothering to read what I'm writing. Nothing of what I said is about the article. It's about your misinterpretation of what fossuser meant when they said "religious element".
I can't explain the same thing for a third (fourth, I guess? since I just tried again) time, I'm running out of different ways to say it. So I'll just leave it there.
Your meta-commentary on memes is neat and all, but again, somehow, completely misses the point I was making.
> It's about your misinterpretation of what fossuser meant when they said "religious element".
My point, where is the proof of that "religious element" beyond memes? Is it in the article? Is it in the links? Where can we see this religious fervor in action?
The article is very matter of fact. I expect people to be matter of fact as well.
I swear to God, I feel like I'm asking for the Individualist Eleven book, and everyone asserts me it exists, and they read it, but no one can ever finds it.
> Your meta-commentary on memes is neat and all, but again, somehow, completely misses the point I was making.
It's necessary because memes aren't real. They might have started based on some interactions that 10 years ago, but by their nature they will mutate and twist.
>My point, where is the proof of that "religious element" beyond memes? Is it in the article? Is it in the links? Where can we see this religious fervor in action?
You can argue with fossuser about the validity of what they said.
I'll offer my opinion, which is not some proof from god or anything that you seem to be seeking, which is that I find significantly more annoying comments from Rust users, about how something should be rewritten in Rust to fix everything, than any other language. But, again, this is not proof from god. I'm just a guy making an observation based on my lived experience. You have a different lived experience. Glad we could clear that up.
> which is not some proof from god or anything that you seem to be seeking
You know what, you or anyone else can start with actual proofs. I don't want your lived experience and memes as proof, I need messages, posts from people (bonus points for sudo-rs members) that show how zealous they are about Rust and rewriting all the things in it.
I'm a Java dev, that just dabbles in Rust. I've seen observed many claims about Rust zealotry with no actual proof. Whenever I ask for them, I get a blank stare and dodging.
Hence, my comparison with the book from Ghost in the Shell. It, too, was a meme, an actual memory virus. Everyone read it, and no one could find the proof it existed.
(I'm sure if I pick any specific quotes, you'll start arguing the semantics of what is "zealous", how whatever number of comments I pick are outliers, or not proof enough, etc. So, here's one query, of many, that you can pick through.)
In the end, I really could not care less if you agree with the characterization or not. But your enthusiastic defense is fun. If you keep going, you'll be coming close to being an example yourself!
First, a simple grading system:
0 - No RIIR sentiment
1- Joking or
2 - Mentioning Rust in positive light
3 - Suggesting Rust positive light for project
4 - Asking for RIIR, saying stuff like this wouldn't happen in Rust
5 - Demanding RIIR
| | | RIIR grade (0 -> 5) | Notes |
| --- | --------------------------------------------- | ------------------- | ----------------------------------------------------------- |
| 1 | https://news.ycombinator.com/item?id=43912708 | 4 | Parent post is talking about Rust |
| 2 | https://news.ycombinator.com/item?id=43910022 | 0 | Talks about Fish rewrite |
| 3 | https://news.ycombinator.com/item?id=43909844 | 0 | Discusses Issues |
| 4 | https://news.ycombinator.com/item?id=43909222 | 1 | Jokey on RIIR |
| 5 | https://news.ycombinator.com/item?id=43906665 | 0 | Talking about RIIR |
| 6 | https://news.ycombinator.com/item?id=43905224 | 0 | Promotes a rewrite in C versus a Rust rewrite |
| 7 | https://news.ycombinator.com/item?id=43897309 | 2 | Discusses Rust in positive light, but nothing about rewrite |
| 8 | https://news.ycombinator.com/item?id=43865281 | 0 | Discusses negatives of JS backends |
| 9 | https://news.ycombinator.com/item?id=43851214 | 0 | Talks about knowledge bias |
| 10 | https://news.ycombinator.com/item?id=43851075 | 5 | RIIR (maybe joke) |
| 11 | https://news.ycombinator.com/item?id=43840479 | 0 | RIIR is mentioned in passing, not actually used |
| 12 | https://news.ycombinator.com/item?id=43833836 | 4 | RIIR suggestion |
| 13 | https://news.ycombinator.com/item?id=43832828 | 0 | Advises against Rust |
| 14 | https://news.ycombinator.com/item?id=43832638 | 0 | Not RIIR |
| 15 | https://news.ycombinator.com/item?id=43832349 | 4 | Asks for RIIR (maybe jokingly) |
| 16 | https://news.ycombinator.com/item?id=43827713 | 0 | Congratulates on Rewriting in C#/Unity |
| 17 | https://news.ycombinator.com/item?id=43797673 | 0 | Neither it nor the GP are acually RIIR |
| 18 | https://news.ycombinator.com/item?id=43791746 | 3 | Mentions Rust in positive light |
| 19 | https://news.ycombinator.com/item?id=43791093 | 1 | Joke |
| 20 | https://news.ycombinator.com/item?id=43791090 | 1 | Joke |
| 21 | https://news.ycombinator.com/item?id=43781819 | 2 | Arguments for writing code in Rust |
| 22 | https://news.ycombinator.com/item?id=43769094 | 5 | RIIR |
| 23 | https://news.ycombinator.com/item?id=43768282 | 0 | Negative on RIIR |
| 24 | https://news.ycombinator.com/item?id=43766357 | 0 | Explaining what RIIR means |
| 25 | https://news.ycombinator.com/item?id=43766000 | 4 | Asks for RIIR |
| 26 | https://news.ycombinator.com/item?id=43764348 | 0 | Discusses implementation in Rust |
| 27 | https://news.ycombinator.com/item?id=43757201 | 0 | Talks about Rust |
| 28 | https://news.ycombinator.com/item?id=43731538 | 2 | Mentions Rust in positive light |
In summary, there are 28 items on the first page, totalling 38 points.
Doing an average, it's about 1.35 points, which suggest that on average, people are somewhere between joking about RIIR and mentioning Rust in positive light.
However actual number of RIIR between 2-5 depending how you look at it, 5-17%. Assuming the rest of pages have a similar spread, and that targeting only keywords of RIIR captures accurately the sentiment - I suspect the latter is the case. I've seen more negativity about Rust in https://news.ycombinator.com/item?id=43910745 in few hours, than positivity about Rust in several days.
And I've seen my comments that are positive about Rust get way more downvoted, than comments skeptical or negative on Rust.
So sudo is ridden with bugs and safety issues, as opposed to the Rust alternative? I came across a lot of ridiculously absurd logic bugs in the Rust version. Maybe you can still see GitHub Issues.
The comment you responded to says: "Seems odd that they don't advertise it [the usage of Rust], though."
Isn't not advertising a language the polar opposite of being religious about a language?
I am all for a memory safe sudo and I don't care which language it is written in, use C, Ada, Rust, as long as it is a suitable systems programming language understood by a community of developers and you can proof memory safety to an acceptable degree. If the people first to do it in an such an way happen to use Rust, not accepting that based purely on the language is what would sound religious to me..
Maybe this protectionist reaction (see recent drama within the Linux kernel) is every bit as religiously colored as some people claim Rust people are.
I mean memory safety? What comes next? Not allowing us to use after free like true men would? \s
I don't have a strong opinion on what language - the bit you edited in what I was replying to changed the meaning of what they were saying.
My reply is flagged dead now which is fine since it did create an unproductive thread, but it was more that I had noticed Rust as a community seems to have more of an identity based political bent around it more so than other languages. Something I've also noticed with Mozilla - it's not just the language, but that the language signals you're a certain kind of person with a certain kind of politics in addition to the general pro-rust stuff.
I don't recall seeing this combination elsewhere with other languages before - though there have been religious like battles over languages forever, but I don't think it's been predictive of someone's political identity before?
> but I don't think it's been predictive of someone's political identity before?
This is a pretty astounding claim. On which data did you base that conclusion? Because if it is purely anecdotal, you might consider that this is a bit like with Apple fanboys. Apple generally makes good products. Most people who use their stuff don't even talk about it, but those who do talk about it tend to have strong opinions that extend the quality of Apples products themselves.
But these opinions are not even remotely representative of the broad majority of Apple users.
Rust similarily lends itself to fanboyism, because the language has a strong narrative going for it, that is part of its success. The narrative isn't even a bad one: create a programming language that makes certain common classes of mistakes impossible and others much harder. Like every topic with strong narrative this will draw in a certain amount of people who will strongly defend said narrative, but those aren't necessarily the manority of the people who use the language.
So unless you made a proper poll that tries to select for a broad set of Rust users instead of basing your judgment on a loud online minority I wouldn't be confident in the result.
I with "identity based bent" you mean they are inclusive and have strong community rules, it might just be that this is normal where the Rust users are from. Last time I checked Rust was very popular in European countries and over here these kind of rules are pretty off the shelve standard. But please tell me this isn't about you calling them "woke" and confusing basic human dignity with politics.
There was recently that article about Python switching to a proof verified C crypto library. Yes, I welcome verified C code. But Rust is much easier to use instead
Tho the extra properties re side channels in said verified code outdoes Rust, so I'd also say it'd be undesirable to replace that C code with Rust
It's not religious. Memory safety is a thing. If by politics you mean the government: they only got started recommending memory safe languages once it became clear that foreign actors were going to keep exploiting C / C++ vulnerabilities.
Rust is part of a modernized iteration in language design this century
Nobody is calling for Ada code to be rewritten in Rust. But at this point you'd want an argument to choose Ada over Rust when it has become more widespread, especially in open source projects
You can find lots of resources here to learn Ada / SPARK: https://learn.adacore.com or just to see what is up. Alternatively, there are good blog posts, too.
I thought I should reply separately to your comment, but I do not see how he got to the conclusion "in other words, if your goal is to write a (say) safe implementation of the DOM that can render real-world web pages while efficiently using memory on a general-purpose computer, Ada is probably the wrong tool for the job.". My only "issue" here would be its verbosity, which is why I choose C still quite often.
They were opining that Ada is unsuitable for fine grained data structures (like Rust being awkward with linked lists) & lacking mature graphics APIs
For years I used a C window manager I wrote which was less than 150 lines[1], it can definitely be a terse language. But I've also written pretty tight Rust code for a card game engine & its http server. I don't think Rust is particularly more verbose. Rust code can be artistic too[2]
To be honest, I have not yet written Rust seriously, so I cannot comment as much on it. I mostly use C, OCaml, Lua, at times Perl, these days. I do not know how much the language would feel like it is getting in the way of "expressing" my thoughts.
Why does it matter, really? I mean sure, ada could've been an alternative language that everyone pushed for using but it kind of missed the boat due to historical circumstances , the context around its early use, etc. It might even be that rust users are just more enthusiastic and have been able to push more... But so what?
But why does it matter if the language that has seen some traction in terms of "rewriting software in safer languages" is rust? At that point it becomes even more religious to just reflexively oppose rust because "well why didn't x or y see the same push??"? Again, it really doesn't matter why!
This sounds like a dismissal. It is worth getting rid of the misunderstandings of Ada. It is worth letting people know that safe alternatives to C do exist and have existed long before Rust. You said it yourself that the issue may have been historical circumstances, in which case it should be clarified. Ada has a lot of great things built-in to the language. I especially love its type system and constructs for concurrency. Imagine if it had the hype of Rust, as a better alternative to C (which it easily could be). It goes further than Rust when it comes to safety, there is a reason for why you can find it in critical software.
> But why does it matter if the language that has seen some traction in terms of "rewriting software in safer languages" is rust? At that point it becomes even more religious to just reflexively oppose rust because "well why didn't x or y see the same push??"? Again, it really doesn't matter why!
If it does not matter, then why not Ada / SPARK indeed? I am sure the whys matter to some extent.
Again it doesn't really matter imo. There's no reason for ada rewrites to not take place, but I don't seem to come across a lot of community projects aiming at rewriting, say, coreutils in Ada. That's maybe due to the lack of hype (something rust doesn't lack at all). But regardless, I think that most people know and have know that memory safe alternatives have existed for a while.
I agree that it does seem like there's a misconception that there's "C or C++" (system languages) and "the rest" (memory safe but not system langs).
Which is obviously false, and I think the novel thing about rust's hype is that it's always compared to C or C++ (instead of java or c#, for example).
I think that's why it feels like it's the only language that is talked about when discussing "memory safety" (even if most mainstream languages are memory safe now). Go had a similar "system lang" hype to it until it was clear that it really wasn't.
Ada is undoubtedly a systems language (as you said it's been used to build insanely complex systems and it did just fine), but from my POV the little marketing that it has doesn't emphasize that.
I think though one of the reason ada doesn't get discussed a lot is that it doesn't have a big open source community. Ada could even be more popular in terms of actual LoC written, but most of that development is held behind very closed doors, so it's very hard to actually get a community going. Which then makes it hard to actually go through a full rewrite of things like coreutils.
Why is HN downmodding this? We're programmers, surely we all agree memory safety is a thing? Infosec people surely all agree that foreign actors have been exploiting vulnerabilities for the last three decades?
I'm not complaining about the downmods, I'm just weirded out - it's like a music forum disagreeing that flutes are real.
# U.S. government guidance on memory-safe languages
Here's the list of links to U.S. government documents recommending memory-safe programming languages for cybersecurity.
1. *White House ONCD - "Back to the Building Blocks" (Feb 2024)*
- Encourages developers to use memory-safe languages like Rust, Python, Java, C#, Go, Swift to reduce vulnerabilities.
- Link: https://bidenwhitehouse.archives.gov/wp-content/uploads/2024...
What your parent is referring to is that three of those links now 404. Some of that is simply because whitehouse.gov gets redone with new administrations, and so old stuff is thrown out. They're also referring to how the Trump admin is talking about seriously reducing CISA's budget. Things like that.
Only if you don't buy any downsides with it. That makes it situational dependent. For example:
- less people being able to read the code, work with the code, find (security) bugs
- slower
I know, I know, rust is not really slower, and for sudo it probably wouldn't even matter. But safety isn't the be all and end all of software. There is a lot of software out there where memory safety doesn't matter, or matters a lot less than other aspects.
Supply chain attacks is a big downside no one ever mentions. Even sudo-rs drags dependencies in from Github at build time instead of being self-contained, which is just an absurd thing to do for such an essential tool, especially in the current political climate.
1) every dependency comes from crates.io, not straight from GitHub
2) the dependency list is tiny
3) it uses a cargo lock, so even if it were using a GitHub dependency, that file keeps a hash of the dependency and points at the specific commit, so if the dependency were to introduce a backdoor it wouldn't be automatically picked up and a commit history rewrite would also fail
>"But I'm aware that some people are frightened of new languages..."
I am not frightened. I program in many languages and have no problems grasping Rust concepts. However I find Rust way too opinionated and restricting for personal tastes. For business I can not see myself replacing C++ with Rust unless my paying clients specifically request it. So far not a single one had expressed any interest.
This is not a new paradigm. It is a limitation in the design of the borrow checker, which causes you to go around until the borrowing takes on mainly a tree structure.
There's been cases[1], of particular note, the unescape overflow one[2]. This one scathed the reputation of sudo enough to get people pushing for alternatives such as doas. The track record of vulnerabilities in general leaves a bit to be desired, even outside of memory vulns.
Sudo had quite a few problems with security, partially because of this doas was developed for BSD.
Some problems come from the huge amount of features(ldap, easter eggs, ...).
sudo-rs reduces the problems by not implementing those features.
> Some problems come from the huge amount of features(ldap, easter eggs, ...). sudo-rs reduces the problems by not implementing those features.
This makes me wonder:
1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?
2) If these features are useful in the real world, will a Rust rewrite of sudo inevitably gain these features over time and end up with similar problems?
doas is 500 lines of C. Two orders is magnitude less than sudo yet still covers the core functionality. Sure you could grandfather”s axe your way into the final product, but difficult to see how a a hypothetical code base 1% of the original counted as anything but a rewrite.
2. While a feature may be useful, the question is how useful, and to how many people. sudo-rs is removing features that aren't used very much, if at all, and doesn't plan to add them, to combat this. Those users can still use the original sudo.
Ubuntu moving to a memory safe sudo implementation isn't actually that concerning to me. It's a good idea to have a smaller, safer sudo alternative as the default, as OpenBSD does with doas. Users can install sudo if they need it. My problem is that it needs to specifically be called something else than sudo. Again OpenBSD has doas, which to the users clearly isn't sudo, so users don't expect it to behave as sudo or configure as sudo.
By all means, write a better, safer, smaller, more secure version of sudo, but don't have command be sudo or sudo-rs, name it something else.
Debian is currently in the process of dropping the direct LDAP support in sudo, in favor of sssd. From sudo's NEWS.Debian.gz:
> In practice, there are few installations that use sudo-ldap. Most installations that use LDAP as a directory service and sudo have now opted for sssd, sssd-ldap and libsss-sudo.
> The Debian sudo team recommends the use of libsss-sudo for new installations and the migration of existing installations from sudo-ldap to libsss-sudo and sssd.
The features we specifically don’t support are those related to direct LDAP support within sudo, so things like loading a sudoers file directly from LDAP. Sudo-rs will use any user retrieved via NSS, such as when configured using SSSD to load LDAP users. And from the authentication side you can use whatever PAM supports, so anything like Kerberos etc, which again can be coupled with the same LDAP database.
This one is easy: run0 is not implemented in a memory-safe language, but in C. It is likely to be hit by exploitable memory-handling bugs, like the rest of systemd, as has happened multiple times before.
"This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components."
Somehow "maintainability" has never been something I'd ever associate with Ubuntu. Is it a reference to their source tree? That'd make a lot more sense than if they were referring to the OS itself.
The Linux port has not been maintained for 3 years. Has unmerged rowhammer fixes and generally a yolo auth system best described as "dangerous". You are better off using a well maintained project, that includes the CVEs^Wwarts.
It's a mistake to think that `doas` on Linux is the same as `doas` on BSD.
Just as with the sudo-rs reimplementation, a doas-rs rewrite is not going to solve the inherent issues we get with SUID binaries. We are better off implementing better models (see ssh and run0).
Those should be closed WONTFIX. Neither doas nor sudo can protect you from the consequences of running untrusted code and must not attempt to do so because it adds needless complexity to safety-critical software.
I wonder if there’s one that hardcodes a simple policy like “members of the wheel group can run any command with a password, and a 5 minute timeout”, but is also sudo command line compatible.
That’s what 99% of distros default to, and it’s simple.
I have been using sudo-rs for over a year. The only issue that I've had is running into `-E` being unsupported once every few months - which is arguably a good thing because I shouldn't be naughty and allow arbitrary envs to leak into a privileged session.
The point of the "memory safe" sudo was not only that though. They removed a lot of nice really rarely used features to make the attack surface smaller.
I am not sure if memory-safety is the biggest issue in sudo design. I find the fact that it is a setuid binary a much bigger issue because a bug can possible result in privilege escalation.
I found an alternative implementation that doesn't rely in being a setuid binary like systemd-run0 much more interesting from a security perspective, but I am no security expert.
Right, but now the vector for privilege escalation will have to be a logic bug in memory-safe sudo instead of either a memory corruption (see CVE-2021-3156) or a logic bug. It’s hard not to see this as a major improvement.
A major improvement would be to get rid of glibc altogether. As long as glibc is the default, the problems persist.
That is possible: https://github.com/sunfishcode/eyra
Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate. Depending on how sudo authenticates phishing attacks or password reuse from another breach can be used to escalate privileges.
I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates.
You can enforce a boundary between root and an account that never elevates though. And as far as I understand hardening sudo helps with that.
Why not? The way Windows does it should work in theory I think?
Maybe you can't realistically do it on Linux, because Linux doesn't care about desktop security and doesn't have the kind of privileged GUI that you need.
Windows is a bit different I suppose. Many pieces come together to make it kinda work there.
* Privileged gui to display and approve what will run as you mentioned. In Linux, non-privileged gui is used to request permission to do... something.
* Executable verification. Let's say someone with user level permissions swaps out the program you wanted to run for a malicious one. The replacement would not pass certificate checks which would be revealed in the privileged gui. Maybe you could supply an old version with known vulnerabilities though idk?
* Kinda commandline parameters verification. In Linux-land you can pass parameters to the program those could be intercepted with user-level permissions. In Windows this would be displayed in the privileged gui. However! The parameters are only visible if you click "show more" which I would guess <1% of people actually do.
As an example of the last point I tested making a shortcut to cmd.exe and used Run As Administrator. Then I changed the shortcut to C:\Windows\System32\cmd.exe /c calc and again did Run As Administrator. Opens calculator instead of command prompt with identical approval gui (except with show more).
The way Windows does it is users are prompted to elevate permissions, and can be tricked into clicking "Yes," just like users can be tricked into using sudo.
Well yeah you can't enforce any security boundary if your threat model includes "user might be tricked".
It can't be enforced on Linux because `sudo` can be trivially MitM'd, but you can't do that on Windows because it's just a click.
But the entire threat model we were discussing was that the user might be tricked:
Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate
That's why the OP said that's not an enforceable security boundary. If the user is capable of attaining superuser privs, you can trick them, regardless of how attaining those privs is implemented.
Yeah I wasn't agreeing with that either.
I didn't interpret OP's comment like that. I think he was saying you can't enforce the boundary at all even if users don't get tricked.
That's true on Linux because the sudo UI can trivially be MitM'd by malware. You can't do that on Windows so trivially.
That was doable, and how it worked, under Windows until a few weeks ago [0].
[0] https://cyberdom.blog/abusing-the-windows-update-stack-to-ga...
>I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates.
So stop doing that!
Who are you shouting at?
Going back to the topic of the discussion, making sudo more resilient prevents a whole class of possible bugs (see CVE-2021-3156). You may not like sudo, but it is very commonly used to manage access, prevent accidental errors, or improve accountability on Linux servers and workstations. It is not going away. Therefore, improving sudo is a worthwhile goal and a thing to be celebrated.
I'm not shouting.
>sudo more resilient prevents a whole class of possible bugs
Good, but this doesn't fix the easiest way to escalate privileges as an attacker through sudo. Memory safety doesn't help people who run "curl | sudo bash" to install a random program from the internet.
>It is not going away.
But if work is done it could become very niche and eventually stop getting new usage over time.
> help people who run "curl | sudo bash" to install a random program from the internet.
I don't think you can help those people, unless you seriously lock down the machine to the level of iPhone. Neither Android nor Windows have "sudo" for example, and yet they can get malware just fine... all the difference is instead of the password, user clicks on confirm button a few times.
I advice to (1) think about how you use sudo (2) think what would you replace it with and (3) think how the replacement can be abused by malware.
Here is one example:
(1) Today I used "sudo" to run docker: "sudo -Eg docker docker run..."
(2) the sudo-less replacement would be to add myself to docker group, or switch to rootless docker
(3) If I add myself to docker group, malware can trivially escalate by starting a privileged container. If I switch to the rootless docker, I am weakening security boundary between my primary user and the docker containers I run.
> I'm not shouting.
In text format, all-caps or the use of an exclamation mark are often used to indicate shouting.
So, it is not unreasonable for people to read your sentence as such.
What should you do instead?
Capabilities. Proper microkernels already do that
how do they solve sudo's problems though? Exchanging "sudo" with "require-root-capability" or "start-privileged-session" will still have many of the same logic problems.
Unless you mean something like "capabilities are always inherited, and there is no way to increase them", which would mean that sudo-like scripts are impossible, and you need to start all-new session as root user for admin actions. Good news, it's already possible in linux - just don't install "sudo", and maybe set up SELinux to disallow all escalation. Turns out no one wants to do this though.
fine grained.
there's no god-mode who can do everything. there's no universal kernel level. micro means only minimal things happen in the kernel or at root level, like routing messages.
even windows understood that those times, when they did split Administrator from System. linux followed then with system users for certain services. but capabilities only allow certain calls at certain times. there's no setuid 0, only cap this and cap that for this admin user for a certain time range.
BTW, SElinux is the default on a proper linux like Redhat. I use it daily. I also have to adjust the ssh caps, not just the firewall settings. Everybody wants that, just not the debian nobs.
There is omitted detail here. Capabilities are a great way to determine access control (IMO, they are essential in general as a user-facing model too). However, that still leaves the question of who gets what capabilities. For the network service to be able to hand out network capabilities, it itself must have at least as much authority, and it had to get that authority from some other source of capabilities. There must be some privileged component that forges all capabilities, and actually distributes enough authority to make the system usable. For example, as soon as a human user becomes relevant, the system's user-avatar must be able to command authority, in a way that may seem sweeping. This could mean directly or indirectly changing which program is the network service, which means the ability to influence all networking activities, which is no small authority.
An agent logically has all the capabilities necessary to do what the agent should be able to do. The sum of capabilities of an agent indicates "the worst that can happen" if the agent is malicious. It makes sense that if a network service is malicious, all networking activities can be subverted. Still, the storage activities shouldn't be subverted, and of course the network service wouldn't have the storage service capability. However, if a user is malicious, anything could go wrong that the user is normally trusted to not make go wrong. Correspondingly, the user must have an expansive sum of capabilities.
Capabilities are themselves simple, but that is the mechanism perspective. Access control policy is an entirely different beast, and any mechanism at best minimizes the risks.
This all sounds very reasonable as long as servers/services are involved. Linux has capabilities for this purpose, and systemd goes a long way towards the vision you describe - daemons which do not need root and instead get all capabilities from the supervisore process.
However, were were talking about "sudo" and this is purely interactive tool (I am sure some people run sudo non-interactively, but we can all agree it's a bad security practice). So, how does this nice capabilities vision mesh with the idea of "administrator user"?
From what I see, it's not much different. Instead of "sudo" which verifies user identity+permissions and then gives out "root" or some other user, we have some other hypothetical tool ("become-admin"?) which verifies user identity+permission and gives out powerful system-changing capabilities. Frankly, I don't see much difference - it's the same security model either way.
(A related argument I've seen is "you should not need sudo for common tasks like update software or configure network" - but on modern Linuxes, you don't need sudo for that already, this is done via dbus + polkit calls. No "proper microkernels" required, that is already deployed everywhere.)
Design the system so that you do not need users to escalate to root. Find each use case where a user may want to use sudo and then come up with an alternate way to accomplish that action from a regular account.
That would just elevate each regular account to be a root account. There is no other way to make things like modifying files directly under / possible, or to change system configurations. You can lock everything down instead, then you have Android, but then you have certainly not enabled everything a user can do with sudo.
>There is no other way to make things like modifying files directly under / possible
It doesn't need to be possible.
>change system configurations
You can have an settings app to configure the system.
>then you have Android
Which is much farther ahead than Ubuntu on security. Ubuntu needs to play catch up.
>but then you have certainly not enabled everything a user can do with sudo.
The goal is not to be able to do everything. The average user doesn't need to be able to do anything. Especially with their regular account.
Sounds like you don't want a Linux system, but rather a Chromebook. Have you seen https://chromeos.google/products/chromeos-flex/ ? Install it on your computer and you get Android-like security model, including only verified software and lack of "sudo" or any sort of root access.
A Chromebook is a Linux system. My concern is with Ubuntu improving their security posture. Telling Canonical to give up on Ubuntu and switch everyone over to ChromeOS is not something that I predict would work.
> The average user doesn't need to be able to do anything.
We have that, it's called android.
Anybody who finds themselves using sudo is already well off the beaten path, by their own choice. There's nothing wrong with that.
Doing system updates is not off the beaten path.
And system updates don't need sudo on desktops, it is not 1990's anymore... GUI apps like software-properties-gtk use dbus with polkit auth to upgrade software without any involvement of "sudo" or giving root access to users.
Using GNU/Linux at all is. Choosing to use such an operating system and then also choosing to do your updates from a terminal emulator is even further off the beaten path.
The beaten path is the defaults. Windows and MacOS particularly.
Currently, for any given action, the following possibilities are implemented:
* The user may never perform the action (would require sudo, but the user doesn't have sudo rights)
* The user may sometimes perform the action (i.e. only after authenticating with sudo)
* The user may always perform the action (is always implicitly authenticated)
"Being root" is just another name for the last option.
What fourth alternative do you have in mind?
>"Being root" is just another name for the last option.
No, it's not. Take for example ping. If we want users to be able to always be able to use ping does that mean they need to be root? No, it doesn't. A privileged part of the OS can handle doing the raw socket and the unpriviledged user can talk to that part of the OS.
The key point is that some operations that require privileges are okay to expose to a user, but giving the user privileges for everything is dangerous.
Examples please? Modern desktop OSes are pretty good at exposing safe operations to users so that no "sudo" is required.
Those will also have to be fixed/considered, but do not detract from the contribution of removing memory safety bugs which may enable exploits.
This is a case of doubling down on bad design. To me it's wasted effort preventing theoretical bugs in niche setups.
I think the opposing view is that moving away from sudo is substantially more effort and would break basically everything to accomplish "the same" thing as robustifying sudo (for some very loose definition of "same")
Yes, it's more effort, but it's not close to being the same.
I mean moving from IPv4 to IPv6 is more effort, but it's not close to being the same...
And it's also why it mostly has not happened for most people.
Even with a new, perfect paradigm, there would be billions of systems running sudo for years.
I don't see how this attack is related to the setuid binary. No matter what method you provide to the user to elevate their privileges, they can be tricked into doing it. If it was provided by a daemon, built into systemd, or anything else, the problem would be the same.
It's related because malicous code can use the setuid binary to elevate its privileges.
>If it was provided by a daemon, built into systemd, or anything else
Yes, this is also dangerous.
So what's your recommendation? Removing the user?
> Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate
So does your OS.
Do you have in mind a design that enables users to escalate privileges while preventing them from being tricked into escalating privileges?
A bug in a daemon-based sudo alternative would surely also result in privilege escalation?
I think the main benefit of eliminating setuid binaries is that you can forbid them system-wide (e.g. via mount flags), as a hardening measure.
There's value in always starting processes from a known-secure environment rather than attempting to transform a user's arbitrary environment into a secure one.
True, CVE-2021-4034 comes to mind as a recent example (exploiting zero-length argv)
How is that any different than a daemon that has a parser error in its message handler, except that the daemon could be misconfigured to listen on a network socket?
The original unix process abstraction was extremely simple; the entire spec is a few pages.
The problem is that Linux keeps adding more and more levels of Rube Goldberg machine to its security model, so now literally no one understands how a default minimal install of, say, Ubuntu works.
Adding a magic daemon that runs stuff as root to this pile of complexity probably won’t help. Ripping out almost all the cruft that’s accumulated over the years, and adding back something sane (maybe BSD jails) would work a lot better.
> How is that any different than a daemon that has a parser error in its message handler
The non-daemon has to parse just as much in addition to making itself secure. Actually it needs to parse more things in more complex ways.
Assuming static linkage (which sudo has to assume), there’s really not much to parse. It should just be dealing with a null-delimited list (argv) and the caller’s environment variables (which it just needs to ignore and clear by default).
Here’s a simple implementation: https://github.com/TheMilkies/rut/blob/main/rut.c
(Though it doesn’t clear the environment unless I’m missing something - they should probably replace the call to execvp with one to execvpe, and add a null pointer to the end of the argument list).
The problem of setting up root’s environment and parsing the command line is left to the shell in both solutions (the thing I linked doesn’t indirect through a root login shell).
There’s also the config file, but that’s the same for both.
Similarly, the system could be running some SEL derivative or be using a capability system that causes non-standard behavior from system calls, but the daemon has the same problem.
I think this post explains why much better than I can: https://mastodon.social/@pid_eins/112353324518585654.
So yes, I am not saying that privilege escalation bugs are impossible if you have a different architecture, but like Lennart argues is that it makes them much more difficult to happen, especially because creating a proper setuid is difficult. Also there is a bunch of things that makes sudo especially tricky to implement correctly.
I used to be annoyed that sudo would reliably crash from memory errors.
Eventually the bug (and associated vulnerability) was patched. I think.
Rust version of sudo had lots of ridiculous logic bugs. I do not see the improvement.
Do you have an example of the logic bugs you're referring to?
I am pretty sure it is around here somewhere: https://github.com/trifectatechfoundation/sudo-rs/issues.
I apologize, I do not bookmark these issues, but maybe I should start doing that? In any case, you will find logic bugs which may raise the question "is it really worth the rewrite?".
A more interesting link is https://github.com/trifectatechfoundation/sudo-rs/issues?q=l... IMO. Glancing down that list, a lot of them aren't what I would personally view as major problems (ex. "rustup is inappropriate for security critical software" - maybe it is, but that's not a specific exploitable bug), but I would suggest https://github.com/trifectatechfoundation/sudo-rs/issues/575 as a potentially interesting looking example.
> I apologize, I do not bookmark these issues, but maybe I should start doing that?
Yes. If you want to point out problems, it really helps if you can point at specifics.
> In any case, you will find logic bugs which may raise the question "is it really worth the rewrite?".
There's a cost/benefit question, but note that the mere presence of some bugs doesn't make a rewrite worthless.
Thank you!
You have the burden of proof to substantiate your accusations. Until then they're entirely unfounded.
Aren't full rewrites pretty much universally considered harmful?
No
Not universally, but often it introduces logic bugs that the original project did not have. I guess it heavily depends. In this case, I think it may do more harm than good. Just use "doas" or something. FWIW, I trust "sudo" more than "sudo-rs".
> This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components. Sudo-rs is developed by the Trifecta Tech Foundation (TTF), a nonprofit organization that creates secure, open source building blocks for infrastructure software.
Ubuntu continuously updates itself without permission, killing apps and losing previous state. You have the Javascript based Gnome window manager that is always bugging out. The Ubuntu packages, drivers and kernel are laughably behind Debian and even further behind mainline. Ubuntu continues to morph into something I don't believe in.
That all said, Rust is not a smoking gun for incorrect application logic. It could still happily incorrectly execute stuff with the wrong permissions or blow something up badly. I think it's also a bad idea to offer it as a drop-in replacement when clearly features are still missing since a long time [1].
[1] https://github.com/trifectatechfoundation/sudo-rs/issues?pag...
> That all said, Rust is not a smoking gun for incorrect application logic. It could still happily incorrectly execute stuff with the wrong permissions or blow something up badly.
This side steps the issue which is "Does Rust help you make software more correct?" No one is arguing that Rust is perfect. There are plenty of bugs in my Rust software. The question is only -- are we better off with Rust than the alternatives?
> I think it's also a bad idea to offer it as a drop-in replacement when clearly features are still missing since a long time [1].
Your example is the Github issue page?
Look -- I agree that, say, uutils/coreutils missing locales may frustrate some users (although I almost never use them). But "close enough" is more the Unix way than we may care to realize. But especially in this instance, because sudo is not POSIX (unlike locales which are). A distro is free to choose any number of alternatives.
Ubuntu wants to lay claim to "the Rust distribution" and it's hard to blame them when Linux wants to lay claim to "the Rust kernel".
> This side steps the issue which is "Does Rust help you make software more correct?" No one is arguing that Rust is perfect. There are plenty of bugs in my Rust software. The question is only -- are we better off with Rust than the alternatives?
There is a lot of embedded knowledge in existing implementations, Rust deals with just one small class of bugs but drops a lot of this knowledge in the process.
I would generally be in favour of just introducing better memory management to C/C++ and hard enforcing it in particular repositories.
> There is a lot of embedded knowledge in existing implementations,
Agree. The question whether to rewrite and/or whether to use any new implementation should take this fact into account.
> Rust deals with just one small class of bugs but drops a lot of this knowledge in the process.
Hard disagree. Rust explicitly deals with several very important classes of bugs (memory safety and concurrency), and also aids correctness via other helpful design features like tagged unions and immutability by default. But Rust, the language, does not drop any knowledge in the process, though any decision to rewrite in any language may drop some knowledge, and/or may create new bugs, in the process.
> I would generally be in favour of just introducing better memory management to C/C++ and hard enforcing it in particular repositories.
This is really easy to say, but in practice it just hasn't worked out, and there is loads of empirical evidence to back that up.[0] It is not as if market incentives don't exist to create better C/C++ code.[1] If you have a way to do it better, I have no doubt Google, half a dozen other hyper-scalers, and the US government will pay you handsomely for your solution. But, at this point in time, if this is the solution, I'm afraid it's time to put up or shut up.
[0]: https://www.usenix.org/conference/enigma2021/presentation/ga... [1]: https://www.darpa.mil/research/programs/translating-all-c-to...
> This is really easy to say, but in practice it just hasn't worked out, and there is loads of empirical evidence to back that up.[0] It is not as if market incentives don't exist to create better C/C++ code.[1] If you have a way to do it better, I have no doubt Google, half a dozen other hyper-scalers, and the US government will pay you handsomely for your solution. But, at this point in time, if this is the solution, I'm afraid it's time to put up or shut up.
It really wasn't too difficult to get high reliability for memory management in C/C++ which is also concurrency safe (I have active projects running for years like this). The difficulty was enforcing it so that you are reduced to a subset of the language and it has to be followed with discovery at compile time.
The trap I'm concerned we are falling into is the "just re-write the C/C++ project in Rust". I still believe the solution is in enforcing better practices at compile time.
Linux wants to lay claim to "the Rust kernel"
Entirely untrue. It may happen, but there is zero consensus to port Linux to rust. Not even the tiniest bit.
> Entirely untrue. It may happen, but there is zero consensus to port Linux to rust. Not even the tiniest bit.
... But I did not say there was a consensus to port Linux to Rust? I'm sorry you misunderstood.
Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust? I believe that there are many reasons why Linus chose to give Rust for Linux a chance. I believe at least one of those reasons is mindshare. If Linux chose not to experiment with Rust drivers, then that mindshare might go somewhere else.
>> Ubuntu wants to lay claim to "the Rust distribution"
Notice, Ubuntu is doing a similar thing. Canonical isn't porting all of Ubuntu to Rust. It is picking and choosing bits which they can, and would like, to move to Rust. Why? Probably for similar reasons. They want to seen as friendly to the Rust mindshare.
Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust?
This isn't a thing. Linux isn't laying claim to any such assertion.
If you want to know Linus's reasons, then read the LKML. He's quite open in all of his thoughts in this regard, and it has nothing to do with labeling Linux 'the Rust kernel'.
I don't know if this is some weird sort of advocacy, or you're just listening to a lot of over the top rust people, but nothing you're saying here is real.
>> ... I believe that there are many reasons why Linus chose to give Rust for Linux a chance. I believe at least one of those reasons is mindshare. If Linux chose not to experiment with Rust drivers, then that mindshare might go somewhere else.
Again, very sorry you misunderstood me. However, I am now pretty certain one of your difficulties is that you stop short of reading my next sentence, and then my next sentence after that. See my quoted comments above. I made very clear these are strictly my beliefs.
> If you want to know Linus's reasons, the read the LKML.
Perhaps when I said "I believe" I was being too subtle about what "my beliefs" are or what "beliefs" mean.
I hope you would agree -- just because one has expressed certain technical reasons/desires does not mean that there were not any unexpressed social reasons/desires, or what philosophers also call "higher order volitions" (long term volitions, or volitions about volitions), for one's actions.
Now -- I do not know but I do believe there may be social reasons for Rust being adopted in the Linux kernel, because I have read the LKML and I have reasoned about why Linux is experimenting with Rust drivers from things Linus and others have said.
Feel free to disagree, of course, but, in the future, please make more of an effort to avoid mischaracterizing me again.
Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust
Drop the "mischaracterising" routine. You're asserting specific things, so expect to get challenged when they're nonsense.
> Drop the "mischaracterising" routine. You're asserting specific things, so expect to get challenged when they're nonsense.
If I said "Coca Cola wants to lay claim to being the best cola soda in the world", I'm sure you would also say to me: "Patently untrue. Where exactly in Coca Cola's public statements are we to find that statement?!", instead of, perhaps reflecting, and asking yourself -- is that a reasonable belief for one to hold, given Coca Cola's marketing?
If I am not conforming to your expectations, perhaps it is because your expectations that need a reset.
Ubuntu wants to lay claim to "the Rust distribution" and it's hard to blame them when Linux wants to lay claim to "the Rust kernel".
You stated this as fact, as an active statement and goal. It isn't. At all. It's made up fantasy.
Trying to reframe things after, by changing that statement into "oh, that's just an idea I had!" and then blaming others, is invalid and dishonest.
You seem to want to blame others for your made up, untrue statements being challenged. Give it a rest. Your attempts to blame shift will gain no traction here.
You stated something as fact that is not. You were wrong to do so. You are wrong to blame me for pointing it out. You are wrong to continue complaining.
You are wrong.
Clear?
> You stated something as fact that is not. You were wrong to do so. You are wrong to blame me for pointing it out. You are wrong to continue complaining. You are wrong. Clear?
Ugh. Well, I suppose it must seem very unfair to live a life without the benefit of figurative language and/or subtextual meaning. Know that I'm praying for a cure.
Good luck sir or ma'am!
Nothing you alude to above is remotely accurate, and simply another attempt to redirect.
You've now crafted multiple lies, over your muktiple replies, to explain away your untrue statements. This too is wrong.
> Ubuntu continuously updates itself without permission...
It does default to installing security updates automatically. However, this is completely configurable.
It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective.
If you want different behaviour, just configure it as you wish.
> The Ubuntu packages, drivers and kernel are laughably behind Debian and even further behind mainline.
This just isn't a reasonable description of reality.
Unless you're referring to an Ubuntu LTS, in which case, of course it is: that's the entire point of Ubuntu LTS, and Ubuntu users have the choice of using the six monthly non-LTS releases if they want more up-to-date packages, which Debian users do not have.
> It does default to installing security updates automatically. However, this is completely configurable.
Man, but have you personally tried to disable it?
Did you stop apt-daily.service apt-daily.time apt-daily-upgrade.service and apt-daily.timer? Did you repeat the same but masking and disabling those services. Don't forget to repeat that for unatended-upgrades.service. Even after that whenever our CI fails an apt-get we have a pstree output to figure out what other dark pattern canonical came up with.
This whole debacle made me consider RedHat for my next install, and I use Ubuntu for almost 2 decades. It became unreliable in servers.
Dont get me started on the lack of security updates on "multiverse" packages which starts to include more and more packages and thus LTS means less and less. This is not innocent but so you buy Ubuntu One.
Their answer will be "just make your server robust to restarts bro", not really understanding the fact that some stuff simply cannot be restarted. We have Ubuntu desktop running a robot arm (not our choice of OS, but the manufacturer). Mid-operation snap decides to kill the robot that would otherwise be happy operating away and sending stats to the cloud.
I'm personally moving to Debian. It's 99% how Ubuntu used to be and most Ubuntu stuff is just a .deb that is relatively compatible.
> Man, but have you personally tried to disable it?
Sure. It's just a one line change in the configuration file (/etc/apt/apt.conf.d/50unattended-upgrades). Or, if you're doing a mass deployment, just don't install the unattended-upgrades package.
> figure out what other dark pattern canonical came up with
The mechanism is inherited from Debian. It isn't Canonical's architecture.
If you want to hack internals to do things in a more complicated way, then that's up to you, but you can't then complain that it's unnecessarily complicated.
> Sure. It's just a one line change in the configuration file (/etc/apt/apt.conf.d/50unattended-upgrades). Or, if you're doing a mass deployment, just don't install the unattended-upgrades package.
That answer shows you have not seen that pattern fail.When that fails or is overwritten by an update, remember my comment.
Ironically you just added another way to configure a simple thing, proving my point.
> It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective.
A better default behaviour would be to alert the user and allow them to choose to indefinitely defer by "accepting the risk". Some setups, rightfully or wrongfully, have a very long running time and cannot be restarted.
> If you want different behaviour, just configure it as you wish.
I'm not sure if it changed, but they made it extremely difficult on purpose. You can stop snap from updating, but then lots of other things also break.
> This just isn't a reasonable description of reality.
It's my experience with packages I use.
> A better default behaviour would be to alert the user and allow them to choose to indefinitely defer by "accepting the risk".
That would be terrible UX and is exactly contrary to Ubuntu's philosophy, which is to do the right thing by default.
The alternative is to bombard the user with questions that they're generally not in a position to understand, and force them to receive an education on stuff that doesn't matter to most users before they can use their computer.
> That would be terrible UX and is exactly contrary to Ubuntu's philosophy, which is to do the right thing by default.
Even in Windows (or at least it used to be), the decision to perform an update now was a user decision. Just killing off applications without warning is the worst UX ever. Randomly killing stuff off is the opposite of what I want my OS doing.
> The alternative is to bombard the user with questions that they're generally not in a position to understand, and force them to receive an education on stuff that doesn't matter to most users before they can use their computer.
It doesn't have to be like that. It could be: "Do you want to update now? The following programs are affected and will be restarted: X, Y, Z. [Learn more]" The answers could be "Yes", "Remind me on next boot", "Remind me later" (offers common delays, i.e. 1 hour, 1 day, 1 week).
What is should never do is take the power away from a user. I saw an Ubuntu user's system restart their snap programs in the middle of delivering a conference presentation without warning. That was the worst way that could have been handled.
I think you mean a magic bullet instead of a smoking gun :)
I meant "smoking gun" from a cyber security perspective, i.e. the conclusion or the final part of the investigation. "magic bullet" would also work here too though.
Evidence, particularly of a crime, that is difficult or impossible to dispute. [1]
Even with your explanation I don't think it fits here.
[1] https://en.m.wiktionary.org/wiki/smoking_gun
You seem to have inferred the wrong meaning of "smoking gun" and that's why your usage above doesn't make sense.
There's no valid reason cyber security people would take a well known idiom and repurpose it as you imply, and a quick Google suggests they haven't done this.
[dead]
Fish in a barrel!
> Ubuntu continuously updates itself without permission, killing apps and losing previous state.
What? Is this some snap thing because apt sure as hell doesn't do this without you configuring it explicitly.
Not sure what OP was referring to, but snaps are indeed a ridiculous problem.
There's no control of when snaps update, Ubuntu has explicitly said they will never add this.
There was no way to disable snap auto-updates until just last year(-ish?) when Firefox finally announced they would no longer support snaps and started telling people how to tear them out and replace them with native packages or Flatpaks. Low-and-behold, Ubuntu suddenly got the feature to disable automatic snap updates. After saying explicitly they would never allow it for years, and telling high-uptime users to instead block snap daemon network access via the firewall to avoid it.
apt won't on its own, but if you're using the official images there's probably a service running that's calling it, probably for security patches etc.
The bigger problem is upgrading packages deliberately but being surprised by the results. My team's current favorite is the upgrade process itself suddenly having new interactive prompts breaking our scripts.
> My team's current favorite is the upgrade process itself suddenly having new interactive prompts breaking our scripts.
This is how dpkg and apt have worked in Debian and Ubuntu pretty much since their inception. Look into debconf, dpkg and ucf configuration to learn how to integrate these with your automation. The mechanisms for this have existed for decades now and have not substantially changed in that time.
dpkg grew knowledge of Source lists suddenly?
If you're installing software from Debian/Ubuntu repos, you can only use aptitude or apt to my knowledge. Other tools give you the ability to install DEB files you already have, and manage what's on your system currently. And aptitude and apt are both well known for never having had a "stable" scriptable interface. In fact they themselves tell you that their commands are not stable and should not be used for scripting, despite no alternative mode or application existing.
Recently Ubuntu moved to apt 3 as well, which massively overhauled the tool from apt 2. All those scripts people wrote to use apt 2 (because there was no alternative) broke recently when they now had to use apt 3.
I thought DEBIAN_FRONTEND=noninteractive was supposed to avoid that?
That and a couple of -o's, like conf old (not sure, on my phone)
Ubuntu continuously updates itself without permission, killing apps and losing previous state
I've never seen this happen and I've run Ubuntu in production for years. Apt does not auto-update unless it's configured for unattended upgrades — and both Debian and Ubuntu allow you to configure unattended upgrades in apt. And unattended upgrades via apt should not kill running user processes or cause data loss.
The Ubuntu packages, drivers, and kennel are laughably behind Debian.
This is just plain wrong — even for the steelman argument of Debian unstable or testing, which are not intended for general use. Debian unstable and testing are on kernel 6.12. Ubuntu 25.04 is on kernel 6.14.
Debian stable, meanwhile, is on 6.1. Ubuntu has the far more-recent kernel.
I don't know what you mean by "drivers" — there aren't separate drivers on Linux from the kernel; they're shipped in the kernel. Ubuntu's are also more recent than Debian, since the kernel version is more recent.
With respect to packages, obviously I can't check every package version, but e.g. coreutils in Ubuntu are on 9.5, released in March 2024; systemd on Ubuntu is a version released this year (and until last month Debian unstable and Ubuntu were identical); gcc is identical; etc. While Ubuntu occasionally lags Debian unstable, it's not by much.
If you compare to actual Debian stable, it's not even close. Debian stable is ancient.
And ultimately... Why are you using Debian unstable? It's called "unstable" for a reason. It receives basically no testing. Even the "testing" version is more stable, and that's not intended to be stable at all and doesn't necessarily receive security updates. Ubuntu is less-stable than Debian stable, but far more up-to-date; Debian testing is less-stable than Ubuntu... And usually still not even as up-to-date. Debian unstable is basically untested; if you want that you'd be better served by a rolling release distro like Arch where the packages are going to be way more up-to-date anyway.
The Debian wiki cautions against treating unstable or testing releases as general purpose, so I truly don't think even this steelman is viable. [1] In fact, they refuse to even call Debian unstable a "release" since there are no release practices associated with it and the code is effectively untested.
Ubuntu is nowhere near my favorite Linux distro, but claiming it's more out of date than Debian is just FUD.
Debian is very very stable — at least, Debian stable is — and people love it for that. But the tradeoff is that everything in it is ancient. If you want something that's like Debian, but more up-to-date but slightly less stable — that's Ubuntu. If you want a rolling release, that's Arch. (And of course, there are even more-different distros like NixOS or ostree-based ones; there's the Red Hat universe of RHEL and the closer-to-bleeding-edge Fedora; etc etc.) Using Debian unstable is either a magnanimous act of sacrifice in order to help test future Debian versions, or it's self-harm.
Personally if I wanted to use a Debian-derivative on the desktop, though, I'd probably use System76's PopOS, which is basically a cleaned-up Ubuntu with some nice GNOME extensions. I'm more curious in the future to try out ostree-based distros, though, like the various Fedora Atomic ones, since they have nice rollbacks without the user-facing complexity of NixOS.
1: https://wiki.debian.org/DebianUnstable
I have the hardware for a new home server waiting to be set up (as in, I don't need a new home server i'm just messing around, so once in a while i log in and configure one more service).
I tried the latest Ubuntu and it seems to be targeted at either containers or desktops. Everything I wanted to set up networking wise was a pain for my little non standard configuration.
Ended up wiping it and installing Debian instead.
As for this Rust thing, first question that comes to my mind is what features are missing from this new godly impervious to hackers by default implementation.
After years of working with Ubuntu on desktops and servers, I can tell you that for a server Ubuntu will probably always be the wrong choice.
Ubuntu seems to find it necessary to always invent some new way of doing a standard thing. Like how they use netplan for networking, a tool they invented themselves for a task that already has industry standard options available, is missing basic features those alternatives have, and adds nothing the alternatives don't also have (including any better usability). They do this all the time, and have to eventually be dragged into the modern era when they finally get sick of having no community support for their one-off inferior tool.
In particular I'm just waiting for snaps to finally die. But at least that has some technical possibilities the alternatives don't, they just aren't functionally available in snaps yet. In another 20 years, if Ubuntu keeps at it with their unconfigurable, hardcoded, private snap registry and slow limited advancement snap portals-equivalent implementation, they might even have half as much functionality and packaged tools as Flatpak current has today.
---
If you want a decent server, Debian is a better option, even though they have some finnicky choices, and its enough like Ubuntu you might have some cross-ober familiarity. Some of the old standbys like Fedora aren't good options because of their frequent update schedule and lack of long term support, but there are also some very good niche options if you can dig a lot more.
Also worth noting: if you want to keep the server working, you should plan on pretty much everything being in containers. It adds some complexity to what you're doing, but keeps each little experiment isolated from the others and avoids polluting the global system.
When there's Debian, Ubuntu is moot for servers and personal use (for power users at least).
One of my former colleagues used to install Ubuntu servers. I replace them with Debian when I get the chance. I was already blacklisted for Snap, so I can't re-blacklist them for going uutils and sudo-rs, and that's sad (as in Bryan Cantrell's famous talk).
Worth mentioning that many packages on Ubuntu are only available via snap, which includes docker-cli, so they cannot be used inside containers.
> Ubuntu is the most widely deployed Linux operating system
Nitpicking, but I thought Android was the most widely deployed Linux OS around...
You are correct but in this context Linux means GNU/Linux.
Bit like how tomato is technically a fruit but everyone knows that in the context of a supermarket it’s a vegtable
Ironically, Ubuntu's efforts to replace its GNU components with non-GNU alternatives is very quickly going to turn it back into just Linux.
That's the logic Oracle uses to say Java is the most widely deployed language in the world, because it runs on phone sim cards and credit cards
I think that's alright?
I was Ubuntu user until they've introduced snap and started forcing it down everybody's throat. No more Ubuntu for me.
>> I was Ubuntu user until they've introduced snap and started forcing it down everybody's throat. No more Ubuntu for me.
What issues did you have with snap packages?
I am not aware of any problems with snap packages.
They have some pretty nice features compared to traditional packages:
https://snapcraft.io/docs/get-started#p-19156-connect-an-int...
If snap packages have caused problems for you, what were the problems?
Big and slow.
For me it was their begging for money on install.
Would you prefer the Microsoft way of begging for money before install?
Canonical has some interesting ways:
https://www.theregister.com/2021/02/11/microsoft_azure_ubunt...
I prefer the Arch way of "begging for money on install", which is to say, none at all.
I currently prefer Debian
Maybe "deployed" is the key word here. Android is treated like a fixture of mobile devices rather than a fungible Linux distro.
Linux kernel yes, there is very little GNU/Linux userspace on Android.
[flagged]
> we do not need a flame war or chain of comments about what RMS' valid points were, when he was being (tremendously but unintentionally) offensive, and when he was merely being overly pedantic
If your intention is to not start a flame war, you might want to avoid contraversial topics such as the obviously manufactured canceling of RMS by the-powers-that-be.
And if you do want to see some flame war about the real RMS cancelling, here you go: https://news.ycombinator.com/item?id=22299156
Yeah, I remember that. That canceling was exactly what I referred to. I didn't mean to imply that the canceling was fake by putting it in the quotes, but that it was intentional and orchestrated. I've removed the quotes to avoid further misunderstanding.
Ubuntu is the most widely deployed Ubuntu operating system
Android uses the Linux Kernel, but iirc (correct me if I'm wrong), it doesn't come with the required application to make it Unix and hence is not the Linux operating system. That would mean it's only using the same kernel as the Linux operating system?
Idk, just speculating to maybe get the thought process
> That would mean it's only using the same kernel as the Linux operating system?
There's no "Linux operating system". Linux is the name of the kernel. Android is an operating system, GNU/Linux is, things like BusyBox/Linux are. They're all operating systems that use the Linux kernel.
Linux is a perfectly good operating system. If you're motivated enough, you can boot Linux straight into your software without any other dependencies at all. Linux operates the system just fine all by itself.
There's this weird definition of "operating system" which means "some sort of platform with a shell and little commands like cp, ls, etc.". That's just what POSIX tells people an operating system is, not the ultimate truth. It doesn't have to be that way.
You kinda blew my mind just now. I never considered an operating system as a collection of packages before (conceptually speaking).
Uh, didn't I say exactly that? Gnu/Linux Is just collegially known as "Linux" and the operation system suffix made it clear what he was talking about. I didn't come up with the usage of the term, I was merely trying to interpret their words.
there's competing specs, holy wars, etc. but POSIX is kind of like what you're describing. popular distros are usually mostly-but-not-completely compliant.
There was also the https://en.wikipedia.org/wiki/Linux_Standard_Base , but unfortunately it wasn't particularly successful.
> it doesn't come with the required application to make it Unix and hence is not the Linux operating system.
Linux is not a Unix https://en.wikipedia.org/wiki/Unix-like
Some would say that Android isn't Linux OS[1]. It runs Linux, in same way Linux runs Wine. As a (POSIX) compatibility layer.
[1] because it doesn't abstract the hardware platform, doesn't multiplex hardware, nor protect software principals from each other https://www.youtube.com/watch?v=36myc8wQhLo&t=8m48s
Seems like the trifecta group is /just/ about migrating tools to rust? Am I understanding that right?
I don't have a problem with it, specifically. Seems odd that they don't advertise it, though.
The other big thing iirc is they’re all MIT licensed rather than GPL(et variants) licensed
Sudo is permissively licensed. https://www.sudo.ws/about/license/
Ah, interesting to know. I guess it is only the coreutils stuff where that is a concern
[flagged]
Politics is just everything. "No politics" usually means, "Opinions which conflict with mine are unwelcome" or at best the small-C conservative idea that the status quo has existed forever and so whatever happens to presently be the case is just how things should be.
In your own comment you mention "actually the best outcome" but that's a matter of politics, doubtless you have different ideas about what "best" would be than I do, and I appreciate that perhaps you've never considered that anybody other than you could be right, but you might want to take a moment to think again.
> Politics is just everything.
The point is that they seem to have conflated opinions about what policies are correct for general real-world issues, with those that are specific to the task of programming.
> "No politics" usually means
No; "no politics" usually means "please do not attempt to bring up topics that relate to decisions made by governments, and instead stay focused on topics directly related to the project at hand".
> or at best the small-C conservative idea that the status quo has existed forever and so whatever happens to presently be the case is just how things should be.
I have never understood how this argument makes sense to anyone. Obviously, "changing the status quo" is a policy position in a way that "not changing the status quo" isn't. The argument is effectively that it's impossible to just not care about something, for any given thing. I refute this by noting that an effectively unlimited number of policies can be proposed, yet I am not constantly thinking about politics.
> but that's a matter of politics, doubtless you have different ideas about what "best" would be than I do, and I appreciate that perhaps you've never considered that anybody other than you could be right, but you might want to take a moment to think again.
Again, I can't fathom how this line of argument makes sense to anyone. "Politics" is, quite simply, understood by the overwhelming majority of people in such a way that determining "best outcome" for a computer program not used in any government capacity is obviously not a political matter.
Or else: in your view, what does "should `sudo` do X in Y situation?" have in common with "should country X go to war with country Y?" ?
> Politics is just everything. "No politics" usually means, "Opinions which conflict with mine are unwelcome" or at best the small-C conservative idea that the status quo has existed forever and so whatever happens to presently be the case is just how things should be.
Everything is political in the same way that everything is offensive and everyone is evil. As in, you're welcome to go around saying that, but don't expect people to find this to be an enlightened perspective.
You've always encountered this, it just not (until recently) had a _whole language_ to migrate to. It's this strong impulse to do things the "right way" which is a very good instinct, but always has the danger of becoming "rigor theater". It's the same any time anyone proposes to "just" port to a new framework, or runtime, or platform, or language.
Tale as old as time.
We've accepted it at this point, but I wonder if the religious element of GNU tools and free software in general was as contentious way back when.
A little while ago I realized with a start that it's been years since I've heard anyone angrily insist on calling it "GNU/Linux", when that was constant background noise during the Slashdot era. One of those old fights that just faded away, I guess.
Oh yeah, I got to meet Stallman at a book signing when I was like 17, and like an idiot happened to wear a "Linux" shirt.
I genuinely hadn't thought of this point of contention beforehand, but oof he did not care for that.
Did you tell him you were a fan of just the kernel, not the userland?
I got him to imply I was being cheap!
A lot of the userland _isn't_ GNU any more, people use a lot of alternatives for once much more dominant GNU tools, and people use a lot more commandline tools which have no relation to GNU. Systemd took over and for containers there's no init. Plenty of alternative libc implementations as well.
GNU is nowhere near as dominant in the non-kernel code that people run any longer.
And a lot of the GNU zealots who were particularly interested in getting credit with naming got old.
Its more that it ceased to be true: you can build a "nognu" Linux now, with LLVM as the system compiler, and musl/libc++ instead of glibc/libstdc++.
https://distfiles.gentoo.org/releases/amd64/autobuilds/curre...
Or use Chimera Linux.
That's true. I find myself still saying GNU/Linux where it's relevant (e.g. when referring to the userland, or a compatible userland) but it's not as contentious as it used to be, which is a nice breath.
St IGNUcius has been a thing for a quarter century at least https://stallman.org/saint.html
GNU sort of lost its way around GPLv3 (it gives cloud services a free pass, but not locally run software, which is the opposite of letting users control what their computer does).
That killed most of the “user freedom” enthusiasm of the early days. These days, there’s the AGPL, but that’s mostly used like the BSL (“if you want to use AGPL in production, pay us”), than for bootstrapping freedom-respecting compute environments.
If you disagree, show me an AGPL userland that’s appropriate for daily-driving.
I’m slowly migrating off Linux to the BSDs these days. The politics seem less destructive to the user experience with them.
What kind of free pass would you want to give to locally run software?
Can't you already do anything you want to GPL code locally?
I think it is not that local code does not get a free pass by itself but the combination.
By letting cloud services that use GPL software stay closed source it actively encourages development of cloud based tooling in a commercial context and users end up getting forced to sign up with and connect to a closed source cloud service they have even less control over than traditional locally running closed source software.
I think Stallmans motivation for the FSF includes a story about modifying a driver for a printer to support new features. Now imagine if that printer had a cloud based interface and imagine how the GPL would help Stallman add features for a new printer to it. It doesn't, if he wanted to fix the interface he would have to reverse engineer it from scratch. 40 years of FSF and it lets a decades old trend run circles around its goals.
> By letting cloud services that use GPL software stay closed source it actively encourages development of cloud based tooling
This is why AGPL was invented. You might use my AGPL code in your cloud service, but you need to provide the source code you are running to your clients. You are not allowed to keep any secret sauce secret from your users.
MIT and BSD (and plain GPL) don’t protect users again abuses like this.
GPLv2 was fine. AGPL is fine.
V3 is incompatible with selling bootloader locked software stacks (pretty much all consumer hardware these days).
Concretely, I can’t do this local thing: Take GPLv3 software, build a board, link the software to vendor blob firmware (~ all current hardware requires this step), flash it to a ROM on the board and sell it to you with a copy of the GPLv3 software’s source code.
I can take the same vendor blob, add a TCP stack, and have your device shell into a copy of GPLv3 software with closed source modifications running in my data center.
This has massive negative consequences for users of GPLv3-reliant IoT crap and cloud services.
> V3 is incompatible with selling bootloader locked software stacks (pretty much all consumer hardware these days).
Which is great. It prevents enshitification of consumer devices.
If you look just at consumer devices, it's great.
But their argument is that blocking that loophole, while not blocking an even worse loophole, caused more harm than good.
In other words we should have moved as much as possible directly to AGPL, and left the rest on GPLv2.
> The religious element
It is only "religious" if you think it in such a way.
I'd say the amount of skepticism (rather than valid criticism) has been no less than enthusiam in the community.
As the saying goes, there are two kinds of languages...
[flagged]
[flagged]
Not like GNU is any less religious...
I think they just want to ditch GNU tools and lots of young, low level programmers want to use Rust (same rationale for Linus accepting Rust code into the kernel).
sudo isn't GNU though.
I mean, I don't necessarily use rust a lot and it's not even possible to "use" in most cases in my domain (machine learning engineering)... But to say that it's religious is just weird. It would have been super easy to portray as religious every push for better engineering practices in other fields, in fact I bet that it would've happened if the internet was common back when people were doing exactly that for say, civil engineering or mechanical engineering.
It is almost always the case that proposed changes to the technology stack of a project is intrinsically political. Unless every participant is equally proficient with the new thing as the old thing, then the proposed change is a de facto power play which will change the balance of power and experience and consequently usher in a reorganization.
This is why so many Linux developers resists the addition of Rust or C++.
> The religious element of rust programmers
Yeah. I too, hate the Rust Evangelically Orthodox Later Day Christians.
Oh, wait... You're serious. What is religious about rewriting tools in Rust? Isn't that what most programmers do for fun and learning?
Is it any more religious than worshiping Alan Kay or Dijkstra?
> It makes me wonder how much is motivated by stuff other than what’s actually the best outcome.
Looks in the thread... Sees https://www.sudo.ws/security/advisories/
Are you sure the status quo is the better outcome?
>What is religious about rewriting tools in Rust?
"Religious" isn't being used to refer to people rewriting tools in Rust.
It's used to refer to people zealously commenting on message boards that every single tool ever built should be rewritten in Rust, and if you aren't rewriting your tool in Rust, you're an idiot.
> It's used to refer to people zealously commenting on message boards that every single tool ever built should be rewritten in Rust.
Ok, but between me, GP and the article, who said that? Where are the Rabid RIIR fans?
And before you misquote me, I said, why wouldn't you rewrite stuff in Rust, if the status quo is ridden with bugs, and safety issues? And why shouldn't a Linux distro switch to it if they desire.
>Ok, but between me, GP and the article, who said that? Where are the Rabid RIIR fans?
The person you replied to said: "The religious element of rust programmers seems more extreme than other languages."
You interpreted that in a way that ended up with you asking "What is religious about rewriting tools in Rust".
I clarified that the typical way "religious element of rust programmers" is interpreted is not the act of rewriting tools, but the proselytizing about rust on message boards. I then gave an example of what that proselytizing typically looks like (which was not a claim that you said something like that).
That is the "religious element" being referred to. The proselytizing is the religious element, not the act of rewriting tools in Rust.
(The meme "Rust Evangelists" didn't manifest out of thin air because people hate memory safety or whatever -- it's because people are really, really passionate about Rust, and are vocal about that passion)
> The proselytizing is the religious element, not the act of rewriting tools in Rust.
Ok. Where is the proselytizing taking place in the article?
Is the sudo-rs did work, the proselytization? Where is it?
> The meme "Rust Evangelists" didn't manifest out of thin air
That's not how memes work. It's just something that appeals to some group that spreads it. It can be true, false and fabricated out of thin air.
What if I told you, that "What if I told you" meme isn't what Morpheus says to Neo? The scene itself is so divorced from meme it doesn't carry much resemblance (here https://youtu.be/L8H9DqkrkcY)
>Ok. Where is the proselytizing taking place in the article?
It's not? It's like you're picking random words out of my comment to quote without bothering to read what I'm writing. Nothing of what I said is about the article. It's about your misinterpretation of what fossuser meant when they said "religious element".
I can't explain the same thing for a third (fourth, I guess? since I just tried again) time, I'm running out of different ways to say it. So I'll just leave it there.
Your meta-commentary on memes is neat and all, but again, somehow, completely misses the point I was making.
> It's about your misinterpretation of what fossuser meant when they said "religious element".
My point, where is the proof of that "religious element" beyond memes? Is it in the article? Is it in the links? Where can we see this religious fervor in action?
The article is very matter of fact. I expect people to be matter of fact as well.
I swear to God, I feel like I'm asking for the Individualist Eleven book, and everyone asserts me it exists, and they read it, but no one can ever finds it.
> Your meta-commentary on memes is neat and all, but again, somehow, completely misses the point I was making.
It's necessary because memes aren't real. They might have started based on some interactions that 10 years ago, but by their nature they will mutate and twist.
>My point, where is the proof of that "religious element" beyond memes? Is it in the article? Is it in the links? Where can we see this religious fervor in action?
You can argue with fossuser about the validity of what they said.
I'll offer my opinion, which is not some proof from god or anything that you seem to be seeking, which is that I find significantly more annoying comments from Rust users, about how something should be rewritten in Rust to fix everything, than any other language. But, again, this is not proof from god. I'm just a guy making an observation based on my lived experience. You have a different lived experience. Glad we could clear that up.
> which is not some proof from god or anything that you seem to be seeking
You know what, you or anyone else can start with actual proofs. I don't want your lived experience and memes as proof, I need messages, posts from people (bonus points for sudo-rs members) that show how zealous they are about Rust and rewriting all the things in it.
I'm a Java dev, that just dabbles in Rust. I've seen observed many claims about Rust zealotry with no actual proof. Whenever I ask for them, I get a blank stare and dodging.
Hence, my comparison with the book from Ghost in the Shell. It, too, was a meme, an actual memory virus. Everyone read it, and no one could find the proof it existed.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Have fun.
(I'm sure if I pick any specific quotes, you'll start arguing the semantics of what is "zealous", how whatever number of comments I pick are outliers, or not proof enough, etc. So, here's one query, of many, that you can pick through.)
In the end, I really could not care less if you agree with the characterization or not. But your enthusiastic defense is fun. If you keep going, you'll be coming close to being an example yourself!
Fine let's dig in: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... I'm analyzing the first page
First, a simple grading system: 0 - No RIIR sentiment 1- Joking or 2 - Mentioning Rust in positive light 3 - Suggesting Rust positive light for project 4 - Asking for RIIR, saying stuff like this wouldn't happen in Rust 5 - Demanding RIIR
In summary, there are 28 items on the first page, totalling 38 points. Doing an average, it's about 1.35 points, which suggest that on average, people are somewhere between joking about RIIR and mentioning Rust in positive light.However actual number of RIIR between 2-5 depending how you look at it, 5-17%. Assuming the rest of pages have a similar spread, and that targeting only keywords of RIIR captures accurately the sentiment - I suspect the latter is the case. I've seen more negativity about Rust in https://news.ycombinator.com/item?id=43910745 in few hours, than positivity about Rust in several days.
And I've seen my comments that are positive about Rust get way more downvoted, than comments skeptical or negative on Rust.
So sudo is ridden with bugs and safety issues, as opposed to the Rust alternative? I came across a lot of ridiculously absurd logic bugs in the Rust version. Maybe you can still see GitHub Issues.
[dead]
The comment you responded to says: "Seems odd that they don't advertise it [the usage of Rust], though."
Isn't not advertising a language the polar opposite of being religious about a language?
I am all for a memory safe sudo and I don't care which language it is written in, use C, Ada, Rust, as long as it is a suitable systems programming language understood by a community of developers and you can proof memory safety to an acceptable degree. If the people first to do it in an such an way happen to use Rust, not accepting that based purely on the language is what would sound religious to me..
Maybe this protectionist reaction (see recent drama within the Linux kernel) is every bit as religiously colored as some people claim Rust people are.
I mean memory safety? What comes next? Not allowing us to use after free like true men would? \s
I don't have a strong opinion on what language - the bit you edited in what I was replying to changed the meaning of what they were saying.
My reply is flagged dead now which is fine since it did create an unproductive thread, but it was more that I had noticed Rust as a community seems to have more of an identity based political bent around it more so than other languages. Something I've also noticed with Mozilla - it's not just the language, but that the language signals you're a certain kind of person with a certain kind of politics in addition to the general pro-rust stuff.
I don't recall seeing this combination elsewhere with other languages before - though there have been religious like battles over languages forever, but I don't think it's been predictive of someone's political identity before?
> but I don't think it's been predictive of someone's political identity before?
This is a pretty astounding claim. On which data did you base that conclusion? Because if it is purely anecdotal, you might consider that this is a bit like with Apple fanboys. Apple generally makes good products. Most people who use their stuff don't even talk about it, but those who do talk about it tend to have strong opinions that extend the quality of Apples products themselves.
But these opinions are not even remotely representative of the broad majority of Apple users.
Rust similarily lends itself to fanboyism, because the language has a strong narrative going for it, that is part of its success. The narrative isn't even a bad one: create a programming language that makes certain common classes of mistakes impossible and others much harder. Like every topic with strong narrative this will draw in a certain amount of people who will strongly defend said narrative, but those aren't necessarily the manority of the people who use the language.
So unless you made a proper poll that tries to select for a broad set of Rust users instead of basing your judgment on a loud online minority I wouldn't be confident in the result.
I with "identity based bent" you mean they are inclusive and have strong community rules, it might just be that this is normal where the Rust users are from. Last time I checked Rust was very popular in European countries and over here these kind of rules are pretty off the shelve standard. But please tell me this isn't about you calling them "woke" and confusing basic human dignity with politics.
There was recently that article about Python switching to a proof verified C crypto library. Yes, I welcome verified C code. But Rust is much easier to use instead
Tho the extra properties re side channels in said verified code outdoes Rust, so I'd also say it'd be undesirable to replace that C code with Rust
[flagged]
It's not religious. Memory safety is a thing. If by politics you mean the government: they only got started recommending memory safe languages once it became clear that foreign actors were going to keep exploiting C / C++ vulnerabilities.
https://www.theregister.com/2024/11/08/the_us_government_wan...
So why are we not using Ada / SPARK?
Indeed Ada found popularity for aircraft software
Rust is part of a modernized iteration in language design this century
Nobody is calling for Ada code to be rewritten in Rust. But at this point you'd want an argument to choose Ada over Rust when it has become more widespread, especially in open source projects
Here's someone else's take on your question a few years ago: https://news.ycombinator.com/item?id=28347930
Just for the curious, Ada is used in these industries:
- Avionics
- ATM
- Space
- Rail
- Automotive
- Defense
- Security
- Medical
https://www.adacore.com/about-ada
You can find lots of resources here to learn Ada / SPARK: https://learn.adacore.com or just to see what is up. Alternatively, there are good blog posts, too.
I thought I should reply separately to your comment, but I do not see how he got to the conclusion "in other words, if your goal is to write a (say) safe implementation of the DOM that can render real-world web pages while efficiently using memory on a general-purpose computer, Ada is probably the wrong tool for the job.". My only "issue" here would be its verbosity, which is why I choose C still quite often.
They were opining that Ada is unsuitable for fine grained data structures (like Rust being awkward with linked lists) & lacking mature graphics APIs
For years I used a C window manager I wrote which was less than 150 lines[1], it can definitely be a terse language. But I've also written pretty tight Rust code for a card game engine & its http server. I don't think Rust is particularly more verbose. Rust code can be artistic too[2]
1. https://github.com/serprex/nobox/blob/master/nobox.c
2. https://github.com/serprex/Kelxquoia/blob/master/src/main.rs
To be honest, I have not yet written Rust seriously, so I cannot comment as much on it. I mostly use C, OCaml, Lua, at times Perl, these days. I do not know how much the language would feel like it is getting in the way of "expressing" my thoughts.
https://github.com/serprex/nobox/blob/master/nobox.c is definitely terse. :D I get lost just by looking at it; a little bit of refactoring (indentation-wise) would help though.
Why does it matter, really? I mean sure, ada could've been an alternative language that everyone pushed for using but it kind of missed the boat due to historical circumstances , the context around its early use, etc. It might even be that rust users are just more enthusiastic and have been able to push more... But so what?
But why does it matter if the language that has seen some traction in terms of "rewriting software in safer languages" is rust? At that point it becomes even more religious to just reflexively oppose rust because "well why didn't x or y see the same push??"? Again, it really doesn't matter why!
This sounds like a dismissal. It is worth getting rid of the misunderstandings of Ada. It is worth letting people know that safe alternatives to C do exist and have existed long before Rust. You said it yourself that the issue may have been historical circumstances, in which case it should be clarified. Ada has a lot of great things built-in to the language. I especially love its type system and constructs for concurrency. Imagine if it had the hype of Rust, as a better alternative to C (which it easily could be). It goes further than Rust when it comes to safety, there is a reason for why you can find it in critical software.
> But why does it matter if the language that has seen some traction in terms of "rewriting software in safer languages" is rust? At that point it becomes even more religious to just reflexively oppose rust because "well why didn't x or y see the same push??"? Again, it really doesn't matter why!
If it does not matter, then why not Ada / SPARK indeed? I am sure the whys matter to some extent.
Again it doesn't really matter imo. There's no reason for ada rewrites to not take place, but I don't seem to come across a lot of community projects aiming at rewriting, say, coreutils in Ada. That's maybe due to the lack of hype (something rust doesn't lack at all). But regardless, I think that most people know and have know that memory safe alternatives have existed for a while.
It comes across as if many people think Rust is the "most memory safe alternative". I dunno.
I did start writing coreutils in Ada but I gave up. :(
I agree that it does seem like there's a misconception that there's "C or C++" (system languages) and "the rest" (memory safe but not system langs).
Which is obviously false, and I think the novel thing about rust's hype is that it's always compared to C or C++ (instead of java or c#, for example).
I think that's why it feels like it's the only language that is talked about when discussing "memory safety" (even if most mainstream languages are memory safe now). Go had a similar "system lang" hype to it until it was clear that it really wasn't.
Ada is undoubtedly a systems language (as you said it's been used to build insanely complex systems and it did just fine), but from my POV the little marketing that it has doesn't emphasize that.
I think though one of the reason ada doesn't get discussed a lot is that it doesn't have a big open source community. Ada could even be more popular in terms of actual LoC written, but most of that development is held behind very closed doors, so it's very hard to actually get a community going. Which then makes it hard to actually go through a full rewrite of things like coreutils.
Why is HN downmodding this? We're programmers, surely we all agree memory safety is a thing? Infosec people surely all agree that foreign actors have been exploiting vulnerabilities for the last three decades?
I'm not complaining about the downmods, I'm just weirded out - it's like a music forum disagreeing that flutes are real.
Trump administration also rescinded this I believe.
Not particularly. Some of this stuff started under the last Trump administration as well. We'll see.
It's all sides of government.
Edit: all links now fixed.
____
(generated, but with references)
# U.S. government guidance on memory-safe languages
Here's the list of links to U.S. government documents recommending memory-safe programming languages for cybersecurity.
1. *White House ONCD - "Back to the Building Blocks" (Feb 2024)* - Encourages developers to use memory-safe languages like Rust, Python, Java, C#, Go, Swift to reduce vulnerabilities. - Link: https://bidenwhitehouse.archives.gov/wp-content/uploads/2024...
2. *CISA, NSA, FBI, and partners - "Memory Safe Roadmaps" (Dec 2023)* - Recommends memory-safe languages (C#, Go, Java, Rust, Ruby, Swift) and roadmaps to eliminate memory issues. - Link: https://www.cisa.gov/resources-tools/resources/case-memory-s...
3. *NSA - "Software Memory Safety" (Nov 2022)* - Advises using memory-safe languages like C#, Go, Java, Ruby, Swift to avoid C/C++ vulnerabilities. - Link: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
4. *CISA - "Urgent Need for Memory Safety" (Sep 2023, updated Dec 2023)* - Promotes memory-safe languages as part of the Secure by Design campaign. - Link: https://www.cisa.gov/news-events/news/urgent-need-memory-saf...
5. *White House press release - "Future Software Should Be Memory Safe" (Feb 2024)* - Calls for memory-safe languages to reduce cyberattack surfaces. - Link: https://bidenwhitehouse.archives.gov/oncd/briefing-room/2024...
6. *NIST - "Safer Languages" (updated Oct 2022)* - Highlights memory-safe languages like Rust and Ada to prevent common vulnerabilities. - Link: https://www.nist.gov/itl/ssd/software-quality-group/safer-la...
What your parent is referring to is that three of those links now 404. Some of that is simply because whitehouse.gov gets redone with new administrations, and so old stuff is thrown out. They're also referring to how the Trump admin is talking about seriously reducing CISA's budget. Things like that.
All the links are now fixed and return OK now. I don't think Whitehouse data archival is what the parent was referring to.
There were a lot of people online misinterpreting it, it’s possible they saw one of those threads.
I was one of those people indeed, and I appreciate your clarifications in this thread.
Memory safety is strictly a good thing, regardless of motivations.
But I'm aware that some people are frightened of new languages and paradigms especially if they're 'harder' than what they're used to.
Only if you don't buy any downsides with it. That makes it situational dependent. For example: - less people being able to read the code, work with the code, find (security) bugs - slower I know, I know, rust is not really slower, and for sudo it probably wouldn't even matter. But safety isn't the be all and end all of software. There is a lot of software out there where memory safety doesn't matter, or matters a lot less than other aspects.
Supply chain attacks is a big downside no one ever mentions. Even sudo-rs drags dependencies in from Github at build time instead of being self-contained, which is just an absurd thing to do for such an essential tool, especially in the current political climate.
1) every dependency comes from crates.io, not straight from GitHub
2) the dependency list is tiny
3) it uses a cargo lock, so even if it were using a GitHub dependency, that file keeps a hash of the dependency and points at the specific commit, so if the dependency were to introduce a backdoor it wouldn't be automatically picked up and a commit history rewrite would also fail
https://github.com/trifectatechfoundation/sudo-rs/blob/main/...
>"But I'm aware that some people are frightened of new languages..."
I am not frightened. I program in many languages and have no problems grasping Rust concepts. However I find Rust way too opinionated and restricting for personal tastes. For business I can not see myself replacing C++ with Rust unless my paying clients specifically request it. So far not a single one had expressed any interest.
This is not a new paradigm. It is a limitation in the design of the borrow checker, which causes you to go around until the borrowing takes on mainly a tree structure.
Did sudo have memory problems? Did it ever fail because it didn't handle its memory correctly?
There's been cases[1], of particular note, the unescape overflow one[2]. This one scathed the reputation of sudo enough to get people pushing for alternatives such as doas. The track record of vulnerabilities in general leaves a bit to be desired, even outside of memory vulns.
[1]: https://www.sudo.ws/security/advisories/
[2]: https://www.sudo.ws/security/advisories/unescape_overflow/
Sudo had quite a few problems with security, partially because of this doas was developed for BSD. Some problems come from the huge amount of features(ldap, easter eggs, ...). sudo-rs reduces the problems by not implementing those features.
> Some problems come from the huge amount of features(ldap, easter eggs, ...). sudo-rs reduces the problems by not implementing those features.
This makes me wonder:
1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?
2) If these features are useful in the real world, will a Rust rewrite of sudo inevitably gain these features over time and end up with similar problems?
> 1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?
OpenBSD did this with their doas utility:
* https://en.wikipedia.org/wiki/Doas
"without a rewrite" means cutting down the existing code. A completely different program goes into the same category as "rewrite".
doas is 500 lines of C. Two orders is magnitude less than sudo yet still covers the core functionality. Sure you could grandfather”s axe your way into the final product, but difficult to see how a a hypothetical code base 1% of the original counted as anything but a rewrite.
Your phrasing sounds like you disagree with me, but you're saying the same thing, right? That doas is not an example of "without a rewrite".
2. While a feature may be useful, the question is how useful, and to how many people. sudo-rs is removing features that aren't used very much, if at all, and doesn't plan to add them, to combat this. Those users can still use the original sudo.
It can't end up with similar problems, due to the memory safety guarantee.
That's not to say that it won't create other ones.
There are many types of security problems beyond memory safety issues.
Ubuntu moving to a memory safe sudo implementation isn't actually that concerning to me. It's a good idea to have a smaller, safer sudo alternative as the default, as OpenBSD does with doas. Users can install sudo if they need it. My problem is that it needs to specifically be called something else than sudo. Again OpenBSD has doas, which to the users clearly isn't sudo, so users don't expect it to behave as sudo or configure as sudo.
By all means, write a better, safer, smaller, more secure version of sudo, but don't have command be sudo or sudo-rs, name it something else.
Removing LDAP is a huge problem for the more important sudo deployments though: centralized management of permissions is kind of a vital function.
Debian is currently in the process of dropping the direct LDAP support in sudo, in favor of sssd. From sudo's NEWS.Debian.gz:
> In practice, there are few installations that use sudo-ldap. Most installations that use LDAP as a directory service and sudo have now opted for sssd, sssd-ldap and libsss-sudo.
> The Debian sudo team recommends the use of libsss-sudo for new installations and the migration of existing installations from sudo-ldap to libsss-sudo and sssd.
Ah that makes more sense.
The features we specifically don’t support are those related to direct LDAP support within sudo, so things like loading a sudoers file directly from LDAP. Sudo-rs will use any user retrieved via NSS, such as when configured using SSSD to load LDAP users. And from the authentication side you can use whatever PAM supports, so anything like Kerberos etc, which again can be coupled with the same LDAP database.
Those people can keep using sudo; it’s not going away. The rest of us get better security.
Is it actually removing ldap or is it offloading to pam?
Could you clarify what you mean by more important sudo deployments?
Yes it has:
https://nvd.nist.gov/vuln/detail/cve-2021-3156
How does sudo-rs compare to run0? https://news.ycombinator.com/item?id=40205714
This one is easy: run0 is not implemented in a memory-safe language, but in C. It is likely to be hit by exploitable memory-handling bugs, like the rest of systemd, as has happened multiple times before.
An already existing and tested C software gonna have less bugs than a new rust rewrite
Sudo has had bugs filed and fixed that were found by sudo-rs.
It’s not that simple.
I don't believe that actually, neither does Ubuntu.
And if we're talking about memory bugs (which we were up to now), then definitely no.
But run0 is new C code anyway so I don't see how your claim is relevant.
A trivial Google search answers that. run0 requires systemd-type OS.
Given that Ubuntu uses systemd like the vast majority of Linux systems nowadays, how does sudo-rs differ from run0?
You might not have a systemd instance inside a container, but you still might want to switch user IDs there.
Podman has systemd inside, you can run0 in it
Surely that depends on the container? Podman doesn't artificially inject a systemd process as PID 1 by default.
Not all containers are on podman
The Lennart post about it explain it https://mastodon.social/@pid_eins/112353324518585654
He was comparing to "normal" sudo, but sudo-rs have the same problems he highlighted anyway
sudo-rs uses setuid.
run0 does not (and instead relies on systemd).
---
To answer your next question: setuid, while historic, is a bit weird, and is disabled in some environments, e.g. NoNewPrivileges.
sudo-rs doesn’t gratuitously require a root privilege daemon that regularly ships filesystem destruction and remote unauthenticated arbitrary code execution bugs.
If your bar is “I’ll tolerate such crap”, you may as well run your desktop session as root.
Nice technical argument, did Lennart bite you while you where sleeping?
If sudo does this, as you imply, why do Linux system still exist that are not part of a botnet?
Implication is that systemd does this, not sudo.
No one is rewriting systemd in rust?
I'm not aware of any serious project to do so, there's been some small projects, nothing on the scale of uutils or sudo-rs.
"This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components."
Somehow "maintainability" has never been something I'd ever associate with Ubuntu. Is it a reference to their source tree? That'd make a lot more sense than if they were referring to the OS itself.
Next they should adopt uutils[1] as coreutils, findutils, diffutils, etc alternative.
[1] http://github.com/uutils/
They are: https://jnsgr.uk/2025/03/carefully-but-purposefully-oxidisin...
Related discussion from 2 months ago: https://news.ycombinator.com/item?id=43403821
doas is a much simpler (and therefore better) alternative.
doas is a really bad option on Linux.
The Linux port has not been maintained for 3 years. Has unmerged rowhammer fixes and generally a yolo auth system best described as "dangerous". You are better off using a well maintained project, that includes the CVEs^Wwarts.
It's a mistake to think that `doas` on Linux is the same as `doas` on BSD.
We need a doas-rs port that is maintained, i guess.
Just as with the sudo-rs reimplementation, a doas-rs rewrite is not going to solve the inherent issues we get with SUID binaries. We are better off implementing better models (see ssh and run0).
Both implementations of doas for Linux have (the same) unfixed security issue:
- https://github.com/Duncaen/OpenDoas/issues/106
- https://github.com/slicer69/doas/issues/110
I have a hard time recommending doas over sudo on Linux when the issue has been fixed in sudo but not in doas.
Those should be closed WONTFIX. Neither doas nor sudo can protect you from the consequences of running untrusted code and must not attempt to do so because it adds needless complexity to safety-critical software.
Which distros still have TIOCSTI enabled in their kernel? I just checked for Arch and it's disabled.
doas is not a compatible drop-in replacement for existing users.
I did not claim that.
Here is my doas config:
It be read and understood without prior knowledge.Sudo: #ALL ALL = (root) NOPASSWD: C_ZFS
I have no idea what is going here, not sure what ALL means, why root is in (), etc.
Neither is sudo-rs. From TFA:
> some features of the original sudo will not be implemented in sudo-rs if they serve only highly niche use cases
I wonder if there’s one that hardcodes a simple policy like “members of the wheel group can run any command with a password, and a 5 minute timeout”, but is also sudo command line compatible.
That’s what 99% of distros default to, and it’s simple.
For my limited use case, alias sudo=doas seems to work fine.
I have been using sudo-rs for over a year. The only issue that I've had is running into `-E` being unsupported once every few months - which is arguably a good thing because I shouldn't be naughty and allow arbitrary envs to leak into a privileged session.
What are the implications of the license not being GPL?
sudo is already (basically) MIT licensed https://www.sudo.ws/about/license/
Oh well. Completely forgot about that.
That's good to hear.
sudo-rs is already default AerynOS (SerpentOS).
[flagged]
The point of the "memory safe" sudo was not only that though. They removed a lot of nice really rarely used features to make the attack surface smaller.