Podling Report Reminder - April 2017

[johndament]

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 19 April 2017, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, April 05).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://wiki.apache.org/incubator/April2017

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

Re: [mentors] updates.netbeans.org

[Simon IJskes]

My thoughts: I think you should strive for transfer of the domain to apache.

As oracle will continue to handle the updates of the non-apache 
versions, it will need to keep a webservice for providing these updates.


A webserver @ apache listening to updates.netbeans.org kan forward the 
requests to netbeans.oracle.com. Or the updates.netbeans.org domainname 
can point to a service within oracle infra. The responsibility to keep 
up this server/lookup can be agreed in the transfer contract.


This way the netbeans.org domain can be transfered to apache, and old 
installations in the field can keep receiving the updates.


For new (apache) installations in the field, they can query another url, 
for instance 'updates.netbeans.apache.org', but they can also query 
updates.netbeans.org with an other path, which can be used to 
distinguish between different forwards. It all depends on the updates 
service capabilities (thinking of CDN solutions).


Maybe serving non-apache data from an apache owned domain, needs to be 
checked by apache-legal.


Also apache-infra needs to know what kind of load to expect on 
updates.netbeans.org.


G. Simon


On 05-04-17 16:17, Geertjan Wielenga wrote:

Hi all, especially our mentors,

When we donate netbeans.org and related properties to Apache, there's one
area that's important to be aware of and hopefully find an answer to and
that is the following URL:

updates.netbeans.org

When everything becomes netbeans.apache.org, the above URL will need to
stay the way it is, it cannot become 'updates.netbeans.apache.org'.

The reason for that is that the above is hardcoded into NetBeans IDE. It
points to the official NetBeans update center, where plugins are found.

Although the URL is not hardcoded in the sense that it is in a Java source
file, it is in a Properties file and can be changed in the Plugin Manager
in NetBeans by any user. However, we don't believe the majority of people
will apply such an update to NetBeans, therefore if  the URL were to change
under Apache, the majority of NetBeans users will still have "
updates.netbeans.org" applied and will be not be able to receive updates.

For example, what can happen, once in a while, is that security updates
need to be applied to NetBeans, based on Oracle requirements and demands,
on previous versions of NetBeans, i.e., from before the donation to Apache.

Therefore, 'updates.netbeans.org' must stay 'updates.netbeans.org' and not
change to 'updates.netbeans.apache.org'.

Two possible solutions:

1. We donate all of netbeans.org to Apache, but Apache accepts that '
updates.netbeans.org' will not be changed to 'updated.netbeans.apache.org'.

2. We do not donate 'updates.netbeans.org' to Apache, i.e., we exclude it
from the donation.

Thoughts welcome.

Thanks,

Geertjan

Re: Securing the IDE: sandboxing plugins

[Emilian Bold]

But the OSGi security is never enforced, no?

--emi

Pe 5 apr. 2017, la 15:35, Jaroslav Tulach  a scris:

> Challenging task.
> 
>> On úterý 4. dubna 2017 18:29:09 CEST Emilian Bold wrote:
>> Hello,
>> 
>> One of the reasons I install only the essential plugins is the fact we have
>> no sandboxing.
>> 
>> No IDE has plugins sandboxing, but we can do better.
>> 
>> There is a wide array of plugins that need very little permissions (eg. the
>> highly rated "Toggle line wrap") and users would install them without
>> worries.
>> 
>> Having a sandbox would also make a plugin review simpler. The less and
>> lower impact permissions a plugin needs, the easier to review.
>> 
>> On most machines whatever overhead a security manager would have is
>> tolerable.
>> 
>> Module creators would have to add the global tag OpenIDE-Policy and define
>> a standard privacy policy file (which we could enhance with IDE-specific
>> permissions).
> 
> Possible. Compare your approach with OSGi security spec before you go on.
> 
>> Of course, we would need to display some nicer UI when installing in order
>> to explain the user what kind of permissions the plugin needs. Since the
>> permissions are checked at runtime we could also have (another) user dialog
>> then.
>> 
>> I will start looking at the existing code and see about a proof of concept.
> 
> Probably start somewhere around:
> https://github.com/emilianbold/netbeans-releases/blob/master/core.startup/src/
> org/netbeans/core/startup/ModuleSystem.java
> and related class loaders.
> 
> -jt
> 

Re: [mentors] updates.netbeans.org

[Neil C Smith]

On Wed, 5 Apr 2017, 15:17 Geertjan Wielenga, <
geertjan.wiele...@googlemail.com> wrote:

> When everything becomes netbeans.apache.org,
>

Out of interest, why would it? There are other Apache projects with their
own domains.

Best wishes,

Neil

> --
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

[mentors] updates.netbeans.org

[Geertjan Wielenga]

Hi all, especially our mentors,

When we donate netbeans.org and related properties to Apache, there's one
area that's important to be aware of and hopefully find an answer to and
that is the following URL:

updates.netbeans.org

When everything becomes netbeans.apache.org, the above URL will need to
stay the way it is, it cannot become 'updates.netbeans.apache.org'.

The reason for that is that the above is hardcoded into NetBeans IDE. It
points to the official NetBeans update center, where plugins are found.

Although the URL is not hardcoded in the sense that it is in a Java source
file, it is in a Properties file and can be changed in the Plugin Manager
in NetBeans by any user. However, we don't believe the majority of people
will apply such an update to NetBeans, therefore if  the URL were to change
under Apache, the majority of NetBeans users will still have "
updates.netbeans.org" applied and will be not be able to receive updates.

For example, what can happen, once in a while, is that security updates
need to be applied to NetBeans, based on Oracle requirements and demands,
on previous versions of NetBeans, i.e., from before the donation to Apache.

Therefore, 'updates.netbeans.org' must stay 'updates.netbeans.org' and not
change to 'updates.netbeans.apache.org'.

Two possible solutions:

1. We donate all of netbeans.org to Apache, but Apache accepts that '
updates.netbeans.org' will not be changed to 'updated.netbeans.apache.org'.

2. We do not donate 'updates.netbeans.org' to Apache, i.e., we exclude it
from the donation.

Thoughts welcome.

Thanks,

Geertjan

Re: Securing the IDE: sandboxing plugins

[Jaroslav Tulach]

Challenging task.

On úterý 4. dubna 2017 18:29:09 CEST Emilian Bold wrote:
> Hello,
> 
> One of the reasons I install only the essential plugins is the fact we have
> no sandboxing.
> 
> No IDE has plugins sandboxing, but we can do better.
> 
> There is a wide array of plugins that need very little permissions (eg. the
> highly rated "Toggle line wrap") and users would install them without
> worries.
> 
> Having a sandbox would also make a plugin review simpler. The less and
> lower impact permissions a plugin needs, the easier to review.
> 
> On most machines whatever overhead a security manager would have is
> tolerable.
> 
> Module creators would have to add the global tag OpenIDE-Policy and define
> a standard privacy policy file (which we could enhance with IDE-specific
> permissions).

Possible. Compare your approach with OSGi security spec before you go on.

> Of course, we would need to display some nicer UI when installing in order
> to explain the user what kind of permissions the plugin needs. Since the
> permissions are checked at runtime we could also have (another) user dialog
> then.
> 
> I will start looking at the existing code and see about a proof of concept.

Probably start somewhere around:
https://github.com/emilianbold/netbeans-releases/blob/master/core.startup/src/
org/netbeans/core/startup/ModuleSystem.java
and related class loaders.

-jt