DragonFly users List (threaded) for 2007-03
Re: To be a new DFly commiter
Dnia 16-03-2007, Pt o godzinie 18:58 -0700, Matthew Dillon napisał(a):
> 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.
Brute-force algoritm with collision can take password 100 time faster
than brute-force without brute-force.
Atacker not must stole password file, attack can be made from local
We can don't change password_format and still use md5,
but we can change it to blowfish, maybe this is not a big issue,
but for fix it, we must change only one record in /etc/login.conf.
This is very trivial.
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.
> Domena za 90 groszy!
Serwery za 1 zł!