Some additional thoughts... Regarding “third-party” warnings..this reminds me of the way Amazon’s Fire handles third-party’s. It has a setting to prevent third party plugins with a turn on/off setting which indicates the untrusted nature of allow this.
Also reminder of some of the Linux (think it’s Ubuntu that I saw this on) which comes default with trusted repositories. In this context that really adds a layer to the user reduce the default plugin from being risk but doesn’t prevent it. I think in the case of the Linux “apt” (and probable others), to be able to add a repository, the repository is added and at the same time I believe some form of “public security key” is included. I’m not sure it fully prevents anything in that context but it might at least add a layer of trust to the mix. Not sure on this part but how are “mirrors” handled presently? Would this be a similar use case of a mirror? Are these all trusted in some way? Would a similar process for adding mirrors be relevant here? I’m not sure if this is worth wild as OS layers tend to provide external virus/anti-maleware type functionality, but could a “security” plugin be devised to provide some additional layer of checks (within the context of plugins)? So all that said maybe (1) Need to add some form of “Allow Untrusted Plugin Provider” option (2) Handle third-party provides similar to adding Mirrors (3) Need to put in place some form of authentication mechanism for Plugin Providers when adding the provide repository. I know this may not prevent things but it at least adds a means of establishing some layer of “trust” of the provider being who they say they are and hopefully leads back to an authentic source in some way. (4) Maybe some form of “Netbeans Security” plugin (maybe in the core NetBeans plugins) is needed to provide some layer of addiction checks and/or security functionality. Maybe something like that could do things like looking for the Ant issue identified previously, have some means of adding security key management, etc.). This might be something like a code analysis plugin in some ways with new rules being able to be added as needed (although I suppose that adds to the risk of a malicious rule too :-) ) Eric Bresie ebre...@gmail.com > On July 9, 2020 at 2:48:29 AM CDT, Jaroslav Tulach > <jaroslav.tul...@gmail.com> wrote: > 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:
