Looking for Makefile advice if applicable

[Will Fiveash]

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.

[Benjamin Kaduk]

Post by Will Fiveash
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

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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Will Fiveash]

Post by Benjamin Kaduk
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.

[Tom Yu]

Post by Benjamin Kaduk
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Will Fiveash]

Post by Tom Yu

Post by Benjamin Kaduk
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

[Greg Hudson]

Post by Will Fiveash
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Will Fiveash]

Post by Greg Hudson

Post by Will Fiveash
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.