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)); + elseI 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
Description: PGP signature
