Initial Windows agent repository

OGP64/usr/share/doc/libxcrypt/TODO

@@ -0,0 +1,100 @@
+to-do list for libxcrypt
+------------------------
+
+This list is categorized but not in any kind of priority order.
+It was last updated 20 October 2018.
+
+* Code cleanliness
+  * Find and remove any code that still does dodgy things with type punning
+  * Factor out all of the repetitive base64 code
+  * Factor out the multiple implementations of HMAC and PBKDF
+
+* Testsuite improvements
+  * Investigate branch coverage
+  * Do some API fuzz testing and add missing cases to the testsuite
+  * Many of the `test-crypt-*.c` files repeat more or less the same
+    code with different data, consider merging them
+
+* Portability
+  * Make sure the symbol versioning macros work with all of the
+    compilers that anyone needs (they use GCC extensions that clang
+    also supports).
+
+* Hardening
+  * bcrypt-like selftest/memory scribble for all hashing methods
+    * how do we know the memory scribble is doing its job?
+  * build out of the box with compiler hardening features turned on
+  * something bespoke for not having to write serialization and
+    deserialization logic for hash strings by hand, as this is
+    probably the most error-prone part of writing a hashing method
+
+  * the most sensitive piece of data handled by this library is a
+    cleartext passphrase.  OS may have trusted-path facilities for
+    prompting the user for a passphrase and feeding it to a KDF
+    without its ever being accessible in normal memory.  investigate
+    whether we can use these.
+
+* Additional hashing methods
+  * Argon2 <https://password-hashing.net/>
+  * ...?
+
+* Runtime configurability (in progress on the [crypt.conf branch][])
+  * allow installations to enable or disable specific hash methods
+    without rebuilding the library
+  * make the default cost parameter used by `crypt_gensalt_*` for new
+    hashes configurable
+  * update the compiled-in defaults used by `crypt_gensalt_*` (not the
+    defaults used when no explicit cost parameter is present in a
+    hash; those can’t be changed without breaking existing stored hashes)
+    * relevant benchmarking at
+      <https://pthree.org/2016/06/28/lets-talk-password-hashing/>
+  * offer a way to tune cost parameters for a specific installation
+  * N.B. Solaris 11 has all of these features but our implementation will
+    probably not match them (they have a `crypt.conf` but it’s not the
+    same, and their `crypt_gensalt` is API-incompatible anyway).
+
+[crypt.conf branch]: https://github.com/besser82/libxcrypt/tree/zack/crypt.conf
+
+* Potential API enhancements:
+
+  * Support for "pepper" (an additional piece of information, _not_
+    stored in the password file, that you need to check a password)
+
+  * Reading passphrases from the terminal is finicky and there are
+    several competing, poorly portable, questionably sound library
+    functions to do it (`getpass`, `readpassphrase`, etc) -- should we
+    incorporate one?
+    * If we do, should it know how to trigger the trusted-path
+      password prompt in modern GUI environments? (probably)
+
+  * Make the crypt and crypt_gensalt static state thread-specific?
+    * Solaris 11 may have done this (its `crypt(3)` manpage describes
+      it as MT-Safe and I don’t see any other way they could have
+      accomplished that).
+    * if allocated on first use, this would also shave 32kB of
+      data segment off the shared library
+    * alternatively, add a global lock and *crash the program* if we
+      detect concurrent calls
+
+  * Allow access to more of yescrypt’s tunable parameters and ROM
+    feature, in a way that’s generic enough that we could also use it
+    for e.g. Argon2’s tunable parameters
+
+  * Other yescrypt-inspired features relevant to using this library to
+    back a “dedicated authentication service,” e.g. preallocation of
+    large blocks of scratch memory
+    * the main obstacles here are that `struct crypt_data` has a fixed
+      size which is either too big or too small depending how you look
+      at it, and no destructor function
+
+* Permissive relicensing, to encourage use beyond the GNU ecosystem?
+  * Replace crypt-md5.c with original md5crypt from FreeBSD?
+  * Other files subject to the (L)GPL are crypt.c, crypt-static.c,
+    crypt-gensalt-static.c, crypt-obsolete.h, crypt-port.h,
+    test-badsalt.c.  It is not clear to me how much material originally
+    assigned to the FSF remains in these files.
+    Several of them are API definitions and trivial wrappers that
+    could not be meaningfully changed without breaking them (so are
+    arguably uncopyrightable).
+  * Most of the test suite lacks any license or even authorship
+    information.  We would have to track down the original authors.