Checking for new version of a program

[Andrei Kulakov]

On Tue, 21 Aug 2001 18:13:14 +1000, Delaney, Timothy <tdelaney at avaya.com> wrote:
> [snip lots of stuff that I agree with]
> 
> IMO you should really only go to an update server when the user requests it.
> Have a prominent "Check updates" button ... Personally, I much prefer apps
> to simply bring up the "downloads" or "updates" web page in the default
> browser - then I can read the release notes (if any) and choose whether to
> apply the update.

Well, it's not a gui app so there's no buttons.. so it checks for a new
version and if one is found, it prints list of changes and then asks you
if you want to download it. So, that's pretty much what you want except
that you don't have to wait for the browser to start and close it
afterwards, and download/unzip the update. I think it's always good to
save time and effort :-).

> 
>> Code that does automatic updating is very tricky.  There are too
>> many potential security holes in it.  The only way I've seen
>> it done that seems safe is with some sort of crypto signatures,
>> but even that has its own problems.  (Eg, is the secret key on the
>> machine accessible to the world?)
> 
> This is one of the few relatively simple parts of an automated update
> process. Who cares if the downloaded update is intercepted and read? What
> you want to verify is that it is valid when received - i.e. sent from a
> valid source, not garbled and not tampered with. Signing is what is wanted
> in this case.

Umm, I believe what Andrew meant here is that signatures should be used to
check that the file is authentic, i.e. it's not trojaned. Obviously,
someone intercepting and reading that file is not a problem since it's a
public download, anyway :P

> 
> So, build a public key into the downloader application, and encrypt the
> content to download with the corresponding private key. Part of the content
> should include a checksum (if you're particularly paranoid, several
> checksums using different algorithms in different places in the stream). If
> the checksum(s) match the data, you can be pretty damn sure that you got
> what you requested, and that it came from a valid source.
> 
> For secure downloads, have the downloading application send the server a
> one-off public key with which to encrypt the data stream. Then decrypt with
> the server's public key (removing signing) and the one-off private key.
> Still not perfect, since at the very least you need to keep the data used to
> generate the one-off public and private keys in memory until the download is
> complete, but there aren't going to be very many people who (a) can get that
> data out of your machine and (b) have the algorithm to generate the public
> and private keys required...
> 
> I now expect some crypto experts to slap me with a big fish ...
> 
> Tim Delaney

Interesting.. I think maybe I should put a warning in the README that
enabling auto-update may be a security risk if my server is cracked, so if
the system has secrets on it, user must disable the feature. With
signatures, even, private signature also can be compromised.. but then
again, even if there is no auto-update, someone can just crack the server
and replace tarball with a trojan (and then post an update to freshmeat
for good measure!). 


-- 
Cymbaline: intelligent learning mp3 player - python, linux, console.
get it at: cy.silmarill.org