[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060704042817.GA20948@openwall.com>
Date: Tue, 4 Jul 2006 08:28:17 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: tcb and friends with shadow-utils 4.0.12
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
