This document lists some of the known bugs:

* In some of the nastier cases (like indefinite length constructions), the BER
  decoder will use small integer multiples the total size of the object. In the
  usual case of something being a few tens/100s of kilobytes at most, this is
  not a big deal, but reading in a 50 meg BER file could be very costly in some
  cases.

* Several places assume ASCII characters. However as of 1.3.5 this is (or
  should be) contained to charset.cpp; everything else should be character set
  independent. The version as shipped assumes ASCII/Latin-1, and modifications
  would be needed to use it on EBCDIC systems.

* T61 strings are treated like ISO 8859-1 strings, even though this is
  technically incorrect. Since everyone else does this too, it shouldn't be a
  problem.

* Due to compatability issues with RedHat's gcc 2.96 compiler, std::vector
  accesses are done using [] instead of at(). This is generally OK (we are only
  *supposed* to read valid indexes), but at times bugs have caused it so that
  an invalid index is accessed, which is either not noticed until later, or
  causes a SIGSEGV on the spot.

  Other GCC related problems: we can't use std::is* or std::to* because GCC pre
  3.0 (including RedHat's 2.96) barfs on it. And std::string is missing the
  clear() function (this is not a real problem, just an annoyance).

* X509_Time::X509_Time(u64bit) is not thread safe (it uses gmtime).
  Unfortunately we can't really rely on gmtime_r being available. The window
  of contention is minimal (we copy the return value into a buffer allocated on
  the stack) but it is there. If you're very paranoid about this, edit the
  get_tm function in asn1_tm.cpp to use gmtime_r

* There are various low-level threading issues, but mostly in places where a
  threaded program should not be touching things (set_mutex_type, for example).

* There is a nasty little problem with the build system. Namely, because we
  pass -Iinclude, some (most? all?) compilers will look in the include/
  directory before looking in /usr/include, etc. This can cause conflicts, when
  a header in /usr/include #include's something like 'mutex.h', expecting to
  get /usr/include/mutex.h, but instead gets the library's mutex.h.

  Thankfully this only affects building, applications aren't bothered by this
  (since they use the standard include paths). It should be fixed, but I'm not
  a sufficient make wizard to figure out how to do so. It's a really stupid
  problem, considering that our code doesn't even want to see the headers as
  <header.h>; all it wants is <botan/header.h>
