Version 0.6, Jul 11, 1999, Id Est <id-est@home.com>

    - fixed a bug wherein if the home-directory file creation process
      was aborted somehow before the user correctly supplied a password,
      the loop device wouldn't be freed.  closed a couple of open file
      descriptors that were left open past the point they should've
      been closed.

    - modified "login.c" to allow the user to choose the size of his/her
      login directory (4/8/16/32/64/128/256/512/1024 MB).

    - minor error message modification.

Version 0.5, Jun 25, 1999, Id Est <id-est@home.com>

    - modified "login-utils/Makefile" to link in "rmd160.o" to "login"
      whether or not "HAVE_PAM=yes" and/or "USE_TTY_GROUP=yes" are
      defined in the file "MCONFIG".

    - modified "README.ehd" to explain what must be done to compile
      "login" on a system that doesn't use PAM.

Version 0.4, Jun 24, 1999, Id Est <id-est@home.com>

    - added "util-linux-2.9r.tar.gz" and "util-linux-2.9r_ehd.tar.gz"
      to the website.

    - modified README.ehd to reflect a fix for the problem of a user
      not being about to log in because of stale lock files left over
      after a sudden loss of system power.  here is the gist of the
      problem and the solution:

        here's what i found concerning abrupt power-off with an active
        encrypted-home-directory:

        user "test" was logged in with home="/crypt/test" when i powered-down
        the system.  when "test" attempted to login after the system came back
        up, i saw the following:

        login: test
        Password:
        Last login: Thu Jun 24 07:34:47 on tty2
        Need a passphrase to enter your home directory.
        Passphrase:
        No directory /crypt/test!
        Logging in with home="/".
        bash: /crypt/test/.bash_profile: Permission denied
        $

        logging "test" out and re-logging in didn't change anything.

        the problem was that a lock file was left in "/var/lock/login" when the
        system lost power, and was not removed when the system came back up.

        i logged "test" out, removed the stale lock file, and "test" was able
        to successfully log in.  all the files in "test"'s home directory
        appeared to be fine.

        so the solution is to put the following line in "/etc/rc.d/rc.sysinit"
        (or the equivalent on a non-RedHat system) to remove stale lock files
        before the system comes up:

        ...
        /bin/rm -f /var/lock/login/*
        ...

Version 0.3, Jun 22, 1999, Id Est <id-est@home.com>

    - added code to allow user to choose his/her encryption method
      from BLOWFISH, CAST128, DFC, IDEA, MARS, RC6, or SERPENT
      (default: BLOWFISH).

Version 0.2, Jun 19, 1999, Id Est <id-est@home.com>

    - fixed bug wherein if you entered a too-short password three times
      in a row, you were allowed to continue creating the encrypted
      directory anyway.

    - added messages detailing exactly which system error that occurred
      during the encrypted-directory creation process to allow for easier
      debugging.

Version 0.1, Jun 17, 1999, Id Est <id-est@home.com>

    - first public release.