Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 4 Jul 2006 00:18:00 -0600
From: Vincent Danen <>
Subject: Re: tcb and friends with shadow-utils 4.0.12

* Solar Designer <> [2006-07-04 08:28:17 +0400]:

> 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:
> > > 
> > >;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.

Ok, well, you know more than I so I'll take your word for it.

> > 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?

As soon as this is squared away so I can tell them exactly what needs to
be done, absolutely.

> > 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.

Hmmmm... well, I'll be damned:

[vdanen@...ld 2.0-CURRENT_32]$ ./bcrypt-test 
+ perl -e 'print crypt("foo", "\$2a\$05\$abcdefghijklmnopqrstuu"), "\n"'
[vdanen@...ld 2.0-CURRENT_32]$ rpm -q gcc

I think you're right.  My build host is running 1.2-RELEASE, which has,
as you can see, gcc 3.4.4.  And the test worked.

> >
> 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 noticed that part, but didn't think too much of it because I didn't
know what that was.  I'm assuming then that, despite putting x86 into
the libcrypt-routines part of the Makefile, it wasn't actually being
used, correct?

> 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.

Ok, I see BF_FRAME is set to 0x200, but I have no idea what would be
sufficient to increase it too.  Care to give me something I can replace
that with and recompile?  It would probably be faster than me
recompiling glibc a few times to find something suitable.

> > 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.

I thought so too, but embarrassingly enough, my spec was passing "CFLAG"
rather than "CFLAGS" so -DSHADOWTCB was never being passed.  Right now,
as things stand, it looks like it's working perfectly, although I need
to do some more testing to call it finished (and, of course, go back to
how it was before, but with the increased BF_FRAME).

> > If nothing else, it's been a bloody challenge... =)
> Perhaps we should do something to make this easier.

Well, you can tell me what value to use for BF_FRAME for starters... =)

> 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!

Well, sometimes I can get really determined...  I recall spending about
3 weeks trying to get SSP properly integrated into both glibc and gcc
about a year ago and finally gave up, but it took me three weeks to get
there.  I think one long weekend invested turned out not too bad.  =)

{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
mysql> SELECT * FROM users WHERE clue > 0;
Empty set (0.00sec)
:: Annvix - Secure Linux Server: ::

Content of type "application/pgp-signature" skipped

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.