Ubuntu 25.10's Rusty sudo holes quickly welded shut

Two vulnerabilities in Ubuntu 25.10's new "sudo-rs" command have been found, disclosed, and fixed in short order. On Monday, Ubuntu security notice USN-7867-1 revealed two security holes in the new Rusty sudo command, whose arrival in version 25.10 The Register described back in May. The sudo is a separate project from the …

[ComputerSays_noAbsolutelyNo]

So, one can still create bugs in the safe language Rust?

[Androgynous Cupboard]

If one tries hard enough, one can create bugs in anything.

[Notas Badoff]

^#%@

Prose or porn: the difference is not in the language, it is in how the language is used.

[BartyFartsLast]

People can write shit code in any language, it's just more amusing when it's a language that's revered for its safety

[Kurgan]

New code, new bugs. This is why innovation is seldom good.

[botfap]

Copying an existing utility purely for the purposes of re-writing in today's fashionable dialect is hardly innovation. Its ego driven indulgence. Sadly we seem to be seeing that more and more within the open source ecosystem

[FIA]

Yeah, those bastards... how dare they spend their time doing what they want.

We should demand a refund!!

It's not like they're re-writing a utility that allows godlike privilege escalation in a modern language that makes a whole subclass of common mistakes harder, with the aim of making it easier to maintain and safer long term or anything like that.

;)

[Nolan748]

Passing this off as some trivial passion-project is so incredibly disingenuous. These half-baked alternatives are being pushed as the default for one of the most used Linux distros on the internet. No one has a problem that they're being developed in the first place, it's their forced replacement that's moronic.

[Anonymous Coward]

No one has a problem that they're being developed in the first place, it's their forced replacement that's moronic.

That's been the story of Linux from its very beginning.

One word: systemd.

[Dwarf]

Ahh an idea

Let’s get the rust team to target the systemd team and demand a rewrite of systemd in rust

That should keep all of them tied up for years

Then someone can have all the fun of trying to debug that, which should keep them occupied for another couple of years.

[frankvw]

"These half-baked alternatives are being pushed as the default for one of the most used Linux distros on the internet."

Which exposes the real problem here, as I see it: this is NOT an issue with Rust as a language; instead this is a QA issue.

When a privilege-escalating component is completely rewritten from scratch in another language (any language, for any reason) one would expect it to be extra thoroughly examined before being released into the hands of the Great Unwashed. It appears that what has done here has fallen somewhat short of that.

[Anonymous Coward]

Linux has QA? Really?

[Lipdorn]

Because C is such a simple language, there are tools available to prove whether the C code is memory safe, free from undefined behaviour and other bugs. Possibly a lot safer to simply run these tools on the existing C code and fix the bugs than to rewrite the whole program in a new language.

[Androgynous Cupboard]

Forgive me if my irony meter breaks with this comment.

This whole thread started with a joke and has continued as one, with lots of earnest opinions on how things should be done. I have particularly enjoyed the "rewriting things should be stopped" angle from people using Linux - go talk to the BSD people in the mid-90s for a take on that one - and that issue with application design rather the language itself somehow indicate this whole thing is wrong footed.

The nearest thing to a sensible comment so far is "new code, new bugs". This is true. Any rewrite starts with one step back, it's what happens next bit that's the important bit.

[Anonymous Coward]

Ego driven indulgence describes the whole open source community, they're all dick waving to some greater or lesser degree

Some of them are unknowingly exposing they're arseholes too

(Read it again, "they're" is correct)

[Anonymous Coward]

Your reminder about "they're" was too late. I'm still traumatised by my imagination generating images of Poettering et all bending over and parting their buttocks.

[Bebu sa Ware]

Re: re-writing in today's fashionable dialect

Copying an existing utility purely for the purposes of re-writing in today's fashionable dialect is hardly innovation. Its ego driven indulgence.

An alternate view one might hold is that recreating an existing non·trivial application with a new programming tool is one very effective way of testing that tool on a real world problem with the added advantage you have a reference implementation with which to compare the new version against.

Here the tool is the innovation – not the recreated application.

Although "[an] ego driven indulgence " does rather make one think of Rust.

(Hush now, child. Play nicely. They only want the best for us. ;)

[Blazde]

New code, new bugs. This is why innovation is seldom good.

In this case the old code has new bugs too..

sudo-rs has 5 low severity CVEs in it's entire 2.5 year history: https://www.cve.org/CVERecord/SearchResults?query=sudo-rs

