[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 3 Sep 2009 21:15:31 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: distro patches
On Thu, Aug 20, 2009 at 07:14:50PM -0600, RB wrote:
> I've filed a bug for Gentoo to get them to update their JtR package
> (including getting rid of the awful params.h patch), and they've
> thanked me by asking me to submit some of their patches upstream.
> Whether I agree or not, I've cherry-picked those that may be of
> benefit to others; please consider these for future incorporation.
Thank you! I have some comments below. Please feel free to pass them
back to the Gentoo folks.
> The first patch (mkdir-sandbox) adds a check for EACCES against the
> return value of the mkdir() call in src/path.c that makes it more
> compatible with Gentoo's 'sandbox' build tool.
I think this should be approached differently. Rather than exit on the
error (current "official" behavior) or ignore the error (current
behavior with the Gentoo patch), I think JtR should print the error
message and continue.
> The second and third (stackdef.S and all-5-stackdef.S) patches are the
> ubiquitous set that prevents dire warnings in environments that are
> strict about stack executability. I've split them so it's clear which
> applies to the core tree and which applies to the all-5 patchset.
Yes, I was aware of this for a while, but I hesitated to apply the
changes because they could break builds on older and/or on non-Linux
systems. However, I've recently tested this on an ancient Linux system
(11 years old binutils and gcc, slightly newer libc 5) and the build
succeeded, so I am willing to apply the change now, maybe adding a check
for __linux__.
> The final (cflags) patch is actually from the gentoo-prefix project,
> and forces src/Makefile to respect pre-existing CFLAGS values. It's
> not complete, but at least gives the idea of what they were intending
> to do.
I understand the problem, but the patch is not acceptable because it
results in duplicate compiler options being used with the modified make
targets. In practice, the options listed on the command line last
should take precedence, which is fine, yet it does not look pretty.
Thanks again,
Alexander
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.
