In future, bugs should migrate to the SourceForge tracker:

https://sourceforge.net/tracker/?func=browse&group_id=233013&atid=1088569

Switzerland probably contains many bugs.  Here are some important ones:

Usability:

 - Control-c mightn't always exit the application properly (this is a thread
   management issue, and has been largely but maybe not entirely fixed).

Security against network adversaries:

 - We don't use SSL yet.

 - Switzerland doesn't send HMAC keys to Alice and Bob yet.

 - Until we do both of the above, adversaries who could be bothered could find
   a way to modify packets such that the hash fragments matched anyway, so
   Switzerland wouldn't notice.

Other security issues:

 - It is possible for the switzerland client to quit in such a way that it does
   not shred & delete the temporary file used for packet capture.  This would
   leave copies of raw captured packets on the system's hard disk.  (On unusual
   copy-on-write or versioning filesystems, this might be the case even if we
   call shred.  We won't fix that.)  [MOSTLY FIXED, but we should probably
   catch a few signals and handle those.]

Semantics:

 - The firewall penetration code needs to know about transport layer protocols.
   It currently works for TCP, UDP, SCTP and port-less protocols, but not for
   some other protocols like RDP.  Fixes should go in Packet.py!

 - If a network modifies a flow from the very first packet, we currently won't
   realise that we're seeing both ends of the flow.  This is because the "flow
   matchmakers" in Switzerland.py are currently (src_ip, dst_ip,
   hash_of_opening_packet_with_some_fields_masked).  Those criteria are good
   for penetrating firewalls, but if we have a very weird NAT or network that
   changes a field we wouldn't dream of masking (like the IP DO_NOT_FRAGMENT
   flag, which we've seen modified by Netgear MR814v2 wireless routers, for
   instance), we won't handle it well.  We now tell the user when this occurs,
   but we should really try some other matchmaking strategies in cases where
   the existing algorithm isn't working.

 - We need to be more consistent in our responses to crazy NATs.

Performance:

 - The current matchmaking and reconciliation algorithms are designed to work
   well for large flows.  Large numbers of tiny flows, such as those seen
   during port scans, have not been optimized at all.  We don't know how many
   simultaneous port scans the current client and server can handle.
 
 - FastCollector / PacketListener currently exchange packets through an mmap'd
   array.  Alternative implementations are possible, and will store more
   packets per byte of RAM than we currently do (currently, small packets take
   up as much space as large packets).

