Re: Importance of memory hygiene (was: What do LLMs mean for GnuPG?)

On 3/30/26 02:29, Robert J. Hansen wrote:
>> This is a red herring on all modern systems, given the overall 
>> architecture of this tool.
>
> Yes and no. The general rule is to take responsibility for zeroizing 
> sensitive memory. Defense in depth involves, you know, *depth*.
>
> I agree with your comments; I disagree with your conclusion.

In general, the general rule is correct and zeroing sensitive data upon 
expiry is a valid defense-in-depth practice.  :-)

But the edge case that Claude identified is not actually a problem:  if 
the program panics, it will shortly exit, at which time the kernel is 
responsible for destroying its entire virtual address space.

This actually leads to *another* possible problem that Claude seems to 
have missed:  what precautions are you taking to ensure that the 
generator state and/or generated passwords do not appear in a core dump?

>> Put simply, for a "one-shot" tool that uses only a short-lived 
>> process, there is no need to be concerned about this issue.
>
> Save that it's a remarkably good habit to get into. :)

I agree that it remains a good habit; in the DOS era, it was critical, 
lest your private key material eventually end up in the slack space in 
the last block of a file.

Modern systems are "a bit stricter" about such information leaks.  :-)

That said, the exception to the general rule is limited to exactly the 
type of tool you have written and a longer-lived process that only 
transiently needs sensitive information must take care to zero it, lest 
the sensitive information linger in swap or worse.

>> I do not have the citation close at hand but I remember seeing 
>> studies done that found that developers believed that using LLMs made 
>> them about 25% faster, but the actual data showed that LLM usage made 
>> them about 19% slower. (Numbers retrieved from personal human memory, 
>> may not be exactly accurate.)
>
> Was it the METR survey?
>
> https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

That appears to be it.

> [...]
>
>> This last point suggests to me that perhaps a strict prohibition on 
>> the use of LLMs to develop for GnuPG might be appropriate.
>
> I'm thinking it might be a good addition to the developer agreement, 
> yes. Concur.


-- Jacob


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