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.

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.

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.

Took some digging, but there it is.

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.

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.

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.

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.

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

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

Rather than being seen as attacks on a project, these sorts of comments are often just highlighting some things that whoever is looking at that particular project might want to fix.

The "don't criticise unless you're prepared to fix it" attitude is very similar to the sort of "Don't bring me problems, just solutions" attitude that some managers have that results in a culture of people keeping quiet about stuff they've spotted but don't have either the time or ability to fix themselves.

Rather than leaving comments about how astounded we are, we should come up with a solution (which I'll note wasn't even mentioned in the parent post). Maybe a build step to autoregen the Downloads page? Maybe an email to the developers that will ask nicely for them to note which bug fixes are for security and which ones aren't?

Omission of facts is sometimes a defense mechanism for people who are embarrassed. The parent post could have only made the developer's insecurity about security greater. I understand that we have to make criticisms about open source software, but maintaining an open source project can sometimes be totally thankless work. We should try our best to Be Nice to people who work for free, because otherwise they won't want to work at all.

This is definitely a vector that attackers can and do use. If the developer is infected, particularly by a virus that changes the compiler to emit infected code, this can by proxy infect the products they develop.

See e.g.:

https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...