Date: Wed, 22 Sep 1999 09:28:41 -0600 From: Nate Williams <nate@mt.sri.com> To: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Cc: nate@mt.sri.com (Nate Williams), Mark Murray <mark@grondar.za>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/secure/lib/libcrypt Makefile src/lib/libcrypt Makefile Message-ID: <199909221528.JAA13544@mt.sri.com> In-Reply-To: <199909220552.JAA00506@tejblum.pp.ru> References: <199909220327.VAA11157@mt.sri.com> <199909220552.JAA00506@tejblum.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> > No, you'd rather everyone be confused as to *which* version of > > libcrypt.so.1 is the correct version? With your solution, there could > > be *dozens* of files with the same name that are very different from one > > another, and only the 'latest' version is correct. > > This is normal for every program in the system. You don't have a > version number on cat(1) or login(1). Sure we do. It's called the $FreeBSD$ version number. :) > This is normal for shared libraries as well. Version number on a > shared library is only a something about binary compatibility, it has > nothing to do with the feature set or somesuch. You got it. My libc.so.1 is *NOT* binary compatible with yours, because yours is newer than mine. Therefore, if I install mine on your box, then programs that previously worked will no longer work. > > That portion of your commit was wrong, in that it violates POLA. Yes, > > it's more work for you, but that's the price *YOU* pay for tracking a > > system that is in constant development. > > Oh. Note: there is only one password database in your machine. An user > ask the question: "Can I use SHA1-encrypted passwords in the password > database?" My answer (it is also in docs): "Yes you can." So far we're in agreement. But, my answer would be different than yours. My answer would be to upgrade to FreeBSD-X.X for sometime after month-day, and do a buildworld to get the new functionality. This is no different than someone asking if bdin.56.7 is installed. It requires some work on the part of the user to get this functionality, and potentially a rebuild of all binaries that it effects. If you want 'updated' password encryption, you must rebuild all binaries that use password encryption to be safe. However, if we are not adding functionality but are simply fixing a bug, *then* we don't need to bump the version number. This means that *nothing* has changed functionally (assuming you can fix the bug w/out making any external API changes and/or additions), then there is no need to bump the version. > This answer is plain and simple, but break POLA. Your answer is no different than mine. Rebuild some libraries, but mine also requires re-linking the programs that do encryption. Your answer: "There is a lot of programs > that autheticate users against the password database. If an user has an > SHA1-encrypted password, some program will mistakely reject passwords of > such users. To determine if a program can handle SHA1-encrypted > password, you can run ldd on it, like this: ldd /usr/local/sbin/sshd. If > ldd show libcrypt.so.3, the program will work with SHA1-encrypted > passwords. If it show libcrypt.so.2, the program will not work wuth > SHA1-encrypted password." This answer does not break POLA, and will > confuse noone, right?. Correct. It may be work, but if you want to run a continually moving target, you must be prepared to have to do a little bit of work occassionally. If you don't want to do the work, then run only the RELEASE candidates. The path you suggest is madness. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909221528.JAA13544>