Re: [PATCH 1/3] tests: Cast to void to suppress warnings about unused variables

On 1/31/26 13:21, Collin Funk via Gnupg-devel wrote:
> Jeffrey Walton via Gnupg-devel <[email protected]> writes:
>
>> On Sat, Jan 31, 2026 at 8:36 AM Werner Koch via Gnupg-devel <
>> [email protected]> wrote:
>>> On Sat, 31 Jan 2026 01:26, Rudi Heitbaum said:
>>>> Address compiler warning when variable is unused because it’s used
>>>> only in assert.
>>> Anyone who defines NDEBUG does not known what s/he does.  An assert is
>>> there for a reason.  It is plain stupid to use an assert but disable it
>>> for production.
>> Asserts are a debugging and diagnostic tool.  Confer, <
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/assert.html>.
>> Asserts should not be enabled in production software.
> I generally agree, but there is some benefit to having a program crash
> instead of continuing in an undefined state.

There is also the small matter that we are talking about assertions in a 
testsuite, not the main program that will actually be installed.  These 
programs help to validate that the main program was probably actually 
compiled correctly.

Maybe adding "#undef NDEBUG" to each C source file in the testsuite 
would be a more appropriate solution to these warnings?

>> If an assert triggers, it usually causes a program to crash.  Sensitive
>> data can leave the app's security boundary and be egressed through the
>> crash dump or report.  Companies like Apple, Canonical, Google and
>> Microsoft could have access to the sensitive data.
>>
>> I've even seen asserts used in BitCoin wallets, and the crash reports
>> uploaded to Microsoft App Center Diagnostics.  The private keys for the
>> wallets were burned!
>>
>> I've never seen a project document that private keys and shared secrets
>> should be rotated after a program crashes due to an assert.
> Yeah, that is bad.

GPG also has its own assertion infrastructure for checks that remain 
effective in production builds, and presumably kills the process in a 
controlled manner that avoids potentially including sensitive 
information in a crash dump.

Remember that GPG has a "secmem" facility for storing sensitive data.  I 
would be surprised to see a similar feature in a typical BitCoin wallet, 
just as I would be very surprised if Werner Koch had not considered and 
addressed this risk in GPG years ago.


-- Jacob



_______________________________________________
Gnupg-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-devel