* Solar Designer <solar@private> [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:
> > >
> > > 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.
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@build 2.0-CURRENT_32]$ ./bcrypt-test
+ perl -e 'print crypt("foo", "\$2a\$05\$abcdefghijklmnopqrstuu"), "\n"'
$2a$05$abcdefghijklmnopqrstuuz29TNT43FrbrkSgusq0SUVtGQkhH2mm
[vdanen@build 2.0-CURRENT_32]$ rpm -q gcc
gcc-3.4.4-5113avx
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.
> > 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 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: http://annvix.org/ ::
This archive was generated by hypermail 2.1.3 : Mon Jul 03 2006 - 23:19:17 PDT