During that time alone 3 high severity CVEs have been announced in the original sudo, including a memory safety issue: https://www.sudo.ws/security/advisories/

The goal of sudo-rs is not just to have a memory safe version of sudo but to reduce complexity especially in security sensitive areas so that logic errors are less likely and less severe. Time will tell just how successful that's been but so far it's looking like a worthy case of rewriting something from scratch however ill-advised that may be in general.

[MJB7]

Comparing CVE rates

> sudo-rs has 5 low severity CVEs in it's entire 2.5 year history: https://www.cve.org/CVERecord/SearchResults?query=sudo-rs

> During that time alone 3 high severity CVEs have been announced in the original sudo

That is the important metric. If sudo-rs has fewer bugs than sudo, then it's worthwhile. I had honestly not expected that result though; I had expected that old code like sudo would have had most of the bugs flushed out by now.

[R Soul]

sudo-rs versus sudo

People's Front of Judea, meet the Judean People's Front.

[Dan 55]

Absolutely. But rest assured they are memory safe bugs so there is no need to concern yourself while the userland bug count is set back by two decades.

[Taliesinawen]

The bug resides in programmers brains /s

Dan 55: “Absolutely. But rest assured they are memory safe bugs so there is no need to concern yourself while the userland bug count is set back by two decades.”

ClippyAI: “Although written in Rust, the vulnerability is a logic issue, not a memory safety bug”

[breakfast]

As the old saying goes: You can write Perl in any language.

[grumpy-old-person]

Memory safety does not prevent logic errors!

[DrXym]

Yes and nobody ever claimed different

[Doctor Syntax]

"this is quite common behavior in packages that ship replacements for older, more complex tools"

There's the quandary. If an application had been stable for a long time is there justification in rewriting it? Are there more undiscovered issues in the original version that outweigh the new ones which will be, at least initially, introduced?

[Bluck Mutter]

ninjed me!!!

It's 6AM down here in the land of the Kiwi and having just seen this article I would posted the same.

I have been using Unix since 1981 and Linux since 1998 and thus have never known a time when sudo didn't exist.

As you state, surely there are other fish to fry with Rust and not a utility that is decades old and given it's usage model, one that has been thoroughly vetted over this time.

Bluck

PS: Just checked and there is 22401 lines of C code in the Linux version of sudo....so not something where hidden bugs could exist:

pwd

/work/sudo-main/src

apparmor.c exec_preload.c net_ifs.c sudo_edit.h

conversation.c exec_ptrace.c openbsd.c sudo_exec.h

copy_file.c exec_ptrace.h parse_args.c sudo.h

edit_open.c exec_pty.c preload.c sudo_intercept.c

env_hooks.c get_pty.c preserve_fds.c sudo_intercept_common.c

exec.c hooks.c regress sudo_noexec.c

exec_common.c intercept.exp.in selinux.c sudo_plugin_int.h

exec_intercept.c intercept.pb-c.c sesh.c sudo_usage.h.in

exec_intercept.h intercept.proto signal.c suspend_parent.c

exec_iolog.c limits.c solaris.c tgetpass.c

exec_monitor.c load_plugins.c sudo.c ttyname.c

exec_nopty.c Makefile.in sudo_edit.c utmp.c

cat *.c *.h | wc -l

22401

[Doctor Syntax]

Re: ninjed me!!!

My view of sudo is that, irrespective of the age of the version or the language in which it's written, it has a basic flaw. If a user's ID is known then root access is only one password away, even if it has to be used twice.

It's there to solve a problem that doesn't need to exist. In 1981 subsystems such as printing had their own admin IDs such as lpadmin.

[Jamie Jones]

Re: ninjed me!!!

It seems to be a Linux user thing where they'll say "don't su to root!!! Use sudo - it's safer", and the proceed to list a bunch of commands the user needs to type, and every one of them is preceded by "sudo".

The linuxsphere seems to have the same reaction to responsible root use as it does to configuring swap!

[VoiceOfTruth]

Re: ninjed me!!!

Amen.

I have seen so many 'user guides' where sudo in front of everything. I think they all copy off each other. If I had 10 commands that needed to executed in sequence, I would write the guide thusly:

To avoid typing sudo over and over, sudo -s for the next bunch of commands. You will see where we exit back to an unprivileged user.

[Steve Graham]

Re: ninjed me!!!

Giving the default user full root access to everything is a Ubuntu thing. (Inherited in derived distros.) Many other Linux distros stick to the traditional Unix-y permissions regime. So, if I need to do system admin, I log in as root. That's the way I've always done it, and that's the way I like it.

