UAC complains VLC is unsigned.

Digital signatures are great - when properly managed but I think they also can give you a false sense of security.

Checking out some of the installers on my PC I note that very few don't have a digital signature: QuickPar, Iview, Stunnel to name a few, so it's obvious to me that digital signatures today seems almost mandatory. But. I'd trust an unsigned installer from a well known developer than a signed installer from a person or company I have never heard of etc, any day of the week.

 

A developer giving a hash value means nothing but to show that the hash provided matches the one the user gets when checking the file. It doesn't mean it's clean or anything like that. It just doesn't. Perfect match != safe.

Regarding the website getting hacked, and this isn't just about VLC, but generally speaking, if they replace the binaries (and the hash values), and if the original binary was digitally signed, either they got hold of a fake/stolen digital signature. (Which is why I mentioned already they work in theory. So, I'm not an apologist of digital signatures.) But, should CAs work properly and bad guys not being able to get a valid one, then digitally signing software would be the way to go, and is the way to go if they want their software also to be used in enterprise environments. I personally do not know any enterprise (from those I know, of course) that allows unsigned software to be installed/run.

Regarding open source, it has all to do with open source, code and compilation. If I (or a team) can study the code, and be sure all is OK, its recompiled. What better way to know something is safe, if not studying the source code?

I respect how you see things, but the same way certificates give a false sense of security, hashes also do.

 

So, you mean, things are exactly like with certificates?

 

I don't see why it would be any better? What guarantes me that the binary wasn't tampered with and the hash value replaced to match the one of the tampered file? I just don't have a way to know, do I?

This is why I don't just trust the certificate and/or the hash, on their own. Which is why I value certain services that allow us to monitor what the installer/program does.

I just don't feel safe either by knowing software is digitally signed or there's a hash value. They're just part of the equation, but not the result.

 

Pretty much. So, as for the OP, I certainly cannot see much of a reason why a non-profit open-source project should waste money on code-signing certificates.

 

Programs should be signed because certificates are really helpful for creating policies. That's it. Path/hash rules are ~Snip~ , but certificate rules are easily managed.

Ideally every legitimate program would go out and get signed.

 

Please elaborate what you mean by creating policies.

 

Hmm, yeah. The money is definitely worth the 0.000001% of users who run AppLocker with VLC and proper high-end Windows edition. Like, this ain't an app you'd see normally in any corporate environment.

 

One really simple example would be Applocker. With certificate rules you can allow VLC to execute, and then when it updates, it will still be allowed to execute, because even though the hash changed the certificate information hasn't.

With VLC unsigned you have to update your policy every time VLC updates, or, you have to use insecure path rules, which would allow any program with write access to the executable file to bypass the policy entirely.

 

Applocker is only one example.

There are applications for users as well. Besides, when you see the VLC executable you have no idea if it's really the right one. What if the site were hacked and it had started dropping maliicous exe's? Without a cert you'd have to rely on your AV.

But it's irrelevant. If all legitimate programs were signed there could be way more advanced policies that would significantly benefit the user.

They could just sign it themselves. You'd get a warning saying the certificate isn't valid, but it would still make policy generation way easier.

edit: A hash is not sufficient. Otherwise we'd still all be using hashes. If I hack their site and I can distribute malware I can sure as hell change one line of text on it. Certificates are way better for verifying a file is from a specific publisher.

 

Sounds reasonable.

Do you know any real life examples? What programs have write access to another executable?

 

Oh really? And how does the cert make it any different?

Oh really? And if you hack their site, you sure cannot upload your own signed EXEs? (As you say, they could just sign it themselves. So could you, none of the average "click yes" Joes out there would tell the difference.) Suggest you also see Google for the fraudulent certs issued for Microsoft, Google, Yahoo, Mozilla, Skype - greetings to Comodo, the Microsoft Terminal Services certs blunder, DigiNotar (official govt. sanctioned NL CA) or lately TURKTRUST SSL certificate fiasco. (BTW, how many of those TVL certs shipped by Comodo do you trust? )

 

Good point, agreed.

 

Do you know exactly what "certificate information" is used for that? A quick search turned up http://technet.microsoft.com/en-us/library/ee619725(v=ws.10).aspx#BKMK_WhatRruleConditions :

Not explicitly mentioned is the signer's public key. Making me wonder if someone could get past an existing AppLocker rule by signing with *different* cert/keys as long as those fields jive. The self-signed scenario being the riskier one.

 

You can always trust a certifying authority. Just like the ratings agencies in the run-up to the crash of 2008.</sarcasm>

 

Actually, we cannot trust them either. I mentioned that a couple times or so.

Bottom line is: We cannot trust the CA, we cannot trust the hash, we cannot trust the developer, we cannot trust the download source. You trust what the installer/executable does, and for that you need to study what it does.

I think I'm going to dedicate myself to cooking. It's a lot easier.

 

@Doktor

You get a cert verifying it's from them.

Probably not, no.

 

Who cares?! Seriously enjoy using your PC.

 

Oh really? You clearly have absolutely no clue what we are discussing here.

 

The purpose of a certificate is to bind an identity to an executable. That's literally what it's designed for.

Regardless, even if you were right (you aren't, the entire CA system is built for this purpose) that it doesn't provide an identity, signing legitimate executable files is best practice as, again, it makes policy generation much easier.

It may surprise you to know this but, oh my god, people watch videos on enterprise computers pretty often.

Plus, if all legitimate executable files were signed, or even just the vast majority, there could be way better security products for end-users.

By signing it themselves they use an uglier solution, but at least it's better than nothing, and entirely free. I think they could easily scrounge up the funds for a signature though that would last a few years.

 

Besides the fee required for obtaining a digital certificate from a CA, there are a few "hoops to jump through" involving the entire process...

The first two criteria are both reasonable and should be expected by anyone applying, but the last requirement would seem to present an obstacle for many. No wonder so many developers don't bother

Source

 

There's also the following for "individual" developers, mentioned in the same URL.

I believe the latter example would fit for VLC/others?

 

Thanks, I missed that of course. Although it seems to be an obstacle for most developers isn't it, since making a profit to at least supplement their living is fairly typical, I would think? The latter case looks to be for non-profit causes.

Sure, since VLC is free Open source.

 

For a small project with a single developer I'd get not using a cert. But VLC is a large project, and I feel that they could raise the funds for a 3 year certificate.

 

OMG. Whose identity are you "binding?" Of the unknown guy who "hacked" one of those CAs I mentioned above to issue certs for whatever he wants? Extremely useful.

Except that the signature does not ensure it's legitimate at all, not any better than the hash published somewhere. You are blindly trusting some CA, examples of their screwups being discussed regularly and some of the cases taking months or even years to get discovered.