Hi Dennis
On 18.03.2012 19:12, Dennis E. Hamilton wrote:
There are several things that make me nervous about this idea.
1. User Agent strings are not assured to be reliable. And the update site has
to be carefully protected against itself being attacked with bogus HTTP
requests.
Yes, web service must be secure.
I assume that the Apache server fullfill these needs.
2. Ideally, a build identifies a unique web location that is specific to that
build or build set (e.g., developer previews for a forthcoming release might
use a single one). My preference is for static pages, just to make life not
so complicated. My SERIOUS PREFERENCE is that an information-available not
be silent but be by launching the default browser if checks are enabled. The
AOO desktop software should, when checking is enabled or requested, do as
little as possible before relying on the browser. If there is a way to
differentiate "nothing-new" from "there is information" in HTTP response
headers, with the browser launched for "there is information", that would be
handy.
No browser is launched by the update service automatically.
The update service analyses the XML response and provides certain information to
the user inside the office.
If the analysis reveals that an update is available and an download website is
given, the user can hit a button to open with link in her/his browser.
If the analysis reveals that an update is available and an download link is
given, the user can trigger the download by hitting a button.
The user can specify, if the check for updates is performed automatically - see
Menu Tools - Options - Online Update. Here the user can also decide the download
the update automatically.
Best regards, Oliver.
3. What's nice about (2) is that when a replacement/update is installed, so
is the URL to use to check for further updates/announcements.
4. The web site can be updated to reflect changes over time without much fuss
beyond reasonable care.
5. There does need to be information from the user agent built into AOO with
regard to current language settings. The response mechanism should allow for
text information as well as instructions on what to do to get an update.
(Using the default browser presumably deals with this case.)
6. There needs to be a way to disable automatic checking for updates and
allowing explicit check for updates from the Help and/or About information.
(That may be true already, I am reciting from principle here.) The setting
of this might be part of a first-run dialog when there is no user
configuration that specifies a preference.
BIGGER WORRIES
This increases the threat surface against an user's installed copy of AOO.
It also creates problems that repackagings and derivative builds are at risk
of not updating this information reliably or simply passing off the update
responsibility to Apache OpenOffice. A bigger concern is creation of a bogus
update location in a derivative that is designed for malicious purposes.
The threat surface carries increased possibility of phishing the user as well
as downloading malware, especially if the user is operating their AOO (or
look-alike) at too-high levels of privilege. Also, auto-checking on startup
has unwelcome performance problems when the network is unavailable or very
slow.
It is not clear to me what can be done to make this a trustworthy arrangement
and also secure confidence of users that they are in control and nothing
fishy will happen.
So far, my role model for this (apart from Microsoft Update, which is
probably an unreachable level for us and probably undesirable as well) is
what TortoiseSVN does in letting me know there is an update and where to go
to find out about it. It is especially important that an open-source product
have some simple but reliable way of keeping the user in control and without
adding to attack surface and concerns about anonymous risk. (In that
respect, Skype, Second Life, Java, and Adobe updaters are too inflexible and
also intrusive. I notice that family members I observe always cancel those
pop-up notices and go about their business.) I assume that Linux distros
that bundle an AOO build will also have their own way of vetting and offering
updates, but installs of AOO-built binary releases will bypass that.
Unfortunately, I don't have a better picture of a clean way to mitigate the
risks associated with automatic, on-line update checking.
Let's talk about what can be done.
- Dennis
-----Original Message----- From: Kay Schenk [mailto:kay.sch...@gmail.com]
Sent: Sunday, March 18, 2012 10:10 To: ooo-dev@incubator.apache.org Subject:
Re: update service - proposal for temporary solution until AOO 3.4 is
released.
On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann<
orwittm...@googlemail.com> wrote:
Hi,
On 15.03.2012 12:47, Oliver-Rainer Wittmann wrote:
Hi,
I have continued the work started by Regina, Ariel and Kay regarding the
update service. I have documented my findings at [1].
I think we have everything together to bring a corresponding web service
back to life.
I think we have at least two options for such a web service.
If we want to create a 'real' web service which on demand creates an
appropriate response the HTTP GET request contains all needed information
in its header fields "User-Agent" and "Accept-Language" to implement such
a web service. The "User-Agent" field contains the operating system, the
machine architecture and the bundled languages of the installed office.
If a corresponding installation package of newer version is available a
corresponding response can be generated.
Another solution could be to provide a static XML document, based on an
atom feed, which contains as much entries as installation packages for
the latest version are available. For each installation package which
defines itself by the operating system, the machine architecture and the
bundled languages an entry is needed. Such entries need to be duplicated
for every existing office installation with different<UpdateID> in its
version.ini.
Any thoughts, comments, corrections, ...?
BTW, the update service of a certain installed office can be tested
locally. No HTTP GET request is involved in this case, but you can test
with certain XML documents provided as responses. You can change the
value of<UpdateURL> in file <version.ini> of your office installation to
a local file URL - e.g. under Windows to something like
file:///C:/check.update.xml
[1] http://wiki.services.**openoffice.org/wiki/Update_**
Notification_Protocol#A_**glance_on_the_code_for_the_**
Apache_OpenOffice_3.4_release<http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release>
The<UpdateURL> in the installed OOo 3.3 instances is
http://update36.services.**openoffice.org/**ProductUpdateService/check.**
Update<http://update36.services.openoffice.org/ProductUpdateService/check.Update>
.
This is no longer available. This also annoys our users I think.
If we can redirect this URL and the redirection would provide the following
XML document the corresponding update service in these offices will reply
"<your office> is up to date" The XML document which needs to be provided
only has to contain this XML snippet: <?xml version="1.0"
encoding="UTF-8"?> <inst:description
xmlns:inst="http://**installation.openoffice.org/**
description<http://installation.openoffice.org/description>">
</inst:description>
Can someone implement the redirect? May be
http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update>can
be used as the redirect. Here, I think it was Kay, already an XML document
exists which only needs to be updated.
Note: I have also an OOo 3.1 installed. Here the<UpdateURL> is
http://update32.services.**openoffice.org/**ProductUpdateService/check.**
Update<http://update32.services.openoffice.org/ProductUpdateService/check.Update>
.
May be we should redirect all URL matching http://update3[0..6].services.*
*openoffice.org/**ProductUpdateService/check.**Update<http://services.openoffice.org/ProductUpdateService/check.Update>
Oliver--
Hi -- I missed this post until just now.
I can put this code snippet in in
http://www.openoffice.org/ProductUpdateService/check.Update as you suggest.
...and send a note to INFRA regarding the DNS changes
However, I'm a bit concerned with telling users (and perhaps folks using a
very old version) that their version is "up to date" when it isn't. Is this
all we can do about this right now?
Best regards, Oliver.
