Re: To be a new DFly commiter

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    Well, hmm.  Kinda out of the blue, and I don't want to discourage anyone
    who is this enthusiastic, but I have a few buts of my own.


1.
a) chg default password_format do blowfish since there are known
algoritm of collision for md5.

    I don't think this is a big issue.  When I was doing BEST Internet we
    had a number of incidents where the master.passwd file on a user
    machine would get stolen.  Even though only root can read it there
    were numerous holes in programs that at least allowed unauthorized
    read access to root-only files.  This occured several times throughout
    BEST's history and we had to ask people to change their passwords on
    the effected machines.

    The person would then run a cracker on the file off-line.  Crackers
    tended to simply guess passwords, though, not actually try to decrypt
    or fake them.  I do not think the MD5 collision issue is really
    pertainant to the main problem.

    Also, who actually uses passwords in the password file any more these
    days?  I don't know about all of you, but I do not run any services
    where REMOTE access to the machine is granted via a standard password.
    It is ssh or nothing.

b) add support for openwall passwdqc (password checker) pam module (this
was added to FreeBSD 5.0)

    

c) add support for openwall tcb - the alternative to shadow (with pam
module) which is more secure than pam_unix and pam_pwdb, because tools
like 'passwd' or 'chage' don't neet SUID, instead it use SGID 'shadow'.
Group 'auth' may be used to read-only access to all password hashes.

    I don't like the idea of changing the password file mechanics, and
    especially do not like the idea of storing anything in the user's home
    directory.  In my considered opinion, not even the user should have
    any access to the encrypted form of his password (and I think this
    is one of the deficiencies of the .ssh/authorized_keys file 
    mechanism that SSH uses).

2.
a) Replace sendmail with postfix (with cyrus-sasl). It is faster and use
cleaner config file.

    I personally believe that postfix is superior.  I personally do not
    mind running GPL'd code.  But I also would prefer to have as little
    GPL'd code in our managed code base as possible.

    What does this mean?  I would dearly like to integrate portions of
    pkgsrc managed packages into our buildworld and installworld 
    system, that is have the buildworld create a little package building
    jail and build and install selected packages, with appropriate defaults,
    as part of the base system build.  Then we would not have to import or
    maintain the sources for at least the larger integrated pieces (such
    as sendmail/postfix, bind, etc).

b) Add imap-uw as simple pop3 and imap4 daemon.

    I'd prefer this be maintained via pkgsrc.

c) Add stunnel for SSL/TLS access to mail-related daemon.

    I don't have much background knowledge on stunnel.  It sounds like
    another thing that should be maintained via pkgsrc.

3. Build alternative to pkgsrc packages system, which will be build on
pacman from archlinux.org, and use tweaked PKGBUILD scripts.
This packages system should be easier to maintain, and we will keep
track on all our packages.
For faster port packages to DFly, we can use makepkg with PKGBUILD
(which is a shell script) or we can rewrite this scripts to Makefiles
which will stop building package on error.
I will rewrite pacman tool which will be use this same archive format,
but for library to reading archives I'll use libarchive,
and for fetching packages from net I'll use libfetch.
I need name for this tool, because this should be different than pacman.

    I don't think a single person would be able to maintain an
    alternative.  Simply keeping up to date with all the new versions
    of various things that occur every day would be difficult.

						-Matt