I wrote: > > OK, this suggests that the problem is in fact with crypt_blowfish or the > > way it is integrated or compiled. And I think that I know what it is - > > most likely, you need to increase BF_FRAME in x86.S: > > > > http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/x86.S.diff?r1=1.4;r2=1.5 > > > > Sorry it did not occur to me to mention this to you before. On Mon, Jul 03, 2006 at 10:02:11PM -0600, Vincent Danen wrote: > I don't think that was the problem. I am almost sure that it was. > What I ended up doing was taking the patch that SUSE was using and > re-adding a few bits (they never touched crypt/Versions so some > symbols weren't being exported or available that pam_tcb wanted ... Oh, that's not good. It means that people can't compile pam_tcb on SUSE Linux even though they (almost) have crypt_blowfish in glibc. Maybe you can contact SUSE folks (Thorsten Kukuk?) about that? > After about a half-dozen glibc compiles and puttering around, bcrypt is > working now (strange... I've had it for over 2 years and never even > tried it so it's been broken all this time). It might not have been broken all this time. If the problem is what I think it is, it should have appeared with your move to gcc 4+ only. > http://svn.annvix.org/cgi-bin/viewcvs.cgi/releases/2.0-CURRENT/glibc/SOURCES/glibc-2.3-avx-suse-crypt_blowfish.patch?root=packages&rev=5738&view=markup This confirms my guess. This patch has: -#define BF_ASM 1 +#define BF_ASM 0 This disables the assembly implementation, thus avoiding the problem with BF_FRAME being too small. I suggest that you drop this SUSE-derived patch and go back to our recommended way of integrating crypt_blowfish (as described in its README or as implemented in Owl), but increase BF_FRAME. > Right now I'm having an issue with userdel complaining that it can't > lock the shadow password file, so it's not deleting anyone. Now that's likely a bug in your forward-port of the shadow suite patch. > If nothing else, it's been a bloody challenge... =) Perhaps we should do something to make this easier. If newer gcc does indeed require a larger BF_FRAME (in fact, I recall this being mentioned to me before), we'll increase the default. Thank you for not giving up on this! -- Alexander Peslyak <solar at openwall.com> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments
This archive was generated by hypermail 2.1.3 : Mon Jul 03 2006 - 21:28:49 PDT