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

From: Stefan Kangas <[email-masked]>
Date: Wed, 15 Jan 2025 17:02:27 -0500

Pip Cet <[email-masked]> writes:

> Looks good to me.  However, on the scratch/no-purespace branch, we need
> to ensure that this function cannot be called on the empty multibyte
> string, turning it into a second empty unibyte string!  I'll push a fix
> to that branch in a bit.

Please do, thanks.

> However, if this function is meant to clear a string from memory
> to prevent leaving confidential data in memory, that won't work with
> MPS.  (I suppose it's reasonably clear that no protection whatsoever
> applies to string properties?)
>
> The problem is MPS allocates string data in a "copying" pool, so several
> copies of the string will usually be present.
>
> alloc.c string compaction may also result in recently-used short strings
> remaining in memory, IIUC, but only if an alloc.c GC cycle happens
> between string creation and the clear-string call.  (But if it does
> happen, it's very likely that a copy of the string is created!)
>
> How important is this feature?  What we have now is better that nothing,
> but if people start relying on it in any way, that's worse than nothing.
> A stern warning in the docstring may help reduce the problem.

I think a stern warning in the docstring makes sense.  This is
potentially security-critical, and we should better make sure that we
can make no guarantees here.

It would be nice if we could have a guaranteed secure way of allocating
and deallocating strings for passwords from ELisp.  Could something like
that be done?  I can think of several dumb and hacky ways to do it, but
none that are clean or smart.