Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 May 2011 20:39:22 +0200
From: magnum <>
Subject: Re: Ideas for jumbo-6

On 2011-05-23 20:08, jfoug wrote:
>> From: magnum To:
>> We should strive to keep this as simple as possible though so I guess
>> number 2 is the way to go. But just maybe we could want that
>> thin-over-thick thing hacked in? Not that I know how we would tell them
>> apart in a canonical way.
> Well, I will be working on thin formats. I was planning on using
> *_thin_plugfmt.c for them, as a 'naming' standard. Thus, we 'could' get
> tricky.  However, is the thin always preferred?  I would guess not.  I would
> think the thin would be a standard install, but then a  user has a problem
> with thin, and tries to revert back to thick, by coping a thick format from
> somewhere (possibly a repository on the wiki of the 'old' thick formats).
> Being a user and not realizing how john is built, it now fails (or continues
> to run with the thin format).  Just poking out a hypothetical to keep the
> thoughts flowing.

True. And maybe we first need to establish this:

How do we treat all old Jumbo-formats whenever we release this?

1) Only mskrb5 and salted-sha formats (and possibly the pending formats 
on the wiki) converted to plugin formats, showing the way. The rest is 
left as-is in Makefile & john.c (and with their current file names). The 
old Jumbo formats can be migrated one by one or a bunch at a time 
whenever revised for other reasons.

2) ALL Jumbo (or non-core) formats (md5-gen counts as core) converted to 
plugin formats.

I vote for option 2. Regardless of which option we choose, all future 
formats are supposed to be written as plugins and named *_plugfmt.c


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.