2 * client library uses as much krb5 as possible to talk to krb4
3 server, converting tickets and whatnot. This will be mostly
4 ripped out, but serves as a proof of concept. Client will
5 successfully receive new-style checksums, but this code won't be
8 Milestone 2 (written, not tested)
9 * server will accept new-style checksums and authenticators, as
10 well as old-style. It will never send them, and "bad things"
11 will happen if non-DES enctypes get used.
12 * Note that this will allow krb5 interrealm clients, and there
13 are no brain-dump issues to deal with. This is aesthetically
17 * client sends only new-style messages
20 * server sends only newstyle messages, and can't brain dump the
21 new keys. (this tests the codepath opened in milestone 1)
24 * server can send new or old-style messages depending on how the
26 * server can brain dump newstyle keys, and figure out whether
27 the rest of the federation speaks them.
30 * zhm can figure out what sort of realm it's talking to, and
31 communicate this to the client.
36 * brain dump via krb5, encrypted
39 * bring sourceforge up to date
42 * cough up a release of sourceforge