On 2026-05-11 17:39:41 +0800, Kevin J. McCarthy wrote: > 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.
Unprintable characters are already converted to '?' in the prompt, so that they will not appear in the filenames of saved attachments. Or can filenames with unprintable characters silently be created? In such a case, this could yield security issues, because some tools print such filenames directly to the terminal, thus potentially with harmful escape sequences. -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