[Liam Proven]

Re: ninjed me!!!

> If a user's ID is known

You miss the point. Without it, one user's ID _is_ always known. It's "root".

[R Soul]

Re: ninjed me!!!

"PS: Just checked and there is 22401 lines of C code in the Linux version of sudo....so not something where hidden bugs could exist"

Indeed. But WTF? Why is there so much code? How much of that bloat is actually useful or necessary?

FYI, BSD's su has only ~600 lines of code, all in a single file. I think it'll be much harder to hide bugs in that.

And why type "cat *.c *.h | wc -l" instead of "wc -l *.[ch]'? Less typing, fewer moving parts, etc...

[R Soul]

Re: ninjed me!!!

I mistyped a singlequote instead of a doublequote to annoy the pedants. Sue me.

[doublelayer]

Re: ninjed me!!!

Because sudo and su do very different things. Sudo has the functionality to allow users to perform only certain commands, to make per-user credential management possible without removing all the privileges, to have logging and monitoring of attempts, and a bunch of features that some people need and some people don't. Su lacks pretty much all of that. In situations where you don't need anything, personal machines often falling into that category, you can choose to save yourself the code and do without. You can also do without su by just allowing root to log in at the shell and no user account can switch to another. But if you include su, you do it because it does something you want, and if you include sudo, it's for the same basic reason. The benefits of sudo are often much more evident on multi-user shared servers, exactly the kind of systems for which it was first written and for which the entire Unix and Linux security model is designed.

[Liam Proven]

Re: ninjed me!!!

> Because sudo and su do very different things.

Absolutely. Valid point, well made.

Snag is that you didn't follow through to the logical conclusion:

"Su" is simple and does something simple. "Sudo" is complicated but does something still quite simple, just different.

Next step: is there something simple that does what sudo does?

Answer: yes, there is. BSD's doas.

[doublelayer]

Re: ninjed me!!!

How is that the logical conclusion and what does it really tell us? What you have in doas is something that does some of what sudo does with an amount of code between that of su and that of sudo. You lose reporting and monitoring, but maybe you didn't need it, but you still have per-user command filtering, but not as many options, and it's still bigger, which we have been using though probably we shouldn't as a proxy for likelihood to contain bugs. All we have from this is the fact that yes, doas also exists and could be another option.

[Liam Proven]

Re: ninjed me!!!

> Why is there so much code?

Exactly. This is the key point that the C-evangelists are missing. The original is pretty big and nobody with the skills has the time to carefully check 22 and a half thousand lines of C for concealed naughtiness or simple mistakes.

[Miko]

Re: ninjed me!!!

Also, the old codebases have been bouncing around for decades, so well-concealed naughtiness might indeed have been inserted in them during the long period before stricter code review policies. In my opinion, this is indeed a reasonable motivation for a full rewrite of old, hard to understand, suprisingly-big-for-what-they-do programs. But on the other hand, keeping feature compatibility with even the weirdest options and combinations risks keeping some carefully-designed design gotchas that makes the rewritten package more vulnerable than it needs to be.

[doublelayer]

Re: ninjed me!!!

Since the tool has access to a lot of important stuff if it has bugs, new vulns in it are found often, sometimes those vulnerabilities have existed for twelve years before you find them, and several of those vulnerabilities like this one or this one have been memory vulnerabilities, both of which let an unauthenticated person elevate to root without special setup, maybe it's not as crazy to think that memory security could be useful. That doesn't mean they did so correctly, but the "thoroughly vetted" argument falls pretty flat, as it does for many tools that get updates frequently enough that bugs slip in. We could argue about what is the best way to prevent that from happening again. Rust is definitely not a magic no problems language. However, when I can find you two problems it would have prevented and they're both that bad, maybe we need more than "but sudo's been around a long time" as a better option.

[Liam Proven]

Re: ninjed me!!!

> maybe we need more than "but sudo's been around a long time" as a better option.

Exactly! Well said!

That is what the "keep the old stuff it's fine" exponents are not seeing. The old stuff is not fine. The old stuff is a huge complicated mess.

If the choice is "carefully untangle that mess" -- for nothing, out of good will -- or for an Alexander to come along and take his sword to it, leaving it useless and thus a hole...

Then a better answer than chopping it to bits is to take the important functions and rewrite them.

Sudo was, as another commenter notes, TWENTY TWO AND A HALF THOUSAND LINES of the most famously unreadable unsafe compiled language there is.

