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 08:28:17 +0400
From: Solar Designer <>
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:
> > 
> >;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.


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>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598 - 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.