[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20101005192120.GA7979@openwall.com>
Date: Tue, 5 Oct 2010 23:21:20 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: JtR project (was: SHA1 salted syntax ???)
W.A. -
While I understand you bringing these topics up in the context of your
repeated requests for a feature and me finally posting a patch in
response, I'd prefer you starting a new thread for the many topics that
you brought up. I've changed the Subject (but did not break the thread)
to reflect this change of topic.
Also, while I made an exception this time, next time you post in French
and without an English translation, I will reject your posting. Sorry
about that, and it's a pity since I find much of your feedback very
useful (thanks!), but let's think of other members of this list.
On Tue, Oct 05, 2010 at 10:56:11AM +0200, websiteaccess@...il.com wrote:
> I post this text in my language, please translate it in yours.
I did using Google Translate, and I'll include some translations or
explanations below (for others reading this):
> Ca fait déjà pas mal de mois que j'essai d'utiliser JTR à mon niveau.
> Suite à pas mal de problèmes pour compiler JTR de base sur os X j'y
> arrive enfin. Y'a toujours un truc qui fait que ça compile avec des
> erreurs.
(Complaints re: there being many patches.)
You don't have to use the patches. Of course, you won't have the
functionality that the patches provide then, or at best you'd have it
later (when/if the functionality is implemented in the official JtR or
in the jumbo patch, if you're fine with having this one patch). The
alternative for the JtR project at this time would be not to have this
functionality at all. You're imagining that we'd have everything in a
"finished software product" at once, but this just does not work for
features that have just been implemented and are being considered, or
that have been partially implemented (e.g., many of those implemented
with patches only work on a subset of the platforms supported by JtR).
This specific generic salted SHA-1 patch that I posted will be part of
the next revision of the jumbo patch. Maybe I could release that new
revision of the jumbo patch right away instead of just this one patch to
be applied on top of jumbo. Would this work better for you (and why)?
> Une documentation insuffisante et uniquement en anglais.
("Insufficient documentation and only in English.")
Some people are saying that the documentation is "insufficient", yet no
one so far was able to (or wanted to) explain to me what exactly is
missing or what to improve. You're welcome to be the first to provide
any help in this area. Please point specific things out (e.g., "this
specific thing is undocumented, I suggest that we document it in
such-and-such way in such-and-such place"). Please create better
documentation on the wiki, even in French if you like (e.g., under
"john/fr" or prefixing the French wiki page names with "fr_").
I don't speak French, so I can't produce French documentation for John.
I could produce Russian documentation, but I decided that my time was
better spent improving code and the English documentation, as well as
working on other projects. Besides, having Russian documentation would
not make you any happier anyway, would it?
This is really something for others in the community (you?) to work on
if they care and like to.
On a few occasions, I did use feedback and questions received on
john-users to improve the documentation, though. Specifically, I
improved the FAQ and I listed some answers on the
http://openwall.info/wiki/john/mailing-list-excerpts wiki page.
> j'ai testé Passwordspro et Hashcat. Contrairement a JTR, il y a une
> interface graphique, il suffit d'ajouter un "module" pour ajouter de
> nouvelles possibilités. Facile et rapide.
Re: a GUI, an integrated GUI is within consideration for JtR Pro,
although so far the demand for a GUI has been surprisingly low and
mostly from people who did not get what JtR was for anyway (so they'd
have other "complaints" even if they were given a GUI).
There are some standalone GUIs for JtR - e.g., FSCrack from Foundstone:
http://www.foundstone.com/us/resources/proddesc/fscrack.htm
This one is Windows-specific and licensed such that it can't be
redistributed (which is why it's not in the contrib/ directory). Does
anyone find it useful? I doubt that many people do.
There's also a Japanese GUI here:
http://bogus.jp/john.php
This one is also standalone and Windows-only.
As to having support for loadable pre-compiled modules, I see what you
mean. Yes, this would eliminate the need for source code patches in
many cases (albeit not in all, so you would continue complaining).
However, this is a more obvious choice for platform-specific apps than
it is for portable ones. To turn "new format" contributions from
patches to pre-built modules, we'd need some sort of "build and test
farm" - to automatically build whatever new modules people are
contributing (in source code) on multiple platforms, provide build logs
back and insist on the contributor fixing all errors. Maybe this would
work, or maybe not (a contributor will not necessarily be willing to
spend time to get their code working on all platforms). Right now, I am
doing some of this manually when I integrate contributions into the
jumbo patch. Then others are making custom builds for various platforms
(Robert, Erik - thank you!)
> A mon sens, si JTR veux rester dans la cour des grands, une interface
> graphique est nécessaire, un système de modules simples à ajouter doit
> gérer les nouveaux formats.
(Re: JtR staying in the same league with other major password crackers.)
I disagree that we should duplicate and directly compete with another
tool. You're suggesting to add a GUI and loadable modules, but the way
the project is organized right now (yes, this may be a problem) this
would take time away from other possible improvements. In my opinion,
those other potential improvements are more desirable because some of
them would in fact be unique, not duplicate what others have already
implemented in another tool. Also, a decent GUI and loadable modules
are harder to implement in a portable app (than in a platform-specific
one). Your new complaints would be about specific builds of the GUI
failing to work on a new version of Mac OS X because of changed library
versions or whatever, whereas someone else would be bringing up Linux
specific issues at the same time. So the maintenance "cost" would
increase a lot.
> Personne n'a envie ( sauf les masochistes ) de passer son temps avec
> des lignes de textes à taper juste pour indiquer ou se trouve tel ou
> tel fichier.
("Nobody (except for masochists) wants to type shell commands ...")
Believe it or not, many people (including me) actually find the command
line a lot more convenient than a GUI (and I don't consider myself a
masochist). I think you're just not making full advantage of the added
capabilities of the command line. To name a few: ease of recording,
revising, sharing, and reusing precise instructions ("type this and
that" is much more specific and easier to revise, share, and reproduce
than "click here and there"), combining multiple tasks (those lengthy
command-lines that pass intermediate results between multiple programs
without having to use temporary files), running multiple tasks on remote
servers, "detaching from" and "re-attaching to" those tasks.
Difficult (or time-consuming?) to type filenames on the command-line?
Not with shell completion - learn it, and you won't regret - e.g., type
a partial filename (the first few letters), then press TAB. Also, shell
histories are great - especially the reverse-search feature in bash,
which lets you almost instantly recall, revise, and reuse a command way
back in the history (Ctrl+R, then type a few letters from anywhere in
the old command - and it's right there for you to edit and reuse).
Then, once again, there's no point in fully duplicating what others are
implementing in other tools. In order for the JtR project to remain
viable, it has to remain different. In this context, it may make more
sense to make JtR's command-line interface more advanced (specifically,
make more things configurable from the command-line vs. having to edit a
file) than to add a GUI. (Assuming that we have to choose - and we do,
because the resources are very limited.)
> en résumé, il manque a JTR :
> - une interface graphique (tous à la souris)
> - bien plus de formats supportés grâce à l'ajout de modules ( comme
> passwordspro )
> - une documentation claire, moins technique et en plusieurs langues
> (indiquer clairement quelle syntax taper pour tel format de hashes a
> cracker)
> - mise a disposition des dernières versions déjà compilées et
> complètes ( tous les patches déjà installés ), pour tous les systèmes (
> win, os X, linux, etc )
Thank you for the summary. I'll comment on the specific points below:
"- GUI (all mice)
- Many more formats supported by the addition of modules (as passwordspro)"
I've commented on these two above. They don't appear to be worth my
time right now. I wouldn't mind others contributing in these areas,
though - e.g., someone could volunteer to make and maintain an Open
Source GUI for JtR. The two GUIs I mentioned above are crippled a bit
too badly (licensing, no source code, lack of maintenance, one is
Japanese-only).
"- Documentation clearer, less technical and in several languages"
"Clearer" is difficult to achieve without very specific feedback (users
suggesting specific things to re-word - even providing "patches").
"Less technical" might be easier, although it would probably require
additional "documentation for the dummies", not changes to the existing
"technical" documentation. However, I need specific advice here - e.g.,
what exactly is "too technical" about the "doc/EXAMPLES" file, and how
would your suggested "less technical" documentation differ from it - what
other things to describe? what to omit? what to describe differently
(and how)?
"In several languages" - this is clearly not something I can do, but you
can. :-) I could do it for Russian, but this would hurt the project (my
time is limited).
To give a relevant example, for Owl - another project of Openwall - we
have documentation in English, Russian, French, and German. The last
two are outdated lately - the volunteers who made the translations have
simply stopped contributing. For Russian, although I was not the one to
make the translation (from English) initially - another team member did -
I had to make some updates on my own lately, which distracted me from
work on the code a little bit. I am still not convinced that having
those translations was of much benefit to the project; it never appeared
to bring more users to us, but it did take up some of my time away from
work on the technical aspects of Owl.
For JtR, I found various non-English tutorials and documentation
translations on the web, all with various factual errors introduced -
apparently, because people who have a better understanding of the
operation of JtR also have no problem with the English documentation
and/or are not willing to spend their time writing a tutorial or a
documentation translation... That said, I included some links to those
non-English web pages here:
http://openwall.info/wiki/john/tutorials
Portuguese, Russian, French, Spanish, Icelandic so far. These are just
some of the non-English web pages on JtR that I found - there are many
more. Please feel free to add more. In fact, I'd be happy if the
authors of those web pages joined our community and contributed their
stuff to the wiki on their own.
"(Clearly indicate what type syntax for this format has hashes cracker)"
This is difficult to indicate "clearly" because the questions are often
not clear - e.g., many of yours required quite some guessing on what you
actually had. That said, this wiki page is meant to help with this:
http://openwall.info/wiki/john/sample-hashes
Please feel free to add to it and/or suggest another way to address your
request. It'd be best if you start by providing a sample piece of
documentation that would "work for you".
"- Make the latest versions available and already compiled complete (all
the patches already installed), for all systems (Win, OS X, Linux, etc.)"
I understand the request, and we - as a community - have been doing a
few things in this area (thanks again, Robert and Erik!) We can
probably do a bit more.
However, please note that it is not reasonable nor even possible to have
"all" patches applied at the same time - some are mutually-incompatible,
some have sometimes-undesirable side-effects. For example, of the DES
OpenMP parallelization patches that I released, both -omp-des-4 and
-omp-des-7 are reasonable for use (so both are listed on the wiki right
now), but in different cases (which are mentioned on the wiki). In
fact, sometimes an OpenMP-enabled build is preferred, but sometimes not.
Then we have 32- vs. 64-bit. This would result in lots of different
builds to choose from (different "latest" versions, different build
options, many platforms). Essentially, you want both to have the latest
development, experimental, and purpose-specific code available for use
_and_ to have it available in a "finished product" - but these things
just don't mix very well.
> Alexandre, dit que je pose toujours les mêmes questions. Ce n'est pas
> faux, je n'ai toujours pas trouver l'endroit à
> http://www.openwall.com/lists/john-users/ ou je peux faire une
> recherche sur mes anciens messages postés !
> Y'a t-il un moteur de recherche spécifique ? La aussi, on est perdu.
(W.A. did not know how to search the list archives.)
I answer this question in here once in a while. There are searchable
archives linked right from the JtR homepage. Here they are:
http://dir.gmane.org/gmane.comp.security.openwall.john.user
http://marc.info/?l=john-users
Of course, the "local" archive (on openwall.com) will also need to be
enhanced with a search capability - this is on my to-do (for years...)
There are so many things to improve and so little time.
Thank you for your feedback, and please post in English next time - or
at least include an automated English translation right away (if you
can't do any better).
Alexander
P.S. I wrote most of my response above before I saw Simon's translation.
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.
