Re: [HEADS UP] Binary package changes
On Thu, 2007-04-12 at 12:56 +0200, Joerg Sonnenberger wrote: > On Thu, Apr 12, 2007 at 02:36:39PM +0200, Grzegorz B?ach wrote: > > When I try install pkg from vulnerable dir and its depends are it All > > dir, dependences can't be installed, but when I try install pkg where > > pkg and every depends are in All dir everything is OK. > > Yeah, that's a known bug. I want to fix it, but it is a lot harder. > > Joerg I suggest small workaround for this bug: Add next dir 'AllWithVulnerable' with symlinks from All and vulnerable. IMHO vulnerable dir should be with capital first letter, because like All it is meta-package dir (ls will display it before package categories' dir).
Re: [HEADS UP] Binary package changes
On Tue, 2007-04-10 at 21:20 +0200, Joerg Sonnenberger wrote: > On Thu, Apr 05, 2007 at 05:32:59PM +0200, Grzegorz B?ach wrote: > > I can't install any packages from pkgsrc-box.org, but from > > pkgsrc.dragonflybsd.org it works OK. > > Can you rebuild pkg_install with the attached patch and see if that > works? > > Joerg With your patch I can install packages from pkgsrc-box.org, but I have different problem not related with previous. When I try install pkg from vulnerable dir and its depends are it All dir, dependences can't be installed, but when I try install pkg where pkg and every depends are in All dir everything is OK. I attached output from pkg_add -v xdoom for example. [1mftp -detv ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All/[m [1mftp> prompt off [mparsing: ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All;ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable path: ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All path: ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable increasing RLIMIT_NOFILE to max. 7293 open files trying PKG_PATH ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All Spawning FTP coprocess [1mftp> nlist xdoom /var/tmp/pkg.S82W3i [m [1mftp> cd . [mpkg_add: nothing appropriate found [1mftp> nlist xdoom.tbz /var/tmp/pkg.wHkubb [mReusing FDs 4/5 for communication to FTP coprocess [1mftp> cd . [mpkg_add: nothing appropriate found [1mftp> nlist xdoom.tgz /var/tmp/pkg.mBnPX2 [mReusing FDs 4/5 for communication to FTP coprocess [1mftp> cd . [mpkg_add: nothing appropriate found [1mftp> nlist xdoom-*.tgz /var/tmp/pkg.bJl0Bl [mReusing FDs 4/5 for communication to FTP coprocess [1mftp> cd . [mpkg_add: nothing appropriate found [1mftp> nlist xdoom-*.tbz /var/tmp/pkg.bJl0Bl [m [1mftp> cd . [mpkg_add: nothing appropriate found [1mftp> close [mtrying PKG_PATH ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable ftp_start: new host or dir, stopping previous connect... currentHost='pkgsrc-box.org', newHost='pkgsrc-box.org' currentDir='packages/current/DragonFly-1.8/All/', newDir='packages/current/DragonFly-1.8/vulnerable/' [1mftp -detv ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable/[m [1mftp> prompt off [mftp stopped Spawning FTP coprocess [1mftp> nlist xdoom /var/tmp/pkg.Z3eEr3 [m [1mftp> cd . [mpkg_add: nothing appropriate found [1mftp> nlist xdoom.tbz /var/tmp/pkg.ZYQLVY [mReusing FDs 10/11 for communication to FTP coprocess [1mftp> cd . [mpkg_add: nothing appropriate found [1mftp> nlist xdoom.tgz /var/tmp/pkg.Iqj47U [mReusing FDs 10/11 for communication to FTP coprocess [1mftp> cd . [mpkg_add: nothing appropriate found [1mftp> nlist xdoom-*.tgz /var/tmp/pkg.J9Huzl [mReusing FDs 10/11 for communication to FTP coprocess [1mftp> cd . [m [1mftp> nlist xdoom-*.tbz /var/tmp/pkg.J9Huzl [m [1mftp> cd . [mpkg_add: nothing appropriate found [1mftp> nlist xdoom-1.10nb3.tgz /var/tmp/pkg.Zpg8b0 [mbest match: 'ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable/xdoom-1.10nb3.tgz' 'ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable/xdoom-[0-9]*.t[bg]z' expanded to 'ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable/xdoom-1.10nb3.tgz' Trying to fetch ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable/xdoom-1.10nb3.tgz. Reusing FDs 10/11 for communication to FTP coprocess [1mftp> cd . [m [1mftp> get xdoom-1.10nb3.tgz "| ( cd /var/tmp/instmp.II2rMq; /usr/pkg/bin/tar --use-compress-program gzip -vvxp -f - | tee /dev/stderr )" [mbest match: 'ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable/xdoom-1.10nb3.tgz' Reusing FDs 10/11 for communication to FTP coprocess unpackURL 'ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable/xdoom-1.10nb3.tgz' to '/var/tmp/instmp.II2rMq' tar: ustar vol 1, 10 files, 4556800 bytes read, 0 bytes written in 30 secs (151893 bytes/sec) +CONTENTS +COMMENT +DESC +BUILD_VERSION +BUILD_INFO +SIZE_PKG +SIZE_ALL bin/xdoom bin/sndserver share/doom/doom1.wad pkg_add: Warning: package `ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable/xdoom-1.10nb3.tgz' was built for a different version of the OS: pkg_add: DragonFly/i386 1.8.0 (pkg) vs. DragonFly/i386 1.8.1 (this host) [1mftp> nlist libXext-1.0.3 /var/tmp/pkg.UBQJj9 [mparsing: ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All;ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable path: ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All path: ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/vulnerable increasing RLIMIT_NOFILE to max. 7293 open files trying PKG_PATH ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All ftp_start: new host or dir, stopping previous connect... currentHost='pkgsrc-box.org', newHost='pkgsrc-box.org' currentDir='packages/current/DragonFly-1.8/vulnerable/', newDir='packages/current/DragonFly-1.8/All/' ftp stopped Reusing FDs 10/11 for commun
Re: [HEADS UP] Binary package changes
On Thu, 2007-04-05 at 12:48 +0200, Joerg Sonnenberger wrote: > Hi all, > due to the dead of my old server I've moved the pkgsrc build system to > colocation. A few other things apply as well, so the following changes > should be of general interest: > (1) Binary packages for pkgsrc-current are available from > http://www.pkgsrc-box.org/packages/current/DragonFly-1.8/ > and FTP respectively. This is built with X11_TYPE=modular. > (2) Binary packages for pkgsrc-2007Q1 will follow after Easter when the > branch is cut. > (3) rsync is available as well, if you want to mirror the packages > please contact me first. Due to bandwidth contraints (which might get > sorted out soon), I'd like to keep the list short. > > I'm also looking for a donation of another KVR667D2D4F5K2/4G, as the > virtual machine configuration is running at the memory limit of the box. > > Joerg I can't install any packages from pkgsrc-box.org, but from pkgsrc.dragonflybsd.org it works OK. I have set PKG_PATH to "ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All"; and exec "pkg_add -v bcrypt", after that I get this messages: ftp -detv ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All/ ftp> prompt off parsing: ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All path: ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All increasing RLIMIT_NOFILE to max. 1764 open files trying PKG_PATH ftp://pkgsrc-box.org/packages/current/DragonFly-1.8/All Spawning FTP coprocess ftp> nlist bcrypt /var/tmp/pkg.MmzRc2 ftp> cd . pkg_add: nothing appropriate found ftp> nlist bcrypt.tbz /var/tmp/pkg.pypubU Reusing FDs 4/5 for communication to FTP coprocess ftp> cd . pkg_add: nothing appropriate found ftp> nlist bcrypt.tgz /var/tmp/pkg.Ez18HT Reusing FDs 4/5 for communication to FTP coprocess ftp> cd . pkg_add: nothing appropriate found ftp> nlist bcrypt-*.t[bg]z /var/tmp/pkg.guJMhY Reusing FDs 4/5 for communication to FTP coprocess ftp> cd . pkg_add: nothing appropriate found pkg_add: no pkg found for 'bcrypt', sorry. ftp> close When I set PKG_PATH to "ftp://pkgsrc.dragonflybsd.org/pkgsrc-modular/All";, everything goes OK. This is for every package I try to install (not only for bcrypt).
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. > > > 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
Re: To be a new DFly commiter
Dnia 17-03-2007, So o godzinie 00:05 +0100, Simon 'corecode' Schubert napisał(a): > [EMAIL PROTECTED] wrote: > >>> 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/. > > Yes, I read the docs and I think this is a quite nice and simple scheme to > restrict access and to get rid of a couple of setuid root binaries. We > definitely should discuss this. I'm not talking about integrating the > sources because I suspect they are GPL, but about the principle itself. Tcb is licensed under terms of BSDL. > > Short for everybody too lazy to read: > master.passwd is being split into single per-user files. these are located > in per-user dirs with mode $user:auth 710 and the files $user:auth 640. this > way only root+user can change the files and therefore the password. only > root+user+group auth can read/check the password. don't know about chsh(1) > etc. > > cheers > simon > Czas wybrac dobra nazwe! www.nazwa.pl
Re: To be a new DFly commiter
Dnia 16-03-2007, Pt o godzinie 17:57 +0100, Gergo Szakal napisał(a): > *My* *sole* opinion follows: > * pkgsrc is here to stay, it works fine, you'd better contribute to (even > smoother) pkgsrc integration > * postfix license is too restrictive (IBM), same for stunnel (GPL), > developers of *BSD systems would like to avoid licenses that are more > restrictive than BSDL. > I use DFly because it is better than linux for me (not because it has less restrictive license), and IMO postfix is better than sendmail, thus postfix should be used. Currently nobody should use mail server without sasl authentication. Postfix can be authenticated also with dovecot which is mainly pop3/imap4 server and is released partialy under MIT and LGPLv2.1 licenses. .com = 9,90, .pl = 29,90 www.nazwa.pl
Re: To be a new DFly commiter
Dnia 16-03-2007, Pt o godzinie 17:45 +0100, Joerg Sonnenberger napisał(a): > > 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. > > HAHA. This is a good one. It is more secure to not run tools which > manipulate the password db as root? If I can control any of this tools > to execute code with sgid shadow, I can just manipulate the root record > anyway. Sorry to be harsh. > > Joerg > When you do buffer-overflow in passwd you can exec any code with root priviledges, but with tcb you must change root password to run code with root priviledges, and administrator will see this faster. Serwery za 1 zł! www.nazwa.pl
To be a new DFly commiter
Hi everyone, I use DragonFly about 2 year, currently I am ready to submit my tweaks and extensions to DFly system. There're: 1. a) chg default password_format do blowfish since there are known algoritm of collision for md5. 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. 2. a) Replace sendmail with postfix (with cyrus-sasl). It is faster and use cleaner config file. b) Add imap-uw as simple pop3 and imap4 daemon. c) Add stunnel for SSL/TLS access to mail-related daemon. 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 hope I'll got write access to CVS for complete this steps. WHO I AM? I am a 21 old student from Krakow in Poland. 3 year's ago I worked on my own Linux distribution, but I halt this project, because I had romance with FreeBSD, and this system IMHO is more self-integrated than Slackware Linux, which I used earlier. And I played with him. For my distribution I ported crypt-blowfish from openwall. And when i halted work on my distripution i put patch for Slackware 10 on http://www.openwall.com/crypt/. For FreeBSD i write coda (CD Digital-Audio Player), which is hosted on https://gna.org/projects/coda. And I ported fdisk from utils-linux package as lfdisk which is hosted on https://gna.org/projects/lfdisk. .com = 9,90, .pl = 29,90 www.nazwa.pl
