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