saving attachement fails on sshfs filesystem

Hello,

Using debian unstable's 1.5.13-1.1 I can no longer save attachements on 
a sshfs (fuse) partition: pressing <enter> at the save-file prompt makes 
mutt wait a few seconds after which the same prompt and default filename 
returns with no error message. Instead of saving the file mutt creates a 
.muttxxx directory for each attempt:

drwx------ 1 ldm ldm    6 2007-01-02 15:31 .mutt7mnbhX/
drwx------ 1 ldm ldm    6 2007-01-02 15:25 .muttKXRT83/

Might this be related to this recent change (debian bug #396104)?

	CVE-2006-5297:
	Race condition in the safe_open function in the Mutt mail client
	1.5.12 and earlier, when creating temporary files in an NFS
	filesystem, allows local users to overwrite arbitrary files due to
	limitations of the use of the O_EXCL flag on NFS filesystems.

	CVE-2006-5298:
	The mutt_adv_mktemp function in the Mutt mail client 1.5.12 and
	earlier does not properly verify that temporary files have been
	created with restricted permissions, which might allow local users to
	create files with weak permissions via a race condition between the
	mktemp and safe_fopen function calls.

	See
	http://marc.theaimsgroup.com/?l=mutt-dev&m=115999486426292&w=2
	for details.

Re: saving attachement fails on sshfs filesystem

I suspect that this is indeed related.  Actually, a similar problem
exists for the vfat file system.

What happens for vfat is this: In order to create a file safely,
mutt creates a temporary directory that it believes it controls [is
that assumption really valid for vfat?], and creates the file in
there. Mutt then needs to move the file one level up.

It appears that, in doing so, we have successfully reduced one
impossible problem (safely creating a file) to another one (safely
moving/renaming a file): To move a file safely, we have for ages
used link(2) and unlink(2), since rename(2) is unsafe on NFS.
Unfortunately, link(2) will fail on file systems that don't support
hard links.

Now, the mutt code even tries to be clever about this, by detecting
EXDEV and falling back to rename(2) in that case -- according to a
comment in safe_rename(), we once made an assumption that file
systems that react with EXDEV to a link(2) that we believe is
guaranteed to be within a single file system can be trusted to do a
proper rename(2), presumably based on the assumption that we're
actually dealing with Coda.

Just to make it all a bit funnier, vfat seems to return EPERM when
you try to invoke link(2), which is not a condition that we seem to
be able to usefully evaluate or react to.

So, we're now caught in a catch-22: We can create our files
super-securely, and in the course of doing so stop creating files on
file systems that don't support hard links, or we can start taking

imap_recent option to use RECENT instead of UNSEEN

Hello.
I have made a patch against a recent 1.5.13 in debian, to use
RECENT instead of UNSEEN when checking for new email over imap.

Imap specification states that UNSEEN is the number of unread messages,
and RECENT is the number of new messages since mailbox was last
selected.

It appears that previous versions of mutt have used RECENT, so I assume
that the current behavior is intentional.

The way I use imap, I have several folders where I have not read all the
messages, and I don't want the folder to be selected unless it has new
messages. Old and unread messages does not warrant my attention, only
new and unread.

To keep the old behavior I have made an option imap_recent that, when
true turns on usage of RECENT, and when false, which is the default,
UNSEEN is used.

I hope you will consider applying this small patch.

Thank you for great work on an efficient text based MUA.

--

-- 
Sincerely | Homepage:
Jørgen    | http://www.hex.no/jhf
          | Public GPG key:
          | http://www.hex.no/jhf/key.txt

[2007-01-03] CVS repository changes

This message was generated and sent automatically.  It contains a
summary of the CVS commits over the last 48 hours.  These changes
should be propagated to the public repository within at most a day
or two.  Most probably, they have already been propagated.

2007-01-02 17:10:34  roessler  (roessler)

	* globals.h, lib.c, lib.h, mutt.h, mutt_socket.c, muttlib.c,
	pgppacket.c, protos.h: add debug harness to lib.c functions,
	and a bunch of dprint's to safe_rename().

Re: imap_recent option to use RECENT instead of UNSEEN

* Jorgen Hermanrud Fjeld wrote:
> Hello.
> I have made a patch against a recent 1.5.13 in debian, to use
> RECENT instead of UNSEEN when checking for new email over imap.
> 
> Imap specification states that UNSEEN is the number of unread messages,
> and RECENT is the number of new messages since mailbox was last
> selected.

thank you very much for this patch, i'd reverted to 1.5.11 because of this
issue but your patch restores the previous behaviour i had come to
expect.

--

-- 
ben darby

Re: [2007-01-03] CVS repository changes

Hi,

* Thomas Roessler [07-01-03 04:00:41 +0000] wrote:
>2007-01-02 17:10:34  roessler  (roessler)

>	* globals.h, lib.c, lib.h, mutt.h, mutt_socket.c, muttlib.c,
>	pgppacket.c, protos.h: add debug harness to lib.c functions,
>	and a bunch of dprint's to safe_rename().

Apropos debugging: for some time now I hate the debug levels mutt 
provides since it sometimes takes ages to search for certain things 
especially when the debug level increases.

I thought of adding "types" or "bits" of debug output instead of levels 
which can be turned on and off. In the code, a debug message could be 
defined to belong to any number of types by ORing some bits.  The user 
could then say "give me all debug output for imap and pop but no socket 
traffic and no hcache output" via:

   -d imap,pop,nosocket,nohcache

or similar. The current debug levels of 1..5 could be made aliases so 
nobody would even notice a change.

An implementation of this would be trivial and the macro implementation 
can be kept; only a tiny parser for the debug bits is required.

Comments?

   bye, Rocco

Re: saving attachement fails on sshfs filesystem

On Tuesday, January  2 at 06:23 PM, quoth Thomas Roessler:
> So, we're now caught in a catch-22: We can create our files 
> super-securely, and in the course of doing so stop creating files on 
> file systems that don't support hard links, or we can start taking 
> the risk that the creation of files in shared directories is subject 
> to race conditions at least in some use cases.  (Note that we use 
> safe_fopen even for files in locations that are derived from user 
> input.)
>
> Input welcome. 

It seems to me that the problem is one of policy rather than 
implementation: if we have a policy of "fall back" then the idea of 
"securely creating files" is bogus, and if we don't have such a 
fall-back policy, then we simply cannot create files on filesystems 
that have no way of creating files securely.

And, for matters of policy, it seems a config variable is in order. 
The default should, of course, be to create files securely, but it 
should be possible to turn off this behavior (set 
$secure_file_creation=no), for people who neither care nor are able to 
use a filesystem on which files can be created securely.

Might that solve the problem acceptably?

~Kyle
--

-- 
Three things in human life are important.  The first is to be kind. 
The second is to be kind.  And the third is to be kind.
                                                        -- Henry James

[2007-01-04] CVS repository changes

This message was generated and sent automatically.  It contains a
summary of the CVS commits over the last 48 hours.  These changes
should be propagated to the public repository within at most a day
or two.  Most probably, they have already been propagated.

2007-01-02 17:10:34  roessler  (roessler)

	* globals.h, lib.c, lib.h, mutt.h, mutt_socket.c, muttlib.c,
	pgppacket.c, protos.h: add debug harness to lib.c functions,
	and a bunch of dprint's to safe_rename().

Crash in menu.c

Hi,

lately I get the following crashes when trying to send a message:

   #0  0x0807b3f1 in menu_pad_string (s=0x100 <Address 0x100 out of bounds>, n=0) at menu.c:163
   163       mutt_format_string (s, n, cols, cols, 0, ' ', scratch, mutt_strlen (scratch), 1);
   (gdb) bt
   #0  0x0807b3f1 in menu_pad_string (s=0x100 <Address 0x100 out of bounds>, n=0) at menu.c:163
   #1  0x0807b5c0 in menu_redraw_index (menu=0x8a9aa80) at menu.c:219
   #2  0x0807c61d in menu_redraw (menu=0x8a9aa80) at menu.c:832
   #3  0x0807c69c in mutt_menuLoop (menu=0x8a9aa80) at menu.c:859
   #4  0x080bb278 in tls_negotiate (conn=0x8a93000) at mutt_ssl_gnutls.c:781
   #5  0x080bb85d in mutt_ssl_starttls (conn=0x8a93000) at mutt_ssl_gnutls.c:153
   #6  0x080b84b3 in mutt_smtp_send (from=0x0, to=0x91c7ca0, cc=0x0, bcc=0x0, msgfile=0xbfbfac80
"/home/pdmef/tmp/mutt/mutt-peter-1001-1588-37", eightbit=1) at smtp.c:384
   #7  0x0809a826 in ci_send_message (flags=5, msg=0x8a7fe80, tempfile=0x0, ctx=0x80f4800,
