Saving attachments with a leading dot

Saving attachments with a leading dot

[Jesper Harder]

RFC 2183 says:

,----
|    Since this memo provides a way for the sender to suggest a filename,
|    a receiving MUA must take care that the sender's suggested filename
|    does not represent a hazard. Using UNIX as an example, some hazards
|    would be:
| 
|    +    Creating startup files (e.g., ".login").
| 
|    +    Creating or overwriting system files (e.g., "/etc/passwd").
| 
|    +    Overwriting any existing file.
| 
|    +    Placing executable files into any command search path
|         (e.g., "~/bin/more").
| 
|    +    Sending the file to a pipe (e.g., "| sh").
| 
|    In general, the receiving MUA should not name or place the file such
|    that it will get interpreted or executed without the user explicitly
|    initiating the action.
| 
|    It is very important to note that this is not an exhaustive list; it
|    is intended as a small set of examples only.  Implementors must be
|    alert to the potential hazards on their target systems.
`----

Gnus doesn't prevent creating startup files.  We could:

· Strip leading dots from file names, or

· Set the default value of `mm-default-directory' to somewhere
  (where?), so attachments aren't saved in ~.

WDYT?

Any other nasty file names we should watch out for?

Re: Saving attachments with a leading dot

[Ted Zlatanov]

On Wed, 24 Sep 2003, harder@myrealbox.com wrote:

> RFC 2183 says:
> 
> ,----
>|    Since this memo provides a way for the sender to suggest a
>|    filename, a receiving MUA must take care that the sender's
>|    suggested filename does not represent a hazard. Using UNIX as an
>|    example, some hazards would be:
>| 
>|    +    Creating startup files (e.g., ".login").

That's dangerous iff the startup file doesn't exist already, IMO.
Otherwise it's simply a special case of the third item.

>|    +    Creating or overwriting system files (e.g., "/etc/passwd").

It's impossible to catch all the system file names.  I would only
worry about it if it's a subcase of the third item.

>|    +    Overwriting any existing file.

I think with a warning, this should be allowed.  It's a very
legitimate use of attachments.

>|    +    Placing executable files into any command search path
>|         (e.g., "~/bin/more").

I think we should simply never set the executable bit on any saved
attachment, that's all.  It's a good practice generally, since a lot
of users have '.' in their path.

>|    +    Sending the file to a pipe (e.g., "| sh").

I don't think Gnus should ever allow pipes.  The file name should be
saved as is, and if the user specified a special character in the
name, then so be it.

>|    In general, the receiving MUA should not name or place the file
>|    such that it will get interpreted or executed without the user
>|    explicitly initiating the action.
>| 
>|    It is very important to note that this is not an exhaustive
>|    list; it is intended as a small set of examples only.
>|    Implementors must be alert to the potential hazards on their
>|    target systems.
> `----
> 
> Gnus doesn't prevent creating startup files.  We could:
> 
> · Strip leading dots from file names, or

Why?  This is a legitimate use.  I would warn the user instead, with
an offer to remove the dot.  Ditto for existing files.

> · Set the default value of `mm-default-directory' to somewhere
>   (where?), so attachments aren't saved in ~.

I like that default a lot, and it makes sense for most users.

> Any other nasty file names we should watch out for?

'-' and variations thereof is the most annoying one...  Most users
don't know about "rm --" and can get caught - not to mention that most
Unix utilities don't deal with file names beginning with '-'
gracefully.  Maybe we should also warn about the shell special
characters.

Ted

Re: Saving attachments with a leading dot

[Benjamin Riefenstahl]

Hi Jesper,


Jesper Harder <harder@myrealbox.com> writes:
> Any other nasty file names we should watch out for?

Control characters in names.  Especially \n could possibly be used for
exploits.


benny

Re: Saving attachments with a leading dot

[Ted Zlatanov]

On Wed, 24 Sep 2003, Benjamin.Riefenstahl@epost.de wrote:

> Jesper Harder <harder@myrealbox.com> writes:
>> Any other nasty file names we should watch out for?
> 
> Control characters in names.  Especially \n could possibly be used
> for exploits.

Could that occur naturally in UTF-8 filenames?  Does Gnus support
those?  I have no idea if MIME supports them to begin with.

Ted

Re: Saving attachments with a leading dot

[Benjamin Riefenstahl]

Hi Ted,


> On Wed, 24 Sep 2003, Benjamin.Riefenstahl@epost.de wrote:
>> Control characters in names.  Especially \n could possibly be used
>> for exploits.

