-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Block Versions Based on Some Filter #818
Comments
It relates with #810 |
I like the idea, but we would need to elaborate a bit more what are the boundaries and whether is possible with the current design + being optional |
Not having looked deeply into this yet, I imagined this would work by looking at the json object that has all metadata (e.g. this). When verdaccio goes to return this (or derived info from this) it would first parse this object and pass it to a plugin (where the default passes it through unchanged). This plugin could then do whatever it wanted to modify this source of truth. The rest of this proxy would have to obey that vision of the world. One example plugin would be one that takes in the rules described above and removes blacklisted and/or temporarily barred versions. If today where
From there, it would remove This could break end users in an odd way if your blacklist makes modules that are required implied dependencies appear to not exist. It would be better if we had some clear feedback mechanism for this case, but this is still much safer. |
Hi @juanpicado, any more thoughts on this? |
@mlucool I haven't had time yet, sorry. |
I spent some time on this. I would I was able to remove packages by adding in a function in storage.getPackage that pruned the result by deleting both the time and versions key for that specific version.
The only major issue with this approach is if you delete something that is a also a Therefore, I propose we add in a plugin with an API of one function, What do you think? Worth pursuing? |
Add a plugin that can filter all packages before being returned. This enables blocking at the verdaccio level. Fixes: verdaccio#818
@juanpicado I created an WIP in #1161 for what I think could create a plugin based approach to solve this. What do you think of this concept? If you like it, what do you think are the next steps to get this ready for merging? I know I need to refactor this so external plugins can be created and add unit testing. |
Add a plugin that can filter all packages before being returned. This enables blocking at the verdaccio level. Fixes: verdaccio#818
Add a plugin that can filter all packages before being returned. This enables blocking at the verdaccio level. Fixes: verdaccio#818
Add a plugin that can filter all packages before being returned. This enables blocking at the verdaccio level. Fixes: verdaccio#818
Add a plugin that can filter all packages before being returned. This enables blocking at the verdaccio level. Fixes: verdaccio#818
Add a plugin that can filter all package metadata before being returned. This enables blocking of bad packages at the verdaccio level. Fixes: verdaccio#818
Add a plugin that can filter all package metadata before being returned. This enables blocking of bad packages at the verdaccio level. Fixes: verdaccio#818
Add a plugin that can filter all package metadata before being returned. This enables blocking of bad packages at the verdaccio level. Fixes: verdaccio#818
Add a plugin that can filter all package metadata before being returned. This enables blocking of bad packages at the verdaccio level. Fixes: verdaccio#818
Add a plugin that can filter all package metadata before being returned. This enables blocking of bad packages at the verdaccio level. Fixes: verdaccio#818
Add a plugin that can filter all package metadata before being returned. This enables blocking of bad packages at the verdaccio level. Fixes: verdaccio#818
Add a plugin that can filter all package metadata before being returned. This enables blocking of bad packages at the verdaccio level. Fixes: verdaccio#818
Add a plugin that can filter all package metadata before being returned. This enables blocking of packages from verdaccio. IPluginStorageFilter are loaded like other plugins from the config. Verdaccio will look for plugins in config.filters and pass this to storage.init. This is the same design as other plugins and will be dynamically found with the same rules. These plugins must impliment a filter_metadata method, which is called serially (in the order loaded from the config) for every metadata request. It gets a current copy of a package metadata and may choose to modify it as required. For example, this may be used to block a bad version of a package or add a time delay from when new packages can be used from your registry. Errors in a filter will cause a 404, similar to upLinkErrors as it is not safe to recover gracefully from them. Note: When version is removed, be careful about updating tags. Fixes: verdaccio#818
Add a plugin that can filter all package metadata before being returned. This enables blocking of packages from verdaccio. IPluginStorageFilter are loaded like other plugins from the config. Verdaccio will look for plugins in config.filters and pass this to storage.init. This is the same design as other plugins and will be dynamically found with the same rules. These plugins must impliment a filter_metadata method, which is called serially (in the order loaded from the config) for every metadata request. It gets a current copy of a package metadata and may choose to modify it as required. For example, this may be used to block a bad version of a package or add a time delay from when new packages can be used from your registry. Errors in a filter will cause a 404, similar to upLinkErrors as it is not safe to recover gracefully from them. Note: When version is removed, be careful about updating tags. Fixes: verdaccio#818
Closing as this was completed via #1161 |
@mlucool Was this documented anywhere? I see all the PRs merged, but I can't see anything about filters on the docs site |
@robcresswell not extensively https://verdaccio.org/docs/en/dev-plugins#filter-plugin but yes, also the PR contains some information. |
🤖This thread has been automatically locked 🔒 since there has not been any recent activity after it was closed. |
Is your feature request related to a problem? Please describe.
Recent issues with community published libraries either malicious or not are generally caught by the community quickly. I'd like to come up with a defense against these types of issues.
Describe the solution you'd like
The ability to create a plugin that allows for fine grained, rule based control of if a package appears to exist to npm clients.
For example, I could create a rule that says a package must have been published at least X days ago before the registry proxy claims it exists to clients. This would take us off bleeding edge, but lower the risk of major issues. I would also be able to do things like feed it a blacklist of libraries that no one should be able to download (e.g. in the days before npm grabbed this, we would block it). A good design would allow for easy admin and escape hatches to let new versions flow through. It may also consider allowing clients the ability to override this depending on the design and trust model we want to build.
There is clear risk here and moving away from a simple proxy and increasing the complexity and management of a proxy, but given the seriousness of recent issues, I believe would add a good line of defense.
What do you think?
The text was updated successfully, but these errors were encountered: