From 1b7e35d0720400f2566023146257c0a3bf89ce87 Mon Sep 17 00:00:00 2001 From: nion Date: Wed, 23 Mar 2005 11:23:10 +0000 Subject: [PATCH] Nico Golde: - updated some names - remove README.SECURITY because it can not be confirmed anymore git-svn-id: svn://svn.berlios.de/mutt-ng/trunk@227 e385b8ad-14ed-0310-8656-cc95a2468c6d --- README | 4 ++-- README.SECURITY | 60 ------------------------------------------------- 2 files changed, 2 insertions(+), 62 deletions(-) delete mode 100644 README.SECURITY diff --git a/README b/README index d025a5b..d747c08 100644 --- a/README +++ b/README @@ -1,7 +1,7 @@ -README for mutt-ng +README for Mutt-ng =================== -If you got the mutt source code from the public SVN repository, please +If you got the Mutt-ng source code from the public SVN repository, please read doc/devel-notes.txt to make sure that you have a complete development environment. diff --git a/README.SECURITY b/README.SECURITY deleted file mode 100644 index 359f44a..0000000 --- a/README.SECURITY +++ /dev/null @@ -1,60 +0,0 @@ -$Id: README.SECURITY,v 3.0 2002/01/24 12:10:47 roessler Exp $ - -Recently, there have been reports on security problems induced by -the interpretation of shell meta-characters embedded in MIME -parameters. These reports were referring to Pine, but the problem -also applied when using mutt. - -More precisely, a mailcap entry like this one would lead to -problems: - -> text/test-mailcap-bug; cat %s; copiousoutput; \ -> test=test "`echo %{charset} | tr '[A-Z]' '[a-z]'`" != iso-8859-1 - -When expanded with a charset parameter of ``touch${IFS}ME``, a file -named "ME" would be created in the current directory. - -While we don't completely agree that this is an actual MUA problem -(see below), we have implemented a couple of fixes for this: - -- Backticks are handled specially when preparing % expandos for - mailcap entries. This fix will keep the current problem from - occuring, but we are sure there are other possible mailcap entries - where this doesn't help. - -- We have added a configuration variable named $mailcap_sanitize, - which is set by default. If set, mutt will restrict possible - characters in mailcap % expandos to a well-defined set of safe - characters. This is the safe setting, but we are not sure it - doesn't break some more advanced MIME stuff. - ->>> DON'T UNSET THIS OPTION UNLESS YOU KNOW WHAT YOU ARE DOING. - - -Anyway, this problem is not necessarily a problem which should be -solved inside the MUA, as it's difficult (maybe impossible) to solve -there. Additionally, there is more than one program which parses -mailcap. So writing secure mailcap statements is generally a good -idea. We encourage you to do this. - -The most basic rule is this one: - ->>> KEEP THE %-EXPANDOS AWAY FROM SHELL QUOTING. - -Don't quote them with single or double quotes. Mutt does this for -you, the right way, as should any other program which interprets -mailcap. Don't put them into backtick expansions - as you have seen -above, this is a recipe for disaster. Be highly careful with eval -statements, and avoid them if possible at all. - -If you have to use the %-expandos' values in context where you need -quoting or backtick expansions, put that value into a shell variable -and reference the shell variable where necessary (possibly with the -proper quoting put around it, like in "$charset"). - -For example, a safe version of the mailcap statement above could -look like this: - -> text/test-mailcap-bug; cat %s; copiousoutput; test=charset=%{charset} \ -> && test "`echo \"$charset\" | tr '[A-Z]' '[a-z]'`" != iso-8859-1 - -- 2.20.1