Two security issues were discovered in sudo-rs, a Rust-based implementation of sudo
Posted by brutal_seizure@reddit | programming | View on Reddit | 145 comments
deltanine99@reddit
But, Rust ?!?!?
BinaryIgor@reddit
Switching to theoretically safer language - C vs Rust - does not automatically means less bugs, unfortunately. As usual, skills are the issue
QuaternionsRoll@reddit
Well, ideally it should mean fewer bugs (or at least fewer classes of bugs), but no language can prevent logic errors. The best they can do is encourage design patterns that are easier to reason about, and Rust is only marginally better than C in that regard (although both are much better than C++).
DevilSauron@reddit
How is C easier to reason about that C++? The language is so barebones that you have to reinvent everything including dynamic arrays, hash tables and linked lists. You also have no information about which pointers are owning and which are merely observing, no guarantee about destructors, and so on.
CircumspectCapybara@reddit
Yup, people who say C is easier than C++ don't realize devs are just going to have to hand-roll and reimplement many of C++'s zero-cost abstractions, which is just C++ with extra steps.
NYPuppy@reddit
This is also a good point. Libraries like Gtk are basically reinventing C++ in C with macros. I think most C libraries I have seen and even the Linux kernel are very macro heavy to enforce at least some kind of correctness.
atxgossiphound@reddit
A little historical context: Libraries like GtK aren't really "reinventing" C++ with C macros. They're based on style of programming in C that was incredibly common in the 80s and 90s. C++ was evolving at the same time, but wasn't widely accepted.
Using macros for generic and OO programming was pretty common in C (and probably still is?). Macros were (are?) just part and parcel of how you design software in C.
mpyne@reddit
GTK didn't even exist until the mid-90s, C++ had been around for quite some time by then, which is why the competing Qt toolkit was already around and already written in C++.
atxgossiphound@reddit
While that's technically true (I'm assuming you used Wikipedia to get your dates), in the mid-late 90s, C++ was still in it's early adoption phase. Some projects had already committed to it, but a lot of existing projects were not using it and had no plans to migrate. Developers from those projects also had little interest in leaving C for C++.
It's kinda like the situation with Rust today. Some projects have gone all in on it, but most haven't (and never will). Rust will likely be an important language for a while now, as it's gotten over it's initial adoption hump. That's pretty much where C++ was at the time GtK was started.
GtK was very much committed to C at the time and Qt to C++, for roughly the same reasons some projects use Rust and others use C or C++ today.
I was actually there and using both GtK and Qt and C and C++ at the time. I was on the side of "C++ is the future" but was working on a large system written in C.
QuaternionsRoll@reddit
I never said C is easier than C++. Abstractions are much easier to develop and use in C++. I only said that C++ encourages design patterns (chiefly, polymorphism and specialization) that are harder to reason about the logic of. The advantage of idiomatic C and Rust in this regard is that the flow of control is almost always obvious, whereas C++ can be comparatively surprising.
dys_functional@reddit
You're missing the point of c if you reimplements c++ in every c code base. Continuing on with your dynamic dispatch idea, in my ~10 yoe in c, I have never really found a use case where dynamic dispatch really made sense over static.
For lifetimes, never try to manage them at a single elements level, manage them statically or in batches/heaps/arenas. Ownership is only hard if you are dogmatically trying to store independent lifetime data with every single piece of data. Once you realize you don't actually ever need to do that, it becomes trivial.
In a c devs eyes, the abstractions provided to you on c++ are not necessary and generally cause more problems than they solve. The solution is not to remake those abstractions, it's to realize you are better off without them.
NYPuppy@reddit
The problem with C++ compared to C is that C++ layers complexity on C. C has inherent complexity but since the language is small it's easier to reason about. In C++, it's easy to shoot yourself in the foot with copies versus moves, destructor semantics, not implementing gang of whatever patterns etc.
I like C and Rust. Zig is ok too. C++ is less approachable and not as nice to use. Just look at things like SFINAE.
binariumonline@reddit
I'm not sure why you are being downvoted so much, you are completely currect.
Full-Spectral@reddit
All of this discussion is why Rust. C is ancient and far too low level. C++ is much higher level but also ancient and full of footguns. Rust is the modern C++, that provides the safety without the endless evolutionary baggage.
nemesit@reddit
rust is just a junk language
Full-Spectral@reddit
No serious developer could possibly hold that position, The reason anyone usually says that is because they like some other language and don't want it to be pushed down the ladder, or they just have no real experience with existing systems languages in large projects.
I've used C++ for decades and probably written multiple times more code in it than you, and I'd never go back to it if I had a choice. Rust just takes so much of that cognitive burden off me and lest me concentrate on logical correctness and delivering value.
nemesit@reddit
no the syntax is garbage so the language is junk you wouldn't write production code in whitespace either
Full-Spectral@reddit
Sigh... That's purely opinion and nothing else. And it's most likely opinion based on lack of understanding.
Most everyone thinks a new (serious) language they don't know has weird syntax, because it's different from what you are used to. If the language introduces concepts above and beyond those of the languages you know, even more so.
Once you are used to it, it makes perfect sense. I know find myself writing Rust syntax when I'm forced to write C++, because it must makes more sense to me now.
nemesit@reddit
no i worked extensively with it and its simply bad and hey i know like most of the languages in use so while it is an opinion it is MY opinion which i formed by using most of the languages out there at some point in my career.
NYPuppy@reddit
On the contrary, Rust's syntax is modern and readable. Most modern languages tend to follow similar patterns, it's why Rust, TypeScript, Zig, Kotlin, Python with type hints etc all look similar.
CircumspectCapybara@reddit
Eh SFINAE sounds scary, but without it, we couldn't have overloaded templates that can be broad and specific toward a variety of type parameters.
If you want unreasonable complexity, check out "the most vexing parse"
mark_99@reddit
C doesn't have a formal ODR and it's less likely to occur as C doesn't tend to have code in headers, but it's still problematic in that it's inherent to the TU model - C will just pick the first definition in the linker and if they aren't all identical that's still broken.
C++ Modules, which is finally becoming usable, fixes things as violating ODR is almost always detectable (so not impossible but you'd need to try really hard to screw it up).
dsffff22@reddit
Usable, nice joke, https://arewemodulesyet.org/tools/
Basically no LSP/IDE support at all, still incomplete everywhere and barely any libraries ported.
sweetno@reddit
I'd say, on the contrary, C is way too primitive for comfortable coding. Anything involving strings, for example, becomes a memory management exercise. There is also this tendency to extend C APIs with dynamic dispatch via function pointer + opaque
void*. That's very error-prone, but also inevitable in C.C++ is syntax sugar with oftentimes surprisingly unexpected semantics; C is syntax-sugar free, even for the cases you'd like brevity.
DevilSauron@reddit
What does this mean? Since the language is small, it's easier to, say, write a parser for it or even describe its semantics formally, but that does not imply anything about understanding real codebases in C or C++. If I had to choose between understanding 100k lines of C or C++, I would choose C++ any day, since the code contains much better information about the actual semantics of the real program.
NYPuppy@reddit
The reason is what I said above. C++ is brittle. While it has more type information than C, C++ doesn't handle its complexity well. It's easy to cause issues by missing one of its plethora of rules and recommendations. The entirety of C++'s history is exactly that it's trying to fix those flaws which is why it has things like std::span now. But even with that, it's easy to cause a use after free with spans which defeats the purpose of it.
C++ is needlessly complex. It's a kitchen sink language with every feature thrown in and those features clash with other features. One of the reasons I prefer newer languages now is exactly that the languages are much cleaner and saner. C, which obviously isn't new, is still a nicer language than C++ because its straightforwardness is a better holder of its complexity. I think that's the reason why languages like Rust or Zig are straightforward too.
I'm aware that C is extremely flawed too. It just has a better excuse for its flaws and is more direct about them.
Oxi_Ixi@reddit
In C it is easier to reason about the language. In C++ or Rust it is easier to reason about the code.
dsffff22@reddit
The big issue with C++ is that It has too much implicit behavior and builds upon SFINAE(basically the compiler tries out every possible overload/apply-able combination until one compiles). Then also with modern move semantics and captures It can become really difficult to reason on a system level what happens in a function. C might force you to write more boilerplate, but in most cases C code is easier to reason about.
aaronfranke@reddit
Rust eliminates an entire class of bugs, memory safety bugs, which are a significant fraction of bugs. I'd say that qualifies as a very significant improvement, not just "marginally".
QuaternionsRoll@reddit
Memory safety bugs are not logic errors…
aaronfranke@reddit
Yes, I know. Logic errors exist in both languages. Rust does not eliminate logic errors. Rust only eliminates memory safety issues.
Hecknar@reddit
I mean, this is the dream.
C is a very simple and very small language, Rust is a mountain of complexity in comparison. I expect that we have eradicated one type of issues but the price is that new classes of issues will take their place.
PrimozDelux@reddit
In C the complexity has to live in the code
QuaternionsRoll@reddit
This comes up a lot, and I honestly don’t think it’s a fair comparison. The simplicity of a language doesn’t necessarily imply anything about the simplicity of using the language (see: brainfuck).
First and foremost, there is the pervasive use of bespoke macros. Pretty much all C projects of any significant size are built this way. It’s great that C is a simple language, but does it really matter if it’s because the language is missing a ton of features that most projects have to build out themselves? Is it really fair to call a language “simple” when the code of its foundational libraries are so infested with obscure macro invocations as to become nearly unreadable?
Second, it can be really hard to tell if something is undefined behavior in C. Worse yet, even if something definitely is UB, you then have to ask, “But is it really?” Signed overflow is a shining example of this. Hell, the Linux kernel is even compiled with
-fno-strict-aliasing.Lastly, there are compiler extensions. I don’t think it’s reasonable to compare another language to ISO C when so many projects don’t actually use it. As of a few days ago, the kernel is now built with both GCC and MSVC extensions enabled, for example. Sure, those extensions don’t add that much complexity to the language by themselves, but even having to consider what compiler(s) you’re targeting is an element of complexity that often goes unconsidered.
I guess you could argue that you aren’t obligated to use complicated macros or compiler extensions. I would have two responses to this:
MornwindShoma@reddit
Thank you for writing a long and detailed comment. I'm sorry that no one will care to get out of their religious positions.
airodonack@reddit
C is very simple and small until you get good at it then you realize there’s a mountain of random bullshit you have to remember to be considered a C master.
Full-Spectral@reddit
The problem with your position is that a small and simple language is fine until the code base is no longer small and simple, then it becomes a serious limitation. A more capable language may be more of a hassle for small and simple stuff, but the tables quickly turn as the code base grows and it becomes a significant benefit.
Also, it's just fundamentally wrong in another way. There are basically two classes of errors, logical errors and 'mechanical' errors for lack of a better word at the moment. If you remove the mechanical errors, that doesn't create new errors, it just leaves logical errors which were already there to begin with. And, it leaves more time to address those logical errors.
And, frankly, Rust makes it less likely you'll have logical errors as well, because of the very conservative default positions it takes, which are with a couple arguable exceptions the safest ones. C and C++ are on the opposite ends of the universe from that.
stumblinbear@reddit
Really hasn't been even close to my experience with Rust. It pretty much just eliminates issues, it doesn't really bring new ones
CircumspectCapybara@reddit
Yeah just because we have bad drivers and the majority of driving accidents are caused by user error (DUI, distracted driving), that doesn't mean the car itself shouldn't be as safe and sound as possible (seatbelts, the engine shouldn't explode randomly).
stylist-trend@reddit
I think the lesson to take from this is regardless of if it means fewer bugs or not, it doesn't mean zero bugs.
BogdanPradatu@reddit
It can also mean more bugs.
nemesit@reddit
it also doesn't mean safer, safer c is easy it just also means slower c which usually defeats the purpose of using c in the first place
matthieum@reddit
Does it?
Systems programming languages are used when either low-level access or performance is required.
When I look at the utilities in coreutils, be it sudo, ls, etc... I would argue that +/- 10% performance is hardly going to make a difference.
nemesit@reddit
true
tracernz@reddit
I would argue that's true for any non-trivial rewrite, whether in a different language or not. You always get some old bugs back again, and some new ones to go with them.
Ar-Curunir@reddit
Why don’t you program in assembly then?
BinaryIgor@reddit
C is a higher level language as compared to Assembly, so it often makes implementation faster (not always though). Rust, I think, is at the same as C abstraction level
Ar-Curunir@reddit
Definitely not true. For example, you don't have to reimplement numerous data structures, you have access to higher level constructs such as pattern matching, enums, mutability analysis, tuples, traits, generics, and more. Oh and the build system is way more ergonomic.
Programming in Rust feels much higher level than programming in C.
hgwxx7_@reddit
Mildly disagree, because even the most skilled could have made this mistake. The authors did consult with the author of sudo, and did engage security auditors. They had the skills, the people they consulted had skills.
Codebase age is the issue. Every code base becomes more secure the longer it's in use without changes being made. Bugs, including security bugs, are found and fixed, leading to a more secure code base.
What we shouldn't read from this is that it makes no difference what language we use - we will always have bugs. What matters is the severity of the bugs. Like this other comment points out, one is a low severity issue and the other is only applicable in a non-default configuration. Not great, but not catastrophic either. And now the codebase has two fewer issues in them.
Ar-Curunir@reddit
Why don’t you program in assembly then?
Hecknar@reddit
Looking forward to the time when we realize that we have simply replaced one set of security issues with a different set of security issues…
QuaternionsRoll@reddit
I assume that you mean immature codebases by “a different set of security issues”?
Hecknar@reddit
Immature code base, less experienced developers, less mature ecosystem and a much more complicated and sophisticated language.
QuaternionsRoll@reddit
Agreed. This is an underappreciated problem, especially when replacing tools that (a) have existed for decades and (b) don’t change much.
I don’t think this is fair. Sure, Rust is a “hip” language, but plenty of experienced developers work in Rust. I would also posit that young, inexperienced developers aren’t exactly rushing to make a
sudoimplementation, of all things.Also agreed, although it doesn’t really come into play here.
sudo-rs’ has three dependencies, and none of them are at all concerning (libc,glob, andlog`).I would argue that Rust is substantially simpler than C at scale. C is rather simple in theory (albeit surprising at times), but the macro-laden C that you typically find in real projects can quickly outpace the complexity of Rust. Put another way: the simplicity of a language is not necessarily correlated to the simplicity of using the language.
ub3rh4x0rz@reddit
Rust has a macro system that is more sophisticated (read: complex) yet also leads to compiler message dead ends. The strictness of rust has benefits, but it is still valid to be wary of complex things, and rust is orders of magnitude more complex than c on just about every dimension, perhaps excluding package management and linking, but I'd argue thats more about ease than simplicity
NYPuppy@reddit
We didn't replace one set of security issues with another. We solved one set of security issues but still have the other sets of security issues that languages, including rust, can't solve. There's no way that rust can warn that a program is susceptible to a signal leaving data in stdin.The fact that rust didn't prevent that issue doesn't mean that rust is flawed and we need to toss it away or something.
ub3rh4x0rz@reddit
They might be referring to the security issues that inherently stem from a relatively young and untested changelog and mandates to migrate all the c/c++ things to rust
FlowingWay@reddit
We feel exactly the same way about C, but that doesn't stop people from attacking it. You reap what you sow.
RedEyed__@reddit
Interesting thinking. It's like now we replaced (added) set of security issues with mechanical locks to digital locks?
JusT-JoseAlmeida@reddit
Bad take. The analogy would be more like: we replace mechanical locks where the pins sometimes fall out if you don't assemble exactly right with mechanical locks which are engineered to be impossible to assemble wrong in that way
MornwindShoma@reddit
We've replaced the C macros with actual codified language features.
QuestionableEthics42@reddit
These takes are so ignorant. No. You are removing a very large and common type of security flaw. They are absolutely not just being replaced by a new large type of security flaw. Just some small ones. It is 100% significantly more secure.
vplatt@reddit
That's some Trump level math there. I think we can acknowledge that Rust code isn't going to have NO security issues, but if you said 97% more secure, we might be able to agree that it would have 3 security issues for every 100 issues found in C code. But then again, you'd have to provide citations and show the study and how the measurements were made, etc. Well... I get why you didn't, but that shit is hard right?
All of which begs the question: Do we have any empirical measurements of how secure Rust code is "by default"? I imagine this is going to be very hard to measure.
JusT-JoseAlmeida@reddit
He didn't say it is 100% more secure, he said there is a 100% chance it is significantly more secure. Which is true
Full-Spectral@reddit
It's completely silly. Mostly I think it's just people who see their favorite language being challenged, and are just looking for FUD to spread.
NYPuppy@reddit
I don't even think it's that. I doubt that most or even any of the people on phoronix code in C. They just view C as some kind of mystical language that will "save" us from "woke".
Michael posts these news because he knows his active users are incompetent but would drive engagement. Phoronix is basically X.
stylist-trend@reddit
After seeing so many people online who fervently dislike Rust for seemingly no reason, this just made so much stuff click for me.
vHAL_9000@reddit
Rust doesn't just provide memory safety, but decreases logic errors.
Monadic types force you to explicitly handle error/none cases. Immutable by default makes many of mistakes impossible and makes it simpler to reason about the code. Besides memory safety,
mut&,&, and smart pointer types prevent accidental race conditions and express intentions. The strict type system and exhaustive matching catches tons of mistakes. Iterators can get rid of many indexing errors while increasing clarity and conciseness. There's no double-inheritance. I could go on and on.johndoe2561@reddit
It's a stupid trend to just implement the same tool in Rust. Focus on features / properties, not implementation language.
JusT-JoseAlmeida@reddit
It is not a stupid trend to try to make more secure tools which are the backbone of the entire modern technology ecosystem
johndoe2561@reddit
Sure. It IS a stupid trend to call the thing you're making foo-rs, communicating: foo, but in Rust. Not, foo, but more secure. Or foo, but faster. Or foo, but better in these other ways.
That is just stupid bandwagon BS and it's just the same shit with every single fucking tech fad every single time.
JusT-JoseAlmeida@reddit
That, I can agree with. But I understand why they do it
However it's still a positive thing
neondirt@reddit
The expression "error prone" springs to mind.
happyscrappy@reddit
The first issue seems small but it indicates sudo-rs does things entirely differently than the old sudo. And given how long the old sudo has been around it's very hard to justify this.
I understand the value of a memory-safe language (and Rust offers even more than that). But if you made a high-level list of the operations sudo does and made a flow chart then the new program should share the same list and flow chart with the old program.
I know that's not sexy, that programmers typically relish the design aspects of writing a program. But compatibility and security requirements are so high for a tool such as sudo that it hardly makes sense to rewrite from scratch.
For example, if the original reads the PW from the tty directly then the new version should.
renatoathaydes@reddit
Finally a solid, reasonable take on this.
Pharisaeus@reddit
I think that's often the problem ;) Software that has been around for a long time has lots of quirks and corner cases that evolved organically, and might not be immediately obvious or the reasons for those "features" is not clear until you thoroughly research it. And many of those things are non-functional requirements, which might not be captured by a simple flow-chart or by requirements specification.
imachug@reddit
This isn't nearly as bad as I imagined.
The first issue is that, if
sudowas killed while typing in the password, the password would remain in thestdinbuffer and would be consumed by whatever shell you ransudofrom. Slightly annoying, but not really problematic.The second issue is significantly worse, since it allows basically arbitrary impersonation as far as I can see, but it only works if
/etc/sudoerscontainsDefaults targetpw, which is not the default configuration.HipstCapitalist@reddit
Genuine question, how could #1 even be addressed? If the program is killed it has no control over how to dispose of it.
NYPuppy@reddit
Signals can be caught. The solution is to register a signal handler, catch signals like sigkill, then erase stdin.
These two security issues don't say anything about rust or c. Signals are difficult and most programs don't handle them correctly. Entire classes of syscalls had to invented just to help user space programs handle signals correctly.
Sudo itself is difficult too. It's complex and I would prefer if far less complicated solutions existed
JMBourguet@reddit
From signal(7):
NYPuppy@reddit
Thanks for the correction! I made a typo, I meant sigint not sigkill. The question was for ctrl+c which is sigint and often caught.
TotallyNotAVampire@reddit
sudo runs as uid 0, so the limited user should not be able to SIGKILL it. And if another superuser process is SIGKILLing it, you have an entirely different problem.
oridb@reddit
https://flak.tedunangst.com/post/doas
crozone@reddit
Do what current
sudodoes by default. Don't read the password from stdin.Instead, read directly from
/dev/ttyin raw mode.Halkcyon@reddit
I wonder why they didn't choose to do that?
Vimda@reddit
Because all the people rewriting things in rust are not doing so with the historical context of the existing systems. They just see C=Bad, Rust=Good, and plow on ahead
MornwindShoma@reddit
Nothing to do with Rust. Try again
Vimda@reddit
Not to do with Rust, but the particular culture of replacement at all costs that Rust seems to breed
MornwindShoma@reddit
The only reason why you're talking about this is that it's Rust and you hate Rust. Code by itself is and always will be expendable. Codebases are meant to evolve and change and not get stuck in the past forever. People rewrite stuff all the time.
Vimda@reddit
Hahaha I write rust as a job. Rust is great, but this isn't evolving a thing, this is replacement without learning from the old thing at all.
MornwindShoma@reddit
That's not a problem for Rust. It's a problem for the individual developer to deal with.
omeguito@reddit
If it’s a cultural trait within the language then it is a problem for the entire community of that language to solve before arrogantly trying to reinvent the wheel of critical software
MornwindShoma@reddit
Again, you're attaching some sort of personality to a tool. That's not a rational argument.
gimpwiz@reddit
Being more generous:
Younger people are excited to do new and cool things, and may be disdainful of the old for good reasons or bad, but lack historical context and understanding for Why We Did It That Way and don't even know to ask because they don't know what they don't know. It's important to guide them because we were all younger and more ignorant, and they will be greybeards soon, and we need them to guide the next newbies.
Vimda@reddit
Perhaps, but also perhaps just tossing out 50 years of history is silly on its face, and the folks rewriting this stuff should know to ask as a basic qualification for rewriting in the first place
NYPuppy@reddit
No one is throwing out 50 years of history. The fact that rust is a success is because the flaws of C were known for decades. Rust is not the first language to try to usurp C, it's just the only one that succeeded.
You falsely believe that there is some kind of cabal pushing rust. The fact that rust is accepted and that rewrites occur is because stakeholders are the ones rewriting software to begin with.
C is awesome. I got downvoted by C++ fans in another thread for pointing out why some people prefer C to C++. C is awesome but it was never perfect and never designed to last this long. It was a language, like all languages, that succeeded by accident.
gimpwiz@reddit
This is a great opportunity for the new authors to heavily document what they learned and why they made various decisions, to rely less on institutional knowledge and more on written documentation.
Like you said though, one might have expected them to have carefully read the existing codebase, and asked clarifications on any line, any method, any decision they didn't understand. That they did not is not unusual but neither does it impress nor fill with confidence.
The interesting thing to me about this rewrite is that a lot of times, old crufty code is old and crufty because it has to deal with so many odd corner cases and usecases. In doing a clean sheet rewrite, one may find the opportunity to carefully define inputs and outputs, expectations and needs, write simpler smaller code, and basically just not support the super old weird shit anymore. (Though usually what actually happens is they end up thinking they will do this... and end up dealing with the fallout of incompatible behavior for ages.) But the current version of sudo doesn't really need to do anything different from a rewrite, so they should really aim for perfect behavior compatibility unless there's a great reason not to. It's also frankly a small piece of code that makes it much more straightforward to do so. Not approaching it with this attitude is - well. Exuberance untempered by hard experience. Happens to everyone.
The other thing about rewrites is that often in the context of rewriting code that was originally written 50ish years ago is that there is nobody left to ask. In this case there's a whole community of people maintaining that institutional knowledge. Not asking in detail is, again, a choice made by people who will hopefully not make the same mistake again.
sisyphus@reddit
You could be even more generous which is: Rust does in fact eliminate entire classes of bugs, one of which is the most common security issue in all of software and it's not even close. However, those classes of bugs are not exhaustive of all the bugs there are, ie. Rust is an improvement, not a panacea.
CramNBL@reddit
You realize that they are not allowed to read the source code of the GNU coreutils right? right?
Otherwise it cannot be MIT licensed.
It's a blind-folded rewrite. I'm sure you'd do better though, using C and without looking at the original code.
gefahr@reddit
I haven't been following this, but why blindfolded when there are appropriately licensed sudo available in the BSD ecosystem?
CramNBL@reddit
uutils coreutils is a rewrite of the GNU coreutils, and they have to behave like that, almost identically. I'm not aware that there's a 1:1 BSD replacement for sudo, but everytime I had to write shell scripts that were compatible with GNU and BSD systems, it was a pain the ass.
Blindfolded might be an exaggeration, but the point is that it's much less forgiving than a typical rewrite. On top of that, it's also cross-platform, so they are gonna try to write as little platform dependent code as possible, and I suspect that this issue was a consequence of that incentive.
omeguito@reddit
You don’t have to read the source code to study how to properly read passwords and how getpass works
Booty_Bumping@reddit
uutilsandsudo-rsare not just ignoring history. Quite the opposite - the goal is to be nearly exactly compatible with the originals.uutilshas been incredibly successful at that, they are passing a huge percentage of the test suite forcoreutils, better than any alternatives.13steinj@reddit
I believe this "raw mode" is the same that is used by the
getpassutility.You'd be surprised how many people forget to use this or don't understand the implications.
matthieum@reddit
I may old school, but I'm never surprised at people passing on adding a dependency for something simple. Dependencies are their own cans of worms.
Of course, the problem here is that it appears deceptively simple :/
ketralnis@reddit
getpassisn't even a dependency, it's in libc https://man7.org/linux/man-pages/man3/getpass.3.htmlinvisi1407@reddit
However
(..)
13steinj@reddit
It's obsolete for reasons that don't really matter in this precise context https://stackoverflow.com/a/34946461
That said I was referring to a general case, not specifically the C function. The term "getpass" has become so ubiquitous for this purpose that other programming languages have copied the name and completely re-implemented it, e.g. Python's. I assumed that other languages's stdlibs also followed suite.
Halkcyon@reddit
I'm just trying to approach it as a choice they made, whether through lack of knowledge or they did think about it and chose stdin.
matthieum@reddit
I am guessing the answer is simply: because they didn't realize the implications.
I mean, you want to read an input, you reach for the standard input stream... no?
Why instead reach for an unportable, and harder to use,
/dev/tty? The problem of reading input has been solved already, no need to reinvent the wheel!Oops...
JasTHook@reddit
No! Absolutely no and a thousand times no.
Here they don't want to read an input. They want to read a password from the controlling try.
The program being run under sudo may want to read that input and it's me be coming from a file not a console.
Halkcyon@reddit
Sure, but there are also a lot of people arguing in bad faith in this post about how Rust bad, or the devs are inexperienced, but I wanted a rhetorical device to offer them grace.
dsffff22@reddit
https://github.com/trifectatechfoundation/sudo-rs/commit/e5fe2b84daf2c20c9c2d2fb3b158d41a24bff81f
They actually choose to do that but only for prompts with feedback together with using
/dev/ttydirectly. So they were aware to disableICANON, but forgot about the non feedback case.QuestionableEthics42@reddit
It depends how it's killed. Ctrl+c doesn't actually kill it, it tells it to commit suicide, so it can still clean up before it exits. Ctrl-z is the non negotiable one that doesn't have any handlers the program can create to clean up things like that.
jaerie@reddit
What do you mean? I'm guessing you're referring to suspending a process in a shell with ctrl+z? That sends a sigtstp which can certainly be handled by the process. Are you maybe confusing it with sigstop? That's not related to ctrl+z, but it is indeed not able to be caught (and also results in a suspended process to be restarted with sigcont)
QuestionableEthics42@reddit
Oops. I thought ctrl z sent sigkill. Yea, I actually mean kill -9.
imoth_f@reddit
I think they meant sigkill(9).
jaerie@reddit
But that has even less to do with ctrl z, unless they mean something else with that
Extracted@reddit
Now that you mention it, I’m surprised leaving «ctrl+c» as a comment instead of «kill yourself» isn’t a thing
nemec@reddit
Ctrl+Alt+Delete you
i_dont_know@reddit
Most people will think you mean copy instead of kill.
Extracted@reddit
So it’s a dogwhistle
gletschafloh@reddit
Thats good knowledge for the toxic kiddies in online games
nerd5code@reddit
Ctrl+C lets it kill itself, iff it’s installed a handler for
SIGINT, but it’s technically only a request to stop whatever it’s doing, whether or not that involves killing itself. The default action, sans handler, is for the OS to kill it.Ctrl+Z works very similar, and sends
SIGTSTPinstead ofSIGINT. This is not a request to kill, but to suspend; by default it stops the process likeSIGSTOP(which can’t be handled, unlikeSIGTSTP). Of course, on DOS Ctrl+Z is the EOF signal; onUnix that’s Ctrl+D by default—all of these key combos can be changed for POSIX or X/Open ttys.Ctrl+\ is
SIGQUITby default, which is actually a quit request, not just interruption. Kills by default.SIGTERMis what’s sent by the OS to politely request termination (e.g., at shutdown).SIGKILLis the one you were thinking of, that can’t be intercepted. Instant kill, more or less (I/O and swapping can still keep the process around for a bit).2rad0@reddit
Read passwords one character at a time instaed of buffering the full secret in a contiguous memory chunk.
sweetno@reddit
In principle you can do unbuffered input, SDL-style.
MCPtz@reddit
Also this is Ubuntu 25.10.
I think it's great they are trying out all of these rust core utils now, to try to work out the transition to rust for, hopefully, better long term security and less maintenance on bugs on those tools.
Might be Ubuntu 26 is a little bit easier to maintain, on many of those tools.
dontyougetsoupedyet@reddit
No, thanks.
LupoShaar@reddit
The biggest lesson is that it's still too fresh for serious deployment
KawaiiNeko-@reddit
Not sure what all the downvotes are for, does that not make sense? For such an integral and critical part of the system would it not be better to wait for a longer time to sort all the critical issues out before using it as the default on distros? (looking at you, Ubuntu)
socratic_weeb@reddit
The main issue with sudo-rs and every other attempt at rewriting the gnu utils is GPL-washing. They use a cuck license that will please the corporate world more, but will be worse for everyone else in the long run.
chucker23n@reddit
??
I wouldn't phrase it in those terms, but yes, some people feel better using a non-viral license.
The onus is on the FSF to make their license attractive.
socratic_weeb@reddit
This
MornwindShoma@reddit
Please think with your brain before you post.
socratic_weeb@reddit
Says someone who doesn't even give a single argument. Cuck licenses are bad for everyone but greedy corporations.
cowinabadplace@reddit
The real annoyance these days is everyone trying to popularize some 'brand name' word. Give it a break. Sudo's license is far more permissible than the GPL in the first place.
MornwindShoma@reddit
Still no base for your accusation here. Try again
socratic_weeb@reddit
You mean what I said about the GPL-washing being secretly backed by corps? Like I said in my OP, I "can't prove it". How about you trying to read again, this time with a bit of critical thinking. GPL-washing still a thing that happens, and it is bad for everyone.is
GaymerWasTaken@reddit
So... what if I want to release my software under the MPL that way indie developers can benefit from my code or improve it without having to merge it with original?
GPL licenses require you to state your changes from origin. I personally don't like that, and even if you are okay with it - it's still tedious and annoying.
Additionally, I want EVERYONE to have freedom with my code. The code cannot be "used against" me, because most of the time I simply don't care to enforce a license in the first place, much less actually protect the damn code.
MPL and MIT are not bad. IIRC, they still require the source code to be kept open source - just not the same extent as the GPL - for example, if I choose to use MIT code as a template and close-source the result, I can, since the changes were more substantial than the template project. GPL specifically forbids this, and if someone can take my open source code and profit off of it - I personally say good for them; I know I can't most of the time, and if they change it to make it better, that's entirely fair game in my eyes.
You don't have to agree with me at all, but you also can't shit on developers for making choices YOU don't agree with. It's not your fucking code, it's not your fucking decision to make, and you don't know the care or ability to enhance the code that the original programmer may have had, nor the care or ability to enhance the new developer may have.
Sure, if you literally copy-paste my code and then profit off of it, you're an asshole, but the GPL isn't going to protect me from Google stealing my shit in the first place, it's mostly going to impact smaller developers. Google isn't even likely to completely steal and propritarize MIT code in the first place, they actively give credit. So who the hell do you think is this big monolithic corporation that is stealing random people's open source code and making it proprietary without modification? Even Amazon didn't dare when they did a bunch of bogus with Elasticsearch!
Your arrogance and ego is blinding, you're not superior to anyone else because you use a GPL license, and nobody is beneath you for using a license they prefer. If you think different, you're just as bad as the companies that DO steal open source code without credit or changes, because atleast those companies don't demand license changes to make things easier for them.
chucker23n@reddit
How about starting with: don’t sexualize software licensing
chucker23n@reddit
That person needs help.
mrlinkwii@reddit
sudo dosent have a gpl licence
socratic_weeb@reddit
My bad
NYPuppy@reddit
A what license? This isn't Phoronix.
Gipetto@reddit
https://www.reddit.com/r/linux/s/vPALvCH1h9