Ted Zlatanov <tzz@lifelogs.com> writes:
> Could that occur naturally in UTF-8 filenames?

No, control characters are an ASCII feature, UTF-8 doesn't create
them.  But a malicious mail sender can easily create them.

> Does Gnus support those?  I have no idea if MIME supports them to
> begin with.

I'd have to check the standards for myself for the official rules.
But a test mail to find out how the transfer encoding for filenames
can look like and a quick modification of that mail shows that this
does what I meant:

>>>>>>
Subject: test nl in attachment
From: Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de>
Message-ID: <test#nl@seneca.benny.turtle-trading.net>
MIME-Version: 1.0
Content-Type: application/octet-stream
Content-Disposition: attachment; filename*=iso-8859-1''%0arm%20somefile
Lines: 2

Any content

<<<<<<<

This results in the filename "\nrm somefile" (in C literal syntax).
This could have bad effects, if the file is saved with that name and
later used with some shell script.  That script might even just be
your nightly backup.


benny

Re: Saving attachments with a leading dot

[Reiner Steib]

On Wed, Sep 24 2003, Jesper Harder wrote:

> RFC 2183 says:

> |    +    Sending the file to a pipe (e.g., "| sh").

Emacs happily created »| xless« when trying to save such an
attachment.  The content isn't sent to a pipe.

[...]
> Gnus doesn't prevent creating startup files.  We could:
>
> · Strip leading dots from file names, or
>
> · Set the default value of `mm-default-directory' to somewhere
>   (where?), so attachments aren't saved in ~.

If we take a different directory, we need to make sure it exists and
create it otherwise.  (Personally, I don't like programs that clutter
up my ~/ with new directories.)  Using `message-directory' (default:
"~/Mail/") could cause problems; at least if the file looks similar to
an mbox file: `nnfolder-directory' defaults to `message-directory'
therefore `nnfolder-generate-active-file' would create bogus groups.
Subdirs under ~/Mail could conflict e.g. with nnml, I guess.

How about only changing the default of
`mm-file-name-rewrite-functions' from `nil' to, say
`mm-file-name-rfc-2183'?  `mm-file-name-rfc-2183' could do the
replacements (or offer them?).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Saving attachments with a leading dot

[Ted Zlatanov]

On Wed, 24 Sep 2003, Benjamin.Riefenstahl@epost.de wrote:

> I'd have to check the standards for myself for the official rules.
> But a test mail to find out how the transfer encoding for filenames
> can look like and a quick modification of that mail shows that this
> does what I meant:
> 
>>>>>>>
> Subject: test nl in attachment From: Benjamin Riefenstahl
> <Benjamin.Riefenstahl@epost.de> Message-ID:
> <test#nl@seneca.benny.turtle-trading.net> MIME-Version: 1.0
> Content-Type: application/octet-stream Content-Disposition:
> attachment; filename*=iso-8859-1''%0arm%20somefile Lines: 2
> 
> Any content
> 
> <<<<<<<
> 
> This results in the filename "\nrm somefile" (in C literal syntax).
> This could have bad effects, if the file is saved with that name and
> later used with some shell script.  That script might even just be
> your nightly backup.

I'd say Gnus should warn the user and offer an alternative, but allow
saving this file since there are legitimate cases where it can be
useful.

Ted

Re: Saving attachments with a leading dot

[Benjamin Riefenstahl]

Hi Reiner,

> On Wed, Sep 24 2003, Jesper Harder wrote:
>> RFC 2183 says:
>
>> |    +    Sending the file to a pipe (e.g., "| sh").

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
> Emacs happily created »| xless« when trying to save such an
> attachment.  The content isn't sent to a pipe.

Of course.  But what will your typical home-grown, sh-based nightly
backup script do with that filename, once the file is created?  If you
are not *very* sure without needing to verify, you have already lost,
I think.

benny

Re: Saving attachments with a leading dot

[Benjamin Riefenstahl]

Hi Ted,

> On Wed, 24 Sep 2003, Benjamin.Riefenstahl@epost.de wrote:
>> This results in the filename "\nrm somefile" (in C literal syntax).

Ted Zlatanov <tzz@lifelogs.com> writes:
> I'd say Gnus should warn the user and offer an alternative, but
> allow saving this file since there are legitimate cases where it can
> be useful.

Can you name a legitimate case?  Just curious here, because I can't.

benny

