Why we write the code ourselves
We believe paranoia is a virtue, and we strive to be very virtuous. We know you wouldn't send us a source code trojan. But there are bad people. And we know we'd probably catch it. But we make mistakes.
An important side benefit is that there no arguments when we use code in Tiger Business Envelopes.
So think of us as your free development team. You can tell us just where Envelopes needs to be improved, and if we agree most people need it, we'll write the code for you. And you'll get the source.
Whenever you test and do code reviews you're a Tiger Tamer. You'll get credit right along with the developers.
Like the Free Software Foundation and Sun, we ask that if you do write code for Envelopes, you assign the copyright to Tiger.
- Use best-of-breed open source third party software whenever possible
- Time spent evaluating alternatives is always, always, always a fraction of time needed for custom development and maintenance
- Licenses on commercial side of the license firewall (OCE) must allow commercial development by us
- Major components
- Open Crypto Engine
- Pluggable encryption.
- Personal mail server
- MIME encoding
- Web using SSL
- "Safe as money"
- SSL is commonly used to protect financial transactions
- At least as good as paper envelopes
- No http in server; only https
- Allowed IP addresses configured at installation time
- SSL cert double checked through file system
- Why not Swing?
- Trojan risk in (mostly) closed source Swing is significant
- Any closed source is a temptation for spyware
- For years Sun's jdk automatically started the remote debugger on start-up
- Trojan risk is much harder to mitigate than network risk in web interface
- Replacing Swing with open source is a major effort
- Localization for natural languages
- Goal is for UI to largely disappear after installation
- Errors communicated through email, as any other mail server does
- Options portion of installer can be rerun as needed
- First wizard panel is two options
- "Just do it"
- "I'm an expert"
- Get current external SMTP/POP3/IMAP
- Automatically if possible, from client's configuration
- Configure mail client to use Tiger
- Get options and passphrase
- Options for experts
- Security level
- Level defines presets, but options still customizable
- High, Medium, Low
- Plugin selection
- Ideally, no configuration of external encryption packages
- Specify external SMTP/POP3/IMAP servers
- Configure mail client to use Tiger
- If "Require all mail to be encrypted"
- Incoming cleartext politely bounced, with web link to Tiger Envelopes
- Outgoing with no public key available bounced locally
- When To address has no public key
- Only allow locally added keys, or
- Get one from key servers
- Ask every time, or
- Ask for passphrase
- For each encryption plugin used
- If "Remember", encrypt (and hide?) passphrase on disk
- If not delegated to plugins
- Secure CORBA/IIOP
- "Secure" may be too strong a word at first; perhaps "Personal"
- Must be open source
- Features which we may have to add if third party package doesn't have them
- List of allowed IP addresses
- For Tiger Envelopes, only 127.0.0.1
- Optional alternate IIOP port
- IIOP over SSL/TLS
- Opportunistic SMTP over SSL
- Proxy speaks cleartext SMTP on one side, SMTP over SSL (with fallback to cleartext) on the other
- Proxy positions
- At client, to provide SSL to existing SMTP server
- At existing server, to provide SSL to other SMTP servers
- Proxy always tries SSL connection first, then falls back to ordinary SMTP
- If SMTP server at other end supports SSL either natively or through this proxy, the connection is secure
- No change is needed to existing servers
- Opportunistic IPv6 does this better, but isn't yet easy or reliable
- Testing via JUnit
- Extensive logging is essential to debugging
- Only effective way to capture errors at user sites
- No interactive debugger can handle concurrent processes running protocols with timeouts
- log4j is 30,000 lines. We don't want the logger itself to be a potential source of bugs.
- Java 1.4's logging is convoluted and badly designed. "FINE, FINER, FINEST"? C'mon.
- None of this is an issue since we took the seldom justified step of writing our own. Tiger's Log class is less than 300 hundred lines and works very well.
- Extensive exception handling
- Include javadocs in code
- Streaming messages
- If we have multiple threads with messages passed asynchronously we save realtime.
If a subprocess such as encryption takes too long, a protocol e.g. SMTP, can time out. But this is no different from when we lose the connection for some other reason. We have to handle timeouts anyway.
Use the extensive logs. If you're debugging a complex process without a log, it just takes one line to start one.
When you find a bug, the first thing to do is to write a JUnit test for it. Then you'll know when it's fixed, and if it ever comes back.
CORBA.BAD_PARAM usually means a null parameter was sent to a CORBA server, i.e. a plugin.
A CORBA error with "Completed: Maybe" usually means the server went into an infinite loop.
Since uncaught exceptions in a CORBA server such as null references don't make it back though to a CORBA client, it's essential to enclose every public method body of a server in try/catch and log any unexpected exceptions. See com.tigerprivacy.crypto.GPGPlugin.
We are ready to do all the development for Tiger Envelopes and give it away under the GPL. If you do want to contribute more than 10 lines, we ask that you assign the copyright to Tiger. This is standard practice for both the Free Software Foundation and Sun. It makes copyright registration easier, avoids having to go back to all the authors to get permission when the license changes, and lets Tiger defend the copyright, if necessary. A joint copyright assignment is best, so both you and we have full rights to use, modify, and redistribute the work.
Once GPL, always GPL. Neither Tiger nor anyone else can "take back" code once it's been released under the GPL. That's forever. It will always be free.
A comment with multiple exclamation points, "!!!!", indicates code that needs attention
The comment string "//DEBUG" is used in two primary ways
- At the end of a line of code, to indicate code that is only intended for debugging
- At the beginning of a line of code, to indicate code that is only commented out while debugging
Tiger runs several processes for servers, clients, object broker, etc. No interactive debugger handles multiple processes talking to each other with protocol timeouts. Use the logs instead.
There is only one instance of each CORBA server. One GPGPlugin, one PGPPlugin, etc. When clients ask the ORB for an instance, they always get the only one by that name. You should add the synchronized keyword to public method declarations of your Plugin implementations in Java, unless you're absolutely sure that concurrent access to that method is ok. It's ok to add synchronized to the implementation of an abstract method, at least with Jikes.