Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lib install --git-url and --zip-file must now be esplicitly enabled #1075

Merged
merged 1 commit into from Nov 16, 2020

Conversation

silvanocerza
Copy link
Contributor

Please check if the PR fulfills these requirements

  • The PR has no duplicates (please search among the Pull Requests
    before creating one)
  • The PR follows
    our contributing guidelines
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)
  • What kind of change does this PR introduce?

Changes an existing command flags.

  • What is the current behavior?

--git-url and --zip-file flags can be freely used in lib install.

  • What is the new behavior?

--git-url and --zip-file flags are now hidden by default and must be explicitly enabled by setting library.enable_unsafe_install to true in arduino-cli.yaml or by using the env var ARDUINO_ENABLE_UNSAFE_LIBRARY_INSTALL.

  • Does this PR introduce a breaking change?

Yes, but I suppose it won't be an issue since the feature has been added recently and released only on nightlies.

  • Other information:

None.


See how to contribute

Copy link
Contributor

@per1234 per1234 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I gave it a try and it works just as I expect it to.

@silvanocerza silvanocerza merged commit bacc2ac into master Nov 16, 2020
@silvanocerza silvanocerza deleted the scerza/hide-lib-install-flags branch November 16, 2020 13:22
@matthijskooijman
Copy link
Collaborator

Hm, I'm curious about this change, how are these options unsafe, really? They can cause random stuff to be downloaded, but the IDE does not actually execute anything from a library (unlike platforms), so the possibility for unsafety seems limited?

Also, this implies that regular library installs from the library manager are somehow more safe, but is this really the case? There is more potential for verifying the safety of libraries in the manager, but in practice I think there is only some limited manual inspection of library metadata correctness, but I doubt that @cmaglie fully inspects the contents of each library when adding it to the library, and I expect no manual inspection happens on future updates to the library.

Or is there another kind of safety meant here?

@ubidefeo
Copy link

@matthijskooijman
we're just taking a bit of distance from what people install as libraries that might end up in their secure IoT applications.
In the future as we work towards a centralised library repo with different levels of machine/human vetting we'd like to be able to recommend libraries that have a higher ranking based on solid information provided, maintainers being physical entities who actually take responsibility for their code, provide verification of examples based on architecture compatibility and so on.
It's a long-term plan, but we'll have to start somewhere :)

This option allows users to have the flexibility to install whatever they wish, and it'll be at some point transferred to the new IDE as a UI configuration option.
Right now we're addressing the need to install things in zip files and git repos, which IMO is really useful, and adding this configuration property makes sure that you can't just point to a URL and download whatever unless you know what you're doing.
"Overzealous" might be the word replacing "safe" for now :D

@matthijskooijman
Copy link
Collaborator

Thanks, sounds like a reasonable approach!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants