Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4EBE5C77.6010707@hushmail.com>
Date: Sat, 12 Nov 2011 12:45:59 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: LM & NT prepare() segfaults

I had to revert your fix for XSHA512 in a new patch (posted as 0014). A
proper test was already in there, and the added one broke it! Other than
that, all is good (I think).

magnum


2011-11-12 02:02, jfoug wrote:
> Done.  Pretty trivial patch.  Should have bullet proofed both the pot load,
> and all current prepare() functions which reference any element other than
> [1].
> 
> It is 'assumed' that [1] would always have valid data in it. We could put
> checks in there, but I did not.  In all reality, the setting of [0] and
> [2]..[9] to point to "" should have been enough.
> 
> Jim.
> 
>> From: jfoug [mailto:jfoug@....net]
>>
>>> I'd appreciate it if you look into this and upload a patch - having all
>>> prepare()'s check for NULL before using fields beyond the 2nd and/or
>>> having the loader set those to "" when parsing the pot.
>>
>> Will do.  Likely both.  But I do not want to depend upon check for null
>> in
>> existing formats, only to have a new format come along that does not
>> check.
>> I would rather put in the checks in the formats which do check, and then
>> make sure that pot loader sends non-null values across for those fields.
> 
> 


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.