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

diff --git a/README b/README
index d025a5b..d747c08 100644 (file)
--- 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 (file)
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
-