Sorry, my mistake, I misunderstood what you meant.

In that sense, yes, in "general" I agree.
In general parsing arguments outside of a "main like context" is not a good design. If possible, libraries would be configured with data already structured and curated by the application, and this is possible because in general applications are designed with privileged knowledge of the capabilities of the libraries they are using. And avoids issues like "what if there's a clash between the arguments that the application uses, and those that the library uses"? Would such an application even be well formed?

However, there might actually be a killer application for this. For example, a third-party plugin or extension, that can be extended with custom options (that would be convenient to pass through the command line) but that the application itself would not know to forward those arguments to the right library, (and it is closed for modifications). In that situation the library would have no other choice but to parse its own arguments directly without support from the application, (but in that scenario the library would be the one designed with privileged knowledge of the application).

It's an unusual pattern for sure, but not an unrealistic one.



________________________________

From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, October 13, 2024 9:50:48 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
Subject: Re: [std-proposals] A draft for a std::arguments proposal


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.