incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject [DL] overarching issues was ....Re: [DL LOGIC] How to choose a mirror when more than 1 is available?
Date Sun, 15 Apr 2012 22:58:28 GMT
OK, I did a small amount of investigation so far.

I turn your attention to the following pages concerning product release 

1. (see 
specifically "Policy Overview" and "Mirroring".

2. In the Mirroring section, there is mention of a script to direct 
users to an appropriate URL for downloading. (Bear in mind that for the 
most part, these instructions pertain to a single instance of a product. 
We have MANY!)

3. More information on the "script" mentioned in the "Mirroring section 
can be found on:

The generic script called "closer.cgi" can be found in (if you have an 
Apache login: /www/

Using closer.cgi is pretty straightforward.  We would still use the JS 
logic our existing DL page and generate from the information gathered 
from the user agent, the correct DL string and pass it to closer.cgi. 
Ok, no problem.


4. closer.cgi in term runs a script called mirrors.cgi
Currently mirrors.cgi contains the following line:

MIRRORS_LIST = "***/mirrors.list"

(*s used to hide actual path name. Get a copy of closer.cgi to actually 
see this.)

Apache is already setup with over 250 mirrors by looking at this list.

5. FYI: How to setup your distribution using Apache mirrors is here:

==== SUMMARY ====
6. It is NOT clear to me at this point if we are allowed to use anything 
but Apache mirrors for the AOO 3.4 release. Can someone answer this?

7. I think given that we are relatively close to a release that we 
shouldn't mess with a specific customized DL page a la Apache specs and 
just use the "generic" script in our DL reference. This will be pretty 
easy I think.

8. If we DO want to add additional mirror sites -- SourceForge, 
MirrorBrain -- how do we do this? Change the mirror.list file, and 
referenced this changed file??? Or does this indeed make it a customized 
DL. Currently, SourceForge is not an official Apache mirror.

9. My feeling is that as a single project, we should NOT get directly 
involved in "choosing" mirrors as much as I found the previous 
discussions enlightening. Apache and MirrorBrain seem to have a pretty 
good handle on this.

In any case, we need to make a decision pretty quickly on this. We have 
work to do before 3.4 and we really should be testing now.

So, yes, I did some investigating, but, now I have more questions. And, 
since I've never directly been involved in the DL aspects of OpenOffice 
before, I'm probably not the best person to deal with some of this.

Sorry about the top-posting and the length of this.

On 04/14/2012 03:28 PM, Kay Schenk wrote:
> On 04/14/2012 10:59 AM, Dennis E. Hamilton wrote:
>> Kay, thanks for noticing the security issue around having a script
>> served from an insecure web page.
> concern didn't really stem from the security of the
> "site" but other issues...mostly I got to thinking about
> how we do things now -- manually changing download services vs maybe a
> more automatic way to deal with this. And, perhaps this would be a way
> for us to continue to include MirroBrain as well as SourceForge and the
> Apache mirrors in the download process with minimal effort.
>> That has me thinking about the security context for server-side
>> selection of mirrors (assuming that the server sends confirmed
>> redirects back to the requester),
>> I think the URL to request the download has to resolve to an
>> location where the mirror site selection and
>> forwarding/redirection then happens. (an location in
>> ASF custody would work as well).
> yes, this is a desired goal I think...
>> So now whatever the mirror-selection procedure is, it is on the
>> server and at least read-only (if not inaccessible completely). (The
>> link in the browser page can still be hacked, of course, so it would
>> be good to add some protection in depth at that point of weakness.)
> OK...more good points
>> In addition, the digest values used to confirm the authenticity and
>> integrity of downloads must not be on the mirror sites. They must be
>> in a secured, read-only place that exists entirely in ASF custody.
>> Because digests are not authentication codes (MACs) protected by
>> private keys, the only way they are trustworthy is if they are
>> protected separately and in a unique read-only place where injection
>> of forgeries is (1) extremely difficult and (2) readily detected and
>> repaired. To impede man-in-the-middle situations, this must also be
>> a site that requires TLS (i.e., SSL) access and might be in a very
>> small, narrowly-used subdomain that only that SSL certificate is
>> usable with.
>> Since it is not possible to prevent digests (MDF, SHA1, SHA256, and
>> whatever) from being copied to other sites and also forged there, the
>> only serious end-to-end protection between us as the producers of
>> consumer-software downloads and the individual who installs the
>> software is to also incorporate digital signatures into the downloads
>> themselves. Then facilities of the platform operating system could
>> be relied upon to provide confirmation of the authenticity and
>> integrity of the binary download. This practice is well-established
>> for Windows and our largest group of consumer-software users. I
>> don't know what the arrangements are with respect to other platforms
>> when the binary is downloaded directly by the user rather than
>> provided as a platform update.
> OK, much of what you're describing/explaining here is out of my purview
> I think. I will take a look at the scripting Joe pointed us to, and see
> what I can get from that. I can't make any huge promises at the moment,
> but I will report what I find.
>> (External signatures don't work for consumer software, although that
>> might be fine for our source-release tar balls. It is probably wise
>> to handle the external signatures the same way as the hash-function
>> digests, if not already handled in a secure way.)
>> [With a hat tip to Dan Boneh who covered Message Authentication Codes
>> and the use of digest algorithms with them in Week 3 of Stanford
>> University's on-line Cryptography
>> course,<>.]
>> - Dennis
>> -----Original Message----- From: Kay Schenk
>> [] Sent: Saturday, April 14, 2012 09:21
>> To: Subject: Re: [DL LOGIC] How to
>> choose a mirror when more than 1 is available?
>> On 04/07/2012 09:45 PM, Dennis E. Hamilton wrote:
>>> I agree that it is far more appealing to do this server side
>>> rather than have the client user agent have to fire up only to do
>>> a redirect.
>>> It also leaves open the prospect of handling the failure modes
>>> more effectively.
>>> Of course, that change can be done at any time, perhaps when there
>>> is no peak load on the horizon?
>>> - Dennis
>> I'll take a look at this when I get a moment this weekend. I
>> understand Dennis's concern about the scarey aspects of changing
>> mirror sites in the JS we currently use especially given the number
>> of committers we have now with access to the entire web tree.
>> I'm assuming if we did use server-side mirror selection logic, we
>> would just specify the Apache mirror for ooo ---
>> -- and let server side
>> logic figure it out from there.
>>> -----Original Message----- From: Dave Fisher
>>> [] Sent: Saturday, April 07, 2012
>>> 20:02 To: Subject: Re: [DL LOGIC] How
>>> to choose a mirror when more than 1 is available?
>>> Hi Joe,
>>> While everyone else might be ignoring the distinction between the
>>> Apache closer cgi/ezt and the current OOo javascript methods, I
>>> haven't missed the difference. One is server and the other client.
>> [ ... ] -- Robert Heinlein


"Women and cats will do as they please,
  and men and dogs should relax and get used to the idea."
                                     -- Robert Heinlein

View raw message