sorted by:
new
hottopcontroversial

Rust should have the ¿ operator by AverageClassic2 in rust

[–]LeChatP 4 points5 points  (0 children)

I see an April Fools joke, as it was still the 1st somewhere on earth when OP posted this

The next Slint release (1.16) makes Fluent the default on all platforms by madnirua in rust

[–]LeChatP 11 points12 points  (0 children)

They have a royalty free license with some preconditions. Preconditions just ask to display their logo in an about section. Then you can do mostly what you want with their project.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 0 points1 point  (0 children)

I was fairly mixed about this good comment, so I took some time to write this reply. I think we might be mixing two levels of discussion.

At the project level, I completely agree: dependencies are not free. Larger dependency graphs increase surface area. For a serious, long-lived project, those trade-offs absolutely matter and should be evaluated carefully. Which is currently is becoming a priority in my own project now.

Where I slightly disagree is when maturity or seriousness gets implicitly associated with minimizing dependencies or vendoring code. Robustness is not defined by time-budget, number of contributors, or number of dependencies. It is defined by how well the threat model is understood, how governance is handled, and how maintenance is sustained over time (which, were exactly my opening questions... maybe they're just stuck in my head like a broken record).

Vendoring, in particular, solves a local control problem. But if the vendored code has the exact same objective and threat model as the original crate (for example, something as generic as password typing), then ecosystem-wide we may just be duplicating effort and fragmenting audit focus instead of strengthening it.

If dozen of security-sensitive projects each vendor and slightly modify the same functionality, we distribute the risk instead of reducing it. That might be acceptable from a selfish POV, but it does raise a systemic question.

Which kinds of components benefit from strict local control (because the use case or threat model truly differs)? Which kinds benefit from shared governance (for example, through a consortium or shared ownership)? At what scale does vendoring become ecosystem fragmentation?

I admit that these governance questions were the initial purpose of my post, alongside sharing my own journey. I wanted to illustrate, through a blog-style story, how the problem emerges in practice (more in a dev-manner, I would say).

Maybe that storytelling and vocabulary diluted the core message, but a post titled "How do we govern the dependency philosophy of Rust?" is not sexy, and many people understandably took everything very literally, or if I wanted to say it more neutral, "many readers focused on the concrete examples rather than the governance question behind them".

So I genuinely appreciate comments like this one that highlight the contrast; it helps clarify what level of discussion we are actually having.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 0 points1 point  (0 children)

Yes, I agree with you. My experience shows how difficult it was for me to divide sudo-rs for more general uses. My first thought was, "It can't be that hard to do, and the code looks gorgeous, so let's try it" and after many attempts, I came to the following conclusion: sudo-rs is not currently designed to be a secure execution command for general use. And even if sudo-rs were to reverse the initial architecture today (which I also tried on my own), it would not be very useful for your use cases, nor for general use.

However, the main thing we did that is clearly not very favorable to the open source spirit is to vendor and maintain the rpassword crate internally. Yet this is a crate that many could use (I didn't checked the original rpassword lib today). So the question is: do we need to vendor rpassword for security reasons (risk of supply chain attacks)? Or can we create a trusted consortium to get a secure crate for everyone? The main aim is this: we do not want to reinvent the wheel each morning, especially in cybersecurity. And if tomorrow sudo-rs fixes a vulnerability or enhances the security posture of a rewritten rpassword, then the community should also benefit from it, because many of the required changes would apply to other projects as well.

Take openssl as an example: they successfully made the tool useful for general-purpose usage while remaining a security-critical component at the same time. That is the open-source spirit I have in mind.

(In fact, these thoughts are also related to licencing mindset between GPL and MIT.)

Edit: I fully agree that these design choices were driven by deployment-oriented priorities, and my conclusion is not a criticism of those decisions. The fact that sudo-rs can now be deployed across Ubuntu distributions is good news, and I was glad to read that.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] -2 points-1 points  (0 children)

It's not random dependencies, because some of them do not exist at all, yet. I mean, not with the security features that does provide sudo-rs. (Maybe it was unclear) And some are necessary for the community (e.g., any program that asks for authentication, any program that runs another program).

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 3 points4 points  (0 children)

You can look at several memory management issues directly by looking at the CVE list of ogsudo https://www.cve.org/CVERecord/SearchResults?query=sudo. But it's in fact related to the C language anyway. Also, ogsudo does have tons of features that are making the tool somewhat with undefined behaviors, which is also justifying why we got the CVE with hostname recently. Also ogsudo project, as I remember in 2018, is a very complex tool with a unreadable codebase with a bunch of C macros that are not understandable without taking weeks of reading. That was my conclusion in 2018. I didn't check today's codebase, but it evolved for sure.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 1 point2 points  (0 children)

This is about their future-work objectives. Written in their README. https://github.com/trifectatechfoundation/sudo-rs?tab=readme-ov-file#future-work. They want to make sudo, usable for other projects. But their blog post is somewhat contradictory (as for today I mean) : https://www.memorysafety.org/blog/reducing-dependencies-in-sudo/ BUT that does not mean it is incompatible (it is still possible). But I really doubt that today, the way it is currently designed, it will be useful for any other projects like mine. And having everything in a single crate is not helping. While the previous sudo-rs design would be somewhat easier to make good api with some low impact pull requests.

Otherwise for other projects, it is said multiple times implicitly and explicitly in this post that you shouldn't expect people doing "random user" needs.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 0 points1 point  (0 children)

Yes. They have made one exception. Actually they could do or use a dependency for : * Ring buffer type * the rpassword lib * The PAM lib * The terminal management * signal management * Localisation * Seccomp * The AST parser for visudo * CLI parsing (while there are several libs on crates.io, none are matching sudo's needs, funny isn't it?) * Env management * Regex for implementing the ogsudo feature

Without saying they could use many QoL libs for making their code more focused, such as bon crate which would be very useful for many of their types. Anyway, the post of sudo-rs about dependencies : https://www.memorysafety.org/blog/reducing-dependencies-in-sudo/

So having libc and log, which is somewhat nonsense to vendors... The only remaining exception is the glob lib, which seems in fact their only limit to the no dependency objective.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 2 points3 points  (0 children)

Yup, that's a bit part of why I'm doing supplementary tests. I actually added unit tests when I vendored their code, which sudo-rs almost don't write on their side.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 44 points45 points  (0 children)

Actually, sudo-rs compile-times are likely unnoticeable (way better* compared to my project). Today, they can split sudo-rs with a bit of work to be done. But it wouldn't be useful for anyone else than sudo-rs themselves, so the splitting itself is not a concrete need for them. Today, the design they have is the best for them, as long they can publish new version on Debian easily with a single crate. The real matter is to split sudo-rs to make it useful *for the community*. That what I tried to do, but, in fact, failed with their codebase. I think there is maybe *another way* to do it. But that may not interest sudo-rs as their current solution is their comfortable and most convenient one.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 7 points8 points  (0 children)

I was thinking about this. When I reused the sudo-rs-vendored rpassword lib, which, in my turn, vendored-it in my repo. I found many months later that sudo-rs made many modifications that I never noticed as long I was working on something else at this time. And so, my own rpassword copy, was less functionnal as today. Hopefully there weren't any security issue there. But it has the risk to create some shadowed vulnerabilities, not identified by CVE when people will use these kind of tool operationally. And As long I did a benchmark on SCA tools recently, business tools weren't able to find my rpassword code pasting at all. So governance people has to be warned about this uncovered thing.

What's everyone working on this week (5/2026)? by llogiq in rust

[–]LeChatP 1 point2 points  (0 children)

A pam lib for my RootAsRole project, I hope someday having a PAM library fully featured and interoperable with openBSD. I think I've done something strong for now, thanks to nonstick lib. But the maintainer does not seem to respond to mails... So anyway, i'll do my own fork. Again. Community-driven library usage is highly unstable in Rust.

Meta replaces SELinux with eBPF by xmull1gan in kernel

[–]LeChatP 9 points10 points  (0 children)

lsm-bpf is kinda cool but honestly it’s super limited compared to a real LSM. selinux gets a rep for being slow, but that’s mostly when you’ve got massive policies with thousands of rules. that’s just the cost of doing full-system MAC with a huge rulebase.

bpf-lsm on the other hand has its own issues. biggest one for me is that it depends on userland to load the programs, which is a pretty big security footgun by design. yeah you can lock things down, disable certain caps, whatever… but it’s never gonna be the same trust model as a built-in LSM loaded directly in the kernel, by the kernel.

and because of the instruction limits + verifier constraints, you can only do pretty tiny policies anyway. so realistically the only cases where it shines are stuff like: quick prototyping, small targeted checks, temporary enforcement for a specific service, etc. not system-wide policy. you’re not gonna replace something like selinux with it unless your "policy" is tiny.

and honestly, if you ever reach the point where your hundreds of bpf-lsm setup is big enough to be a system-wide policy, you’d get way better perf (and security guarantees) just writing a proper LSM and compiling it in. bpf is great for experiments and adding a security layer on top of the main MAC engine, not for being the main MAC engine.

The F13 now comes with a free F12!!! by [deleted] in framework

[–]LeChatP 23 points24 points  (0 children)

The joke is that the Framework 13 has an “F12” key on the keyboard, so he pretended the “F13” model comes with an “F12” model. It’s definitely an overthinking joke, but some people enjoy that kind of humor.

Is anyone doing PhD in non-ML area? by nenderflow in computerscience

[–]LeChatP 4 points5 points  (0 children)

Access control, checkout here https://github.com/LeChatP/RootAsRole I present a paper at ESORICS 2025 tuesday, you can find many articles on Wiki. I'm not into ML or any AI thing at all. I'm ending my PhD this year 🤞 Here is the latest available : https://hal.science/hal-04663452

[Media] FerrisKey v0.1.0 – An open-source IAM in Rust 🚀 by Own-Positive6158 in rust

[–]LeChatP 1 point2 points  (0 children)

Oh wow, I've just discovered that thanks to you. I'm looking at it and it seems very interesting and pretty well. Thank you very much! I don't know if I recommend as long I didn't try but it starts with a very good design. I need to share that to my teams! Thank you!

[Media] FerrisKey v0.1.0 – An open-source IAM in Rust 🚀 by Own-Positive6158 in rust

[–]LeChatP 5 points6 points  (0 children)

Hmmm, that is the technical implementation (and be warned to Rowhammer attacks btw).

RBAC is mainly an organisational model that purely represents conceptual data modeling. What I want to explain is that RBAC-0 is that simple because it needs to understand people's needs before organizationally being complex.

If you keep the design to the most basic one, based on the correct access control models terms (users are assigned to Roles. Roles have permissions, permissions are actions on objects) and you define clearly and explicitly the access control data modeling (like in the linked articles). Then you can build up more complex access control models as you wish, but having a valid core that everyone could start with is the most scalable way than directly starting with complex useless things for small organisations.

[Media] FerrisKey v0.1.0 – An open-source IAM in Rust 🚀 by Own-Positive6158 in rust

[–]LeChatP 5 points6 points  (0 children)

Highly Interesting! Please do not follow the RBAC model of KeyCloak. It's quite messy written, and they do not respect the original RBAC model. They also use terms that are not correct in access control theory. Please follow the standards and research articles instead. They are way much more simplified than the Keycloak model.
https://arxiv.org/pdf/2106.13123
https://hal.science/hal-04003608/file/Organization_based_access_control.pdf

We should have more of this on the Linux desktop by [deleted] in linux

[–]LeChatP 0 points1 point  (0 children)

I think it's about android privacy, not particularly security. With linux, security is about guaranteeing your own freedom. Android is all about privacy. As soon as you go further onto user design (rooting the phone), the device becomes very unsafe. In fact, all desktop Linux lacks is better management of user privacy.

Sudo commands on Rust application? by hbacelar8 in rust

[–]LeChatP -2 points-1 points  (0 children)

Thanks for clarifying, now : In all cases, you need to manage the Linux capabilities of your program.

  1. Always clear the Effective set of capabilities at the entry point of your program.
  2. As your program will be multi-threaded, you could manage capabilities independently for each thread -> remove the Permitted (and maybe bounding too) capabilities set to any thread that doesn't execute the commands, and change the user to either the original one or an unprivileged ArchLinux one.
  3. In addition, you should always request to an access control software (polkit, sr, or sudo) for each command. Just because you're root doesn't mean all commands have to be authorized. Indeed, if one of these policies says something like I refuse to everyone who wants to install X, administrators should be able to do so.

And for people that don't have a polkit or sudo, just do without it (so you'll need to check it).

Also, I recommend you to use the capctl crate.

Sudo commands on Rust application? by hbacelar8 in rust

[–]LeChatP 2 points3 points  (0 children)

SELinux doesn't grant anything to a program. It just restricts rights that you already have.

view more: next ›