Re: Saving attachments with a leading dot

[Ted Zlatanov]

On Wed, 24 Sep 2003, Benjamin.Riefenstahl@epost.de wrote:

> Can you name a legitimate case?  Just curious here, because I can't.

Maybe the user wants a \n in the file name?  I know it's unusual, but
it's certainly a legitimate need.  Gnus shouldn't forbid it, only
advise against it.

Ted

Re: Saving attachments with a leading dot

[Jesper Harder]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> How about only changing the default of
> `mm-file-name-rewrite-functions' from `nil' to, say
> `mm-file-name-rfc-2183'?

We might as well split the different replacements up a little to make
it a bit easier to disable the ones you don't like.

What about adding these two to `mm-file-name-rewrite-functions' by
default:

(defun mm-file-name-delete-control (file-name)
  "Delete control characters from FILE-NAME."
  (gnus-replace-in-string file-name "[\x00-\x1f\x7f]" ""))

(defun mm-file-name-delete-gotchas (file-name)
  "Delete shell gotchas from FILE-NAME."
  (setq file-name (gnus-replace-in-string file-name "[<>|]" ""))
  (gnus-replace-in-string file-name "^[.-]*" ""))

Re: Saving attachments with a leading dot

[Jesper Harder]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 24 Sep 2003, harder@myrealbox.com wrote:

>>| * Creating or overwriting system files (e.g., "/etc/passwd").
>
> It's impossible to catch all the system file names.

Gnus strips any directory part of the file name, so I don't think
this is even possible.

>>| * Placing executable files into any command search path
>>|   (e.g., "~/bin/more").
>
> I think we should simply never set the executable bit on any saved
> attachment, that's all.

Should we set the file mode explicitly?  (We already do this for some
other Gnus generated files) What would the apropriate permissions be?

>>| * Sending the file to a pipe (e.g., "| sh").
>
> I don't think Gnus should ever allow pipes.  The file name should be
> saved as is, and if the user specified a special character in the
> name, then so be it.

Well, the _user_ didn't specify it, the sender did.  I think it's
important to remember that the "filename" parameter is nothing but a
suggestion that may form a basis for the actual filename.

The receiving MUA isn't expected to just use the suggestion as is.  In
other words, the parameter is *not* intended as a mechanism to ensure
that the attachment is saved under any specific file name.

>> · Strip leading dots from file names, or
>
> Why?  

