Hacker News Reader

Comment by eps | Hacker News Reader

https://web.archive.org/web/20190119162021/https://trac.vide...

The issue appears to be that while VLC does in fact verify the authenticity of a downloaded update, it also allows it to be signed with a key that it doesn't yet know, in which case it will retrieve this key from the VLC servers _via HTTP_. If that's true, it is a perfectly valid issue that needs to be resolved.

However the tone of the original ticket is a nasty one, which seems to have resonated with the VLC dev in a wrong way.

View on HN

"Jean-Baptiste Kempf" the main contributor of the project later on said :

"Are you sure? For me it verify_signature() for the new key, based on the hardcoded public key."

And concerning the fact that the ticket is open for OsX : "As for OP, the updater on macOS uses Sparkle, and clearly not this update code. "

> The issue appears to be that while VLC does in fact verify the authenticity of a downloaded update, it also allows it to be signed with a key that it doesn't yet know, in which case it will retrieve this key from the VLC servers _via HTTP_. If that's true, it is a perfectly valid issue that needs to be resolved.

That is absolutely untrue. The commenter failed to read 10 lines under the verification of the new key against the old key.

Everything is checked against a public key that is inside the binary.

I reported the issue months ago [1], and I'm sure many have reported it before me. The devs have been ignoring the issue regardless of this particular author's tone.

[1]: https://trac.videolan.org/vlc/ticket/21422

The site is down. But a valid threat model was requested and not given by the original OP.

If there was a post with a valid threat model. That would be interesting, until otherwise, it remains closed

The threat was given by the comment, and a good community manager or developer would have acknowledged that and not have continued to act obstinate. They are actively ignoring it.

https://www.beauzee.fr/2017/07/04/videolan-and-https/

And you haven't read my comments here. Which said we don't know the whole story.

Read the above link and don't believe everything you read online. I have given the developers of VLC the benefit of doubt. Rightfully, so it seems

My ticket was closed without requesting a threat model. As a trivial example this is a privacy leak - anyone on the network path can see what version you're upgrading to. It doesn't sound like a huge deal but we are moving to a 100% encrypted world, and it is a one character change to fix the issue. If VLC wants to keep the update over plaintext then they should justify why they want to do that, not have users justify why it should be over https. Instead, it feels like the VLC devs are having a kneejerk defensive reaction.

You can check VLC website to know what’s the last version. It’s not a secret. While I don’t know the reason to prefer http over https, the only legitimate http threat is to serve non-latest version.

Your issue is long after they were having this as an annoying argument version of the report (and it is really difficult to isolate "well this one guy might have sounded sane"; at some point you burn out even thinking about the issue).

https://trac.videolan.org/vlc/ticket/11987

Because the update is secured with GPG, not with the HTTP part.

Let's assume that the upgrade can be safely downloaded. The potential attacker / authorities will still know that the device has VLC installed with which version.

Reply on news.ycombinator.com