Post #1971047
2026-05-01 13:51 UTC
Replies (2)
-
@swick@hachyderm.io 2026-05-02 10:23
@zeenix If there is a database library with an API based on string manipulation instead of prepared statements, you would never touch the project. You could equally argue that lots of people write software which uses databases but never have to care about malicious inputs. Why would you provide an unsafe API when you could just provide a safe API? Opaque handles to filesystem objects are not particularly hard to abstract in a cross-platform manner. In the worst case that handle is internally just a path. The argument that a crate exists is missing the point. People use what is in the stdlib and they do not even know that they should look for something else. That would be fine if that code is never used by anyone else, but realistically re-using code is a necessity. So if you try to re-use code, you either can't because you notice at the API boundary that e.g. a function call requires a path, or you don't notice that you can't because the security issue is somewhere hidden in the implementation. For example glib uses paths for everything. If you want to trash a file the API requires you to pass a file path. I cannot use the code to trash a file and had to re-implement all of it. glib could have made it secure, we have a library for it: libglnx. It didn't help at all. The issue here is that code does not compose.
-
@pid_eins@mastodon.social 2026-05-04 08:38
@zeenix sorry, but you are basically saying that using rust for system level software where security boundaries exist is not really an issue because it isn't the intended audience for rust, and just too specific. I am pretty sure you are pretty alone in that view of the world though... FS access is a commodity, it just has to be there, hast to work, and be as secure as possible by default because it's highly security relevant, and a primary security boundary itself. Just accept that please.