cmake: mention 'insecure' in the debug build warning

[vszakats]

No description provided.

[jay]

What's your rationale for this? It is quite enough to say do not use in production. A debug build is not itself insecure.

[vszakats]

It depends on the debug build. If it means to contain debug symbols, asserts and -O0, it may still be secure, but this warning is for DEBUGBUILD builds which does more than that which also reduces security. This is OK, but felt it might need more emphasis.

[jay]

this warning is for DEBUGBUILD builds which does more than that which also reduces security.

DEBUGBUILD is what I'm talking about and I think the point is that it is not inherently insecure so we shouldn't represent it that way. There are environment variables like CURL_ENTROPY that can lessen the security and some sanity checks are skipped like enforcing https for DoH. But that is not insecure. I went through the code and the only possible insecure code I see is in curl_msh3 #16342

[vszakats]

I don't agree here. Overriding the random generator and disabling / overriding internals via envs doesn't seem secure to me. The feature is meant for internal testing (according to docs) where this is perfectly fine, but secure it isn't. The env list documented seems incomplete. It's not necessary just envs, but other behavior changes not documented, nor vetted from a security angle. Does the CVE program cover DEBUGBUILD builds?

For step-by-step debugging, getting stack dumps with symbols, DEBUGBUILD is not required. I suspect most users would expect these when enabling a "debug build" for a project. Perhaps the name DEBUGBUILD and ENABLE_DEBUG are wrong? Or perhaps I'm misundestanding something?

edit: Skipping HTTPS and DoH enforcement don't sound secure to me, though probably each should be double-checked case-by-case to know for sure.

[jay]

I think we understand each other fine we just disagree