cur=0x8a5f500) at send.c:1051
   #8  0x080875c7 in mutt_pager (banner=0x0, fname=0xbfbfce70 "", flags=66, extra=0xbfbfce70) at pager.c:2473
   #9  0x08057288 in mutt_display_message (cur=0x8a5f500) at commands.c:211
   #10 0x08060e8b in mutt_index_menu () at curs_main.c:1173
   #11 0x080787c2 in main (argc=1, argv=0xbfbfe6dc) at main.c:980
   (gdb) print s
   $1 = 0x100 <Address 0x100 out of bounds>
   (gdb) print scratch
   $2 = 0x0

I replaced the binary with a hotfix one so that the output isn't really 
as with the crashing binary. However, in both cases scratch is 0x0 which 
seems to make strlen() crash.

[patch] make headers wrap at wrapmargin rather than hardcoded value

... afterall we're using wide-terminal for a reason. ;)

Moin, and enjoy.

-- 
© Rado S. -- You must provide YOUR effort for your goal!
Even if it seems insignificant, in fact EVERY effort counts
for a shared task, at least to show your deserving attitude.

--- sendlib.c	Thu Aug 17 11:00:02 2006
+++ ../sendlib.c	Thu Jan  4 20:30:38 2007
@@ -1518,8 +1518,6 @@
 }

 
-#define WRAPLEN 76
-
 static void foldingstrfcpy (char *d, const char *s, int n)
 {
   while (--n >= 0 && *s)
@@ -1544,6 +1542,7 @@
   int first = 1;
   int wrapped = 0;
   int in_encoded_word = 0;
+  int WRAPLEN=COLS-WrapMargin;

   if (tag)
   {
@@ -1684,8 +1683,6 @@