Comments (3)
Quality Requirements
Some ideas on items for a plugin quality checklist:
- Plugin scripts should be run through a static analysis tool like ShellCheck, and this analysis should be wired into the CI build.
- Plugins should only use HTTPS for downloading artifacts (not HTTP).
- Plugins should not make system-wide changes to the host, such as installing global executables or libraries.
- Where possible, plugins should include integrity checks for all downloaded artifacts using a strong cryptographic hash (SHA256 or better; not MD5 or SHA-1, which are no longer secure).
- Where possible, plugins should include authenticity checks for all downloaded artifacts using cryptographic signature verification (typically using GPG with a statically hosted public key).
- If a plugin performs authenticity checks using GPG, it should not pollute the user's default keychain with these keys, and instead use a dedicated GPG keychain (example).
- Plugin scripts should be human-readable (not obfuscated and/or minified).
- Plugins should have a CI build that executes in a Linux environment.
- Plugins should have a CI build that executes in an OS X environment.
- Plugin authors should run
asdf plugin-test <plugin-name> <plugin-directory>
to run the standard asdf plugin tests for their plugin, and incorporate this command into the CI build.
from asdf-plugins.
License Restrictions
Figured I'd throw in my $0.02 here, since this issue has been stagnant for a while and it's a good prompt.
TL;DR: The only relevant clause in a license for this repo, I imagine, would be a grant to execute the plugin software and to redistribute its source code. This should already be granted in most software licenses.
Concerning licenses and license restrictions generally:
-
A plugin's license may differ from that of the tool it manages. For example, the Java plugin may use the MIT license, but manage, amongst other things, the Oracle JDK, which has its own proprietary license. The Ruby plugin manages several different implementations of Ruby, each with its own license. If this asdf plugins directory has a license requirement of any kind, would that requirement be on the plugin or on the software it manages?
-
If there is some licensing restriction for listing in this plugins directory, then it might also be a good idea to communicate to end-users which license each plugin uses. This could be included in the output of
asdf plugin-list-all
, along with the plugin name and repo URL. It could also be communicated with a license badge in this repo's README, like so:![License](https://img.shields.io/github/license/twuni/asdf-yarn.svg)
-
If communicating the license information per (2) above, there is a risk that end-users may mistakenly assume the license presented is the license for the tool being managed (not the plugin itself). This could be mitigated (but not alleviated) using a "Plugin License" column label, which would help to distinguish that the listed license is for the plugin itself.
-
The status quo of not presenting any specific license information, but just providing the repo URL for each plugin, is probably the most correct approach to communicating license information. It provides end-users with a way to verify this for themselves, as needed, and is guaranteed to be up-to-date because it is the definitive source of truth for that plugin's license. With this option, there's no risk of miscommunicating a plugin's license if it changes upstream.
The prompt isn't about how license information is communicated, though. That's more of a tangential path.
from asdf-plugins.
- A plugin's license may differ from that of the tool it manages. For example, the Java plugin may use the MIT license, but manage, amongst other things, the Oracle JDK, which has its own proprietary license. The Ruby plugin manages several different implementations of Ruby, each with its own license. If this asdf plugins directory has a license requirement of any kind, would that requirement be on the plugin or on the software it manages?
That's a good question. For security reasons we absolutely have to have the plugin code be open source (otherwise we might not be able to legally read it), but I guess requiring them to be free (e.g. MIT license) isn't strictly necessary.
- If there is some licensing restriction for listing in this plugins directory, then it might also be a good idea to communicate to end-users which license each plugin uses.
Possibly, although the way asdf uses plugins I think most users would never have any issues with the various open source licenses (most users won't be packaging plugins into commercial products). But maybe showing the licenses is a good idea.
- If communicating the license information per (2) above, there is a risk that end-users may mistakenly assume the license presented is the license for the tool being managed (not the plugin itself). This could be mitigated (but not alleviated) using a "Plugin License" column label, which would help to distinguish that the listed license is for the plugin itself.
Good point. I'm open to anything here. As far as we are concerned the tool itself can have any license.
Another thing to consider is cruft in the list. We've got quite a few Kubernetes plugins on the list. I'm not a user of Kubernetes so I'm not totally sure why there are some many different plugins for the software around Kubernetes, but we don't want the list to grow so large that it no longer is useful to end users.
I like everything on your checklist! Some of those things are easier to automate than others. Feel free to implement some of those things if you like!
from asdf-plugins.
Related Issues (20)
- pnpm plugin update broke installing pnpm versions older than 6.12 HOT 2
- Single repository for all plugins HOT 8
- [New Plugin]: Stoplight Spectral CLI HOT 1
- Invalid format in link plugin file
- asdf-dotnet or asdf-dotnet-core ? HOT 3
- Remove asdf-conduit plugin HOT 4
- Remove asdf-desk plugin HOT 8
- Remove asdf-stack plugin HOT 1
- [New plugin] Raku HOT 1
- Elixir plugin shows no compatible versions when doing asdf elixir list-all HOT 1
- [New Plugin]: AWS Amplify CLI HOT 1
- It seems that the plugin `asdf-community/asdf-python` has their issues accumulated without people responsible for it? HOT 3
- Swift plugin was removed from the README.md HOT 1
- `asdf-community` GH Discussions doesn't work HOT 8
- Switch to working leiningen plugin
- CI status for plugin list in README.md is causing api rate limiting HOT 6
- [NEW PLUGIN] eza HOT 1
- [New Plugin] JFrog CLI v2 - JF
- [New plugin] chisel
- plugin test script is failing - CI badges missing HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asdf-plugins.