-Security checks
----------------
-
-### Security history
-
-The only past security issues I could find in GNU gettext and po4a
-are:
-
-- [CVE-2004-0966](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0966),
- *i.e.* [Debian bug #278283](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278283):
- the autopoint and gettextize scripts in the GNU gettext package
- 1.14 and later versions, as used in Trustix Secure Linux 1.5
- through 2.1 and other operating systems, allows local users to
- overwrite files via a symlink attack on temporary files.
-- [CVE-2007-4462](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4462):
- `lib/Locale/Po4a/Po.pm` in po4a before 0.32 allows local users to
- overwrite arbitrary files via a symlink attack on the
- gettextization.failed.po temporary file.
-
-**FIXME**: check whether this plugin would have been a possible attack
-vector to exploit these vulnerabilities.
-
-Depending on my mood, the lack of found security issues can either
-indicate that there are none, or reveal that no-one ever bothered to
-find (and publish) them.
-
-### PO file features
-
-Can any sort of directives be put in po files that will cause mischief
-(ie, include other files, run commands, crash gettext, whatever)?
-
-> No [documented](http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files)
-> directive is supposed to do so.
-
-### Running po4a on untrusted content
-
-Are there any security issues on running po4a on untrusted content?
-
-> To say the least, this issue is not well covered, at least publicly:
->
-> - the documentation does not talk about it;
-> - grep'ing the source code for `security` or `trust` gives no answer.
->
-> I'll ask their opinion to the po4a maintainers.
->
-> I'm not in a position to audit the code, but I had a look anyway:
->
-> - no use of `system()`, `exec()` or backticks in `Locale::Po4a`; are
-> there any other way to run external programs in Perl?
-> - a symlink attack vulnerability was already discovered, so I "hope"
-> the code has been checked to find some more already
-> - the po4a parts we are using themselves use the following Perl
-> modules: `DynaLoader`, `Encode`, `Encode::Guess`,
-> `Text::WrapI18N`, `Locale::gettext` (`bindtextdomain`,
-> `textdomain`, `gettext`, `dgettext`)
->
-> --[[intrigeri]]
-
-### Fuzzing input
-
-I was not able to find any public information about gettext or po4a
-having been tested with a fuzzing program, such as `zzuf` or `fusil`.
-Moreover, some gettext parsers seem to be quite
-[easy to crash](http://fusil.hachoir.org/trac/browser/trunk/fuzzers/fusil-gettext),
-so it might be useful to bang gettext/po4a's heads against such
-a program in order to easily detect some of the most obvious DoS.
-[[--intrigeri]]
-
-gettext/po4a rough corners
---------------------------
-
-- fix infinite loop when synchronizing two ikiwiki (when checkouts
- live in different directories): say bla.fr.po has been updated in
- repo2; pulling repo2 from repo1 seems to trigger a PO update, that
- changes bla.fr.po in repo1; then pushing repo1 to repo2 triggers
- a PO update, that changes bla.fr.po in repo2; etc.; quickly fixed in
- `629968fc89bced6727981c0a1138072631751fee`, by disabling references
- in Pot files. Using `Locale::Po4a::write_if_needed` might be
- a cleaner solution.
-- new translations created in the web interface must get proper
- charset/encoding gettext metadata, else the next automatic PO update
- removes any non-ascii chars; possible solution: put such metadata
- into the Pot file, and let it propagate; should be fixed in
- `773de05a7a1ee68d2bed173367cf5e716884945a`, time will tell.
-
-Misc. improvements
-------------------