[vlc-devel] 0.8.6d Release schedule
funman at videolan.org
Fri Nov 23 14:04:21 CET 2007
Le vendredi 23 novembre 2007 à 13:49 +0100, Remi Denis-Courmont a
> On Fri, 23 Nov 2007 12:51:01 +0100, Rafaël Carré <funman at videolan.org>
> > Do the files really have to be served through HTTPS ?
> No. What would need to be done is:
> 1/ authenticate the update informations, supposedly using public key
> cryptography, whereby the "VideoLAN release manager" gets the private
> and the public key is included in the player.
> 2/ provide file sums (e.g. SHA256) for the files to be downloaded, and
> check them after download, but before the update starts.
> Note that none of these require SSL. The infos could be signed just once
> every time they are updated, and served over any insecure channel.
I don't get it.
Are the checksums provided through TLS once the videolan.org server has
been authenticated (still with TLS) ?
What would be the extra weight of embedding cryptographic software in
VLC, and then just serve checksums and their signature over an insecure
channel, then the client do check the checksums' signature with the
embedded public key ?
My point is: TLS is used for transport, but I would prefer a solution
like the GPG-signing of debian APT repositories.
> Unfortunately, we haven't anything that looks remotely like it would be
> capable of doing this in the current code (would be tricky for 0.9.0, and
> pretty impossible for 0.8.6d).
> > I would think:
> > 1/ Authenticate videolan.org with HTTPS
> > 2/ Look for potential updates with HTTP
> > 3/ Download them with HTTP
> I don't understand.
There's nothing to understand I was just confused.
Rafaël Carré <funman at videolan.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
More information about the vlc-devel