Hacker News Reader

Comment by eponeponepon | Hacker News Reader

Yeah, this doesn't really hold water when your software is as widely installed as VLC - I've lost count of the number of deeply nontechnical people I've installed it for, for what that's worth. Checking file sizes is serious half-assing IMO - it's not beyond the wit of teenagers running a botnet to deal with that, never mind determined criminals.

View on HN

NASA could also be hacked by determined criminals, VLC hasn't got unlimited resources to spend. The HTTPS change could be easy, but you don't know what other things can be affected at first glance ( eg. update mechanism on older versions with no https support).

If the attackers can do a MITM, they probably also have other stuff at their disposal :)

But more important, issue the bug with a valid threat model and it could be fixed. As long as there is no threat model and perhaps an active discussion ( this is how open source works), the ticket stays closed.

The OP had 2,5 days to respond.

so suddenly the onus of developing the threat model is on the user?

I believe both devs and users should have the liberty to discuss and propose threat models, but if there already is "some level of precaution" the real question is where was the previous threat model that dictates signing? or is this security theater?

If the developers think there is no threat. Then yes, it is for the user to prove this.

you can't prove a threat model. a threat model is part of what is in or out of scope.

the first thing that should happen is for VLC dev to set up a threat model, if the user base disagrees with the narrow scope of the VLC threat model they should fork.

the second thing that can then happen is that given a threat model, a user could file a bug report to complain how a certain hypothetical attack (within scope of the threat model) violates the security.

think about it this way: for all non-security bugs, would you ask users to "prove that resolving a certain bug is within scope of the project"? how can a user prove what is within the developers' scope?

I think you are making a wrong analogy here. A "threat model" in security is like a "user operation" for the feature.

So in the non-security bug world, the exchange would look like:

Bug report: the program is missing blue circle in the top right corner. Please add is ASAP.

Developer response: what would possibly be the use of this feature? Please tell me of I will close the bug.

Here is a decent developer response: https://www.beauzee.fr/2017/07/04/videolan-and-https/

They don't cryptographically sign the updates as the op mentioned?

They do, with 1024bit DSA with SHA1. Cryptographically weak and forbidden by the NIST.

While yes, it is considered weak, that doesn't mean it is useless. Git uses Sha1 and a lot of other services do as well. Using it to validate and sign an update is probably still pretty much safe as I have only ever seen or heard of a single SHA1 collision ever. And that was in 2017. It took them 6500 years of CPU computation time and 110 years of GPU computation time to find it. I think we can consider SHA1 good enough to sign VLC updates for now.

https://security.googleblog.com/2017/02/announcing-first-sha...

Reply on news.ycombinator.com