You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2012/03/18 19:12:00 UTC
[UPDATE SERVICE] (was Re: proposal for temporary solution until AOO 3.4 is released.)
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.
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.
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.schenk@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 <
orwittmann@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.
>
--
----------------------------------------------------------------------------------------
MzK
"Follow your bliss."
-- attributed to Joseph Campbell
Re: [UPDATE SERVICE] (was Re: proposal for temporary solution until
AOO 3.4 is released.)
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi
On 19.03.2012 00:57, Rob Weir wrote:
> On Sun, Mar 18, 2012 at 2:12 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> There are several things that make me nervous about this idea.
>>
>
> <snip>
>
> Can someone say how long the current product update approach has been
> in use in OpenOffice.org and whether any of the things that make
> Dennis nervous have been an issue in this time?
>
> If the existing approach is known to have worked for several releases,
> without problems, then I propose we continue its use in AOO 3.4 but
> consider enhancements for 4.0.
>
I have an OOo 2.2 installed on my system and it already has the update service.
Rob, I am sure you know the date, when OOo 2.2 had been released - I do not have
the date at hand. It must be around 2003 or 2004.
Best regards, Oliver.
Re: [UPDATE SERVICE] (was Re: proposal for temporary solution until
AOO 3.4 is released.)
Posted by Rob Weir <ro...@apache.org>.
On Sun, Mar 18, 2012 at 2:12 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> There are several things that make me nervous about this idea.
>
<snip>
Can someone say how long the current product update approach has been
in use in OpenOffice.org and whether any of the things that make
Dennis nervous have been an issue in this time?
If the existing approach is known to have worked for several releases,
without problems, then I propose we continue its use in AOO 3.4 but
consider enhancements for 4.0.
-Rob
Re: [UPDATE SERVICE] (was Re: proposal for temporary solution until
AOO 3.4 is released.)
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
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.schenk@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<
> orwittmann@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.
>>
>
>
>
RE: [UPDATE SERVICE] (was Re: proposal for temporary solution until AOO 3.4 is released.)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Hi Kay,
The creation of a "nothing to see here, please move along case" for now is no particular problem.
That should be done. It will help get around problems of folks having to wait for time-outs before their copy of OpenOffice starts.
My main concern has to do with whatever is done when there are updates to report. Also, having an XML response is not necessarily the cleanest thing to do -- the browser can't be used to display anything intelligible to the user. That's why I think this needs to be thought through to ensure a solid use case with appropriate failure modes and minimum attack surface.
- Dennis
-----Original Message-----
From: Kay Schenk [mailto:kay.schenk@gmail.com]
Sent: Sunday, March 18, 2012 14:00
To: ooo-dev@incubator.apache.org; dennis.hamilton@acm.org
Subject: Re: [UPDATE SERVICE] (was Re: proposal for temporary solution until AOO 3.4 is released.)
On Sun, Mar 18, 2012 at 11:12 AM, Dennis E. Hamilton <
dennis.hamilton@acm.org> 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.
>
Dennis --
What Oliver is proposing here is basically an "I don't have any update for
you regardless of who you are" response. In other words, it's a null
response for everyone for the time being. It's not accurate, but, it
essentially does know harm for the time being, and will actually users who
have "automatic update" enabled, and who apparently wait for a bit for OOo
3.3....to do whatever it does at start-up for this.
However, your concern about "bogus" attempts that might result in DoS
attacks is worth considering especially since this "proxy" update service
would be set up on the main web server.
I will go ahead and change the
www.openoffice.org.ProductUpdateService/check.update
to the snippet Oliver has sent but won't send any messages to INFRA until
others weigh in.
>
> 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.
>
well...I can't address a lot of this comment since I don't know a lot about
how the update service is actually programmed, but I think this is what the
structure of the XML update is all about. It DOES rely on the browser but
only so far as it can determine, based on the feed structure, if an update
even exists for the requesting platform. As far as some of your other
concerns below, well....the update "URL" is just a jumping off point for
the actual updates. These updates are presumably under secure control of
AOO, so????
The redirect Oliver has proposed is only for the relay portion if you will.
It will have nothing in it -- no redirects to updates -- so current OOo 3.3
releases will simply go on their way.
I hope this helps.
>
> 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.schenk@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 <
> orwittmann@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.
> >
>
>
>
> --
>
> ----------------------------------------------------------------------------------------
> MzK
>
> "Follow your bliss."
> -- attributed to Joseph Campbell
>
>
--
----------------------------------------------------------------------------------------
MzK
"Follow your bliss."
-- attributed to Joseph Campbell
Re: [UPDATE SERVICE] (was Re: proposal for temporary solution until
AOO 3.4 is released.)
Posted by Kay Schenk <ka...@gmail.com>.
On Sun, Mar 18, 2012 at 11:12 AM, Dennis E. Hamilton <
dennis.hamilton@acm.org> 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.
>
Dennis --
What Oliver is proposing here is basically an "I don't have any update for
you regardless of who you are" response. In other words, it's a null
response for everyone for the time being. It's not accurate, but, it
essentially does know harm for the time being, and will actually users who
have "automatic update" enabled, and who apparently wait for a bit for OOo
3.3....to do whatever it does at start-up for this.
However, your concern about "bogus" attempts that might result in DoS
attacks is worth considering especially since this "proxy" update service
would be set up on the main web server.
I will go ahead and change the
www.openoffice.org.ProductUpdateService/check.update
to the snippet Oliver has sent but won't send any messages to INFRA until
others weigh in.
>
> 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.
>
well...I can't address a lot of this comment since I don't know a lot about
how the update service is actually programmed, but I think this is what the
structure of the XML update is all about. It DOES rely on the browser but
only so far as it can determine, based on the feed structure, if an update
even exists for the requesting platform. As far as some of your other
concerns below, well....the update "URL" is just a jumping off point for
the actual updates. These updates are presumably under secure control of
AOO, so????
The redirect Oliver has proposed is only for the relay portion if you will.
It will have nothing in it -- no redirects to updates -- so current OOo 3.3
releases will simply go on their way.
I hope this helps.
>
> 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.schenk@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 <
> orwittmann@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.
> >
>
>
>
> --
>
> ----------------------------------------------------------------------------------------
> MzK
>
> "Follow your bliss."
> -- attributed to Joseph Campbell
>
>
--
----------------------------------------------------------------------------------------
MzK
"Follow your bliss."
-- attributed to Joseph Campbell