[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Auto-update of native application bundles
From:       zonski () gmail ! com (Daniel Zwolenski)
Date:       2012-07-28 2:47:36
Message-ID: CANbPsPxP=BPoDSFfXNLFH7Oy5F_rQSbkv1dxhaSDkqC_S+kpTw () mail ! gmail ! com
[Download RAW message or body]

Hi Jose,

Regarding signing, I haven't looked too deep into the implementation but at
a high level I think the solution would be that Igor's tools sign your jars
as part of the initial install and then the public key is included in the
release. When the AU code downloads the new JARs it would check that the
new jars are signed with the same certificate.

The weakness in this whole approach is that you initially download an exe
or msi (or whatever for your platform). There's no check on the initial
signature of the install - you are trusting that you downloaded the app
from a friendly site (e.g. http://qantas.com). If that app decides it wants
to delete your hard drive well you shouldn't have downloaded from
dodgybrothers.com.au. What's the advantage really then of the AU code
checking the signature of the subsequently downloaded code, i.e. why should
it do more than the original install? And why should the AU code have this
'sandbox' restriction when there is no sandbox for the rest of the app -
i.e. you could easily open a socket, download some code and run it on the
local machine from within your Java app, essentially doing exactly what the
AU code was doing anyway.

Basically, in my mind we've said "Yes, I trust this application to do
whatever it likes" when we install an app. That's how native desktop apps
work. So why then popup a question later saying "Do you trust me to
download and run some code now?", when the app may have happily been doing
all sorts of things without asking up until this point.

I'm very open to input on this. This is probably a topic of more importance
to some people than others.

p.s. I do think signed jars make a lot more sense in an 'App store'
approach. In this case the App store needs to guarantee the developer is
who they say they are so they can then guarantee to the user that the app
has come from that developer.


On Thu, Jul 26, 2012 at 9:57 AM, Jose Martinez <jmartine_1026 at yahoo.com>wrote:

> 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
>

[prev in list] [next in list] [prev in thread] [next in thread]