[Discuss] Security and lunching programs from the IDE

[Antonio <an...@vieiro.net.INVALID>]

Hi all,

For the Rust support we want to rely on Rust's "cargo" command to 
perform different tasks (adding dependencies, building and running 
projects, etc.).

This is very much the same we do with other external tools we may use, 
such as "maven", or "npm" or "gradle" (we use our embedded "ant" though, 
AFAIK).

The question is, shall the IDE ask the user for permission before using 
any of these external commands? Or is it ok to find them in the PATH, 
for instance, and start using them directly?

Opinions?

Thanks,
Antonio

P.S.:

I know we're warning the user before opening a Gradle "build.gradle" 
script, for instance (since we have to run the script to evaluate it, 
whereas Maven scripts are declarative).

Visual Studio Code also asks for user permission before opening many 
projects.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [Discuss] Security and lunching programs from the IDE

[Matthias Bläsing <mb...@doppel-helix.eu.INVALID>]

Hi,

Am Dienstag, dem 14.03.2023 um 18:31 +0100 schrieb Antonio:
> 
> The question is, shall the IDE ask the user for permission before using 
> any of these external commands? Or is it ok to find them in the PATH, 
> for instance, and start using them directly?
> 

for the building invocation it is IMHO a no-brainer. Nobody expects the
shell to ask you "Do you really want to invoke 'make' from the path?"
and from my POV it is the same for the IDE.

If a command is on the PATH of the user, the user installed it. If a
user is intelligent to write/install a programm "kill my disk" and name
it "cargo" and make it available on the PATH, then this is evolution
and not a problem of the IDE.

So TL;DR: Invoking cargo without asking the user explicitly is IMHO
fine.

We ask for trust when opening gradle projects, because _parsing_ gradle
projects requires invoking foreign code, which could be surprising.

Greetings

Matthias

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [Discuss] Security and lunching programs from the IDE

[Neil C Smith <ne...@apache.org>]

On Tue, 14 Mar 2023 at 17:31, Antonio <an...@vieiro.net.invalid> wrote:
> This is very much the same we do with other external tools we may use,
> such as "maven", or "npm" or "gradle" (we use our embedded "ant" though,
> AFAIK).

Maven is embedded too.

> The question is, shall the IDE ask the user for permission before using
> any of these external commands? Or is it ok to find them in the PATH,
> for instance, and start using them directly?

What are the actions that will invoke the commands?  Are they all
actions where the user should expect code execution?  If yes, I'm not
sure permission is required, although might still be worth
considering?  If not, then sounds like a similar trust mechanism to
Gradle might be needed?

The Gradle trust mechanism came about mainly because it should be
possible to open and inspect a project in the IDE without code
execution, whereas building it you should expect.  Similarly the
Micronaut wizard warnings (because mvnw support was not added with
background execution in mind) -
https://github.com/apache/netbeans/pull/3506

Best wishes,

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists