Security vulnerability in APOP authentication
Hello, I found a security vulnerability in the APOP authentication. It is related to recent collision attacks by Wang and al. against MD5. The basic idea is to craft a pair of message-ids that will collide in the APOP hash if the password begins in a specified way. So the attacker would impersonate a POP server, and send these msg-id; the client will return the hash, and the attacker can learn some password characters. The msg-ids will be generated from a MD5 collision: if you have two colliding messages for MD5 "<[EMAIL PROTECTED]>x" and "<[EMAIL PROTECTED]>x", and the message are of length two blocks, then you will use "<[EMAIL PROTECTED]>" and "<[EMAIL PROTECTED]>" as msg-ids. When the client computes MD5(msg-id||passwd) with these two, it will collide if the first password character if 'x', no matter what is next (since we are at a block boundary, and the end of the password will be the same in the two hashs). Therefore you can learn the password characters one by one (actually you can only recover three of them, due to the way MD5 collisions are computed). This attack is really a practical one: it needs about an hour of computation and a few hundred authentications from the client, and can recover three password characters. I tested it against mutt, and it does work. However, using the current techniques available to attack MD5, the msg-ids sent by the server can easily be distinguished from genuine ones as they will not respect the RFC specification. In particular, they will contain non-ASCII characters. Therefore, as a security countermeasure, I think mutt should reject msg-ids that does not conform to the RFC. The details of the attack and the new results against MD5 needed to build it will be presented in the Fast Software Encryption conference on March 28. I can send you some more details if needed. Meanwhile, feel free to alert any one that you believe is concerned. I am already sending this mail to the maintainers of Thunderbird, Evolution, fetchmail, and mutt. KMail already seems to do enough checks on the msg-id to avoid the attack. -- Gaëtan LEURENT
Re: [PATCH] runtime configurable buffy size
On Wed, Mar 14, 2007 at 11:15:27PM -0700, Brendan Cully wrote:
> On Thursday, 01 March 2007 at 16:23, Miroslav Lichvar wrote:
> > Ok, here is a patch that removes buffy_size completely and adds the
> > check_box_size option.
>
> Looks nice, thanks. But...
Thanks for looking into this.
> > Index: commands.c
> > @@ -842,11 +837,9 @@
> >
> > if (need_buffy_cleanup)
> > {
> > -#ifdef BUFFY_SIZE
> >tmp = mutt_find_mailbox (buf);
> >if (tmp && !tmp->new)
> > mutt_update_mailbox (tmp);
> > -#else
> >/* fix up the times so buffy won't get confused */
> >if (st.st_mtime > st.st_atime)
> >{
> > @@ -856,7 +849,6 @@
> >}
> >else
> > utime (buf, NULL);
> > -#endif
> > }
>
> this looks a little like it should be a conditional on
> option(CHECKMBOXSIZE).
I think it's ok either way. Without the conditional it's a bit
closer to allowing runtime switching of the option and not losing
new mail flags on the mailboxes.
> > Index: mx.c
> > @@ -436,7 +430,7 @@
> > else if (mutt_strcmp (MMDF_SEP, tmp) == 0)
> >magic = M_MMDF;
> > safe_fclose (&f);
> > -#ifndef BUFFY_SIZE
> > +
> > /* need to restore the times here, the file was not really accessed,
> > * only the type was accessed. This is important, because detection
> > * of "new mail" depends on those times set correctly.
> > @@ -444,7 +438,6 @@
> > times.actime = st.st_atime;
> > times.modtime = st.st_mtime;
> > utime (path, ×);
> > -#endif
> >}
> >else
> >{
Same as the first case.
> > @@ -786,9 +777,7 @@
> > case M_MBOX:
> > case M_MMDF:
> >rc = mbox_sync_mailbox (ctx, index_hint);
> > -#ifdef BUFFY_SIZE
> >tmp = mutt_find_mailbox (ctx->path);
> > -#endif
> >break;
> >
> > case M_MH:
> > @@ -815,10 +804,8 @@
> > mutt_error ( _("Could not synchronize mailbox %s!"), ctx->path);
> > #endif
> >
> > -#ifdef BUFFY_SIZE
> >if (tmp && tmp->new == 0)
> > mutt_update_mailbox (tmp);
> > -#endif
> >return rc;
> > }
>
> and probably these too?
This should be ok, mutt_find_mailbox returns NULL when CHECKMBOXSIZE
is disabled.
--
Miroslav Lichvar
Re: [PATCH] hcache: prepend current dir to path for local folders
Hi, * Brendan Cully [07-03-14 13:21:51 -0700] wrote: I've applied this, but I followed up with a patch that _always_ uses realpath if stat succeeds, and doesn't do any other cleanup. The remote URL users should be providing clean paths already. After reading your patch I think the trailing slash issue is superflous (e.g. I agree with your cleanup) since mutt's completion only should add it if the target is a directory (e.g. maildir and mh)... and realpath() should already kill the slash on its own. bye, Rocco -- :wq!
Re: Security vulnerability in APOP authentication
Hi, * Gaëtan LEURENT [07-03-14 15:53:36 +0100] wrote: This attack is really a practical one: it needs about an hour of computation and a few hundred authentications from the client, and can recover three password characters. I tested it against mutt, and it does work. Well, this is a difficult issue. First, using hash algorithms always leaves us with the risk of collisions if it's only a theoretical one. Second, you have the same problem if someone can construct a collision with fully RfC-compliant message-ids. Third, you have many other problems once someone owns your pop server. :) However, using the current techniques available to attack MD5, the msg-ids sent by the server can easily be distinguished from genuine ones as they will not respect the RFC specification. In particular, they will contain non-ASCII characters. Therefore, as a security countermeasure, I think mutt should reject msg-ids that does not conform to the RFC. APOP IMHO should never be considered a secure way of authentication, it's just more secure than sending plain passwords over the wire. But yes, since the RfC says the "timestamp" must be syntacially valid message-id and mutt doesn't check it, there's some room of improvement. On the other hand, it may not be very nice to abort authentication in case the server config is so broken that it generates invalid message-ids... bye, Rocco -- :wq!
Re: mutt/2821: Bug#413144: decrypt-save, -copy not documented
Synopsis: Bug#413144: decrypt-save, -copy not documented State-Changed-From-To: open->closed State-Changed-By: cb State-Changed-When: Thu, 15 Mar 2007 14:14:00 +0100 State-Changed-Why: Fixed by auto-generating this manual part: http://dev.mutt.org/hg/mutt/rev/dd5db5eba4fe Comment added by cb on Thu, 15 Mar 2007 14:14:00 +0100
Re: Security vulnerability in APOP authentication
Rocco Rutte wrote on 15 Mar 2007 11:33:49 +0100: > Well, this is a difficult issue. First, using hash algorithms always > leaves us with the risk of collisions if it's only a theoretical one. Sure, but a single collision is not a security threat... the problem arises when you can construct collisions cheaply. In fact, if there is no weakness in the hash function, it will be easier to guess the password that to find a collision... > Second, you have the same problem if someone can construct a collision > with fully RfC-compliant message-ids. Yes, definitely. I think the use of APOP should be strongly discouraged now. > Third, you have many other problems once someone owns your pop > server. :) Well, the attacker does not need to own your server, a man in the middle is enough. You will have quite a few problems if there is a man in the middle, but risking your APOP password should not be of them... your mails are not safe, but your password should be. > APOP IMHO should never be considered a secure way of authentication, > it's just more secure than sending plain passwords over the wire. But > yes, since the RfC says the "timestamp" must be syntacially valid > message-id and mutt doesn't check it, there's some room of improvement. > > On the other hand, it may not be very nice to abort authentication in > case the server config is so broken that it generates invalid > message-ids... This is not a problem; if the server does not support APOP it does not send a msg-id and I believe mutt already does something useful in this case, like switching to another authentication method... the invalid msg-ids could be handled just the same. -- Gaëtan LEURENT
[PATCH] Document pattern groups in the manual
This patch is more or less copy'n'paste work to "sync" the manual documentation on pattern groups with muttrc(5). And while I'm at it, add some lines to muttrc(5) saying what these groups are useful for. And while I'm at it, fix some style issues. As reviewing the updated muttrc(5) revealed, there was a quoting issue in init.h with the docs for $smtp_authenticators which is fixed, too. --- doc/manual.xml.head | 89 -- doc/muttrc.man.head | 32 -- init.h |2 +- 3 files changed, 100 insertions(+), 23 deletions(-) diff --git a/doc/manual.xml.head b/doc/manual.xml.head index 5e6af5d..c60f496 100644 --- a/doc/manual.xml.head +++ b/doc/manual.xml.head @@ -1523,11 +1523,56 @@ For a complete list, see the command reference. + +Address groups + + +Usage: group [ -group name [ ... ] ] [ -rx EXPR [ ... ] ] [ -addr EXPR [ ... ] ] + + + +group is used to directly add either addresses or +regular expressions to the specified group or groups. The different +categories of arguments to the group command can be +in any order. The flags -rx and +-addr specify what the following strings (that cannot +begin with a hyphen) should be interpreted as: either a regular +expression or an email address, respectively. + + + +These address groups can also be created implicitely by the +alias, lists, +subscribe and +alternates commands by specifying the +optional -group option. + + + +Once defined, these address groups can be used in +patterns to search for and limit the +display to messages matching a group. + + + +Usage: ungroup [ -group name [ ... ] ] [ * | [ [ -rx EXPR [ ... ] ] [ -addr EXPR [ ... ] ] ] + + + +ungroup is used to remove addresses or regular +expressions from the specified group or groups. The syntax is similar to +the group command, however the special character +* can be used to empty a group of all of its +contents. + + + + Defining/Using aliases -Usage: alias key address [ , address, ... ] +Usage: alias [ -group name [ ... ] ] key address [ , address, ... ] @@ -1537,8 +1582,14 @@ a short string to a full address. -Note: if you want to create an alias for a group (by specifying more than -one address), you must separate the addresses with a comma (``,''). +Note: if you want to create an alias for more than +one address, you must separate the addresses with a comma (``,''). + + + +The optional -group argument to +alias causes the aliased address(es) to be added to +the named group. @@ -2286,7 +2337,7 @@ unignore posted-to: Alternative addresses -Usage: [un]alternates regexp [ regexp ... ] +Usage: [un]alternates [ -group name [ ... ] ] regexp [ regexp ... ] @@ -2309,6 +2360,11 @@ receive e-mail. +The -group flag causes all of the subsequent regular expressions +to be added to the named group. + + + The unalternates command can be used to write exceptions to alternates patterns. If an address matches something in an alternates command, but you nonetheless do not think it is @@ -2332,8 +2388,8 @@ is ``*'', all entries on alternates will -Usage: [un]lists regexp [ regexp ... ] -Usage: [un]subscribe regexp [ regexp ... ] +Usage: [un]lists [ -group name [ ... ] ] regexp [ regexp ... ] +Usage: [un]subscribe [ -group name [ ... ] ] regexp [ regexp ... ] @@ -2361,7 +2417,7 @@ command. To mark it as subscribed, use ``subscribe''. You can use regular expressions with both commands. To mark all messages sent to a specific bug report's address on mutt's bug tracking system as list mail, for instance, you could say -``subscribe [[EMAIL PROTECTED]''. Often, it's sufficient to just +``subscribe [0-9][EMAIL PROTECTED]''. Often, it's sufficient to just give a portion of the list's e-mail address. @@ -2380,6 +2436,11 @@ match only mail from the actual list. +The -group flag adds all of the subsequent regular expressions +to the named group. + + + The ``unlists'' command is used to remove a token from the list of known and subscribed mailing-lists. Use ``unlists *'' to remove all tokens. @@ -3607,15 +3668,20 @@ messages: ~Aall messages ~b EXPRmessages which contain EXPR in the message body +=b STRINGmessages which contain STRING in the message body. If IMAP is enabled, searches for STRING on the server, rather than downloading each message and searching it locally. ~B EXPRmessages which contain EXPR in the whole message ~c EXPRmessages carbon-copied to EXPR +%c GROUPmessages carbon-copied to any member of GROUP ~C EXPRmessage is either to: or cc: EXPR +%C GROUPmessage is either to: or cc: to any member of GROUP ~d [MIN]-[MAX]messages with ``date-sent'' in a Date range ~Ddeleted messages ~e EXPRmessage which contains EXPR in the ``Sender'' field +%e GROUPmessage which contain a member of GROUP in the ``Sender'' field ~Eexpired messages ~Fflagged messages ~f EXPRmessages originating from EXPR +%f GROUPmessages originat
[PATCH] Remove reldate.h from EXTRADIST
# HG changeset patch # User Christoph Berg <[EMAIL PROTECTED]> # Date 1173971448 -3600 # Node ID 2befb5b028d73cf7045b426f513d6b6c1c6a7681 # Parent fa6128cf9cba43cf25fc353d7d79377982a25a54 Remove reldate.h from EXTRADIST to fix out-of-tree builds from tarballs (and remove some stray tabs). diff -r fa6128cf9cba -r 2befb5b028d7 Makefile.am --- a/Makefile.am Wed Mar 14 23:03:37 2007 -0700 +++ b/Makefile.am Thu Mar 15 16:10:48 2007 +0100 @@ -74,11 +74,11 @@ EXTRA_DIST = COPYRIGHT GPL OPS OPS.PGP O mx.h pager.h pgp.h pop.h protos.h rfc1524.h rfc2047.h \ rfc2231.h rfc822.h rfc3676.h sha1.h sort.h mime.types VERSION prepare \ _regex.h OPS.MIX README.SECURITY remailer.c remailer.h browser.h \ - mbyte.h lib.h extlib.c pgpewrap.c smime_keys.pl pgplib.h Muttrc.head Muttrc \ + mbyte.h lib.h extlib.c pgpewrap.c smime_keys.pl pgplib.h Muttrc.head Muttrc \ makedoc.c stamp-doc-rc README.SSL smime.h\ - muttbug pgppacket.h depcomp ascii.h BEWARE PATCHES patchlist.sh \ + muttbug pgppacket.h depcomp ascii.h BEWARE PATCHES patchlist.sh \ ChangeLog ChangeLog.old mkchangelog.sh cvslog2changelog.pl mutt_idna.h \ - snprintf.c regex.c crypt-gpgme.h reldate.h + snprintf.c regex.c crypt-gpgme.h EXTRA_SCRIPTS = smime_keys Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: [PATCH] Remove reldate.h from EXTRADIST
# HG changeset patch # User Christoph Berg <[EMAIL PROTECTED]> # Date 1173975665 -3600 # Node ID 5c2f2072a4dbfa69f2db7a93ae52b984f65e165c # Parent 2befb5b028d73cf7045b426f513d6b6c1c6a7681 Pull release date directly from Changelog. diff -r 2befb5b028d7 -r 5c2f2072a4db doc/Makefile.am --- a/doc/Makefile.am Thu Mar 15 16:10:48 2007 +0100 +++ b/doc/Makefile.am Thu Mar 15 17:21:05 2007 +0100 @@ -116,9 +116,6 @@ instdoc: instdoc.sh ../makedoc$(EXEEXT): $(top_srcdir)/makedoc.c (cd .. && $(MAKE) makedoc$(EXEEXT)) -../reldate.h: - (cd .. && $(MAKE) reldate.h) - update-doc: stamp-doc-xml stamp-doc-chunked manual.txt manual.html muttrc.man: ../makedoc$(EXEEXT) $(top_srcdir)/init.h muttrc.man.head muttrc.man.tail @@ -133,10 +130,11 @@ mutt.1: $(srcdir)/mutt.man mutt.1: $(srcdir)/mutt.man $(EDIT) $(srcdir)/mutt.man > $@ -stamp-doc-xml: ../makedoc$(EXEEXT) $(top_srcdir)/init.h manual.xml.head \ +stamp-doc-xml: $(top_srcdir)/makedoc.c $(top_srcdir)/init.h manual.xml.head \ $(top_srcdir)/functions.h $(top_srcdir)/OPS* manual.xml.tail \ - $(top_srcdir)/VERSION ../reldate.h - ( date=`cut -d\" -f2 ../reldate.h`; \ + $(top_srcdir)/VERSION $(top_srcdir)/ChangeLog + $(MAKE) ../makedoc$(EXEEXT) # we do not want to rebuild the documentation in tarball builds + ( date=`head -n 1 $(top_srcdir)/ChangeLog | LC_ALL=C cut -d ' ' -f 1`; \ sed -e "s/@VERSION\@/`cat $(top_srcdir)/VERSION` ($$date)/" $(srcdir)/manual.xml.head ;\ $(MAKEDOC_CPP) $(top_srcdir)/init.h | ../makedoc -s ;\ perl $(srcdir)/gen-map-doc $(top_srcdir)/functions.h $(top_srcdir)/OPS* < $(srcdir)/manual.xml.tail \ Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
[PATCH] Remove absolute paths from gpg.rc
# HG changeset patch # User Christoph Berg <[EMAIL PROTECTED]> # Date 1173976786 -3600 # Node ID 50bc0121e4a8b1c638fa56451d477a7cf3b1cbce # Parent 5c2f2072a4dbfa69f2db7a93ae52b984f65e165c Remove absolute paths. diff -r 5c2f2072a4db -r 50bc0121e4a8 contrib/gpg.rc --- a/contrib/gpg.rcThu Mar 15 17:21:05 2007 +0100 +++ b/contrib/gpg.rcThu Mar 15 17:39:46 2007 +0100 @@ -31,44 +31,44 @@ # breaking PGP/MIME. # decode application/pgp -set pgp_decode_command="/usr/bin/gpg --status-fd=2 %?p?--passphrase-fd 0? --no-verbose --quiet --batch --output - %f" +set pgp_decode_command="gpg --status-fd=2 %?p?--passphrase-fd 0? --no-verbose --quiet --batch --output - %f" # verify a pgp/mime signature -set pgp_verify_command="/usr/bin/gpg --status-fd=2 --no-verbose --quiet --batch --output - --verify %s %f" +set pgp_verify_command="gpg --status-fd=2 --no-verbose --quiet --batch --output - --verify %s %f" # decrypt a pgp/mime attachment -set pgp_decrypt_command="/usr/bin/gpg --status-fd=2 %?p?--passphrase-fd 0? --no-verbose --quiet --batch --output - %f" +set pgp_decrypt_command="gpg --status-fd=2 %?p?--passphrase-fd 0? --no-verbose --quiet --batch --output - %f" # create a pgp/mime signed attachment -# set pgp_sign_command="/usr/bin/gpg-2comp --comment '' --no-verbose --batch --output - %?p?--passphrase-fd 0? --armor --detach-sign --textmode %?a?-u %a? %f" -set pgp_sign_command="/usr/bin/gpg--no-verbose --batch --quiet --output - %?p?--passphrase-fd 0? --armor --detach-sign --textmode %?a?-u %a? %f" +# set pgp_sign_command="gpg-2comp --comment '' --no-verbose --batch --output - %?p?--passphrase-fd 0? --armor --detach-sign --textmode %?a?-u %a? %f" +set pgp_sign_command="gpg --no-verbose --batch --quiet --output - %?p?--passphrase-fd 0? --armor --detach-sign --textmode %?a?-u %a? %f" # create a application/pgp signed (old-style) message -# set pgp_clearsign_command="/usr/bin/gpg-2comp --comment '' --no-verbose --batch --output - %?p?--passphrase-fd 0? --armor --textmode --clearsign %?a?-u %a? %f" -set pgp_clearsign_command="/usr/bin/gpg --no-verbose --batch --quiet --output - %?p?--passphrase-fd 0? --armor --textmode --clearsign %?a?-u %a? %f" +# set pgp_clearsign_command="gpg-2comp --comment '' --no-verbose --batch --output - %?p?--passphrase-fd 0? --armor --textmode --clearsign %?a?-u %a? %f" +set pgp_clearsign_command="gpg --no-verbose --batch --quiet --output - %?p?--passphrase-fd 0? --armor --textmode --clearsign %?a?-u %a? %f" # create a pgp/mime encrypted attachment -# set pgp_encrypt_only_command="pgpewrap gpg-2comp -v --batch --output - --encrypt --textmode --armor --always-trust -- -r %r -- %f" -set pgp_encrypt_only_command="pgpewrap /usr/bin/gpg --batch --quiet --no-verbose --output - --encrypt --textmode --armor --always-trust -- -r %r -- %f" +# set pgp_encrypt_only_command="pgpewrap gpg-2comp -v --batch --output - --encrypt --textmode --armor --always-trust -- -r %r -- %f" +set pgp_encrypt_only_command="pgpewrap gpg --batch --quiet --no-verbose --output - --encrypt --textmode --armor --always-trust -- -r %r -- %f" # create a pgp/mime encrypted and signed attachment # set pgp_encrypt_sign_command="pgpewrap gpg-2comp %?p?--passphrase-fd 0? -v --batch --output - --encrypt --sign %?a?-u %a? --armor --always-trust -- -r %r -- %f" -set pgp_encrypt_sign_command="pgpewrap /usr/bin/gpg %?p?--passphrase-fd 0? --batch --quiet --no-verbose --textmode --output - --encrypt --sign %?a?-u %a? --armor --always-trust -- -r %r -- %f" +set pgp_encrypt_sign_command="pgpewrap gpg %?p?--passphrase-fd 0? --batch --quiet --no-verbose --textmode --output - --encrypt --sign %?a?-u %a? --armor --always-trust -- -r %r -- %f" # import a key into the public key ring -set pgp_import_command="/usr/bin/gpg --no-verbose --import %f" +set pgp_import_command="gpg --no-verbose --import %f" # export a key from the public key ring -set pgp_export_command="/usr/bin/gpg --no-verbose --export --armor %r" +set pgp_export_command="gpg --no-verbose --export --armor %r" # verify a key -set pgp_verify_key_command="/usr/bin/gpg --verbose --batch --fingerprint --check-sigs %r" +set pgp_verify_key_command="gpg --verbose --batch --fingerprint --check-sigs %r" # read in the public key ring -set pgp_list_pubring_command="/usr/bin/gpg --no-verbose --batch --quiet --with-colons --list-keys %r" +set pgp_list_pubring_command="gpg --no-verbose --batch --quiet --with-colons --list-keys %r" # read in the secret key ring -set pgp_list_secring_command="/usr/bin/gpg --no-verbose --batch --quiet --with-colons --list-secret-keys %r" +set pgp_list_secring_command="gpg --no-verbose --batch --quiet --with-colons --list-secret-keys %r" # fetch keys # set pgp_getkeys_command="pkspxycwrap %r" Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: [PATCH] Remove absolute paths from gpg.rc
On Thu, 15 Mar 2007, Christoph Berg wrote: # HG changeset patch # User Christoph Berg <[EMAIL PROTECTED]> # Date 1173976786 -3600 # Node ID 50bc0121e4a8b1c638fa56451d477a7cf3b1cbce # Parent 5c2f2072a4dbfa69f2db7a93ae52b984f65e165c Remove absolute paths. The reason for the absolute paths is very likely to ensure that it does not pick up some random program named "gpg". (Making it configurable from a single point is probably a better way to go). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: [PATCH] Remove absolute paths from gpg.rc
On Mar 15, Thomas Dickey <[EMAIL PROTECTED]> wrote: > The reason for the absolute paths is very likely to ensure that it > does not pick up some random program named "gpg". (Making it configurable > from a single point is probably a better way to go). How many random programs named "gpg" are there around? I think it's a very remote corner case. -- ciao, Marco
Re: [PATCH] Remove absolute paths from gpg.rc
Re: Thomas Dickey 2007-03-15 <[EMAIL PROTECTED]> > The reason for the absolute paths is very likely to ensure that it > does not pick up some random program named "gpg". (Making it configurable > from a single point is probably a better way to go). The proper way to deal with that is not to have "." at the beginning of $PATH. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: [PATCH] Remove absolute paths from gpg.rc
On Thu, 15 Mar 2007, Marco d'Itri wrote: On Mar 15, Thomas Dickey <[EMAIL PROTECTED]> wrote: The reason for the absolute paths is very likely to ensure that it does not pick up some random program named "gpg". (Making it configurable from a single point is probably a better way to go). How many random programs named "gpg" are there around? I think it's a very remote corner case. It really depends on your environment (and even if they're the "same", they may not be the particular version you wanted). Anyway, adding a change like that just gets you noticed on BugTraq, etc. Your choice. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: [PATCH] Remove absolute paths from gpg.rc
On Thu, Mar 15, 2007 at 05:40:52PM +0100, Christoph Berg wrote: > # Parent 5c2f2072a4dbfa69f2db7a93ae52b984f65e165c > Remove absolute paths. For what it's worth, I don't think this is a good change. The absolute path will be correct for most systems, and does guard against rogue gpg's in the path. -- Paul signature.asc Description: Digital signature
Re: [PATCH] Remove absolute paths from gpg.rc
On Friday, 16 March 2007 at 00:07, Paul Walker wrote: > On Thu, Mar 15, 2007 at 05:40:52PM +0100, Christoph Berg wrote: > > > # Parent 5c2f2072a4dbfa69f2db7a93ae52b984f65e165c > > Remove absolute paths. > > For what it's worth, I don't think this is a good change. The absolute path > will be correct for most systems, and does guard against rogue gpg's in the > path. On my OS X system, gpg lives in /sw/bin. Many others probably have it in /opt or /usr/local. I don't think /usr/bin is a particularly foolproof setting, and I also don't think that any person interested in security should run with garbage in $PATH. I would also guess that it's just as easy to modify a person's .muttrc as to put a trojan gpg somewhere in their PATH. I'd like to hear some more concrete examples of the dangers of looking up gpg in the path... pgpz1SLztYPjw.pgp Description: PGP signature
Re: [PATCH] Remove absolute paths from gpg.rc
Re: Brendan Cully 2007-03-16 <[EMAIL PROTECTED]> > I'd like to hear some more concrete examples of the dangers of looking > up gpg in the path... Ack. Just because gpg is a 'security' application doesn't make running "ls" instead of "/bin/ls" less dangerous. Adding /usr/bin merely adds clutter. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: mutt/2760: mime_forward does not work for text/rfc822-headers attachments
Synopsis: mime_forward does not work for text/rfc822-headers attachments State-Changed-From-To: open->closed State-Changed-By: cb State-Changed-When: Fri, 16 Mar 2007 01:22:53 +0100 State-Changed-Why: Report was mostly pebcak. Comment added by cb on Fri, 16 Mar 2007 01:22:53 +0100
Re: [PATCH] Remove absolute paths from gpg.rc
On Thu, Mar 15, 2007 at 05:15:26PM -0700, Brendan Cully wrote: > On my OS X system, gpg lives in /sw/bin. Many others probably have it in > /opt or /usr/local. I don't think /usr/bin is a particularly foolproof Personally, I would still argue that /usr/bin is far and away the most common. Most people are running with gnupg supplied by their distro, and those update /usr/. People using OS X are in a definite minority; in addition, if they're savvy enough to use fink/darwinports to get mutt, it's kind of more or less automatic for them to be able to change an example muttrc. > setting, and I also don't think that any person interested in security > should run with garbage in $PATH. I would also guess that it's just as That's fine, and I would agree, but the person you're dealing with should be assumed to be a normal user, not "any person interested in security". > easy to modify a person's .muttrc as to put a trojan gpg somewhere in > their PATH. If you can modify someones personal files, the game's already over. > I'd like to hear some more concrete examples of the dangers of looking > up gpg in the path... I have none. I remain completely unconvinced by the merits of removing the absolute pathname. However, I'm not the one with commit access, you are. :-) Your call. -- Paul signature.asc Description: Digital signature
Re: [PATCH] Remove absolute paths from gpg.rc
* On 2007.03.15, in <[EMAIL PROTECTED]>, * "Paul Walker" <[EMAIL PROTECTED]> wrote: > > Personally, I would still argue that /usr/bin is far and away the most > common. Most people are running with gnupg supplied by their distro, and I don't know if I agree with that. There are still a lot of people running things that aren't Linux or XyzBSD, and most of those don't ship gpg, and they don't put "local" software in /usr/bin. > those update /usr/. People using OS X are in a definite minority; in > addition, if they're savvy enough to use fink/darwinports to get mutt, it's > kind of more or less automatic for them to be able to change an example > muttrc. I wouldn't agree with that either. I can think of two compromises: * as Thomas Dickey suggested, detect gpg at compile time and insert the correct path into the installed muttrc files; * enforce a sane PATH within mutt. This could, perhaps should be limited to stripping out relative paths. Failing something like this, I'd say it's preferable to make things portable than to make things... *cough* "secure". -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: [PATCH] Remove absolute paths from gpg.rc
* David Champion <[EMAIL PROTECTED]> [03-15-07 21:28]: [...] > I can think of two compromises: > * as Thomas Dickey suggested, detect gpg at compile time and insert > the correct path into the installed muttrc files; this might be a problem for those using an rpm or dep install and/or those who install gpg after compiling mutt. -- Patrick ShanahanRegistered Linux User #207535 http://wahoo.no-ip.org@ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2 OpenSUSE Linux http://en.opensuse.org/
Re: forwarding messages with attachments
On Thu, Mar 15, 2007 at 12:51:55PM -0400, Jean-Rene David wrote: > * Derek Martin [2007.03.14 19:30]: > > I consider this to be utterly and completely > > broken, and I'm considering reporting it as a > > bug, but I'm waiting to see what other people > > think. > > From my limited understanding, when a message is > mime-encoded, the *whole body* is a set of > attachments, including what you refer to as the > body, which is the part you composed before > sending the message. It's not the encoding that I care about... it's the behavior of Mutt as I'm responding to the mail. When READING a mime-encoded message, mutt essentially treats the first plain text attachment as the message body, and does the right thing. However, when FORWARDING such a message, it does not treat this same attachment as a message body that you can respond to. How it gets encoded after I'm done with it is really irrelevant to me. The second issue is that it actually does include the HEADERS of the message in the editable body, along with the usual ---forwarded message--- blah blah... but it does not include the actual message body. I think that's definitely a bug, on both counts. If you're not going to give me the original body, what possible reason would I have for wanting the headers in the body? Including them goes against every reasonable standard for how to quote e-mail messages... If you're not sure what I mean, send yourself a message with attachments, and put something in the body. Then set mime_forward, and forward the message to yourself, and look at the message you get. I can't see any use case for the results being desirable. it's just plain yucky. CCing mutt-dev, since it seems this discussion needs to go there instead of here. Please REMOVE mutt-users if you reply. Thanks -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgpFhUaYEGtDU.pgp Description: PGP signature
mutt: 6 new changesets
6 new changesets in mutt: http://dev.mutt.org/hg/mutt/rev/4ade0c9660d5 changeset: 5004:4ade0c9660d5 tag: tip user:Brendan Cully <[EMAIL PROTECTED]> date:Thu Mar 15 16:29:42 2007 -0700 summary: Add reldate.h to BUILT_SOURCES http://dev.mutt.org/hg/mutt/rev/ed804d94676a changeset: 5003:ed804d94676a user:Christoph Berg <[EMAIL PROTECTED]> date:Thu Mar 15 16:10:48 2007 +0100 summary: Remove reldate.h from EXTRADIST to fix out-of-tree builds from tarballs (and http://dev.mutt.org/hg/mutt/rev/3cee06debc98 changeset: 5002:3cee06debc98 user:Christoph Berg <[EMAIL PROTECTED]> date:Thu Mar 15 17:39:46 2007 +0100 summary: Remove absolute paths. http://dev.mutt.org/hg/mutt/rev/eddcca80b7ee changeset: 5001:eddcca80b7ee user:Christoph Berg <[EMAIL PROTECTED]> date:Thu Mar 15 17:21:05 2007 +0100 summary: Pull release date directly from Changelog. http://dev.mutt.org/hg/mutt/rev/e648206c02e2 changeset: 5000:e648206c02e2 user:Brendan Cully <[EMAIL PROTECTED]> date:Thu Mar 15 09:23:47 2007 -0700 summary: Remove .cvsignores http://dev.mutt.org/hg/mutt/rev/836822cc1260 changeset: 4999:836822cc1260 user:Rocco Rutte <[EMAIL PROTECTED]> date:Thu Mar 15 08:48:04 2007 -0700 summary: Document pattern groups in the manual -- Repository URL: http://dev.mutt.org/hg/mutt
