Skip site navigation (1)Skip section navigation (2)
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>