Parent Directory
| 
Revision Log
| Links to HEAD: | (view) (download) (annotate) |
| Sticky Revision: |
This commit was manufactured by cvs2svn to create tag 'mixmaster_3_0a6'.
Update the nymservers in default dest.alw
Perhaps document --redirect
Add max capability to Type I
Add a FIXME
Documentation of star exclude Minor documentation fixes
Update
Updated HISTORY for Install fixes and *-exclude patch.
We've changed the client defaults to send messages immediately, rather than pool messages. Also, I've removed some automatically generated files, which never should have been in CVS in the first place.
Updated TODO again. (That bug leaving stale t* pool files is still alive.)
Updated todo list.
The protocol will not change for 3.0.
Update TODO
Updated to reflect recent changes.
Added feature request -- Borland compiler compatability.
Update of TODO after Disastry's commits
Add cvs2cl to TODO list
Updated documentation for {IN,OUT}DUMMYP, and to reflect changes in
remailer defaults.
Mixmaster now has a sanity-check on the number of dummy messages
generated automatically.
Fixed typos in mix.1 and Install.
Install now prompts before using a previously generated Makefile.
Allow setting dummy parameters
We now generate dummy messages as mail enters and exits the pool.
We now delete t* and e* files along with p* at PACKETEXP time.
added a few bugs.
Mixmaster keys now have creation and expiration date. It is not secured by any crypto voodoo, it's only informational for clients to decide which keys to use should they have more. - on the client side we do not show remailers (and therefore not use them) if their key is expired. - the remailer refuses to decrypt messages to keys that expired one month ago or earlier. - the remailer automatically creates new mixmaster keys if the current one are about to expire or already are expired. - the latest key from secring.mix is written to key.txt. It used to be the first one. Since creation of new mix key appends the key, this seemed sensible.
what needs to be done for this key expire thing to really work
I've added some more items to the todo list based on user suggestions.
When creating new OpenPGP keys, also set an expiry date. Key lifetime defaults to 8 months but can be overriden by the KEYLIFETIME configuration option. We currently do not store the self signature and the keybinding (which hold the expiry information in DSA keys) in the secret keyring. This is unfortunate because we use the current KEYLIFETIME when recreating them should the public keyring need to be rewritten. The solution is to store them in the secret keyring (like GnuPG does) and not recreate them later if we already have them.
Also list cypherpunk remailers in remailer-conf reply. Thanks to Ulf and Disastry for their help.
update TODO
When sending type II messages interactivly you may now choose a middleman remailer as the last hop in your chain (closes: #481244).
mbox/Maildir mail input is done
Re-introduced the todo list with Reality. Basically, if the install process is made friendly and saner, and we've done real testing on the major platforms, I'm not too interested in holding up 3.0 any longer. Everything else can be done in the point release. Should we: * leave AES support #ifdef'd out if OpenSSL 0.9.7 isn't released? * support AES if the installed version of OpenSSL is 0.9.7beta3 or greater? * include the necessary AES source from OpenSSL, as per the original patch? I'm leaning toward option two, though we should still display the "this version of OpenSSL is untested" message for 0.9.7. FWIW, 0.9.7beta3 has been working fine for me on randseed.
Currently, if Mixmaster is encrypting mail to multiple recipients, it does not honor key preferences, and defaults to 3DES with no MDC. It should choose the "most prefered" settings between the recipients, only using 3DES/MDC if no other choice is available. (We'll have to make some reasonable tie-breaking decisions, too -- for instance, if one key lists AES,CAST and another lists CAST,AES -- which do we take? I think we should have an internal "preference order" that is used in these cases. I propose AES128,AES256,AES192,CAST5,3DES,IDEA,BLOW). We'll want to use the MDC feature in all possible cases. Fixing this is most important -- I'd be okay with using 3DES whenever we have multiple recipients, as long as we could use MDC if they each advertised either support for it in the features flag, or support for ciphers 7,8,9, or 10 (even though we don't support 10). Hmm. Something else to check -- PGP 7.x can decrypt MDC when used with 3DES, right?
Document --store-mail
Spelling fix
Added a few more TODO items.
Some Items
Reacquainted the TODO list with reality.
Initial revision
This form allows you to request diffs between any two revisions of this file. For each of the two "sides" of the diff, enter a numeric revision.
| ViewVC Help | |
| Powered by ViewVC 1.1.5 |