Hello Karl, Ernie. First of all thank you for your contribution to NetBeans. Maintaining jVi, building commercial plugin on top of NetBeans, are both examples of a great support for the project.
> I've seen some posts that say that maven central is safe because the > source is available. That seems a questionable claim. Is there any > review of the source or does anyone build their plugins from source Having sources available and reviewing them before letting a plugin in, would of course be great, but I assume we don't have qualified volunteers to do that. Reviewers should at least check the registrations (in layer, meta-inf services) and make sure they don't do much harm. The "security" of Maven central consists of two components in my opinion: - the content is immutable and signed with .asc files - Sonatype knows who uploads the bits The immutability prevents anyone to destroy evidence. Should there be a security breach, police can trace the identity of the attacker. Especially the immutability is missing in case of custom update centers. I guess the example given by Karl is exactly the one I wanted to analyze: > There should be at least one exception from this restriction for vendors > of commercial plugins. > > My company offers a commercial plugin (JFormDesigner) for NetBeans ... > > Our plan is to create a small (open-source) plugin that only adds the > JFormDesigner update center to NetBeans. Then users can download/update > JFormDesigner from our site and we are not required to upload commercial > binaries to Maven Central. #1 - Such a plugin serves as a promotion. Users checking the content of Tools/Plugins/ Available or the plugin portal are going to find your functionality. #2 - Such a plugin makes installation of the functionality relatively easy for end users. I don't know how to replace #1, but #2 could for example be solved by associating `.nbm` files with NetBeans in the browser - clicking on the .nbm in the browser would offer NetBeans as the default application and NetBeans would open the Tools/Plugins. Then the 3rd party modules installation might be relatively smooth. The major issue I am aiming at is to make sure the end users understand that after installing a plugin with an update center, Apache NetBeans project no longer takes responsibility and the responsibility is on Ernie and Karl. As Antonio points out he is ready to trust Ernie and so will many other users. I guess it is about finding a balance and making sure users know what they do. I don't want to hurt Ernie's and Karl's business, but it should be Apache NetBeans policy that plugins are distributed via Maven central. As far as I understand Ernie is using update center to workaround the publishing process flaws, but as Jirka Kovalský wrote: > I agree that we should only promote hosting of plugins on the official > Apache NetBeans Plugin Portal. If there are reasons why plugin > developers think of creating their own update centers, then let's rather > collect the reasons and try to resolve these in order to avoid these > shadow and potentially risky sources of NetBeans plugins. We should rather improve the process than workaround it. If Antonio wants earlier updates directly from Ernie, he should opt-in (by enabling Ernie's update center that'd be disabled by default?). > Another improvement for more security would be to have a possibility to > restrict update centers to specific plugins. Then e.g. the JFormDesigner > update center would be only used/allowed to download/update > JFormDesigner plugin, but not other plugins. Interesting solution. We just need somebody to implement it ;-) Maybe, rather than finding bullet proof technical solution (which is unlikely anyway), we'd rather update the policy for reviewing the modules. -jt > On 06.07.2020 19:13, Jaroslav Tulach wrote: > > Hi. > > Recently I have noticed discussion explaining how to bypass NetBeans > > Plugin Portal. The usual way is to create a NetBeans module extension to > > provide own update center definition and register it in NetBeans Plugin > > Portal. Once a user downloads such module, the provided update center > > gets activated and can distribute new updates or new modules. > > > > Isn't this a security thread? Shouldn't we ban modules that register own > > update centers? > > > > When we worked on designing the new update center based on Maven central > > repository, I wanted to benefit from the organizational structure of > > Maven repository: > > > > - identity of people who publish there is known to some extent > > - it is not possible to alter once published content > > - there are sources next to each published module > > > > With such constraints we can more properly verify what 3rd party NetBeans > > extensions do before we approve them.. With modules that bypass our > > Plugin Portal by installing their own catalog, we loose any control. > > Owners of such catalogs can publish anything, anytime to anyone and > > change that whenever they want. It's just a matter of time till somebody > > exploits that. > > > > Shouldn't we require 3rd party modules available via the default NetBeans > > Update center to avoid such bypassing and always release new versions via > > Maven Central and NetBeans Plugin Portal? > > > > -jt > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit:
