FYI, I'm working on a patch which will consolidate the authentication code into several new files auth.c - common code authlegacy.c - AUTH_CLIENT & AUTH_SERVER code authkrb4.c - HAVE_KERBEROS specific authgssapi.c - HAVE_GSSAPI specific authsasl.c - HAVE_SASL specific There will be *no* authentication code elsewhere - there will either be conditional compilation, e.g., #ifdef HAVE_KERBEROS connect_to_kserver(); #endif or a call through an authentication object, e.g., auth->connect_to_server(); or a combination of both. (The exact nature is TBD.) The protocol specific files will contain both client & server code. This is usually far clearer than putting the bits in separate files, and most files break down into a common pattern: common variables #ifdef ENCRYPTION encryption code - always common to server & client #endif #ifdef SERVER_SUPPORT server code #endif #ifdef CLIENT_SUPPORT client code #endif None of this should be controversial - in fact, it appears to be the common practice in all other projects supporting multiple authentication methods. The authentication object will probably be quite simple: typedef struct { void *private_data; int (*require_encryption) (); int (*require_authentication)(); int (*authenticate_connection)(); int (*connect_to_server)() int (*init)(); int (*client_close)(); int (*server_close)(); } Authentication; require_encryption() - require data encryption. Returns 1 if acceptable, 0 if undefined (e.g., for legacy) or there's a problem. Compare to share_gssapi_encrypt(). require_authenticat() - require strong authentication. Returns 1 if acceptable, 0 if undefined or there's a problem. Compare to share_gssapi_encrypt(). authenticate_connection() - authenticates the connection. Compare to ?server_authenticate_connection(). connect_to_server - connect to server. Compare to connect_to_?server(). There needs be a factory function, of course, and I'm not sure how the Kerberos4 "start_tcp_server()" fits into all of this. However, I have uncovered one oddity which should probably be cleaned up. client.c and server.c duplicate a lot of the low-level functionality, and the code can't be pulled out into a new file because the names differ. This might make sense if a single process could ever act as both client and server, but as far as I know this never occurs. (I know there's a "connect_to_forked_server", but it should be possible to avoid conflicts here as well.) If this is the case, I believe that it makes the most sense to pull out that duplicate code into a new file. The calls would then be largely modularized to { client, server, root } - { net } - { auth } - { legacy, krb4, gssapi, sasl } Information on HAVE_SASL HAVE_SASL will be an additional authentication method using a SASL layer. SASL provides authentication & encryption support via dynamically loaded modules, think "PAM on a wire." With SASL support, it should be possible to support additional authentication methods with little or no effort. Cyrus-SASL (CMU, BSD-style license) already supports Kerberos4 and GSSAPI, plus a number of other methods. Creating a new module to support CVS passwords should be straightforward. SASL also provides hooks for TLS/SSL encryption, and I believe it's possible to act in an "upgrade" mode where the client connects to the server on the standard port, then requests the channel switch to TLS. (Like STARTTLS in SMTP.) While TLS/SSL provides encryption, the primary motivation will be the authentication provided with digital certs. It is easy to use the "mini-CA" in OpenSSL to generate certs suitable for identifying individuals authorized to access or modify the repository. Bear Giles bgiles (at) coyotesong (dot) com _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs