Parent Directory
| 
Revision Log
| Links to HEAD: | (view) (download) (annotate) |
| Sticky Revision: |
Add a TODO item - Allow Mixmater to run on Win32 without creating directories. Proposed by Christian Danner.
For real this time.
3.0
Updated TODO.
Remove 3.0.x TODO items; it's too late now. Review and move valid ones to 3.1.x TODO.
Add a TODO item for 3.0.x for rab.hash handling.
Added TODO items for win32 crashes
Change windows file extensions to .ini for config files, for editor purposes. Update documentation to warn users about this. Adjust TODO file and HISTORY.
Added a note about fetching fresh stats. Looks like some of these TODO items are already done -- we should clean up that list.
Update TODO, remove stats stuff which is done
Documentation cleanup.
Remove completed mpgp item
remove completed item (ignore type2.list)
remove completed stats items
Merge stats stuff from branch into trunk
Todo: ignore type2.list
TODO: how do we handle randomness on win32?
Add a few todo items
Fixed the Slackware issue. The OpenSSL version check stuff does more harm than good -- we should remove it.
Be more verbose on the stats TODO item. claim windows build/install item
Updated to reflect recent commits, and new issues.
Updated the list.
Mention testing whitespace fix.
Change TODO priorities.
And remove this issue from the TODO list
Fall back to 3DES as Encrypt-Key cipher if we don't have IDEA.
Check if there's a bug with chain and semicolon
Add to TODO: Fall back to 3DES as Encrypt-Key cipher if we don't have IDEA.
Rev version to 3.0b1.
Remove finished items from TODO
Housecleaning for the 3.0b1 release. The timestamp issues are documented in HISTORY, so remove them from the TODO list. Merge all of the 3.0a comments into 3.0b1. Update README (needs another pass.) There should be no more releases from the 2.9 branch except possibly security updates adter 3.0b1 is released.
Removed AC experiment, restored the beast that is Install.
Updated some documentation for key rotation features.
--redirect documentation is already done, we do not want a CVS changelog in the release tarball
Assign one autoconf bug to Dybbuk
document --redirect
auto* needs to be updated, now that we have removed pcre and zlib from Src
The manpage was updated to no longer refer to obsolete nym functionality in revision 603
Drop messages without timestamps and messages with future timestamps.
Rework TODO
Update list of nymservers by Hauke
nym support ifdef'ed out
parse_yearmonthday is ok on Linux, Solaris, FreeBSD and NetBSD, so I assume it is ok
Assign tasks so we finally get 3.0 done
The 'working on the train' commit: Don't try to send a message if there are no recipients left. Set default max-randhops from 20 to 4. Remix-To chain is limited by max-randhops limit as well. Messages to more than one remailer are dropped.
Update todo
disable nym stuff
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 |