On Thu, Jul 9, 2020 at 11:21 AM Christian Lenz <[email protected]> wrote:
> Hi, > > IMHO there is no need to restrict to only maven. I tried to move my > Plugins one by one to the new PP3 and saw 2 or 3 tutorials that I need to > follow which is far more work as before (Settings for sonar, account at > sonar afaik, maven account, etc.). As Geertjan said in slack: „yes but it > is more strict and safe“. I can fully aggree with that. > > So I thought about other solutions like using github for example because > everything is still there. As far as I know Apple with iOS is one of them > who only accept apps from there own app store. There is no alternative at > all afaik but I’m not 100%. > > I can say how it works for android as some of you may know already. You > have the google play store with official apps and restrictions how to > upload your app to them. And there are some other called „blackmarkets“ > where you can download apps on your own risk. Or whereever your APK file is > located (Google drive, via USB cable, etc.). Per default it is not allowed > to install apk files from other sources than the play store, but there is a > config where you can say: „Trust other Sources or install apks from unknown > Sources on your own risk“. And also if you install the apk, you got a > warning again. So I’m for this kind of solution. > > Also on Linux (Ubuntu and others) you can add repositories on your own too. > > So at the end, I’m not for restricting and disallowing other/custom plugin > portals than the PP3. I’m more for settings to avoid it and change the > settings (with a warning) if the user is sure about to use custom/not > trusted sources to install plugins. And that’s it, the rest is up to the > user. > Users can manually add an update center or manually install an NBM (which may register an update center). And I don't think Jaroslav is proposing to remove any of this. What I think Jaroslav is proposing is to restrict or disallow modules that register other update centers in our catalog, Plugin Portal. And I think it makes sense to be somewhat careful about modules in the catalog we maintain, and that are offered to the users by default. I think the Linux repositories are a good example - users can register another repository for themselves, but I doubt you can have a package in the distribution's repository that adds a third-party repository and enables it. So Jaroslav's proposal does not seem to be too far from what I think Linux repositories do? Jan > > > Cheers > > Chris > > > Von: Jaroslav Tulach > Gesendet: Donnerstag, 9. Juli 2020 09:48 > An: [email protected] > Betreff: Re: Bypassing NetBeans Plugin Portal > > 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: > >
