[Privoxy-devel] 0006-enable-lots-of-diagnostics

[Lee]

I apologize for how long it took me to respond.  The msg kept trying to turn itself into a rant about how hard it is to bootstrap oneself out of noob mode; hopefully I've edited out the worst of the rant-y bits.

On Thursday, August 17th, 2023 at 7:00 AM, Fabian Keil wrote:

> Your patch seems to contain a lot of flag explanations.

Right.  I can't remember them and it's annoying having to look them up whenever I'm wondering what they mean/do.  And looking them up in the man page doesn't necessarily _explain_ what they do, so the explanations are more my understanding of what the flags do and/or why they're there.

Along with the flags making _no_ sense; -Wall turns on all warnings .. except that it doesn't, so you need -Wextra; which, again, doesn't turn on all the other warnings, etc.  So all those explanations are mainly for me (and any other not fully clued in people).  The whole LDFLAGS="${LDFLAGS} -Wl,--nxcompat" section was written after I read a VLC bug report about how DEP was supposed to be enabled in the build but wasn't actually enabled in the executable.  Figuring out how to enable DEP and how to verify that it was actually enabled in the executable was a non-trivial task for me.  I'd rather not inflict that learning curve on anyone else that wants to understand those settings.

> Did you write them yourself or are they copied from another
> source in which case there may be license issues.

I mostly paraphrased the info.  And with the infamous "I Am Not A Lawyer" disclaimer, I expect that whatever copying/paraphrasing I've done is covered under fair use, so there shouldn't be any license issues.

> Maybe it
> would be safer to shorten or remove the descriptions and let
> readers who care look them up themselves in the compiler
> documentation.

The problem I had was that the compiler documentation all too often didn't tell me what the flags did.  I had to look on wikipedia and even the gcc mailing list to figure out what some of those flags did/meant.  Maybe the man pages are enough for you -- they seem to be written more as a memory aid for people who already know the info but can't remember specific details, but for me the man pages left much to be desired.  Hence all the comments.

> I think it's also worth mentioning that Privoxy security issues
> usually aren't caught by "compiler flags" anyway so I personally
> don't worry too much about them.

I got used to assembly language not checking hardly anything and having only hardware checks like address out of bounds for programs written in asm.  C seems to be more of a portable assembly language than anything else but I'm still not quite adjusted to it being that basic.

> BTW, the "HardenedBSD" folks also seem to spend a lot of time on
> "compiler flags" when the time (in my opinion) could be better
> spend on code audits and code reviews to avoid security issues
> like [0] and 1 etc.

I'd say that the knowledge level one needs to select compiler flags is _way_ less than the knowledge level one needs to do a decent code audit.  And a code audit applies only to the one bit of code being audited; selecting better compiler flags applies to all the software that is compiled with those flags.  So I can see why a group of unpaid volunteers would spend their time on "compiler flags" even if they don't catch all that much.  .. something, something about collecting low-hanging fruit.  Code audits are _hard_.

So it seems a lot easier to justify spending some time picking compiler flags than doing a code audit.  Which leads to things like cppCheck or .. who was it that offered to do free automated code audits on open-source code?  Automation doesn't depend on expensive, hard-to-find talents to do code audits - it just depends on expensive, hard-to-find talents to write the code :)

Regards
Lee