It might be a drop in replacement to sudo
, but I would not use it as such for a while.
If you look at the bugs that sudo had over the years, only a fraction of them have been caused by unsafe memory operations. The majority has been caused be its own complexity and the complexity of the sudoers
file. These problem classes are not going away by porting the tool over to Rust or any other language.
Since this is a rewrite, it will have its own security bugs that need to be found and fixed first.
So until sudo-rs
has had a couple of years of people fixing security issues, I’d rather not adopt it.
Given that, I have a hard time imagining why someone would pour time and resources into a rewrite of sudo
for years to come instead of working towards a simpler solution.
Yes and no. Sure you can build a library that puts an encoding aware interface on top of strings, but it will cause friction every time the program interacts with something that does not subscribe to the same library, most notably probably the stdlib.
deleted by creator
Ah, that is another thing that Zig does well (in my opinion).
Instead of having a global allocation call, Zig uses an allocator
interface interface, meaning you as the programmer can plug in different allocation strategies as you require. So depending on if you do or don’t like that behavior, just pick the allocator accordingly, either for your whole program or just for parts of it.
His clickbaity nature is what makes ThePrimeagen successful I’d argue
It does not “solve” memory allocation failures, as its not a thing that can be solved.
It exposes memory allocation in a way that forces you as a programmer to handle the possible error situation. You cannot just call malloc
or new
or what have you and the just move on as if nothing happens.
Does that mean that GNU has finally given up on the dream of Hurd ever becoming a thing?
It promises more correct code. As an example, most rust code and in fact most crates you will find will treat a memory allocation failure as an irrecoverable error, ie. your program will just crash.
In Zig, such error classes are not supposed to exist by definition, making the resulting programs more robust.
The thing that keeps me from loving Zig is https://github.com/ziglang/zig/issues/234
I am too shell shocked to keep thinking of strings as u8[] it’s 2023 for god’s sake.
Its never really a good approach to store secrets in plain text. I don’t see how that would be more expensive for your database than validating clientId + secret.
The modern way of thinking about security of internal networks is to assume there is no such thing (marketing term: Zero Trust).
There is no difference security wise. The benefit of the clientid is mainly that it is shared cleartext information, so it can be used in eg. support requests, password recovery, what have you.
Technically true, but he has two merge commits in last three years. Not sure that will still give him much of a pull.
The right to fork the project is granted to anyone by the creater of the project (who by the way is not the current maintainer).
Calling a fork “project hijacking” means the person granting the right by license was acting dishonesty to begin with, wich makes me question who is acting in bad faith. Being able to modify and redistribute open source code are elemental freedoms the FOSS community thrives on. These freedoms do not mandate any reason and they certainly don’t legitimise anyones judgement.
My personal gut feeling: the maintainer will just shoot this attempt down and close the PR.
Happy to be proven wrong here though.
Yes. You could be the one!
Yeah, I tend to agree, the responsibility should definitely warent it.
Good luck with the whole thing, I hope you get a decent bump out of it :)
I think that is rather intentional. The story does not actually offer much of an insight, but give it a Dilbert and slap a clickbaity, slightly misleading spin on it, and you get a descent amount of upvotes.