bugs.txt

含有多种公开密钥算法、多种块加密、多种数据流加密、多种HASH函数、多种CheckSum校验、多种MAC校验等几十种加密算法的程序

This document lists serious known bugs:

* The Hardware_Timer classes (currently just RDTSC on x86 but there are similar
  instructions on other systems that will be supported eventually) have a
  problem. On most or all of the CPUs supporting such instructions, it's
  possible to make them inaccessible to user-space. In this case, we will
  receive SIGILL (on Unix) or probably some other fatal exception on other
  systems.

  It's possible to work around this by catching SIGILL, etc, but it's a really
  awful solution all around (not portable to boot).

  Stupid CPU designers. It should just zero the register if the instruction
  isn't accessible.

* Several places assume ASCII characters. Particularly, we assume certain
  values for the character codes of 'A'-'Z', 'a'-'z', '0'-'9', '+', and
  '/'. Most of these are only for Base64 encoding/decoding, but '0'-'9', in
  particular, is somewhat more entrenched. For major culprits, look in hex.cpp,
  base64.cpp, and enc_tab.cpp.

  On a related note, big_code.cpp:decode assumes that the characters '0'
  through '9' have contiguous and increasing values, but does not assume any
  particular value. The functions to_string and to_u32bit (in util.cpp) also
  have this property. They are less of a big deal, because at some point I'll
  change them to use string streams.

  I really don't know what to do about this, if anything. If anyone out there
  is still actually using an EBCDIC machine and would like to help port Botan
  to MVS or OS/400 or something, send me an email. Otherwise, I doubt I'll ever
  worry about it. I don't like that it's dependent on the character set, but at
  the same time, virtually nobody uses a character set that isn't "like" ASCII,
  at least from this limited view.

  Another nasty thing is that while the encoders will encode into the native
  character set, the decoders will not; they will only accept ASCII chars.
  This can mostly be prevented by generating these tables at run time. Then,
  the encoders and decoders will accept native character set, but not others.

* There is a nasty little problem with the build system. Namely, because we
  pass -Iinclude, some (most?) 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
  (is this correct?). 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>

  The first thought is obviously to simply move include/*.h to include/botan.
  Unfortunately, this breaks when we want to patch a header, as the pipe_unixfd
  module does.