Re: Re: To be a new DFly commiter

[grzela@xxxxxxxxxxxxx]

On Fri, 16 Mar 2007 19:43:27 +0100, "Simon 'corecode' Schubert" wrote:

> Hey Grzegorz,
> 
> first of all, welcome to DragonFly!
> 
> Grzegorz Błach wrote:
> > I use DragonFly about 2 year,
> > currently I am ready to submit my tweaks and extensions to DFly system.
> 
> Now for this list.  We always should consider the positive and negative
> effects
> of change.  I don't want to sound negative, so take everything with a grain of
> salt.
> 
> > 1.
> > a) chg default password_format do blowfish since there are known
> > algoritm of collision for md5.
> 
> I guess that's not much of a problem and possibly also does no harm.  However,
> I
> doubt that the collisions can be exploited.
> 
> > b) add support for openwall passwdqc (password checker) pam module (this
> > was added to FreeBSD 5.0)
> 
> is that some kind of cracklib?  unrelated to this, i've always wanted some
> sort
> of generic password generator in base...
>

I never use cracklib.
Passwdqc is a password generator and checker
(even root must use secure password instead this is in many linux distros),
and is a part of security enhanced systems like openbsd, openwall, alt linux,
and additionaly is in debian, SUSE, and very recent version of redhat.
 
> > 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 am not convinced that this improves security.  Could you please detail your
> security considerations?  My point is:  current tools have been exposed to
> security audit for over 20 years now, so unless something else is conceptually
> more secure, chances are high that we should stick with the original system.
>

I made a mistake in this point,
SGID shadow can only read users list (can not read/write passwords).
SGID auth can read passwords, but can not write it.
Every user have its own shadow file whitch is owned by this user.
Write to user's shadow file can only this user or root.
There is not required SUID root for passwd and related tools.
For more you can read on http://openwall.com/tcb/.

> > 2.
> > a) Replace sendmail with postfix (with cyrus-sasl). It is faster and use
> > cleaner config file.
> 
> We have support by Greg Shaprio, a sendmail developer.  Unless postfix is
> equally well supported, I object replacing it.  I am using postfix on all my
> systems myself, however.  Pkgsrc can do an equally good job in fixing bugs
> etc.
> 
> However, I would like to see a simple mail transport as complete replacement
> for
> sendmail.  I have a concept in mind, but I didn't have enough time and muse to
> do it.
> 
> Please refer to the archives for multiple sendmail vs postfix bikesheds.
> 
> > b) Add imap-uw as simple pop3 and imap4 daemon.
> 
> I don't think this should be part of a BSD base distribution.  Packages like
> these are easily installed by pkgsrc and on top of that are for sure subject
> of
> holy flamewars.
> 
> > c) Add stunnel for SSL/TLS access to mail-related daemon.
>
> In principle I would love to have some tool where I can spy into SSL/TLS
> connections (when they are being established).   Not sure why you'd want to
> use
> stunnel, though.
> 

Ok stunnel is not necessary, I forgot that imap-uw support SSL/TLS natively.
 
> > 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.
> 
> This is a very ambitious effort and I hope that somebody will join you.  Yet
> you
> have to be aware of the fact that DragonFly is supported very well through
> pkgsrc, and this kind of coverage needs to be reached.  You will have to get
> used to the thought that for quite some time you will have to maintain your
> system in parallel to convince people that it is possible and better than
> pkgsrc.
> 

I don't like pkgsrc because this limitations:
1. Many packages in pkgsrc are obsolete, and there are no development version of almost all packages (i wan't to see new version of dbmail, xorg and enlightenment 0.17 in packages system).
2. Many packages in pkgsrc are configured with '--without-threading' option, because not all systems which pkgsrc work on support threading. I want omit this limitation.
3. Binary upgrade packages with pkg_add -u is difficult. Eg. it is possible to upgrade only selected packages. Pacman can upgrade selected packages and also whole installed packages.
I think we should have tool to binary upgrade base system also.

> > I hope I'll got write access to CVS for complete this steps.
> 
> I think most of the changes are either simple enough to be submitted via mail
> first and the other ideas should be discussed thoroughly first.  As soon as
> the
> flood of (good) patches from you becomes a pain for the committers, you will
> get
> the opportunity to directly commit.  In the meantime, you might want to
> consider
> setting up and serving an alternative git or hg repository (better development
> model in my opinion anyways).  Contact me for details on hg and git feeds.
> 

As revision control system currently I use Gnu arch,
currently Tom Lord is rewriting arch with some features from monotone and git.
But it takes very slowly, last snapshot is from 2005y.
In my opinion rcs should have at least this features:
1. atomically commits
2. file rename support
3. access via should be via ftp (is git support this?)
4. must be patch oriented (not file oriented like cvs)
Because arch2 is not ready to production use, we can switch to bazaar-ng (but this is writen in python)
I am not familiar with hg and git, but I will test it tomorrow and then write what I thing about they.

> cheers
>   simon
> 
> -- 
> Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
> Work - Mac      +++  space for low EUREUREUR NOW!1  +++      Campaign     \ /
> Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
> Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \
>
____________________________________________________________________________
. com = 9,90, .pl = 29,90 
www.nazwa.pl