Trusting it because it's 45 is foolhardy. Just because it has a grey beard and has been around forever doesn't mean you should blindly trust it.

[cookieMonster]

sendmail.cf

Can confirm, naively attempted modifying this file as a know it all teenager.

A very humbling experience. Got it working, eventually, but never told anyone, in case I was ever asked to look at sendmail again.

[BinkyTheMagicPaperclip]

Re: sendmail.cf

Very wise. I wrote very custom offline mail routing rules in Sendmail under SCO Unix. Once.

Never again, thank you.

More recently I had a fiddle with exim filter rules after moving e-mail accounts. That's an awful lot better, but not exactly casual user friendly.

[Kurgan]

Re: sendmail.cf

I have written a whole Exim config from scratch to manage a multi-domain scenario with bells and whistles. It works, it's easier than Sendmail, it's really versatile, but it's NOT EASY.

[Wily Veteran]

Re: sendmail.cf

I (vaguely) remember altering sendmail.cf on my 3B1/Unix PC at home back in the pre-internet days when mail required sometimes long bang paths and transport via uucp. It was not, as one of my physics professors used to say, "intuitively obvious to the casual observer."

[Dwarf]

Re: sendmail.cf

The AT&T 3B1 was a great machine with its 68k cpu and 1Mb of RAM, except for the squeggy power supply, but at least you could easily tell when it was working hard

I was lucky enough to have one with the DOS coprocessor board, which just about worked

It took a lot of space and maintenance with the hood up was fun.

[Steve Davies 3]

Re: sendmail.cf

A clear case of

Once bitten by 'sendmail.cf', twice shy' or 'Get the hell out of here if you think I'm going anywhere near that pile of fragile glass where one breath can make it fail'.

Yep, been there, got the mega size box of 'T' shirts to prove it. Sad that they are all size S when I need an XL

[Anonymous Coward]

Re: sendmail.cf

I never had too many problems with sendmail.cf, but at some point I came across a version of sendmail where you had to write a sendmail.mc file in an obscure macro language and then compile that to generate a sendmail.cf. It seemed like a clear case of trying to fix the complexity of sendmail.cf by adding unnecessary extra complexity.

At that point I gave up and switched to a different mailserver.

[Jamie Jones]

Re: sendmail.cf

That's the recommended way of changing .cf files!

I never bothered - why learn an obscure syntax to modify the config, when you have to learn another obscure syntax to tweak the changes the .mc file couldn't make? May as well bite the bullet and work directly with the .cf file!

[munnoch]

Re: sendmail.cf

Right, the m4 macros are so much more obtuse than just learning the config file in the first place that I could never bring myself to use them. I still run a hand-crafted sendmail.cf on the family mail server. It doesn't get changed very often... The thing that many find difficult is that the rewriting rules are declarative not procedural so you need to put your brain into a different mode to follow them.

[Claptrap314]

Re: sendmail.cf

What does it mean that when I saw the .mc extension, I immediately thought, "I bet that's m4"? Having never worked with sendmail or seen a .mc extension before?

I'm WAY too abnormal, it seems...

[Anonymous Coward]

Re: sendmail.cf

IIRC the original author of that obscure macro language, m4, also wrote sendmail. m4 probably never got used for anything else.

[C R Mudgeon]

Re: sendmail.cf

"IIRC the original author of that obscure macro language, m4, also wrote sendmail."

M4 came from Bell Labs, designed by Brian Kernighan and Dennis Ritchie. Sendmail was written by Eric Allman several years later at UC Berkeley.

One thing I'm not clear on: did Allman's original sendmail use m4, or was that a later addition?

"m4 probably never got used for anything else."

GNU Autoconf relies on it -- which means that a great many open source projects do so indirectly.

[doublelayer]

Re: sendmail.cf

I was surprised to see the comment about m4 not getting used precisely because it's used in autoconf and automake and I see those all over the place. I don't really like them, although I admit they are better than not having them is, but I have to use them a lot and therefore I see m4 and things relying on it with some regularity.

[Claptrap314]

Re: sendmail.cf

Umm... I used m4 to create a switch in an asm file that would clearly be orthogonal to the asm's macro commands. I used it ONLY for first-order substitutions. This, of course, led to a ban on single-quotes in the comments.

[Doctor Syntax]

Re: sendmail.cf

I think I may also have looked at sendmail.cf a very long time ago but the memory has been blocked.

[Jamie Jones]

