DragonFly users List (threaded) for 2007-03
Re: To be a new DFly commiter
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.
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).
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.