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.