Re: [PATCH] Add filename filters when saving attachments.

"Kevin J. McCarthy" <[email protected]> Mon, 11 May 2026 17:39:41 +0800

Newsgroups	gmane.mail.mutt.devel
Message-ID	<agGj3ap8WV-wgpMv@qinghai>

On Mon, May 11, 2026 at 07:03:51AM +0200, Rene Kita wrote:
>On Sat, May 09, 2026 at 06:59:22PM +0800, Kevin J. McCarthy wrote:
>> Right now, in receive mode, this filters "/" and unprintables into "_".
>> I could use a stricter sanitizer function, but I think that would be too
>> strict and irritate users.
>>
>> I could also simply filter only "/" -> "_", which might be all we need
>> to do.  Comments?
>
>Maybe I missed some previous discussion, but when saving an attachment
>we prompt the user for the name and display a suggestions, right?
>Besides unprintable characters, which can obviously not be shown in the
>prompt, why do we need to filter anything?

I'll fix up the commit message to make this clearer.  The discussion is 
really about having directory path elements appear in the suggested 
attachment filename.  This could lead to simple issues, such as the 
attachment not being where the user expected it (if they weren't paying 
attention), or perhaps naively thinking the "/" in the suggested name 
would be a part of the filename, or worst of all some kind of attack.

After Alex's feedback, I'm going to just do "/" filtering.  There isn't 
any sense in doing more unless there is an actual issue we're fixing.  I 
was just trying to see if I had missed an angle.

>> +static void safe_attachment_filename(BUFFER *safe_filename, const char *filename,
>> +                                     int sendmode)
>> +{
>> +  if (sendmode)
>> +    mutt_buffer_strcpy(safe_filename, mutt_basename(filename));
>> +  else
>
>I think having a flag on a function to let it do two things is really
>ugly. But if you think that this is the cleanest solution, go with it.

Yeah, the reality of attachment handling is that the fp is the only way 
to distinguish the modes.  No matter which way I handle it, that check 
needs to be made.  I thought this way was clearer than just passing the 
fp along too.

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA

signature.asc (application/pgp-signature, 833 B)