4 ms·

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 install

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.

NicoJuicy 8y ago
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.
- DoctorOetker 8y ago
  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?
  - NicoJuicy 8y ago
    If the developers think there is no threat. Then yes, it is for the user to prove this.
    - DoctorOetker 8y ago
      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?
      - theamk 8y ago
        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.
        NicoJuicy 8y ago
        Here is a decent developer response: https://www.beauzee.fr/2017/07/04/videolan-and-https/ https://www.beauzee.fr/2017/07/04/videolan-and-https/
- lowry 8y ago
  > HTTPS change could be easy Yes, but it adds load on download servers and increases the cost of serving VLC to users.
jjeaff 8y ago
They don't cryptographically sign the updates as the op mentioned?
- dcbadacd 8y ago
  They do, with 1024bit DSA with SHA1. Cryptographically weak and forbidden by the NIST.
  - jjeaff 8y ago
    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-sha1-collision.html https://security.googleblog.com/2017/02/announcing-first-sha...

NicoJuicy 8y ago

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.

DoctorOetker 8y ago
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?
- NicoJuicy 8y ago
  If the developers think there is no threat. Then yes, it is for the user to prove this.
  - DoctorOetker 8y ago
    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?
    - theamk 8y ago
      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.
      - NicoJuicy 8y ago
        Here is a decent developer response: https://www.beauzee.fr/2017/07/04/videolan-and-https/ https://www.beauzee.fr/2017/07/04/videolan-and-https/
lowry 8y ago
> HTTPS change could be easy Yes, but it adds load on download servers and increases the cost of serving VLC to users.

jjeaff 8y ago

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

dcbadacd 8y ago
They do, with 1024bit DSA with SHA1. Cryptographically weak and forbidden by the NIST.
- jjeaff 8y ago
  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-sha1-collision.html https://security.googleblog.com/2017/02/announcing-first-sha...