Re: sendmail.cf

An easy to make typo in the .cf file will do that - everything gets blocked!

[Anonymous Coward]

Re: sendmail.cf

Then one day, an older sysadmin takes pity on you and explains that, actually, you ought to edit the much more readable .mc file and then compile that into a .cf...

That feeling of relief...

[Paul Kinsler]

Re: sendmail.cf

I editted a sendmail.cf precisely once; to remove an open relay that was there by default. I think the instructions were essentially "change just this one line", so that is all I did.

Some time later, I was asked in an interview if I had ever editted a sendmail.cf; so I told them the above. But I have never been sure, subsequently, if the question was intended as a trap (which I had then presumably failed), or a test of knowledge/experience. *shrug*

[R Soul]

Re: sendmail.cf

I don't understand the sendmail.cf hate here.

sendmail.cf is fucking awesome! How many other MTAs had/have a config file that could do the Towers of Hanoi or provide a calculator?

################################################

################################################

#### ####

#### Simple calculator in sendmail.cf ####

#### ####

#### by Matthew Slattery <[e-mail]> ####

#### ####

#### version 0.03 (4th October 1996) ####

#### ####

################################################

################################################

#

# Invoke as follows:

#

# /usr/lib/sendmail -bt -C<filename>

#

# ...where <filename> is this file.

#

# Then you should enter sums prefixed with "9 ", e.g.

#

# > 9 1+2

# > 9 20-6

# > 9 5*-4

#

# More complex expressions (e.g. '1+2*3-4') work too.

#

# Addition (+), subtraction (-), multiplication (*, x or X), integer division

# (/) and modulus (%) are supported. Brackets are not. Expressions are

# evaluated strictly from left to right (i.e. no operator priorities).

#

# If numbers become to large, strange things may happen e.g. "Infinite

# loop" or "Expansion too long" errors. With my sendmail, 100 recursive

# calls is considered infinite, so a result of greater than 99 will cause

# problems (but you can calculate with larger numbers -- "125-50" works).

#

#

V5

Do.:%@!^/[]0123456789+-*xX

CX 0 1 2 3 4 5 6 7 8 9

CY + - * / % !

CZ 0 1 2 3 4 5 6 7 8 9 + - * / %

S9

R$*x$* $1*$2

R$*X$* $1*$2

R$*$~Z$* $1$3

R$*$=Y $1

R$* $:!$1!

R!! $@0

R$*$=Y$=X$* $1$2[$3$4

R$*$=X$=Y$* $1$2]$3$4

R!$*[$*]$*! $1[$2]$3

R$* $:$>5$1

R$*[$*]$*[$*]$* $>7$1[$2]$3[$4].$5

R$*[]$* $@0

R$*-[$*]$* $:-$2

R$*[$*]$* $:$2

R$* $:$1:0

R$*@:$* $>6$1:$2

R$*:$* $@$1$2

S8

R$*<$*$=X$*>$* $:$1<$2.$3$4>$5

R$*<$*.0$*>$* $:$>8$1<$2$2$2$2$2$2$2$2$2$2$3>$4

R$*<$*.1$*>$* $:$>8$1<$2$2$2$2$2$2$2$2$2$2@$3>$4

R$*<$*.2$*>$* $:$>8$1<$2$2$2$2$2$2$2$2$2$2@@$3>$4

R$*<$*.3$*>$* $:$>8$1<$2$2$2$2$2$2$2$2$2$2@@@$3>$4

R$*<$*.4$*>$* $:$>8$1<$2$2$2$2$2$2$2$2$2$2@@@@$3>$4

R$*<$*.5$*>$* $:$>8$1<$2$2$2$2$2$2$2$2$2$2@@@@@$3>$4

R$*<$*.6$*>$* $:$>8$1<$2$2$2$2$2$2$2$2$2$2@@@@@@$3>$4

R$*<$*.7$*>$* $:$>8$1<$2$2$2$2$2$2$2$2$2$2@@@@@@@$3>$4

R$*<$*.8$*>$* $:$>8$1<$2$2$2$2$2$2$2$2$2$2@@@@@@@@$3>$4

R$*<$*.9$*>$* $:$>8$1<$2$2$2$2$2$2$2$2$2$2@@@@@@@@@$3>$4

S5

R$*[$=X$*]$* $:$1<$2$3>$4

R$* $:$>8$1

R$*<$*>$* $:$1[$2]$3

R$*$=X$* $@$>5$1$2$3

S7

R$*--$* $1+$2

