On Thu, Jul 23, 2020 at 7:12 AM Jaroslav Tulach
wrote:
> > (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
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
On Fri, Jul 10, 2020 at 5:38 PM Neil C Smith wrote:
> I personally prefer the idea of hashing in the plugin portal
Agreed, a cryptographic checksum in an HTTPS-retrieved catalog should
be sufficient, and is far less onerous than dealing with certificates.
The more interesting problem is not real
On Fri, 10 Jul 2020, 22:07 Tim Boudreau, wrote:
> >
> > What does this offer in practice, assuming any catalogue is downloaded
> from
> > a trusted location over https, above validating the file against the file
> > hash in the catalogue?
> >
>
> Not all that much, given that if you can compromis
>
> What does this offer in practice, assuming any catalogue is downloaded from
> a trusted location over https, above validating the file against the file
> hash in the catalogue?
>
Not all that much, given that if you can compromise the download, you can
also compromise the hash. Mostly just th
On Fri, 10 Jul 2020, 17:56 Tim Boudreau, wrote:
> That said, since we're unlikely to change the situation with regard to
> code-signing certs worldwide any time soon, Jesse's suggestion in the bug
> linked above is the more reasonable way to go: As long as signature
> information is downloaded v
Hi,
still not convinced that commercial code is allowed...
Issue https://issues.sonatype.org/browse/MVNCENTRAL-692
is about closed source libraries that are free to use.
See comment from Joel Orlina on 05/26/15
I think the main thing is that the artifacts need to be free to
distribu
On Thu, Jul 9, 2020 at 12:00 AM Ernie Rael wrote:
> On 7/8/2020 6:48 PM, Tim Boudreau wrote:
> > Isn’t that security threat the reason JAR signing was invented?
>
> I've heard that all, or almost all, plugin portal nbm's are self-signed.
>
> How does that affect the security implications?
>
> I'v
Hi,
Am Freitag, den 10.07.2020, 16:40 +0200 schrieb Karl Tauber:
> On 08.07.2020 22:21, Ernie Rael wrote:
> > On 7/8/2020 8:07 AM, Karl Tauber wrote:
> > > My company offers a commercial plugin (JFormDesigner) for NetBeans and
> > > for us it is no option to upload our commercial plugin to Maven
On 08.07.2020 22:21, Ernie Rael wrote:
On 7/8/2020 8:07 AM, Karl Tauber wrote:
My company offers a commercial plugin (JFormDesigner) for NetBeans and
for us it is no option to upload our commercial plugin to Maven Central.
Not sure whether this would be even legal. Isn't Maven Central for
open
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
e 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: Donners
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.
Cheers
Chris
Von: Jaroslav Tulach
Gesendet: Donnerstag, 9. Juli 2020 09:48
An: dev@netbeans.apache.org
Betreff: Re: Bypassing NetBeans Plugin Portal
Hello Karl
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
On 7/8/2020 6:48 PM, Tim Boudreau wrote:
Isn’t that security threat the reason JAR signing was invented?
I've heard that all, or almost all, plugin portal nbm's are self-signed.
How does that affect the security implications?
I've also heard that PP3 doesn't require jar signing; see
https://
Isn’t that security threat the reason JAR signing was invented?
-Tim
On Mon, Jul 6, 2020 at 1:12 PM 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
I just noticed that PP3 publishes the artifactId but not the groupId. Is
this intentionally missing?
-ernie
On 7/7/2020 2:36 AM, Jiří 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
developer
Hey,
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? And
just because it works/behaves at first doesn't mean there isn't
something dange
On 7/7/2020 9:25 PM, Jaroslav Tulach wrote:
Thanks Antonio.
Companies aren't going to upload modules with their update centers to
Apache NetBeans PP3, right?
This discussion isn't about removing some AutoUpdate APIs (e.g.
functionality), just about better verification of the modules that the
Ap
Hi,
> 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?
There should be at least one exception from this restriction for vendors
of commercial plugins.
Ah, good to see this isn't about removing autoupdate APIs. Sorry for the
misunderstanding.
AFAIK the only update center plugin in the NetBeans Portal is the jVI
update center.
I've been trusting this update center for several years now, and I'll
keep trusting it for the years to come (as lon
Thanks Antonio.
Companies aren't going to upload modules with their update centers to
Apache NetBeans PP3, right?
This discussion isn't about removing some AutoUpdate APIs (e.g.
functionality), just about better verification of the modules that the
Apache NetBeans project recommends the users to
Hi,
I don't see a security threat here if we warn the user about the
security implications of downloading stuff from a third party update center.
I can't remember if we are alerting the user properly, though. Maybe we
could improve the message.
Being able to add third-party plugin centers i
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 potentia
Hi,
I am just on the way learning to make a plugin available via maven central and
our official
update center step by step and I think it is a good compromise between security
and
practiability. And I like the idea that we have for all plugins the source code
repository
available. I do not
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.
-e
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 a
27 matches
Mail list logo