Looking for Makefile advice if applicable

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Looking for Makefile advice if applicable

Will Fiveash-2
I'm wondering if there is a better way to achieve the following: I'm
creating a new crypto provider for krb5 and in doing that I've created
the src/lib/crypto/ucrypto/ subdirectory.  The contents of that
directory are similar to what is in the src/lib/crypto/openssl directory
except that some of the cipher support is coming from source under
src/lib/crypto/builtin like des.  What I got working was to create
src/lib/crypto/ucrypto/des and in that dir I created symlinks like

des_int.h -> ../../builtin/des/des_int.h
des_keys.c -> ../../builtin/des/des_keys.c
destest.c -> ../../builtin/des/destest.c
...

I am able to build the ucrypto provider this way but I'm wondering if
there is a more refined way of doing this via the Makefile?  I did play
around with modifying the src/lib/crypto/ucrypto/des/Makefile.in
like so:

--- Makefile.in 2017-02-08 17:48:37.000000000 +0000
+++ ../des/Makefile.in  2017-02-28 12:34:15.464204753 +0000
@@ -1,6 +1,9 @@
 mydir=lib$(S)crypto$(S)ucrypto$(S)des
 BUILDTOP=$(REL)..$(S)..$(S)..$(S)..
-LOCALINCLUDES = -I$(srcdir)/.. -I$(srcdir)/../../krb -I $(srcdir)/../../builtin
+builtinsrc=$(top_srcdir)/lib/crypto/builtin
+dessrc=$(builtinsrc)/des
+LOCALINCLUDES = -I $(dessrc) -I$(srcdir)/.. -I$(srcdir)/../../krb -I $(builtinsrc)

 ##DOS##BUILDTOP = ..\..\..\..
 ##DOS##PREFIXDIR = builtin\des
@@ -29,18 +32,18 @@
        $(OUTPRE)key_sched.$(OBJEXT)    \
        $(OUTPRE)weak_key.$(OBJEXT)

-SRCS=  $(srcdir)/d3_aead.c     \
-       $(srcdir)/d3_kysched.c  \
-       $(srcdir)/des_keys.c    \
-       $(srcdir)/f_aead.c      \
-       $(srcdir)/f_cksum.c     \
-       $(srcdir)/f_parity.c    \
-       $(srcdir)/f_sched.c     \
-       $(srcdir)/f_tables.c    \
-       $(srcdir)/key_sched.c   \
-       $(srcdir)/weak_key.c
+SRCS=  $(dessrc)/d3_aead.c     \
+       $(dessrc)/d3_kysched.c  \
+       $(dessrc)/des_keys.c    \
+       $(dessrc)/f_aead.c      \
+       $(dessrc)/f_cksum.c     \
+       $(dessrc)/f_parity.c    \
+       $(dessrc)/f_sched.c     \
+       $(dessrc)/f_tables.c    \
+       $(dessrc)/key_sched.c   \
+       $(dessrc)/weak_key.c

-EXTRADEPSRCS = $(srcdir)/destest.c $(srcdir)/f_cbc.c $(srcdir)/t_verify.c
+EXTRADEPSRCS = $(dessrc)/destest.c $(dessrc)/f_cbc.c $(dessrc)/t_verify.c

without any symlinks in the des dir but when I try to build I see:

making all in lib/crypto/ucrypto/des...
gmake[4]: Entering directory '/export/home/wfiveash/hg/i386/mit-krb5-1.14o-bld/lib/crypto/ucrypto/des'
gmake[4]: *** No rule to make target 'd3_aead.c', needed by 'd3_aead.so'.  Stop.

Suggestions welcome.

--
Will Fiveash
Oracle Solaris Software Engineer
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Looking for Makefile advice if applicable

Benjamin Kaduk-2
On Tue, Feb 28, 2017 at 01:54:36PM -0600, Will Fiveash wrote:

> I'm wondering if there is a better way to achieve the following: I'm
> creating a new crypto provider for krb5 and in doing that I've created
> the src/lib/crypto/ucrypto/ subdirectory.  The contents of that
> directory are similar to what is in the src/lib/crypto/openssl directory
> except that some of the cipher support is coming from source under
> src/lib/crypto/builtin like des.  What I got working was to create
> src/lib/crypto/ucrypto/des and in that dir I created symlinks like
>
> des_int.h -> ../../builtin/des/des_int.h
> des_keys.c -> ../../builtin/des/des_keys.c
> destest.c -> ../../builtin/des/destest.c
> ...
>
> I am able to build the ucrypto provider this way but I'm wondering if
> there is a more refined way of doing this via the Makefile?  I did play
> around with modifying the src/lib/crypto/ucrypto/des/Makefile.in
> like so:

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.

-Ben
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Looking for Makefile advice if applicable

Will Fiveash-2
On Tue, Feb 28, 2017 at 11:34:33PM -0600, Benjamin Kaduk wrote:
> 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.

Thanks for the suggestion, I'll check that out.

--
Will Fiveash
Oracle Solaris Software Engineer
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Looking for Makefile advice if applicable

Tom Yu
In reply to this post by Benjamin Kaduk-2
Benjamin Kaduk <[hidden email]> 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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Looking for Makefile advice if applicable

Will Fiveash-2
On Fri, Mar 03, 2017 at 07:47:09AM -0500, Tom Yu wrote:

> Benjamin Kaduk <[hidden email]> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Looking for Makefile advice if applicable

Greg Hudson
On 03/07/2017 06:03 PM, Will Fiveash wrote:
> As an aside, would MIT be interested in taking the crypto provider that
> I'm working on upstream?

Our policy is not to include crypto providers which use non-open-source
libraries, as we can't easily maintain the code.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Looking for Makefile advice if applicable

Will Fiveash-2
On Tue, Mar 07, 2017 at 07:27:45PM -0500, Greg Hudson wrote:
> On 03/07/2017 06:03 PM, Will Fiveash wrote:
> > As an aside, would MIT be interested in taking the crypto provider that
> > I'm working on upstream?
>
> Our policy is not to include crypto providers which use non-open-source
> libraries, as we can't easily maintain the code.

OK, makes sense.

--
Will Fiveash
Oracle Solaris Software Engineer
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev