Notice that the same security concerns around authenticity and integrity of downloads applies to extension and template downloads as well.
There is currently no embedded signature mechanism for .oxt files, although there could be if .oxt were upgraded to use genuine ODF packages and ODF 1.2 digital signatures. (The current .oxt is a Zip package using a custom, pre-ODF profile.) This would also work for third-party contributors (and be much less expensive than requiring code-signing certificates), be platform-independent, and be extensible to bundling of any other Apache OpenOffice artifacts for which authentication is important. - Dennis -----Original Message----- From: Dennis E. Hamilton [mailto:[email protected]] Sent: Saturday, April 14, 2012 10:59 To: [email protected] Subject: RE: [DL LOGIC] How to choose a mirror when more than 1 is available? Kay, thanks for noticing the security issue around having a script served from an insecure web page. 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). 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.) 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. (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
