Subject: Re: bug#75581: 30.0.93; Crash when copy-sequence on clear-string'ed multibyte strings with text properties

From: Eli Zaretskii <[email-masked]>
Date: Thu, 16 Jan 2025 14:40:57 +0200

> Date: Thu, 16 Jan 2025 11:40:16 +0000
> From: Pip Cet <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked], [email-masked]
> 
> "Eli Zaretskii" <[email-masked]> writes:
> 
> >> The technical reason is that we simply cannot guarantee a string which
> >> is entered in the minibuffer or in a real buffer won't be visible
> >> somewhere: if it's in a buffer, it may be in the gap, and AFAIK there's
> >> no way to clear that
> >
> > compact_buffer does at least part of that job, AFAICT, if it shrinks
> > the gap.
> 
> I don't see how.  Worst case, it calls xrealloc which often leaves an
> extra copy in memory.

make_gap_smaller zeroes out the part the gap which is no longer the
gap.  The rest is moved to the end of the buffer, and then buffer text
is shrunk, which at least in some cases could unmap that part from the
Emacs process's address space.

> > And it should be easy to add a new function that clears the
> > gap completely, and expose it to Lisp or call it from clear-string.
> 
> It's easy to clear the current gap completely, but it's not what people
> want, which is to actually remove the sensitive data from memory.  That
> is much, much harder.

The data in the gap is part of the problem, no?  You said that, and I
agree.  So I'm saying that we can handle at least that part.  It might
not solve the problem completely, but it will make it smaller, no?

> >> it's in the undo history; it's in the M-x view-lossage output.
> >
> > We could handle that as well, by clearing the undo-list and
> > recent-keys.
> 
> So we're up to five necessary changes to do what the callers of this
> function apparently assume will be achieved by it:

Only if we want to.

> > Removing this function sounds too extreme to me, since we have that
> > for many years.
> 
> You're probably right, but it should be clearly documented to prevent
> only ordinary Lisp code from accessing the password, and not to do any
> of the five things above.
> 
> read-passwd, for example, definitely needs more warnings than it
> currently has: if I dump core after evaluating (clear-string (prog1
> (read-passwd "") (garbage-collect))), I see at least three copies of the
> password in the coredump.  (Possibly more that use fixnums).

Yes, documenting these caveats cannot do any harm.