Hello Eric. - pátek 10. července 2020 15:11:57 CEST, Eric Bresie - > 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.
Good/better enough. Just like we currently do with 8.2 update center. User needs to explicitly enable it in Tools/Plugins/Settings tab. That however means that modules in PP3 catalog cannot install "enabled by default" catalogs. E.g. jVi plugin could install its catalog, but it should be disabled by default. Users who trust Ernie would have to go to Tools/Plugins/ Settings tab and explicitly checkbox his catalog. > 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. I know that when I use [PPA](https://launchpad.net/ubuntu/+ppas), I am basically on my own. Btw. It doesn't increase security that the archives are signed, what matters is that they are permanently archived somewhere (by Ubuntu, I assume). > So all that said maybe > (1) Need to add some form of “Allow Untrusted Plugin Provider” option a) having an AU catalog preinstalled, just click the checkbox to enable it b) manually Add a URL as a new catalog > (2) Handle third-party provides similar to adding Mirrors I am not sure what do you mean by this? Apache NetBeans should focus on making it simple to distribute modules as part of Apache NetBeans or via approved PP3 (and Maven central repository). > (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 :-) ) Alas, I haven't designed NetBeans with a security in mind. No SecurityManager and permissions for modules. Now it is too late to fix it on the code level, in my opinion. As such I am only calling for a policy, not a tool. Best regards. -jt > > On July 9, 2020 at 2:48:29 AM CDT, Jaroslav Tulach > > <[email protected]> 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > For further information about the NetBeans mailing lists, visit: --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
