Date: Tue, 21 Sep 1999 21:27:42 -0600 From: Nate Williams <nate@mt.sri.com> To: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Cc: 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: <199909220327.VAA11157@mt.sri.com> In-Reply-To: <199909212219.CAA03066@tejblum.pp.ru> References: <199909211832.UAA73900@gratis.grondar.za> <199909212219.CAA03066@tejblum.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Committing on top of my commit > > (where there is no _breakage_ like Peter fixed) is OUT. > > There _is_ a _breakage_, tough it is not that apparent now. A libcrypt > specific aspect: you added a new encryption algoruthm, SHA1, and > bumoped the version number. This is the correct result, given that there are no 'minor' numbers. If we were using a.out libraries, we'd bump the minor number and leave the major number alone. This is not possible in the ELF world, unfortunately. >Suppose someone want to use SHA1-encrypted > passwords in his password file. (It is legal, right?). Then he will be > forced to upgrade all his old binaries that perform authetication (like > ssh) linked against licrypt.so.2, because libcrypt.so.2 cannot autheticate > users with SHA1 passwords. That is correct. Otherwise, there is no way to know if libcrypt.so.1 is SHA1 capable except by runtime failures. Therefore, the major number must be bumped so that it is obvious to anyone when a new library is required. Otherwise, we end up with the same problems the Linux folks. Oh, you're using libc.so.5, but an *old* version that doesn't work because it's missing the foobletch() routine that is in newer BlueCap release. > Thank you very much, I prefer to live without unexpected/urgent upgrades. > I have other things to bother about. 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. 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. Mark's code changes may be suspect, but two wrongs don't make a right. 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?199909220327.VAA11157>