Security.  Unsuspecting users might not be aware that an obscure
dot-file (which doesn't currently exist in ~) will be read by some
program if it's present.

> I would warn the user instead, with an offer to remove the dot.

I think this is a bit clunky.  Gnus always allows you to edit the file
name before saving anyway.  So it's nearly as easy to just add the
dot, than answering `n' to a `y-or-n-p' question.

Re: Saving attachments with a leading dot

[Ted Zlatanov]

On Thu, 25 Sep 2003, harder@myrealbox.com wrote:

> Ted Zlatanov <tzz@lifelogs.com> writes:

>> I think we should simply never set the executable bit on any saved
>> attachment, that's all.

> Should we set the file mode explicitly?  (We already do this for
> some other Gnus generated files) What would the apropriate
> permissions be?

I would set the file mode to 0600 explicitly when saving attachments.
Normally you'd let the shell do permissions through the 'umask'
mechanism, but neither Gnus nor Emacs seem to have any umask-related
variables or functions, according to M-x apropos.  0600 is a pretty
good, safe choice on Unix systems.  On Windows, of course, it's not
so important.

>> I don't think Gnus should ever allow pipes.  The file name should
>> be saved as is, and if the user specified a special character in
>> the name, then so be it.
> 
> Well, the _user_ didn't specify it, the sender did.  I think it's
> important to remember that the "filename" parameter is nothing but a
> suggestion that may form a basis for the actual filename.
> 
> The receiving MUA isn't expected to just use the suggestion as is.
> In other words, the parameter is *not* intended as a mechanism to
> ensure that the attachment is saved under any specific file name.

I was not aware of that.  In that case I would strip off any shell
metacharacters and a leading '.' or '-', but warn the user of it.

>>> · Strip leading dots from file names, or
>>
>> Why?  
> 
> Security.  Unsuspecting users might not be aware that an obscure
> dot-file (which doesn't currently exist in ~) will be read by some
> program if it's present.

I think this is overreaching a bit.  If the user asks to save
~/.cshrc, maybe he knows what he's doing.  At least this should be
optionally allowed.

>> I would warn the user instead, with an offer to remove the dot.
> 
> I think this is a bit clunky.  Gnus always allows you to edit the
> file name before saving anyway.  So it's nearly as easy to just add
> the dot, than answering `n' to a `y-or-n-p' question.

I'm OK with that as long as it can be set to leave the dot in.

Ted

Re: Saving attachments with a leading dot

[Jochen Küpper]

On Thu, 25 Sep 2003 00:22:57 -0400 Ted Zlatanov wrote:

Ted> I would set the file mode to 0600 explicitly when saving
Ted> attachments. Normally you'd let the shell do permissions through
Ted> the 'umask' mechanism, but neither Gnus nor Emacs seem to have
Ted> any umask-related variables or functions, according to M-x
Ted> apropos.

I would still like to see 666 - umask...  

And what is up with filesystems that use different mechanisms or don't
have them, i.e. AFS, FAT based stuff, ... ? Should Gnus even care what
filesystem the file is written too? (In the spirit of this discussion,
it has to.)

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        Sex, drugs and rock-n-roll

Re: Saving attachments with a leading dot

[Hanak David]

On Wed, 24 Sep 2003, Jesper Harder wrote:

> |    In general, the receiving MUA should not name or place the file such
> |    that it will get interpreted or executed without the user explicitly
> |    initiating the action.

[...]

> Gnus doesn't prevent creating startup files.  We could:

Correct me if I'm wrong, but Gnus doesn't extract attachments
automatically, does it?  And when you do extract an attachment
inentionally, Gnus *always* offers you the filename for editing.  I guess
we can call that "explicitly initiating the action".  And beyond that, I
don't really see why Gnus should *prevent* anything.

Perhaps an additional confirm request for certain filenames would do no
harm, but if you do that, also create a variable
'gnus-article-confirm-save-to-suspicious-files-p', because I, for one,
don't want Gnus to be asking that question.

David

Re: Saving attachments with a leading dot

[Reiner Steib]

On Wed, Sep 24 2003, Benjamin Riefenstahl wrote:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>> Emacs happily created »| xless« when trying to save such an
>> attachment.  The content isn't sent to a pipe.
>
> Of course.  But what will your typical home-grown, sh-based nightly
> backup script do with that filename, once the file is created?  If you
> are not *very* sure without needing to verify, you have already lost,
> I think.

My daily backup is done with TSM (IBM's Tivoli Storage manager).  If
I'd do it shell based, this script wouldn't have any problems neither,
believe me. ;-)  It's not that I would normally use "strange"
characters in file names (I don't even use SPC), but you cannot assume
that the don't exist, especially in other peoples files.

I do not argue against rewriting filenames, but it should be
customizable.  E.g. being able to set `mm-file-name-rewrite-functions'
to nil [1] should be fine for experienced users, and the default can
be changed to '(mm-file-name-delete-control mm-file-name-delete-gotchas).
See Jesper's article: <news:m3u1711rgp.fsf@defun.localdomain>.

Bye, Reiner.

[1] This should satisfy Hanak, too, I guess?
    <news:m2fzill0ku.fsf@maui.hanak.hu>
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Saving attachments with a leading dot

[Jesper Harder]

Hanak David <dhanak@inf.bme.hu> writes:

> Correct me if I'm wrong, but Gnus doesn't extract attachments
> automatically, does it?  

It _can_ do that (depending on you settings), but in that case it
doesn't use the filename parameter.

> And when you do extract an attachment inentionally, Gnus *always*
> offers you the filename for editing.  I guess we can call that
> "explicitly initiating the action".  And beyond that, I don't really
> see why Gnus should *prevent* anything.

The question isn't really whether Gnus should change certain
`filename' parameters.  It already does this (the directory part of
the parameter is always stripped), and rightly so.

It's more a question of how _much_ defensive programming we should do.

Lots and lots of flawed shell scripts don't handle embedded newlines
correctly, so I think it makes sense to acknowledge that fact --
especially because there's very little legitimate use for file names
with control characters.

> Perhaps an additional confirm request for certain filenames would do
> no harm, but if you do that, also create a variable
> 'gnus-article-confirm-save-to-suspicious-files-p', because I, for
> one, don't want Gnus to be asking that question.

With the approach I suggest you can just remove the unwanted functions
from `mm-file-name-rewrite-functions'.

Re: Saving attachments with a leading dot

[Jesper Harder]

Jochen Küpper <jochen@jochen-kuepper.de> writes:

> And what is up with filesystems that use different mechanisms or don't
> have them, i.e. AFS, FAT based stuff, ... ? Should Gnus even care what
> filesystem the file is written too? (In the spirit of this discussion,
> it has to.)

Windows doesn't have an executable bit, right?

On Windows maybe we should warn about saving an executable in a
directory that's in PATH, something like:

(when (and (file-executable-p name)
	   (member <directory where the file is saved> exec-path))
  <warning>)

Does this make any sense?

Re: Saving attachments with a leading dot

[Ted Zlatanov]

On Mon, 29 Sep 2003, harder@myrealbox.com wrote:

> Jochen Küpper <jochen@jochen-kuepper.de> writes:
> 
>> And what is up with filesystems that use different mechanisms or
>> don't have them, i.e. AFS, FAT based stuff, ... ? Should Gnus even
>> care what filesystem the file is written too? (In the spirit of
>> this discussion, it has to.)
> 
> Windows doesn't have an executable bit, right?

No, but it does have some attributes (none related to this).

> On Windows maybe we should warn about saving an executable in a
> directory that's in PATH, something like:
> 
> (when (and (file-executable-p name)
> 	   (member <directory where the file is saved> exec-path))
>   <warning>)
> 
> Does this make any sense?

I think it's fine.

Ted

Re: Saving attachments with a leading dot

[Ted Zlatanov]

On Thu, 25 Sep 2003, jochen@jochen-kuepper.de wrote:

On Thu, 25 Sep 2003 00:22:57 -0400 Ted Zlatanov wrote:
> 
> Ted> I would set the file mode to 0600 explicitly when saving
> Ted> attachments. Normally you'd let the shell do permissions
> Ted> through the 'umask' mechanism, but neither Gnus nor Emacs seem
> Ted> to have any umask-related variables or functions, according to
> Ted> M-x apropos.
> 
> I would still like to see 666 - umask...  

I'm saying that's not something Emacs supports right now.  The shell
should handle it, I think.  In any case, I don't think an attachment
should ever be saved with permissions other than 0600, 0640, or 0644.

> And what is up with filesystems that use different mechanisms or
> don't have them, i.e. AFS, FAT based stuff, ... ? Should Gnus even
> care what filesystem the file is written too? (In the spirit of this
> discussion, it has to.)

I think Gnus should try to give the file proper permissions, but it
shouldn't lose sleep over it.  Sometimes it's not possible.

Ted

Re: Saving attachments with a leading dot

[Jochen Küpper]

On Thu, 02 Oct 2003 14:07:31 -0400 Ted Zlatanov wrote:

Ted> On Mon, 29 Sep 2003, harder=YSGFQ8SKJZVDPfheJLI6IQ@public.gmane.org wrote:

>> Jochen Küpper <jochen=W2i0oK7yYu0+t3nig+EZI7NAH6kLmebB@public.gmane.org> writes:
>> 
>>> And what is up with filesystems that use different mechanisms or
>>> don't have them, i.e. AFS, FAT based stuff, ... ? Should Gnus even
>>> care what filesystem the file is written too? (In the spirit of
>>> this discussion, it has to.)
>> 
>> Windows doesn't have an executable bit, right?

Ted> No, but it does have some attributes (none related to this).

Cygwin does have Unix file permissions, for example. I am not sure
*that* works on FAT?

On Thu, 02 Oct 2003 14:10:42 -0400 Ted Zlatanov wrote:

Ted> I'm saying that's not something Emacs supports right now. The
Ted> shell should handle it, I think. In any case, I don't think an
Ted> attachment should ever be saved with permissions other than 0600,
Ted> 0640, or 0644.

At least 444 is perfectly valid, and some people also like 664 / 666
for most of their files...

Ted> I think Gnus should try to give the file proper permissions, but
Ted> it shouldn't lose sleep over it. Sometimes it's not possible.

+1

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: Saving attachments with a leading dot

[Jesper Harder]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Mon, 29 Sep 2003, harder@myrealbox.com wrote:
>
>> On Windows maybe we should warn about saving an executable in a
>> directory that's in PATH, something like:
>> 
>> (when (and (file-executable-p name)
>> 	   (member <directory where the file is saved> exec-path))
>>   <warning>)
>> 
>> Does this make any sense?
>
> I think it's fine.

I don't have an ms-windows box, so I can't test it.  Anyone?

> I'm saying that's not something Emacs supports right now.  The shell
> should handle it, I think.  In any case, I don't think an attachment
> should ever be saved with permissions other than 0600, 0640, or 0644.

I added a new option `mm-attachment-file-modes', which defaults to 600
-- I thought it made sense to use the same default as
`nnmail-default-file-modes'.

Re: Saving attachments with a leading dot

[Benjamin Riefenstahl]

Hi Jesper,

Jesper Harder <harder@myrealbox.com> writes:
>> On Mon, 29 Sep 2003, harder@myrealbox.com wrote:
>>> (when (and (file-executable-p name)
>>> 	   (member <directory where the file is saved> exec-path))
>>>   <warning>)
>
> I don't have an ms-windows box, so I can't test it.  Anyone?

Windows filesystems are not case-sensitive.  Even the members of
exec-path are not consistent about that here.

benny

Re: Saving attachments with a leading dot

[Lars Magne Ingebrigtsen]

Jesper Harder <harder@myrealbox.com> writes:

>> Correct me if I'm wrong, but Gnus doesn't extract attachments
>> automatically, does it?  
>
> It _can_ do that (depending on you settings), but in that case it
> doesn't use the filename parameter.

`X u' and friends does use the filename parameter, and doesn't prompt
for anything.

> The question isn't really whether Gnus should change certain
> `filename' parameters.  It already does this (the directory part of
> the parameter is always stripped), and rightly so.
>
> It's more a question of how _much_ defensive programming we should do.

I think translating leading dots into "_" would be a good idea.

> Lots and lots of flawed shell scripts don't handle embedded newlines
> correctly, so I think it makes sense to acknowledge that fact --
> especially because there's very little legitimate use for file names
> with control characters.

The same can be said for file names with spaces in them, which are
perfectly normal (and legitimate).

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Saving attachments with a leading dot

[Jesper Harder]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jesper Harder <harder@myrealbox.com> writes:
>
>> It _can_ do that (depending on you settings), but in that case it
>> doesn't use the filename parameter.
>
> `X u' and friends does use the filename parameter, and doesn't prompt
> for anything.

Auch!  They are *far* too dangerous -- they don't strip the directory
part of the file name, and they don't complain if the file already
exists.  So, e.g.

      begin 664 /home/harder/.login

will happily overwrite my .login file.

Re: Saving attachments with a leading dot

[Lars Magne Ingebrigtsen]

Jesper Harder <harder@myrealbox.com> writes:

> Auch!  They are *far* too dangerous -- they don't strip the directory
> part of the file name, and they don't complain if the file already
> exists.  So, e.g.
>
>       begin 664 /home/harder/.login
>
> will happily overwrite my .login file.

That's really not good.  I'm kinda surprised that it does no such
checking -- I mean, it was written in 1992, but even so...

I must be mis-remembering, but I thought it translated all slashes to
strokes... 

Actually, the function I meant to mention was `X m'.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Saving attachments with a leading dot

[Jesper Harder]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Actually, the function I meant to mention was `X m'.  :-)

Ah, yes I see your point.  It should also use
mm-file-name-rewrite-functions.

And gnus-summary-save-parts-last-directory might as well default to
mm-default-directory for consistency.

Re: Saving attachments with a leading dot

[Jesper Harder]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jesper Harder <harder@myrealbox.com> writes:
>
>> Auch!  They are *far* too dangerous -- they don't strip the directory
>> part of the file name, and they don't complain if the file already
>> exists.  So, e.g.
>>
>>       begin 664 /home/harder/.login
>>
>> will happily overwrite my .login file.
>
> That's really not good.  I'm kinda surprised that it does no such
> checking -- I mean, it was written in 1992, but even so...

It _tries_ to do the right thing:

(let ((nnheader-file-name-translation-alist
	     '((?/ . ?,) (?  . ?_) (?* . ?_) (?$ . ?_))))
	(nnheader-translate-file-chars "/bin/sh"))

=> "/bin/sh"

... but it doesn't work.  The logic of `nnheader-translate-file-chars'
was probably changed subsequently.  I've changed it to use
`file-name-nondirectory' instead.

Re: Saving attachments with a leading dot

[Lars Magne Ingebrigtsen]

Jesper Harder <harder@myrealbox.com> writes:

> ... but it doesn't work.  The logic of `nnheader-translate-file-chars'
> was probably changed subsequently.  I've changed it to use
> `file-name-nondirectory' instead.

Cool.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen