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.
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?
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?
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.
https://security.googleblog.com/2017/02/announcing-first-sha...
> This has a unfriendly tone of the OP.
Having lived on both sides of the pond, I'm aware of differences, but in which culture is that considered rude? You're addressing computer geeks, not the King of Thailand.
The thanks afterwards is meant for after they have done it and makes it worse.
What he actually says is: The bug is posted, I offered the solution. Fix it and I won't follow up on this.
Which would be something what a boss would say.
> The thanks afterwards is meant for after they have done it and makes it worse.
That used to trigger me in the past as well, but it is deeply ingrained in corporate communication (at least of West Coast USA). Just ignore it, you can't fight it.
> Which would be something what a boss would say.
I thought so in the past as well, but now everybody uses it.
Thanks for clarifying :)
https://www.cryptologie.net/article/466/developers-are-not-i...
1) PS ...{text} and would loathe the open source model for a second.
2) PS2. Some sign of respect to developers would be nice (y)
3) ...
But haven't found a good one. Your comment is better
:)
So the issue should still be closed according to the supplied information in the bug post submission.
End result for this issue is the same. Also, a comment is not the same as posting a bug.
In fact, if the HTTPS change is faster, this should be prioritized, given that the other issue might take a lot of time to fix: the old validation mechanism will have to be supported for a long time to keep older clients backwards compatible...
I'd take that the VLC guy had a bad day, otherwise that'd be a terrible reaction from someone involved in computer security.
We have no knowledge of "technical debt" or technical issues migrating from http to https. Videolan has 5 applications, perhaps all of them use the same update mechanism, which would broathen the scope of the fix.
What seems trivial (i agree), isn't always that in the software world. We need business knowledge of the VLC source or architecture for having a clear decision.
For what it's worth. I'll give the VLC developers the benefit of the doubt.
VideoLAN isn't in a position to enforce it's hosts to serve the files over TLS.
However the cryptography of the signature check will be updated in the future.
All the installs in a professional network where the use of a proxy changes the certificate would have trouble updating. So now it is changing changing http to https and be able to recover the company certificates in some way, in many different environments.
So yeah, the change is not trivial and will likely break the setup of millions of users. Downloading over http with a proper signature mechanism can be safe and is much easier for the users. If people have concerns over the way VLC is doing it, they are free to show how this can be broken and offer a fix.
Presumably those "professional networks" also use other software that already updates over HTTPS, this is not really VideoLAN's problem in 2019 when we are moving towards HTTPS everywhere.
I don't know who is right, but you claim the update needs to be signed, but eps says that it also allows the update to be signed by a key retrieved over insecure HTTP which of course can be MitM'ed. I guess the threat model includes malicious ISP's / governments, so as a user you want a clear delineation of responsibility, and have VLC either 1) use a backup master key to sign the signing key, so if the signing keys is compromised a new key can be issued from an airgapped system or 2) insist VLC retrieve the second key over HTTPS. I would prefer 1) though...
hm.. we have one of the software authors and a random by-stander arguing about the code? I know who I would bet on.
(Note that if it were a political question, then yes, opinions of any random bystander are potentially as valuable as software authors'. But it is not. I need to see a specific evidence before trusting random strangers)
They already cryptographically sign and validate the updates, which is why it is ignored. It's another solution for the same problem ( reducing change of a malicious update)
PS.
> This is a security risk and should be solved ASAP. Thanks
This has a unfriendly tone of the OP. I would have done the exact same thing in the same situation as the VLC developers ( since there is already a solution implemented).