Vote on PR

2019-07-07 Thread Dr Paul Dale
The following vote passed 6 to 0.

topic: Accept the changes to the OpenSSL policies as per PR#133 (openssl/web).
comment: The definition of trivial being clarified and moved to the web page
 that the missing CLA note references.


Pauli
-- 
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia





Re: Cleaning up include file inconsistencies

2019-07-07 Thread Dr. Matthias St. Pierre
I am beginning to  wonder whether it is a good idea to make the fact
whether a private header file contains exported symbols as selection
criterion for where the header file needs to go in the source tree:

> >  - headers in `include/internal`
> 
> For internal things that we want to make available for both libcrypto
> and libssl (i.e. they are exported in libcrypto.so)
> 
> >  - headers in `crypto/include/internal`
> 
> For internal things that we only want available inside libcrypto
> (i.e. they are NOT exported in libcrypto.so)

If you take a look at commit d5e5e2ffafc7 (Move digests to providers)
then you will notice that the `sm3.h` header file was moved:

~/src/openssl$ git show --stat d5e5e2ffafc7 | grep sm3.h
{crypto/include => include}/internal/sm3.h |   7 +-

So it seems like whenever the first symbol of a libcrypto-only private header 
file
needs to be exported then we also have to move the entire header file?
This is tedious and also doesn't really make sense. Because now the files sm2.h
and sm3.h happen to be in two different directories:

crypto/include/internal/sm2.h
include/internal/sm3.h

To be precise: that's only in master, because in 1.1.1 they are still in the 
same directory.
(That's how I noticed it in the first place, because I compared source trees.)

My suggestion instead would be to store all internal header files which are 
shared by
more than one sub-system either in

include/internal/crypto  ( #include "crypto/filename.h")
include/internal/ssl ( #include "ssl/filename.h")

depending on where the code is *implemented*, not where it is *used*.
The directory `include/internal` itself should not contain any include files.

Whether an internal libcrypto function can be used in libssl should depend only
on libcrypto.num and nothing else.


Matthias