R$*+-$* $1-$2

R$*-+$* $1-$2

R$*++$* $1+$2

R+$* $1

R[$*]+[$*].$* $@[$1$2]$3

R-[$*]-[$*].$* $@-[$1$2]$3

R-[$*]+[$*].$* $:[$2]-[$1].$3

R[$*@]-[@$*].$* [$1]-[$2].$3

R[$*]-[].$* $@[$1]$2

R[]-[$*].$* $@-[$1]$2

R-[$*]*-[$*].$* $:[$1]*[$2].$3

R[$*]*-[$*].$* $:-[$1]*[$2].$3

R$*[]*[$*].$* $@$1[]$3

R$*[$*]*[$*].$* $:$1[$2]*[$3!].$4

R$*[$*@]*[$*!$*].$* $1[$2]*[$3!$3$4].$5

R$*[]*[$*!$*].$* $@$1[$3]$4

R-[$*]/-[$*].$* $:[$1]/[$2].$3

R[$*]/-[$*].$* $:-[$1]/[$2].$3

R$*[$*]/[].$* $#error $@ USAGE $: "Division by zero"

R$*[$*]/[$*].$* $:$1[$2]/[$3!$3!].$4

R$*[$+]/[$*!$*!$*].$* $>4$1[$2]/[$3!$4!$5].$6

R$*[$*]/[$*!$*!$*].$* $@$1[$5]$6

R$*[$*!$*!$*].$* $@$1[$2]$5

R-[$*]%-[$*].$* $:[$1]%[$2].$3

R[$*]%-[$*].$* $:-[$1]%[$2].$3

R$*[$*]%[].$* $#error $@ USAGE $: "Division by zero"

R$*[$*]%[$*].$* $:$1[$2]/[$3!$3!].$4

R$*[$+]/[$*!$*!$*].$* $>4$1[$2]/[$3!$4!$5].$6

R$*[$*]/[$*!$*!$*].$* $@$1[]$6

R$*[$*!$*!$*].$* $@$1[$4]$5

S6

R$*: $@$1:1

R$*:$*0 $@$1:$2 1

R$*:$*1 $@$1:$2 2

R$*:$*2 $@$1:$2 3

R$*:$*3 $@$1:$2 4

R$*:$*4 $@$1:$2 5

R$*:$*5 $@$1:$2 6

R$*:$*6 $@$1:$2 7

R$*:$*7 $@$1:$2 8

R$*:$*8 $@$1:$2 9

R$*:$*9 $:$>6$1:$2

R$*:$* $@$1:$2 0

S4

R$*[$*@]/[@$*!$*!$*].$* $1[$2]/[$3!$4!$5].$6

R$*[]/[$+!$*!$*].$* $:$1[$4!$2!$3].$5

R$*[$*]/[$*!$*!$*].$* $@$1[$2]/[$4!$4!@$5].$6

R$*[$*!$*@!$*@].$* $1[$2!$3!$4].$5

[Bebu sa Ware]

R$*$=X$* $@$>5$1$2$3 … "It's logical, Jim …

but not logic as we know it."

Battled sendmail.cf even before the m4 macro generated version. I reckon if the Lord meant us to mentally execute Turing machine tuples he would have given us infinite tapes (or patience.)

When postfix arrived I dropped sendmail faster than typical American billionaires drop their spouses.

I remember meeting Allman and McKusick in the 1990s, probably around the AUUG '97 conference, at a vendor sponsored event. I only remember their being rather laid·back even by AU standards. ✓ ;)

As for m4, I actually quite like it. Once you get your head around it, it's really useful when you need it. M4 is like Unix — it's not unfriendly; just fussy who it befriends.

[Liam Proven]

Re: sendmail.cf

> sendmail.cf is fucking awesome!

Yes it is. It inspires awe. That's why I shook his hand and asked for an autograph -- on the front of his husband's book on how Unix works. :-)

(I got Kirk's first. Then he introduced the chap sitting next to him. You don't often meet demigods... so to meet two at once is one hell of a day.)

> How many other MTAs had/have a config file that could do the Towers of Hanoi or provide a calculator?

You know that line...

"You say that like it's a bad thing"

You know that one, yes? Now flip the adjective.

[Liam Proven]

Re: sendmail.cf

On inspiring awe, I wish to add a Terry Pratchett quote:

“Elves are wonderful. They provoke wonder.

Elves are marvellous. They cause marvels.

Elves are fantastic. They create fantasies.

