incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: [www] Ext / Temp repository stability ( was Extensions and templates site down )
Date Sun, 14 Aug 2011 17:08:32 GMT
In a distributed system, you also need to deal with security issues and the safety of the download.
 

It might mean that the directory contains signatures or something that the downloading app
can use to validate what it gets from the download URL, especially if we are going to do silent
downloads and installs when the user says go get-em.

There is probably other attack surface to identify as well.

 - Dennis

-----Original Message-----
From: drew [mailto:drew@baseanswers.com] 
Sent: Sunday, August 14, 2011 09:16
To: ooo-dev@incubator.apache.org
Subject: Re: [www] Ext / Temp repository stability ( was Extensions and templates site down
)

On Sun, 2011-08-14 at 17:11 +0200, Eike Rathke wrote:
> Hi Rob,
> 
> On Sunday, 2011-08-14 10:17:28 -0400, Rob Weir wrote:
> 
> > IIRC, these extensions are 3rd party, under a variety of licenses,
> > including some that are not open source.  Is that correct?
> 
> Yes.

I for one agree with this expansive policy, but understand that personal
views of the members here are strong and across the spectrum. Indeed the
policy adopted for the TDF repository is a compromise to address the
question.

> 
> > Another option, which I brought up the last time this topic was
> > discussed on the list, is that we maintain a catalog of extensions,
> > but don't maintain the storage of the extensions themselves.  So a
> > distributed approach where we own the directory.
> 
> Currently OOo has the functionality to query whether an upgrade of the
> extension is available and to download and update if so. The directory
> then should implement that. Note that it is not necessary to have the
> directory provide the extension itself, this is already the case with
> the current extension repository that allows to host the extension at
> a different place. IIRC some metadata and an URL is sufficient,
> hopefully someone familiar with the mechanism can jump in on that. Maybe
> Juergen?
> 
> > >From the end-user perspective, they should not notice a big
> > difference.  They browse a list of extensions, click 'download' and
> > they get the extension.  But the extension would be served by an
> > external site, the responsibility of the extension author.
> > 
> > For this to work we'd need some way for extension authors to submit
> > their extension descriptions and metadata.  Maybe a simple XML format,
> > or a web form that generates that XML.  Then you need a program to gen
> > the website from the XML.  Xalan XSLT could be used for this, for
> > example.
> > 
> > What do you think of a distributed approach like this?

I have two quantitative questions which I would strongly wish to have
answered, if possible, before offering my opinion on long(ish) hosting
options.

1 - The percentage of inbound visitors coming from the application vs
from search engines.

2 - The percentage of artifacts that are stored directly on the OSUOSL
server vs a link to a remote site. I am working on the assumption that
this is a very high ratio, where a goodly number of these local files
are _likely_ stored only on this server. (not sure there would be anyway
to actually answer the last part of that sentence for sure..)


> 
> Fine. Isn't much different from the current situation. Best if technical
> details could be worked out such that no code apart from the actual
> repository/directory URL needed to be changed.

One other thought - I want to restate what I said earlier, regarding
what we can (could) do on a server inside the ASF physical custody vs
3rd party maintained servers - I believe I should of based the
distinction not on the location of the server, but rather the URL
(domain), so that it is significant the difference between
[x].openoffice.org and openoffice.apache.org/[x].

Thanks

//drew

> 
>   Eike
> 



Mime
View raw message