Auto-update of native application bundles

[Jose Martinez]

Dan,

After spending time thinking about jar signing (and more importantly finishing the book Ghost in The Wires) I think jar signing might be a good idea.  I have two questions on how that would work.

1)  Would it be the auto-updater framework that will do the sign-check on the downloaded jars before installing them?

2)  Can the certificate's subject and issuer be predefined into the framework before it is released into the wild?  This way only jars that I sign will be accepted.
 
thanks
jose


________________________________
 From: Rick Walker <thoughtslinger at gmail.com>
To: openjfx-dev at openjdk.java.net 
Sent: Tuesday, July 24, 2012 12:31 PM
Subject: Auto-update of native application bundles
 
Auto-Updater Feedback / Wishlist:

We are keenly interested in the auto-updater and we greatly appreciate the
efforts of all, especially Igor and Daniel. We anticipate posting app
updates on a tight cycle – a week or two will be routine. So a clean,
reliable auto-updater will make our users’ lives vastly simpler.

Our app will require the user to log in and authenticate before launching
the auto-updater. We would prefer to zip up our latest app jars and post to
a predetermined location on our server. If the JRE does not change with an
update, the updater should ignore it and retrieve only our app jars and/or
updated T&C (see below).

Regarding jar signing, we expect to retrieve our app jars from our server.
Even though we generally sign jars, we do not imagine performing a
jar-signing check with each auto-update.

We want to be able to tightly control auto-updates - we may ask users to
pay for some updates. We are concerned that, by placing our jars at a url
accessible to the auto-updater, we might also be inadvertently exposing
them to anyone who might point a browser at the same url. Adding some level
of indirection might help.

Regarding updates to Terms and Conditions or EULA, it would be a great
advantage to post an RTF (perhaps with a version number included in the
file name) alongside our updated app jars so that the updater could
determine whether the user ought to view and agree to the new T&C.

I believe we include an RTF on the installer side (with NSIS or Inno) so
it’s no extra work to also post it for the updater. We also routinely post
updated T&C on our website, so I suppose a simple alternative might be for
the auto-updater to simply point to that url.

>From our perspective, it seems there are three components in play for the
updater, each separately tracked for current version: the JRE, our app
jars, and the T&C.

Regarding user notification, we plan to use auto-updating to make sure that
all users are using the same version of our app – just as if we deployed as
an applet. User notification can therefore be bare bones – “a required
update is now available’.  A "what's changed" document isn't required in
our case.

The download display can be modal – there is no need for the download to
take place in the background.  An incremental progress indicator would be
nicer than an indeterminate display.

Graceful recovery in the event of a failure state (stalled download, file
i/o probs etc) is of course essential.

Cheers to all,
Rick