[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101009170236.GA21947@openwall.com>
Date: Sat, 9 Oct 2010 21:02:36 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Patch for Makefile, concerning Solaris x86
On Sat, Oct 09, 2010 at 01:55:36AM -0400, Robert Harris wrote:
> We does the tgtsnarf program do, anyway?
On a network with Kerberos v4 or AFS, it obtains a TGT for later attack
with KRB4_fmt.c. I doubt that it'd work for current deployments, though.
Quite possibly, no one will ever use this anymore. I was in a "merge
all patches into jumbo" mode when this got in. ;-)
> Why is it only built in Solaris?
It is built on all platforms, but the extra libraries are only needed on
Solaris because having basic networking functions separated from libc
into these libraries is Solaris-specific.
> I purpose we either do this for each Solaris build item (What is a better
> name for this?),
I call them make targets.
> Option 1)
> (add the text "-lnsl -lsocket" to each Solaris build item's LDFLAGS)
...
> LDFLAGS="$(LDFLAGS) -lrt -lnsl -lsocket"
Right, that's what we were discussing so far.
> or this for each Solaris item Option 2)
> (create a new global variable for Solaris only, and use that in the LDFLAGS)
> (Looks like you have a MARKOV LDFLAGS, why not a new one for Solaris?)
You're missing the point behind LDFLAGS_MKV: it is program-specific, not
target-specific. An equivalent would be LDFLAGS_TGTSNARF or LDFLAGS_NET
(in case we ever have more programs requiring the networking functions),
not LDFLAGS_SOLARIS. And you'd add this new LDFLAGS_TGTSNARF or
LDFLAGS_NET to the build line for tgtsnarf, for all make targets (not
only Solaris), but you'd define it to empty string by default and
override it to the proper libs on Solaris. However, as I've mentioned
in the previous message on this topic, there's little point in doing
this because we already have a similar "problem" for -lcrypto and some
other libs, which we're not solving. We could solve all of these, but
it's not something to discuss (a possible discussion would be a waste of
time; I'd rather make the changes on my own if I ever choose to do so).
> LDFLAGS_SOLARIS = -lnsl -lsocket (New Global variable)
>
> solaris-x86-sse2-gcc:
> $(LN) x86-sse.h arch.h
> $(MAKE) $(PROJ) \
> JOHN_OBJS="$(JOHN_OBJS) c3_fmt.o solaris-x86.o x86-sse.o
> sha1-mmx.o md5-mmx.o" \
> CFLAGS="$(CFLAGS) -DHAVE_CRYPT" \
> LDFLAGS="$(LDFLAGS_SOLARIS) -lrt"
This is not substantially different from your Option 1. Also, -lrt is a
Solaris-specific option as well, so it'd need to get into LDFLAGS_SOLARIS
in your example.
> Which do you prefer? Looks like either one works.
Either is fine. They don't differ in what they achieve (unlike possible
per-program LDFLAGS, which would actually result in differently-linked
binaries). I'll let you choose between your Option 1 and a revision of
your Option 2 where -lrt would go into LDFLAGS_SOLARIS as well.
Thanks,
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.
