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.
For example:
* if the mandatory Quality Criteria for PPUC [1] are missing some
security checks, then let's add them to the procedure.
[1]
https://cwiki.apache.org/confluence/display/NETBEANS/Quality+criteria+for+Plugin+Portal+Update+Center
* if verification of plugins is slow, let's agree on some allowed number
of verification requests per month/plugin and reasonable reaction time
for plugin verifiers.
* if plugin verifiers are still overloaded, let's find more volunteers
who will test plugins on a daily basis starting with the requestor
him/herself.
Hope this makes sense,
-Jirka
Dne 06. 07. 20 v 20:25 Ernie Rael napsal(a):
Greetings,
If there were some guarantee or even a reasonable expectation of a quick
response after requesting validation then I'd be more inclined to accept
such a restriction. I am uncomfortable depending on the portal for
critical bug fixes in a timely fashion.
Further comments inline.
-ernie
On 7/6/2020 10:13 AM, 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..
I can think of ways, easy ways, to put security violations into a module
on the plugin portal. Saying that installing a module, and looking at it
for a few minutes (if that long) mitigates security threats from the
module is a joke. Might the testing/validation be more extensive than I
suspect?
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
That's not true. Only the people who install that plugin are susceptible
to malfeasance.
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?
How about only supporting update centers that download from maven
central? Since using Maven Central seems to be the primary method of
security, this would seem to satisfy security considerations and still
allow timely updates.
And are there related RCP issues?
-ernie
PS.
Speaking of PP3, it has two uses. First is building a catalog, second is
as a place to look for plugins and/or get information on plugin before
downloading them. User browsing has issues,
see https://urldefense.com/v3/__http://mail-archives.apache.org/mod_mbox/netbeans-dev/202006.mbox/*3Cc24e9f9e-da9b-e2ab-5ac3-f5fb9b4c750b*40raelity.com*3E__;JSUl!!GqivPVa7Brio!MRNaYRIr3wI3bXWvzWwvlhclhC7nTS9PHAqPwfEOoOrR5mhmzFLucmjd0PccB5LDm1M$
-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:
https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NETBEANS/Mailing*lists__;Kw!!GqivPVa7Brio!MRNaYRIr3wI3bXWvzWwvlhclhC7nTS9PHAqPwfEOoOrR5mhmzFLucmjd0PccsPdHplg$
---------------------------------------------------------------------
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:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
