5 ms·

https://web.archive.org/web/20190119162021/https://trac.videolan.org/vlc/ticket/21737 https://web.archive.org/web/20190119162021/https://trac.vide... The issue

by eps 8y ago

https://web.archive.org/web/20190119162021/https://trac.videolan.org/vlc/ticket/21737 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.

arkadiyt 8y ago
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 https://trac.videolan.org/vlc/ticket/21422
- NicoJuicy 8y ago
  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
  - johnbellone 8y ago
    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.
    - NicoJuicy 8y ago
      https://www.beauzee.fr/2017/07/04/videolan-and-https/ 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
  - arkadiyt 8y ago
    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.
    - vbezhenar 8y ago
      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.
- saurik 8y ago
  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 https://trac.videolan.org/vlc/ticket/11987
- jbk 8y ago
  Because the update is secured with GPG, not with the HTTP part.
Timshel 8y ago
"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. "
jbk 8y ago
> 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.
aries1980 8y ago
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.

by eps 8y ago

arkadiyt 8y ago

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 https://trac.videolan.org/vlc/ticket/21422

NicoJuicy 8y ago
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
- johnbellone 8y ago
  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.
  - NicoJuicy 8y ago
    https://www.beauzee.fr/2017/07/04/videolan-and-https/ 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
- arkadiyt 8y ago
  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.
  - vbezhenar 8y ago
    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.
saurik 8y ago
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 https://trac.videolan.org/vlc/ticket/11987
jbk 8y ago
Because the update is secured with GPG, not with the HTTP part.

Timshel 8y ago

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

jbk 8y ago

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

aries1980 8y ago

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.