The security argument was less about a malicious library, as about a malicious actor inserting an option in your command line. Your main would not be able to safeguard/shield a library from it. And that can open up security bugs. Yes, a library can read the arguments to its process. But is it good architecture? Shouldn't that be controlled by main? Which can filter the arguments or remove dangerous options or special characters before forwarding to the library.   -----Ursprüngliche Nachricht----- Von:Tiago Freire <tmiguelf_at_[hidden]> Gesendet:So 13.10.2024 21:42 Betreff:RE: [std-proposals] A draft for a std::arguments proposal An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>;   > Do we want libraries to access command line arguments? >That is another source of possibly security related bugs, e.g. append logfile to password or configuration file, path is given on command line. > Isn't that what environment variables or config files are there to do it globally for one library over all programs using it. > A command line is like a parameter to main, main should decide, whom to forward it to.   There’s nothing right now that is stopping libraries from accessing the command line arguments. One of the strengths of this proposal is that you can already do this on most platforms, it is just not standard. Having a standard way for libraries to do it doesn’t make it any less safe, it was never safe, you either fully trust the library that you are running or you don’t. If a library is made with malicious intentions and it gets the chance to execute anything at any moment, you are owned, getting access to secrets stored in the command line would be the least of your problems.   I will even go further, you can read the command line arguments for other applications running on your system without much in the way of permissions necessary.