On Thursday, November 24, 2011, Dennis E. Hamilton <orc...@apache.org> wrote: > Here are some proposal elements around the Attack Surface of Apache OpenOffice and keeping it small: > > P1. Extensions, supplements, and updates downloaded by the run-time installer or product shall only be retrieved from URLs under Apache control from sites operated by Apache infrastructure. As a secondary defense, authentication procedures will be used to confirm the provenance of such downloads. >
I think you're trying to control what isn't yours. For example it is perfectly reasonable for someone to install OpenOffice on an enterprise environment and administrivrly configure for extensions to come from an internal corporate server. In fact they may wish to disable all but such extensions. > P2. Registration, checking for notices/updates, and any other access to the web by the run-time should be opt-in and accomplished with the default browser on the platform rather than within the running code. Example 1: Check for Updates in the Help menu is a link and selecting it has the access performed by the default browser. Example 2: User opt-ins to use of on-line help. Help requests to the internet are by providing Apache-controlled URLs to the default browser. The URLs are only to Apache-hosted sites. > Again, we should not assume that we only have direct end users who only receive the bode directly from us. We need to support s dude range of policies.. General point: more groups than this PPMC set security policies for users. We need to support admins, CIO office types as well as end users. > P3. Feature proposals shall be accompanied by assessment of whether or not the attack surface of the product is expanded or not. In most cases, it will be easy to indicate that there is no concern. Operations that can give rise to silent access to networks or execution of code of unknown origin are automatically suspect. Operations that can do so while the installer or product is operated under elevated privilege are automatically considered serious. > Last I heard we were doing CTR. > P4. Existing features that cannot be assured to be outside the attack surface of the product will, when recognized/reported as such, be targeted for possible mitigation and other measures that shrink or eliminate the attack surface contribution. > > These are pro-active measures not related to discovery of defect-related vulnerabilities and existing exploits. > > I don't have a time-limit, or any default consensus, on this proposal. > Since you are not proposing to actually do anything yourself, there is nothing here to seek lazy consensus on. We should avoid having the project get tied down to a policy-crat morass and instead encourage a do- ocracy. > -----Original Message----- > From: Rob Weir [mailto:rabas...@gmail.com] > Sent: Thursday, November 24, 2011 09:40 > To: ooo-dev@incubator.apache.org > Subject: Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?) > > On Nov 24, 2011, at 12:17 PM, "Dennis E. Hamilton" <orc...@apache.org> wrote: > >> Three concerns, in addition to the ones Gianluca expressed already: >> >> 1. The extensions.services.openoffice.org site is not working reliably and is not operated by ASF. Any in-product access to the site has to work well and deal with unavailability. >> > > Do you have a proposal? > >> 2. I repeat my security concern over the increase of the product attack surface when such downloading and installation is done internal to operation of the product or its installer (which may already require elevated privileges) without coming up with stronger means for authenticating extension downloads. (The dictionary case is for data, so that is not quite so scary. Authentication still matters.) >> > > Do you have a proposal? > >> 3. Any automatic update mechanism is a further concern. >> > > Do you have a proposal? > >> A security review activity is apparently missing from the development and feature-decision process. That is not going to serve us well considering that this is a consumer product directed toward non-expert and household users. It must be assumed that our turn will come. >> > > Do you have a proposal? > > >> -----Original Message----- >> From: Andre Fischer [mailto:a...@a-w-f.de] >> Sent: Thursday, November 24, 2011 05:29 >> To: ooo-dev@incubator.apache.org >> Subject: Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?) >> >> Hi all, >> >> The last open item on the IP clearance wiki page is the removal of the >> dictionary module from the AOO source code. In order to provide a >> developer build in the near future that does not contain category-x >> licensed code we need a short term solution. >> >> The central question is if we have to really remove the dictionaries at >> all. I did not see a definitive answer, so to be on the safe side I >> assume that the dictionary module should be removed. >> >> This leaves the question of a replacement. One relatively straight >> forward way seems to be to use the extensions that can be found at >> http://extensions.services.openoffice.org/en/dictionaries. Two ways of >> using these extensions come to (my) mind: >> >> A. Download the extension (assuming that the right locale can be >> detected) automatically from the extension repository during installation. >> >> B. As last step of the installation, pop up a web page that, among other >> things, tells the user that there is a dictionary extension that can be >> installed and what its license is. >> >> Variant A has the better usability but may not be acceptable from a >> legal view. >> >> Variant B would allow to display additional information and could offer >> other (dictionary) extensions as well but would require more work to be >> implemented. >> >> One problem with both variants is that >> extensions.services.openoffice.org already seems to have load problems. >> When everybody who installs Apache OpenOffice has to access this >> server then its load would increase dramatically with a new release. >> >> >> Unless there are objections I will remove the dictionary module now, to >> clear the way for a category-x free developer build (or whatever its >> name should be). >> >> For the 3.4 release we have to decide on and implement a replacement. >> >> Best regards, >> Andre >> > >
