[19555] in Kerberos_V5_Development
Re: Looking for Makefile advice if applicable
daemon@ATHENA.MIT.EDU (Will Fiveash)
Tue Mar 7 18:04:02 2017
Date: Tue, 7 Mar 2017 17:03:46 -0600
From: Will Fiveash <will.fiveash@oracle.com>
To: Tom Yu <tlyu@mit.edu>
Message-ID: <20170307230346.GA13853@oracle.com>
Mail-Followup-To: Tom Yu <tlyu@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>,
MIT Kerberos Dev List <krbdev@mit.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ldvinnqil2q.fsf@sarnath.mit.edu>
Cc: MIT Kerberos Dev List <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Fri, Mar 03, 2017 at 07:47:09AM -0500, Tom Yu wrote:
> Benjamin Kaduk <kaduk@mit.edu> writes:
>
> > I think this is the sort of thing that the VPATH variable is for.
> > So you could set VPATH = ../../builtin/des and declare dependencies
> > on the bare des_int.h and des_keys.c names but pull in their
> > contents from the original location.
>
> autoconf-gnerated Makefiles rely on VPATH for building outside the
> source tree, which will interfere with this usage. Also, VPATH
> functionality isn't very portable across Make implementations. These
> would make it harder for us to integrate upstream. I'd have to think a
> while about how best to do this without using VPATH.
At this point I've modified my implementation of the new crypto provider
so there are no symlinks to builtin files so I don't need to worry about
modifying the Makefiles as discussed in this thread.
As an aside, would MIT be interested in taking the crypto provider that
I'm working on upstream? It is very similar to the openssl provider in
src/lib/crypto/openssl except my provider uses the Solaris libucrypto as
its source for low level ciphers and hashes. The code is self contained
in a src/lib/crypto/ucrypto directory and other than that I made a small
update to src/configure.in to support a --with-crypto-impl=ucrypto
argument. The reason I have created the ucrypto provider is that the
FIPS version of openssl does not support AES-CTS and aborts if this or
any other non-FIPS validated cipher is used. The Solaris libucrypto
does not do that and it is my understanding the AES-CTS cipher will be
FIPS-140 validated
--
Will Fiveash
Oracle Solaris Software Engineer
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
