Re: To be a new DFly commiter
> > What FreeBSD and NetBSD lack is a good system for > > management of binary packages. Marc has very well understood that, > > and has made every effort so that updates work smoothly. To my > > knowledge OpenBSD is the only BSD which has a working update > > mechanism, fully integrated. > > I completely agree with you - I prefer binary packages. If nothing else, > pkgmanager is getting close to taking away much of the pain of manual > compilation and upgrading: http://www.scode.org/pkgmanager/ . And pkg_select has been updated to work with binary packages using the pkg_summary database. And I heard that pkg_chk can use the pkg_summary(5) database for binary updates also. By the way, OpenBSD's solution uses perl. Pkgsrc doesn't depend on perl as perl is not installed on some pkgsrc developers/users systems. Jeremy C. Reed
Re: To be a new DFly commiter
On Sat, March 17, 2007 12:00 pm, Michel Talon wrote: > The reality is that on FreeBSD i find everything i want in the ports, even > more easily that in Ubuntu, while on several other BSD and Linux systems > i don't, by a very large margin. This is not pissing contest, for me the The result at this point is that pkgsrc is the largest possible amount of packaged third-party software for DragonFly. FreeBSD ports, even though it's a larger collection, had/has a smaller percentage of packages that worked on DragonFly, and that number is seriously dwindling now that FreeBSD 4 is reaching end-of-life status. Don't forget to give Joerg credit, as he has made a huge amount of pkgsrc available for DragonFly very quickly. The combination of that and pkgsrc's general cross-platform reach has given DragonFly package support that you usually only see among systems with large-scale corporate support, with budgets to match: Debian, RedHat, FreeBSD, etc. > What FreeBSD and NetBSD lack is a good system for > management of binary packages. Marc has very well understood that, > and has made every effort so that updates work smoothly. To my > knowledge OpenBSD is the only BSD which has a working update > mechanism, fully integrated. I completely agree with you - I prefer binary packages. If nothing else, pkgmanager is getting close to taking away much of the pain of manual compilation and upgrading: http://www.scode.org/pkgmanager/ .
what dc++ client?
Hi! Im looking for *working* dc++ client for DragonFly. dc_gui2 is NOT working properly. Any ideas? -- Sincerely Yours, Vladimir Mitiouchev
Re: New mirror
Matthew Dillon wrote: > I know its a silly question, but what country should I list in > our mirrors section for your mirror? ;) Estonia. -- Hasso Tepper
Re: New mirror
On 17.03.2007, at 19:09, Matthew Dillon wrote: :ftp://ftp.estpak.ee/pub/DragonFly :http://ftp.estpak.ee/pub/DragonFly :rsync://ftp.estpak.ee/DragonFly ^^ I know its a silly question, but what country should I list in our mirrors section for your mirror? I'd say .ee == Estonia. For anybody geographically interested: It is the most northern baltic state, meaning it is located in the north eastern part of europe, bordering russia on the east and finnland (via a bit of baltic sea) on the north. cheerio, simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ PGP.sig Description: This is a digitally signed message part
Re: To be a new DFly commiter
Joerg Sonnenberger wrote: >> One has to be totally unaware of realities to suggest tools from >> obscure Linux distributions, wether they are good or bad, when such >> distribution may collapse at any moment. Already the move to NetBSD >> pkgsrc has cost DFLY division by 3 of the number of available ports with >> respect to FreeBSD for an advantage that i have hard time to even >> discern. > > Package counting like comparing penis length. There are more important > parameters... I've spoken with at least one member of FreeBSD's portmgr > who cursed the current size of the tree, making it very hard to > maintain or move forward. A friend also just reminded me that ports has > over 8700 (!) Perl modules in the list, factoring that out reducing the > divisor a lot. rose% uname -a FreeBSD rose 6.2-RELEASE FreeBSD 6.2-RELEASE #1: Sat Feb 3 12:51:15 UTC 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ROSE i386 rose% find . -depth 2 -maxdepth 2|grep p5|wc -l 2684 and this picks php5 stuff and perhaps other. The reality is that on FreeBSD i find everything i want in the ports, even more easily that in Ubuntu, while on several other BSD and Linux systems i don't, by a very large margin. This is not pissing contest, for me the wide abundance of ports in FreeBSD is by far the most important reason why i am using it. It is certainly not because the kernel is more stable or more performing that on a Linux system, which would not be true, it is because each time i want to use some software i find it. OpenBSD has an excellent packaging system recently revamped by Marc Espie, but it is severely lacking ports coverage. What FreeBSD and NetBSD lack is a good system for management of binary packages. Marc has very well understood that, and has made every effort so that updates work smoothly. To my knowledge OpenBSD is the only BSD which has a working update mechanism, fully integrated. I have written something experimental for FreeBSD: http://www.lpthe.jussieu.fr/~talon/pkgupgrade because i think there is no future for an OS without a binary packages management system,for the reasons that i have mentioned. Sorry, i don't buy Steve's arguments. It is not because One person wants to build sane without gimp support that All users have to endure the pain of building all their ports. The solution is simply that Steve uses an alternative mechanism, involving compilation, when he wants to install sane. If moreover the reason for such desire is to avoid bloat on the hard disk, then i call that an exercise in futility.
Re: To be a new DFly commiter
On Fri, Mar 16, 2007 at 06:58:58PM -0700, Matthew Dillon wrote: > 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). I have some not-yet-commited patches to make unprivileged building a lot more useful. I also plan to work on cross-compilation support for parts of the pkgsrc tree. Both will help a lot for tighter integration of binary packages into distributions. Joerg
Re: To be a new DFly commiter
On Sat, Mar 17, 2007 at 03:30:11PM +0100, Michel Talon wrote: > Another excellent statement! Maintaining a decent ports system is a task for > hundred people. FreeBSD has aroud 200 people doing that, Debian, around > 1000. To be fair, Debian *needs* the thousand people because the approach to packagement they use doesn't scale. > One has to be totally unaware of realities to suggest tools from > obscure Linux distributions, wether they are good or bad, when such > distribution may collapse at any moment. Already the move to NetBSD pkgsrc > has cost DFLY division by 3 of the number of available ports with respect > to FreeBSD for an advantage that i have hard time to even discern. Package counting like comparing penis length. There are more important parameters... I've spoken with at least one member of FreeBSD's portmgr who cursed the current size of the tree, making it very hard to maintain or move forward. A friend also just reminded me that ports has over 8700 (!) Perl modules in the list, factoring that out reducing the divisor a lot. You don't know the advance? Check out a pkgsrc tree and try building random stuff on DragonFly and do the same with ports. Any other question needed? As the person responsible for 2/3 of that I decided to use the way of least resistence and the way more appealing for technical reasons. > The NetBSD people have replaced the horrible mess which is the 4000 lines > bsd.port.mk by a similar horrible mess except it is scattered over many > 5 lines files. You have to start somewhere. Moving logic out of the make scripts is an on-going task, which is work if you don't want to break something. Or want to keep the breakage down to strange packages doing bad things. > Like in many cases it is OpenBSD which is doing the good > work, and in particular they have understood the obvious, that is a ports > system must be centered about binary packages, not recompiling source. I simply refuse to comment that, but it is somewhat ironic... Joerg
Re: To be a new DFly commiter
On Sat, 17 Mar 2007 15:30:11 +0100 Michel Talon <[EMAIL PROTECTED]> wrote: > Already the move to NetBSD pkgsrc > has cost DFLY division by 3 of the number of available ports with respect > to FreeBSD for an advantage that i have hard time to even discern. The advantage is simple to see, as DragonFly and FreeBSD diverged more and more of the FreeBSD ports were failing to build, by now with the termination of FreeBSD-4.x support in the ports tree I suspect there would be a large number of ports failing. The dfports override mechanism was a pure hack that would not have been maintainable for long without effectively forking the FreeBSD ports. As you observed in the bit I snipped maintaining a ports system is no job for a small team so avoiding doing that by joining in with a cross platform system was definitely a good move IMHO. > Like in many cases it is OpenBSD which is doing the good > work, and in particular they have understood the obvious, that is a ports > system must be centered about binary packages, not recompiling source. > This is true for at least two reasons: > - first, today users don't want to lose time compiling Even if 99.% of all users were to use only binary packages *someone* would have to compile sources and maintain patches. For this purpose pkgsrc seems to be well suited. Binary packages from pkgsrc are readily available for most if not all platforms supported by pkgsrc, and yet many pkgsrc users recompile from source, which seems to contradict your contention. To my mind a system that provides binary packages for those that want them and allows source building for those that want to is ideal, certainly a system that provided only binary packages would not please me. When we factor in the little detail that many packages have build options and if you don't like the ones chosen for the bulk builds (for example I use sane but I don't want the gimp around) you have to compile your own it becomes clear that there is at least one good reason for doing your own compiles. -- C:>WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/
Re: To be a new DFly commiter
On Sat, Mar 17, 2007 at 01:26:21PM +0100, Grzegorz B?ach wrote: > Brute-force algoritm with collision can take password 100 time faster > than brute-force without brute-force. Again, password hashes are *not* simple MD5 hashes. They are not even simple salted MD5 hashes. That doesn't mean that a collision is not possible against them, but at least not the stnadard versions everyone is talking about. Joerg
Re: To be a new DFly commiter
Matthew Dillon wrote: > > 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). If i can allow myself to comment Matt's opinion, i think that the two statements above are true and excellent. More generally, there are pieces of traditional BSD installations, such as sendmail, etc. which have better non BSD variants, so that an integrated mechanism to get rid of such base system tools ( i mean only selected few ones ) and import external packages. > > b) Add imap-uw as simple pop3 and imap4 daemon. > > I'd prefer this be maintained via pkgsrc. Yes, in particular when imap-uw is a notorious buggy, insecure and bad performing application. > > 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. Another excellent statement! Maintaining a decent ports system is a task for hundred people. FreeBSD has aroud 200 people doing that, Debian, around 1000. One has to be totally unaware of realities to suggest tools from obscure Linux distributions, wether they are good or bad, when such distribution may collapse at any moment. Already the move to NetBSD pkgsrc has cost DFLY division by 3 of the number of available ports with respect to FreeBSD for an advantage that i have hard time to even discern. The NetBSD people have replaced the horrible mess which is the 4000 lines bsd.port.mk by a similar horrible mess except it is scattered over many 5 lines files. Like in many cases it is OpenBSD which is doing the good work, and in particular they have understood the obvious, that is a ports system must be centered about binary packages, not recompiling source. This is true for at least two reasons: - first, today users don't want to lose time compiling - second, it is *impossible* to guarantee reliability of a system based on source code, because two people may compile the same software on different background, and obtain different result. This is a fundamental issue that nobody will be able to solve.
Re: To be a new DFly commiter
Grzegorz Błach wrote: Brute-force algoritm with collision can take password 100 time faster than brute-force without brute-force. How do you prove this claim? AFAIK collision attacks need to know the plain text. Trying to brute-force a password means not having it in plain text. Hence collisions do not play any role. 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. Yes, I also don't see any reason why we *have* to stick to md5. However, I also don't see any reason why we should switch to blowfish. cheers simon PS: could you please trim excessive quotes when replying? thanks. -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
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
Justin C. Sherrill wrote: In fact, I propose a new rule of thumb: For any proposed feature where: 1: Matt doesn't object, and 2: No existing functionality is lost it should go in. I don't agree. Matt of course has a veto, but the community itself should also agree that this is a feature we want. I guess Matt even doesn't want to permanently watch what other people are doing to object stupid ideas. Looking at the LICENSE file, it is indeedy under a BSD license. Grzegorz, can you submit a unified diff? I guess we need some clever idea to get it working with bare libc as well, etc. Something like this is definitely *not* a work of a saturday afternoon. This is critical infrastructure and needs to be reviewed thoroughly. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
