Re: To be a new DFly commiter

[Grzegorz Błach <grzela@xxxxxxxxxxxxx>]

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.
> 
> 
> 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.
> 

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
network too.
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).
> 
> 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
> 
> ____________________________________________________________________________
> Domena za 90 groszy! 
> www.nazwa.pl


____________________________________________________________________________
Serwery za 1 zł! 
www.nazwa.pl