[JetSetWilly]

Every time an open source project is criticised, you get people saying "why are you criticising, you should do the work" - to the point that this seems to be a mechanism to shutdown any and all criticism of any open source project via special pleading.

One can be very grateful for the work done on an open source project, and recognise that I have no right whatsoever to expect them to hop to it, but I am always free to criticise their work whether it is free or not. Just because a project is open source doesn't mean nobody can utter a bad word about it.

[paulfr]

Thank you. To be clear, I don't mean that as a criticism of the developers, who as the parent points out do very useful work and do it for free. But I feel that it's important to have an objective look at the current shortcomings in the state of 7-zip security, both in order to understand what needs to be done to fix it, and in order to warn current users until those issues are fixed.

7-zip is a widely popular basic utility, like a web browser. A flaw in 7-zip is very serious, because as I pointed out elsewhere simply opening a .zip file will allow an attacker to exploit it. And while there is a strong security culture among web browser developers, 7-zip doesn't seem to have that culture (yet).

There is certainly a massive budget and manpower difference, but a lack of mention of security fixes in the changelog and a lack of hashes isn't a manpower issue, it's a culture issue.

As a side note, compromise of a developer's machine is a big deal in my opinion: it could be easy for a criminal entity to slip in a tiny change in a large patch that introduces a vulnerability; and depending on how builds are performed, a criminal could patch the final .exe with no visible change to the source code. These are tailored attacks, but for a very widely distributed program it would easily be worth the criminal's time.

[striking]

I'm glad you care so much, but I don't think you can fix a culture issue by explaining it away. The best way to set a culture where there hasn't been one before, is to lead by example.

Re: side note; the vulnerability described in the well-known Ken Thompson paper has been exploited just once in the wild. It's cool, but you could say the same thing about trusting Windows or proprietary drivers or hardware.

[nickpsecurity]

I counter the Thompson claim as vastly overstated risk when I see it here. I hadn't even heard that it was ever done before. Do you have a link or the project/time? I try to track these things.

[striking]

https://web.archive.org/web/20100305234633/http://www.h-onli...

Took some digging, but there it is.

[nickpsecurity]

Thanks for digging. I'll be damned! Somebody did pull it off. On my old, favorite platform as well!? So, one time on record.

Still supports my claim that reproducible builds and Thompson are mainstream buzzwords where our real concern per Orange Book days should be: coding defects in compiler source; effects of optimizations; malicious developers; trusted distribution of source; bootstrapping first, verified, local compiler. That's basically a human and machine verified compiler with simple code and signed zip's. Knocks out Thompson attack as side effect and negates reptoducible build need except for debugging.

[paulfr]

I'm not talking about a "trusting trust" attack, which is difficult to pull off and requires special compiler knowledge because it needs to survive bootstrapping.

Here the attacker just needs to patch a binary once and he already has complete control over the machine, so he has an infinite number of options: from simply manually replacing the binary file before it's uploaded to the website, to replacing gcc with a script that patches the source code before calling the original gcc.

[dave2000]

It's not shutting down the criticism. Someone will always say that ("you can fix it blah blah blah") but you can just ignore it. Just don't expect anyone to put in extra hours fixing it to avoid that criticism because people who do open source work for fun in their spare time, and people who give a shit what random people they don't know say about them online are two entirely separate groups.

[striking]

Anyone's within their right to criticize an open source project. I think being "appalled" is a tad illogical, though.

Similarly, does complaining about it on a public forum have any effect? In my book, code speaks louder than words; if you really want to see change, you know what to do.

[de47]

Being appalled seems right to me.

Under many circumstances, our actions come with a certain degree of responsibility. When we write code, we have the responsibility to be pretty open about security.

[nickpsecurity]

Where's the users' responsibility factor in to support the project financially or with code contributions? A gift given as is implies no responsibilities. A tool given for money should work as advertised. Yet, all this talk of responsibility appears on FOSS projects and is one way.

They have no responsibility to anyone. If you want responsibility, there's commercial offerings or you can sponsor 7-zip security for money.

[striking]

Our actions do come with a certain degree of responsibility. It is the user's responsibility, then, not to use software that is "without warranty" if they do not firmly trust it.

You can claim irresponsibility whenever you want, but it takes two to tango.