Elves are glamorous. They project glamour.

Elves are enchanting. They weave enchantment.

Elves are terrific. They beget terror.

The thing about words is that meanings can twist just like a snake, and if you want to find snakes look for them behind words that have changed their meaning.

No one ever said elves are nice.

Elves are *bad*.”

― Terry Pratchett, _Lords and Ladies_

Zawinski's law says:

“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”

We do not want that email function to be Turing complete. BAD PLAN BAD PLAN!

[SCP]

Re: sendmail.cf

Given that it is not English I would assume it to be inspired by the work of Grunthos the Flatulent rather than Paula Nancy Millstone Jennings.

[VoiceOfTruth]

I disagree with this statement

>> he also pointed out that neither issue was related to memory safety – and therefore not directly to Rust itself at all

It is directly related. The whole purpose of sudo-rs is to use Rust. These problems seemingly did not exist in the C version of sudo. These bugs are the direct result of rewriting a key security program in Rust. I wonder if there are other as-yet undiscovered bugs. It doesn't exactly fill me with confidence.

[doublelayer]

Re: I disagree with this statement

That's a problem with rewriting, not a problem with Rust. If it was a problem with Rust, it would mean that something about the language itself made those happen, which it didn't. Rewriting anything complex is almost guaranteed to introduce some bugs, no matter what language you use, even if you use the same language. If you haven't experienced that, either doing it yourself or watching someone else do it, you haven't had much experience. Simultaneously, sometimes there's enough reasons to do a ground-up rewrite of something even when you know there will be debugging to get it to the same level of stability and functionality as the old thing. Everyone gets to decide on their own when that time has arrived and I've never seen it happen without a lot of disagreement.

[Claptrap314]

Re: I disagree with this statement

The question is "what is the point of the exercise"? It seems likely to many of us that the point of the exercise was to do a rewrite in rust. Which is very, very different from doing a clean reimplementation which happens to be in rust.

Rewrites are a security risk in their own right. The rusted nuts sound very much like have found a perfect hammer, and therefore everything ispo facto a nail needing hammering.

[Anonymous Coward]

Re: I disagree with this statement

Does "rewrite in rust" really mean a line by line translation?

If I'd written a clean version of sudo in rust, without looking at the original source at all, I'd still say "I've rewritten it in rust"

[Claptrap314]

Re: I disagree with this statement

I specifically used the phrase "seems like" to make clear that this is not a certain condemnation, but rather a weaker claim.

[Anonymous Coward]

Re: I disagree with this statement

Whilst not literally a "problem with rust", it is still a fair comment to make.

Too many people think that rust is the holy grail of security - so much so that people convert working programs to rust for no other reason than to claim it's now somehow safer.

When this ends up creating a potentially more insecure binary, it's a problem with all this rust stuff.

[doublelayer]

Re: I disagree with this statement

I still disagree, with the clearest reason being this sentence:

"When this ends up creating a potentially more insecure binary, it's a problem with all this rust stuff."

Not at all. When this ends up creating a potentially more insecure binary, it's a problem with this particular piece of code. If it was part of Rust, it would impact everything else, but if it was a bug in that one rewrite, then it's as much a problem with all the Rust stuff as sudo's insecure config file vulnerability was a problem with everything written in C (which it isn't, in case a C fan was not sure what I am saying).

If someone badly rewrites something in a language, it does not make the language or the others using it at fault. When we compare the C version of sudo with this Rust reimplementation, it's also not so clear that the rewrite was bad. Yes, the Rust version has vulnerabilities, but so does the C version, and so far, the Rust one has not had one that allows a unprivileged user shell to turn into a root one whereas C sudo has. I think I can sympathize with the negative reaction to something that has been hyped too much, and Rust has received enough hype to be annoying. When that annoyance turns into hyping any problem with the new thing more severely than the original hype, especially with inaccurate statements meant to make a problem seem worse or more unusual than it actually is, then we have another problem.

[Anonymous Coward]

Re: I disagree with this statement

Well, I guess what I mean more accurately is "It's a problem with all this 'let's write everything in rust because it's wonderfully safe and any fool can use it without any problems' hype mantra."

I'm not blaming the language itself, but the "buzz" around it.

[Missing Semicolon]

Rewrites are nearly always bad

Joel had it right Rewriting loses bug fixes and features you didn't know existed. The regressions in sudo are a classic example of this.

[munnoch]

Re: Rewrites are nearly always bad

