svn rev #24381: branches/nss/

[ghudson@MIT.EDU]

http://src.mit.edu/fisheye/changelog/krb5/?cs=24381
Commit By: ghudson
Log Message:
Remove an NSS branch issue which has been dealt with.



Changed Files:
U   branches/nss/README.BRANCH
Modified: branches/nss/README.BRANCH
===================================================================
--- branches/nss/README.BRANCH	2010-09-29 21:52:57 UTC (rev 24380)
+++ branches/nss/README.BRANCH	2010-09-29 21:53:28 UTC (rev 24381)
@@ -5,44 +5,17 @@
 Identified issues with this branch include, in roughly decreasing
 order of priority:
 
-* The copyright and license statements on new code are problematic.
+* If NSS is used before a fork, the child cannot make use of NSS
+  without performing a successful shutdown, which can't happen if
+  there are any outstanding NSS objects.  This is an ongoing area of
+  discussion.
 
-* k5_nss_init fails on Ubuntu.  More generally, it makes the
-  assumption that the NSS library should be initialized with
-  "sql:/etc/pki/nssdb" on Linux platforms, which is apparently not a
-  universal convention, and with no DB on other platforms.
+* Cached handles in krb5_key objects must be wrapped in a structure
+  which remembers the current pid, so that they won't be used after a
+  fork.
 
-* If k5_nss_init fails, the Yarrow code crashes out with a seg fault
-  during library initialization.  This is because the Yarrow interface
-  to the SHA1 hash implementation has no error path (because there are
-  no failure cases in a direct implementation, assuming well-formed
-  input).  The upshot is that HASH_Init() fails silently without
-  initializing the context length field, and HASH_Final() passes the
-  uninitialized length field as an argument to memcpy().
+* The copyright and license statements on new code are problematic.
 
-* k5_nss_gen_stream_iov sets state->length to -1 to protect against
-  copying of the state structure by the caller, on the assumption that
-  an app trying to copy the state will gracefully fail to allocate
-  (unsigned int)-1 bytes of memory.  This is an invalid assumption;
-  64-bit platforms can often allocate that much memory.  A better
-  approach is to use a loopback pointer to detect copying, as in
-  lib/crypto/openssl/enc_provider/rc4.c.
-
-* There are several ifdefs which are not documented or supported in
-  configure:
-
-  - NSS_LOOKUP_STRING in hmac.c: This code appears to be
-    non-functional.
-
-  - USE_OPAQUE_KEYS in enc_gen.c (defined by default)
-
-  - FAKE_FIPS in enc_gen.c
-
-  - DO_FAST_XOR in enc_gen.c (defined by default); the affected code
-    should probably be factored out with xorblock() from various
-    places in the built-in back end, into an inline function in a
-    utility header file somewhere.
-
 * The code could perhaps benefit from organizational simplification,
   such as eliminating the many small files for enc and hash providers
   (since all of their logic is in enc_gen.c and hash_gen.c anyway).