> always look over the source code for rogue functions
I don't really understand the reasoning behind that - so rather than trusting a proven OS and its packages with lots of eyes on the critical code, I should rather read the code of a cryptographic product and then make a decision based on that? Common advice is not to write crypto code yourself, but reading it and deciding that there might be a backdoor based on gut feeling is right? And having identified some stuff I don't understand, then decide for another program that is goofy but easier to read, and compromise security?
It's more about looking over the source code of the KeepassX app and just that (not all applications you use, of course we have to trust some of them), the code changes are (when there are changes) ~10 lines a month, not a huge amount to check.
What about all its dependencies? What if someone made some unsuspicious changes in a UI library that it uses that have a side effect on the security of KeepassX?
But that's the same argument that I was making about KeepassX itself before. So if I'm trusting for the dependencies to get watched well for not being compromised, why then look into KeepassX itself, wouldn't that apply for the app itself as well?
Because KeepassX is way less used (and its source code checked) than ... QT for example, so rogue functions added into KeepassX will be have less visibility than one added into zlib.
Ok, fair enough. Sorry, didn't mean to troll, was just curious. Still sounds like bad advice for the majority of users who can't really make that call, but for those who can it's consistent.
Don't worry about it :) Not all the steps are mandatory and not all are suited for the majority of Internet users. Everybody picks a base and starts from there.
When it comes to security, I usually worry about people creating complexity that scares people away, and therefore weaken the overall security of all. Over-complex and annoying password procedures are one everyday example that force many people to just go for some stupid password that follows the rules but is easy to crack.
So if there are rules to improve the privacy of users, I would worry about making it look to complex or extreme. I suspect rather than picking some parts that work for them they will go "ok this i can do, this I can do, and .. wait compile it myself and read the source?! - ok, I'll stick to post it notes".
I don't really understand the reasoning behind that - so rather than trusting a proven OS and its packages with lots of eyes on the critical code, I should rather read the code of a cryptographic product and then make a decision based on that? Common advice is not to write crypto code yourself, but reading it and deciding that there might be a backdoor based on gut feeling is right? And having identified some stuff I don't understand, then decide for another program that is goofy but easier to read, and compromise security?