The other problem is that rewriting brings to light existing stuff that doesn't work, or doesn't work as expected. Do you maintain that brokenness in your new shiny version because that's what people are used to? Or do you do force your "correct" version on everyone (if you ever finish the rewrite that is...).

[VoiceOfTruth]

Re: Rewrites are nearly always bad

It's fair to say that sudo-rs is not a drop in replacement for sudo. From the GitHub page: features you might expect from original sudo may still be unimplemented or not planned.

For the FreeBSD version there is a specific option to install 'sudo-rs-coexist', so sudo-rs does not conflict with the existing sudo command names.

As this is not a direct replacement, I feel the command should be called sudo-rs, to avoid any confusion that this is one-for-one replacement.

[Claptrap314]

Re: Rewrites are nearly always bad

Not just in software, btw. AMD faced the same issue with the K5--we had to be bug compatible with Pentium.

[frankvw]

Re: Rewrites are nearly always bad

"Joel had it right"

He did, but what really stands out in his essay is this one sentence:

As if source code rusted.

I see what he did here, more than a quarter century ago. What a visionary.

[Bebu sa Ware]

"Rusty sudo holes quickly welded shut"

Using plenty of flux, one hopes.

I had some mistaken idea that debian shipped doas from OpenBSD instead of sudo. Sudo having a patchy security record although, to be fair, often in practice due to vendors shipping ancient versions and with dodgy modifications.

[Liam Proven]

Re: "Rusty sudo holes quickly welded shut"

> Using plenty of flux, one hopes.

Isn't that soldering, not welding?

Note to passing colonials: the L in solder _is not silent._

> I had some mistaken idea that debian shipped doas from OpenBSD instead of sudo.

THANK you. End of p2 and the first mention of `doas`. You were the first. Well done. Have a biccy.

No no, it's not in Debian. Way too non-trad for them. Debian's for fuddy-duddies, Devuan for _reactionary_ fuddy-duddies.

It's in Alpine though.

But yes, IM very HO, rewriting DOAS in Rust would have been a better start.

[Mythical Ham-Lunch]

Re: "Rusty sudo holes quickly welded shut"

Not if you're arc welding - the flame of an oxy welding torch provides a sufficient atmosphere to prevent weld contamination, but for electric processes without a MIG or TIG setup you will still require flux.

Ironically one is typically require to -remove- any rust with a wire brush or grinding wheel before attempting a weld!

[Peter Gathercole]

Re: "Rusty sudo holes quickly welded shut"

In the early '90s, I used a tool called "op.access", aka "op" which did a similar job to sudo allowing escalated access according to various rules.

One of my talented colleagues built a local tool management and distribution system around it to maintain a fleet of UNIX systems, before tools such as sudo and rsync even existed.

I did trace the source of that tool a while back, but although I found it, I did not record where I found it, so would have to look all over again!

[STOP_FORTH]

Sudo is not required

Come over to the reckless side.

In Puppy Linux (and it's many derivatives/relatives) you are always root!

[Jamie Jones]

Re: Sudo is not required

Pffft. Get back to me when you can become "ludicrous root"

[Manveru]

Crazy indeed

O fcuk, I configured sendmail like 7 times in my life.

Funnily PTSD I have is from JavaScript of late '90s...

[Peter Gathercole]

Re: Crazy indeed

I seem to keep being asked every few years to have a hack at a sendmail.cf file. Last time was about two months ago to make sendmail not listen for inbound mail on an external network interface, but still listen on localhost for locally generated outbound mail, and to allow deferred sending of mail that could not be forwarded first time. A very simple change that would probably have been better done using an ipsec rule, but this hadn't been deployed on this system.

I think it ends up with me because I'm normally the last person asked, after everyone else appears to have said no!

I don't like doing it, especially after I managed to bring down the main external mail gateway at a major UK bank about 20 years ago when I was asked to put an address re-writing rule in the internal mail router for outbound mail destined for one of their outsourcing partners, but forgot to also handle the bounced mails back to the originator for mails that could not be delivered. Ended up with an exponential mail loop (each mail generated two bounce mails that ended up being reflected straight back, which then generated 2x2 messages back etc.)

Took a day or two to build up to the point where the external gateway went sour, which happened during a weekend. My name was mud on Monday morning.

Since then, I've tried (but failed!) to avoid having to do it.

[druck]

Half arsed

Rust commands silently accept all the same switches as the C versions from the GNU coreutils.

Half arsed fuckers. If they can't be bothered to implement all the options of the date command, leave it the fuck alone.