Custom Query (26051 matches)


Show under each result:

Results (1 - 3 of 26051)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#2 Fixed Key rotation crashes server (sample) nickm weasel

[Moved from bugzilla] Description: Opened: 2003-05-29 08:26

(This is a sample bug so I can get used to using the tracker, and see whether bugs get assigned to me properly.)

When key rotation happens (at midnight GMT), the server goes into an infinite loop, exhausts its fds, then dies.

The bug seemed to be that we'd reschedule the next key generation before the current one was complete. Obviously, before the keygen is done, the server will think that a new keygen needs to happen immediately. (ick!) I think I squashed this, but it's hard to be sure. I'll know at midnight GMT tomorrow.

None of my servers died at midnight; I think we're ok.

[Automatically added by flyspray2trac: Operating System: Linux]

#3 Fixed changing PublicKeyLifetime to smaller values isn't good nickm weasel

[Moved from bugzilla] Description: Opened: 2003-05-30 16:12

I had the default PublicKeyLifetime of 3 months and already had generated keys.

Now I wanted to set it to a lower value (1 month or 1 week) but when I start

the server I get the following:

Reading configuration from /home/minion/etc/mixminiond.conf May 30 16:11:33.651 [DEBUG] Configuring server May 30 16:11:33.651 [INFO] Starting server in the background May 30 16:11:33.657 [INFO] Enabling statistics logging May 30 16:11:33.659 [WARN] Directory /home is writable by group staff (mode 775) May 30 16:11:33.661 [DEBUG] Syncing statistics to disk May 30 16:11:33.662 [INFO] Statistics logging enabled May 30 16:11:33.663 [INFO] Setting entropy source to '/dev/urandom' May 30 16:11:33.665 [DEBUG] Initializing server May 30 16:11:33.666 [DEBUG] Scanning server keystore at /home/minion/miniond/keys May 30 16:11:33.671 [TRACE] Found key key_0001 (valid from 2003/05/30 to 2003/08/28) May 30 16:11:33.671 [DEBUG] Found 1 keys. May 30 16:11:33.672 [INFO] Last expiry at 2003/08/28 02:00:00; next keygen at 2003/08/11 13:00:00 May 30 16:11:33.673 [ERROR] Some generated keysets do not match current configuration... May 30 16:11:33.673 [ERROR] Keyset 0001 (2003/05/30 02:00:00--2003/08/28 02:00:00): May 30 16:11:33.674 [WARN] Published lifetime does not match PublicKeyLifetime May 30 16:11:33.675 [WARN] (This problem will go away in a while). May 30 16:11:33.678 [INFO] Regenerating descriptor for keyset 0001 (2003/05/30 02:00:00--2003/08/28 02:00:00) May 30 16:11:33.733 [DEBUG] Disabling module MBOX May 30 16:11:33.734 [INFO] Module DROP: enabled for types 0x0? May 30 16:11:33.734 [DEBUG] Disabling module SMTP May 30 16:11:33.735 [DEBUG] Disabling module SMTP_MIX2 May 30 16:11:33.765 [FATAL] Exception while configuring server May 30 16:11:33.771 [FATAL] Traceback (most recent call last):


"/home/minion/lib/python2.2/site-packages/mixminion/server/", line 1045, in runServer

server = MixminionServer(config) File

"/home/minion/lib/python2.2/site-packages/mixminion/server/", line 648, in init

self.keyring.checkDescriptorConsistency() File

"/home/minion/lib/python2.2/site-packages/mixminion/server/", line 172, in checkDescriptorConsistency

ks.regenerateServerDescriptor(self.config, identity) File

"/home/minion/lib/python2.2/site-packages/mixminion/server/", line 621, in regenerateServerDescriptor

useServerKeys=1) File

"/home/minion/lib/python2.2/site-packages/mixminion/server/", line 960, in generateServerDescriptorAndKeys

assert ok


May 30 16:11:33.771 [FATAL] Shutting down because of exception: exceptions.AssertionError

The crash is a shallow logic error: the code double-checks that any new descriptors it generates must produce no consistency errors. I'm going to make an exception for public key lifetime, because (as the warning notes) we don't automaticly propagate those changes.

Why not? Because pmce a descriptor is published, we want the set of keys to remain valid for as long as promised, so that reply blocks will continue to work. When you set a new publicKeyLifetime, it applies to _new_ keys, not to existing ones.

If you really want to go to a shorter lifetime, stop your server, edit PublicKeyLifetime, run 'mixminion server-DELKEYS', and restart the server.

That a change of PublicKeyLifetime only affects new keys is probably The Right Thing. So for current keys the lifetime should stay the same and mixminion should start as usual.

Okay, the fix in CVS should solve it.

[Automatically added by flyspray2trac: Operating System: Linux]

#4 Fixed Incorrect node routing with mbox nickm weasel

[Moved from bugzilla] Reporter: colin@… (Colin Tuckley) Description: Opened: 2003-06-23 20:44

sending a message using:

mixminion send -t mbox:fred@cside -P sushi,cside

results in the Selected path being sushi:cside,cside

which is not sensible.

I'm deferring a fix for this bug until 0.0.6. It's not a showstopper, and I need to rework the path selection logic pretty heavily in 0.0.6 anyway.

Fixed in 0.0.6 CVS. If you specify the same last hop in your path and in an exit address, it now counts only once.

[Automatically added by flyspray2trac: Operating System: Linux]

1 2 3 4 5 6 7 8 9 10 11
Note: See TracQuery for help on using queries.