[vlc-devel] Future of the update mechanism

[Rémi Denis-Courmont]

Le jeudi 30 juillet 2009 18:16:45 Felix Paul Kühne, vous avez écrit :
> Am 30.07.2009 um 16:37 schrieb Rémi Denis-Courmont:
> > Le jeudi 30 juillet 2009 17:30:30 Georg Seifert, vous avez écrit :
> >> The check for new version is recommended to use a secure connection,
> >> but it works also over simple http.
> >
> > If it were as simple as removing security, Funman would not have
> > implemented
> > OpenPGP support in the first place. We must verify that the
> > downloaded update
> > is not corrupted, yet we should not depend on TLS for that.
> >
> > From what's been said, it would seem that Sparkle fails the "Windows"
> > requirement as well as the "security without TLS" requirement.
>
> Well, as hinted by Pierre previously, using the current approach for
> Windows or switching to a native windows-updating mechanism kind of
> makes sense. I don't really see why clearly platform-dependent code
> must be forced to be independent.

What is platform-dependent? Network access, cryptographic algorithms, 
filesystem access, and executing a program is portable across OSX and Windows 
with almost zero ifdefs...

However... the update code was one of the few (the only?) thing that OSX 
developers could be relied on for fixing and testing. Seriously, who is 
writing the Windows code? The Windows UI is written by Linux devs, especially 
J-B, by virtue of the Qt4 commonality. The core Windows support is -sort of- 
maintained by the WinCE guys and myself. The contrib, even though it's an 
OSX+Windows thing, is maintained by Linux developers too! And in fact, the 
update code was written by a Linux dev, and then rewritten by another one.

I have no rights to blame OSX volunteer developers for not caring about 
Windows., and so, I am not going to do it. But, if they cannot be bothered to 
support the update code, then I will stop maintaining the Windows core. 
Afterall I could not care less either.

> Regarding the SSL-dependency of Sparkle, it's a bit a 1.5 kB download
> per check we're discussing here. The actual update can be safely
> downloaded through untrusted channels, as it is checked against the
> signed hash. I seriously doubt that 1.5 kB downloads kill our server.
> Additionally, nothing speaks against updating the update mechanism a
> few hours or days after we hit the news pages once the peak traffic is
> over.

The number of public key cryptographic operation the server must do is 
proportional to the number of fetch and independent from the size of the 
payload. The encryption and decryption cost is proportional to the size of the 
payload... *but* there is no point in encryption here - we only care about 
integrity, not confidentiality! In other words, SSL is a waste, an overkill. 
And since we have to turn off the wiki and forums, I assume we are short on 
resources, so SSL is a no go.

Then again, if Sparkle supports offline DSA... no problem.

-- 
Rémi Denis-Courmont
http://www.remlab.net/