Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 14 Dec 2012 11:09:53 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Run-time change of a format's max length

On 12/14/2012 09:33 AM, magnum wrote:
> On 14 Dec, 2012, at 3:39 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
>> What if a user started a session using --length, interrupted it, and
>> tries to restore after upgrading john?
> 
> Yes, or if he started a mskrb5 crack specifying --format (it was renamed). I'm thinking for Jumbo we might be best off simply recommending to not update in this situation, or to manually hack the .rec file yourself (which is really trivial for both cases).
> 
> We could support --length for one more revision of Jumbo, with a printed notice it's deprecated. But I'm not sure how to do the same with mskrb5. We should have function-label aliases, which is usable for other things too, like mapping a name to a dynamic... This could also be used for things like md5 vs md5crypt and ssha vs salted-sha1, and it could also alias format tags. This could be a list in john.conf, perhaps something like this:
> 
> [List.aliases:functions]
> mskrb5 = krb5pa-sha1
> ssha = salted-sha1
> radius = dynamic_1008

Since this section is just intended to keep existing .rec files usable,
I guess there is no need to adjust the bash completion script.

> [List.aliases:tags]
> $dynamic_0$ = $md5$
> 

This could be the easiest way to implement compatibility with older john
versions.
All these compatibility sections could be placed in a separate include
which gets included into john.conf just before john.local.conf.
The include should start with a comment explaining that it contains
sections which ensure backwards compatibility, so that john users know
they are not supposed to change those settings.
(If changes are required, they should file a bug report.)

Frank

Powered by blists - more mailing lists

Your e-mail address:

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