OK, I did a small amount of investigation so far.
I turn your attention to the following pages concerning product release
(DL):
1.
http://incubator.apache.org/guides/releasemanagement.html#apache-releases (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: http://www.apache.org/dev/release-download-pages.html
The generic script called "closer.cgi" can be found in (if you have an
Apache login: /www/www.apache.org/dyn/closer.cgi
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.
See:
http://www.apache.org/dev/release-download-pages.html#download-scripts
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:
http://www.apache.org/dev/mirror-step-by-step.html
==== 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.
Well...my concern didn't really stem from the security of the
openoffice.org "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
apache.org location where the mirror site selection and
forwarding/redirection then happens. (an openoffice.org 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,<https://www.coursera.org/#course/crypto>.]
- Dennis
-----Original Message----- From: Kay Schenk
[mailto:[email protected]] Sent: Saturday, April 14, 2012 09:21
To: [email protected] 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 ---
http://apache.tradebit.com/pub/incubator/ooo/ -- and let server side
logic figure it out from there.
-----Original Message----- From: Dave Fisher
[mailto:[email protected]] Sent: Saturday, April 07, 2012
20:02 To: [email protected] 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
--
------------------------------------------------------------------------
MzK
"Women and cats will do as they please,
and men and dogs should relax and get used to the idea."
-- Robert Heinlein
