Subject: 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 09:05:45 +0200

> Cc: [email-masked], Kanakana <[email-masked]>,
>  Andreas Schwab <[email-masked]>
> Date: Wed, 15 Jan 2025 23:02:32 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[email-masked]>
> 
> 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.  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 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.

> Physically, clearing memory only makes sense if
> it's an entire cache line: a partial cache line memset will leave the
> original copy in RAM while creating a write-back entry in the CPU cache:
> if that is what you're worried about, the naive approach will actually
> make things worse.

I think there are APIs to clear memory securely, no?  How do other
applications do this?

In any case, we don't say in our documentation that clear-string is
secure or even intended for secure clearing of string text, so I don't
think we give someone false security promises.

Removing this function sounds too extreme to me, since we have that
for many years.