76399 2005-01-02 05:40 0000 johntheripper-1.6.37_p1 uses / for all it's files 2005-08-23 14:28:01 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified x86 Linux RESOLVED FIXED P2 normal --- 1 pookey@pookey.co.uk dragonheart@gentoo.org dr@baileynet.org pookey@pookey.co.uk 2005-01-02 05:40:21 0000 I just upgraded johntheripper-1.6.37_r1.ebuild to johntheripper-1.6.37_p1.ebuild. # ls / bin boot dev etc home lib lost+found mnt opt proc root sbin service sys tiel tmp usr var # pwd /root/john # john ./mailpasswords ^C # ls / bin dev home john.pot lib mnt proc sbin sys tmp var boot etc john.log john.rec lost+found opt root service tiel usr Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: files appeared in / rather then the current directory Expected Results: looked for the .rec file in that pwd, and made it's log file etc. in the pwd. pookey@pookey.co.uk 2005-01-02 05:47:46 0000 i removed the epatch line in the ebuild, and it seems to have fixed the problem. ChangeLog says: 01 Jan 2005; Daniel Black <dragonheart@gentoo.org> -johntheripper-1.6-r1.ebuild, -johntheripper-1.6.37-r1.ebuild, +johntheripper-1.6.37_p1.ebuild, metadata.xml: Version bump removes old version. New _p1 version contains new patches and fixes bug #59195 (by Benoit Izac <benoit.izac@free.fr>) and bug #56528 I'm guessing one of the new patchs messes things up somewhat dragonheart@gentoo.org 2005-01-02 20:58:26 0000 is HOME set in the environment? Bug 56528 requested I use it. Should it default to /tmp if not set? pookey@pookey.co.uk 2005-01-02 22:36:17 0000 # john --restore fopen: /john.rec: No such file or directory # echo $HOME /root # ls ./john.rec ./john.rec # pwd /root/john I would suggest that rather then using /, $HOME, or /tmp, the pwd is used. This was the behaviour in r1 I think. Happy new year :) dr@baileynet.org 2005-02-28 17:22:49 0000 I am experiencing something similar, for some reason, john thinks it's home directory is "/home". $HOME is set in my environment to /home/username. username@host test $ john password-testfile open: /home/john.log: Permission denied If I use sudo, it drops john.log and the other session files into "/home" It should put them into the user home directory by default. dr@baileynet.org 2005-02-28 17:34:52 0000 Sorry, when I sudo, it drops them in the root. dragonheart@gentoo.org 2005-02-28 23:55:40 0000 This is undoubtedly an error in the patch I did. Unfortunately I'm running out of time to fix such things. If you have the ability I'd appreciate a hand. pkdawson@gentoo.org 2005-03-04 08:16:09 0000 It's a problem with these lines: + if (path) + if (!john_home_path && (pos = strrchr(path, '/'))) { + john_home_length = pos - path + 1; If I do: export HOME=/home/pkdawson/ (note the slash on the end) then it works normally. kalin@ThinRope.net 2005-08-23 05:41:08 0000 And why is it supposed to spit a ton of files in home?? Isn't it normal for a simple text based program to output in the current directory? kalin@ThinRope.net 2005-08-23 06:11:57 0000 Yes, just got bitten by some files in / Confirming this as a bug. BTW, 1.6.38 is out with some minor improvements in speed (mostly NT LM DES (1.5 times), FreeBSD MD5 and Kerberos AFS DES. [stats on a P4@2.4GHz] Anybody fixing this bug and bumping to 1.6.38? dragonheart@gentoo.org 2005-08-23 07:06:22 0000 removed johntheripper-1.6.37_p1 added johntheripper-1.6.37_p11 using the bigpatch from http://www.cr0.net:8040/misc/patch-john.html added 1.6.38 too. enjoy kalin@ThinRope.net 2005-08-23 12:36:49 0000 Ok, I don't want to open a new bug, but apparently the SRC_URI is bad... http://www.openwall.com/john/b/john-1.6.38.tar.gz It should be with a /c/ instead of /b/, so: http://www.openwall.com/john/c/john-1.6.38.tar.gz No idea what is the meaning behind that... kalin@ThinRope.net 2005-08-23 12:45:45 0000 And 1.38 does not work out-of-the-box :-( ~ # john fopen: john.ini: No such file or directory Shall I open another bug? dragonheart@gentoo.org 2005-08-23 14:28:01 0000 SRI fixed john 1.6.38 seems to expect /etc/john/john.conf in your current directory. Don't worry about another bug - I'll look later.