Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 9 Sep 2012 04:53:30 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: EncFS fails on OSX (was: New formats: KRB5-18 and KRB5-23)

On 9 Sep, 2012, at 2:30 , magnum <john.magnum@...hmail.com> wrote:

> On 8 Sep, 2012, at 18:49 , Dhiru Kholia <dhiru.kholia@...il.com> wrote:
> 
>> On Fri, Sep 7, 2012 at 12:55 AM, magnum <john.magnum@...hmail.com> wrote:
>>> On 09/06/2012 09:12 AM, Camille Mougey wrote:
>>>> 
>>>> I send you two new formats, named KRB5-18 and KRB5-23 and both tools :
>>>> krb5_util.patch and kdcdump2john.
>>> 
>>> While they work like champs on Linux, both fail self-test on OSX, although
>>> there are no problems nor warnings when building. I'm not sure I'll be able
>>> to debug that soon, maybe you or someone else can.
>> 
>> This problem on OSX is now fixed
> 
> After another minor patch I just committed, there is one single problem left in OSX (except for OpenCL problems that I blame Apple for) and that is not in -fixes:
> 
> Benchmarking: EncFS PBKDF2 AES / Blowfish [32/64]... FAILED (cmp_all(1))
> 1 out of 177 tests have FAILED
> 
> Note that this happens most of the time, but not always! Some initialization problem?

It turns out this format works fine when I add "-I/opt/local/include" for macports' libgmp (perhaps because this affects OpenSSL too) while it fails if I don't (but just go with Apple's stuff). Maybe there is no problem in the format but somewhere else.

The working build shows this in --list=build.info:
OpenSSL library version: 1000103f

While the failing one shows this:
OpenSSL library version: 90812f	(loaded: 1000103f)

BTW despite the above clearly showing we are loading SSL dynamically, I never see libssl here:
$ otool -L ../run/john
../run/john:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	@rpath/libcudart.dylib (compatibility version 1.1.0, current version 4.2.0)
	/System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL (compatibility version 1.0.0, current version 1.0.0)

Not sure if there is anything we should change in JtR... probably not.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