Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

[Jakob Bohm]

Let me explain this a bit more clearly:

The fipscanister.o file (like any other .o file) contains
two things:

1. The actual code and constant data (if any) that needs
  to go in the final .so or program file.  This is what
  will eventually be hashed to produce the embedded sha1
  check.

2. Relocation information on how the linker should adjust
  the code to indicate its location in the .so file (and
  in memory on some platforms) and how other parts of the
  .so file shall be adjusted to indicate the location of
  the code in fipscanister.o.  This data is used and
  removed when creating the copy of the fips canister in
  the .so or program file.

Therefore an sha-1 sum of the fipscanister.o file will
include more (and different) bytes than the fips canister
inside the final .so file, and will thus not match the
sha-1 sum that needs to be embedded inside that .so file.

Also for some build targets, the fips canister inside
the final .so file will similarly not match the in-
memory fips canister in the running program, which is
what the embedded sha-1 sum must match.

Using a 3rd party build script which downloads the source
code from somewhere beyond your control cannot be used as
a secure way to build anything supposedly secure.  Such
build scripts are fundamentally insecure and should not
be used.

On 15/03/2016 05:26, Satya Das wrote:


Hello Ethan,

I am tweaking the centos rpmspec to use my fips object module.  That 
seems to be downloading source tar ball, patching etc.


Please note that the sha1 of the so is not so interesting as the 
embedded sha1 check inside so (when one calls FIPS_mode_set). 
Essentially if I can get the embedded sha1in the so, I can compare 
that with the sha1 I have as part of the object module I have built. I 
am assuming the embedded sha1 is that of fipscanister.o.


Hope that makes sense ?

Thanks.


From: Ethan Rahn
Sent: Monday, March 14, 6:11 PM
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with 
what is embedded in libcrypto.so

To: openssl-users@openssl.org

Is there a reason why you cannot build it from a controlled build 
environment and record the hash of the final .so?


It seems that it would be pretty non-trivial if not impossible to pull 
a .o file from a .so in the exact same format that it went in, such 
that you could check the hash. Being able to check if a .c file is in 
the same state in the .so afterwards seems pretty much impossible 
given all the things that would change in the code with compiling and 
linking in between the .c state and the final .so state.


On Mon, Mar 14, 2016 at 5:30 PM, Satya Das > wrote:



Hello,

I have a simple problem I am trying to solve. I have built a fips 
capable openssl shared object (.so). I also have the sha1 hash of the 
fipscanister.o in a file called fipscanister.o.sha1. I also have the 
sha1 hash of fips_premain.c in a file called fips_premain.c.sha1. In 
order to make sure the build is good, I want to make sure that the 
.so was indeed built with these versions of fipscanister.o and 
fips_premain.


Is there a way to do this ? I am on centos 6.6 x86_64 and linking to 
object module 2.0.11 from openssl 1.0.1e with patches.





Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

[Mike Mohr]

During the final linking stage, when the shared object is built, the
compiler is free to insert functions from compiled object files anywhere it
sees fit in the final shared object's code segment.  The object file is
fundamentally transformed by this process; information which was present in
the original object file may or may not end up in the resulting shared
object.  Although the machine code in the subroutines should be copied into
the final shared object unmodified, the original object file is effectively
gone and cannot be recovered.  Without the original object file, we cannot
calculate its cryptographic hash.

"As long as politics is the shadow cast on society by big business, the
attenuation of the shadow will not change the substance."

Dewey, J. (2008). *The later works of John Dewey, 1925 - 1953* (Volume 6,
page 163). Carbondale, IL: Southern Illinois University Press.

On Mon, Mar 14, 2016 at 9:26 PM, Satya Das  wrote:

> Hello Ethan,
>
> I am tweaking the centos rpmspec to use my fips object module.  That seems
> to be downloading source tar ball, patching etc.
>
> Please note that the sha1 of the so is not so interesting as the embedded
> sha1 check inside so (when one calls FIPS_mode_set). Essentially if I can
> get the embedded sha1in the so, I can compare that with the sha1 I have as
> part of the object module I have built. I am assuming the embedded sha1 is
> that of fipscanister.o.
>
> Hope that makes sense ?
>
> Thanks.
>
>
> From: Ethan Rahn
> Sent: Monday, March 14, 6:11 PM
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
> To: openssl-users@openssl.org
>
> Is there a reason why you cannot build it from a controlled build
> environment and record the hash of the final .so?
>
> It seems that it would be pretty non-trivial if not impossible to pull a
> .o file from a .so in the exact same format that it went in, such that you
> could check the hash. Being able to check if a .c file is in the same state
> in the .so afterwards seems pretty much impossible given all the things
> that would change in the code with compiling and linking in between the .c
> state and the final .so state.
>
> On Mon, Mar 14, 2016 at 5:30 PM, Satya Das 
> wrote:
>
> Hello,
>
>
>
> I have a simple problem I am trying to solve. I have built a fips capable
> openssl shared object (.so). I also have the sha1 hash of the
> fipscanister.o in a file called fipscanister.o.sha1. I also have the sha1
> hash of fips_premain.c in a file called fips_premain.c.sha1. In order to
> make sure the build is good, I want to make sure that the .so was indeed
> built with these versions of fipscanister.o and fips_premain.
>
>
>
> Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> object module 2.0.11 from openssl 1.0.1e with patches.
>
>
>
> Thanks
>
> --
> openssl-users mailing list
> To unsubscribe: https
> ://
> mta.openssl.org
> /mailman/
> listinfo
> /
> openssl-users
> 
>
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

[Satya Das]

Hello Ethan,

I am tweaking the centos rpmspec to use my fips object module.  That seems to 
be downloading source tar ball, patching etc.

Please note that the sha1 of the so is not so interesting as the embedded sha1 
check inside so (when one calls FIPS_mode_set). Essentially if I can get the 
embedded sha1in the so, I can compare that with the sha1 I have as part of the 
object module I have built. I am assuming the embedded sha1 is that of 
fipscanister.o.

Hope that makes sense ?

Thanks.



From: Ethan Rahn
Sent: Monday, March 14, 6:11 PM
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is 
embedded in libcrypto.so
To: openssl-users@openssl.org

Is there a reason why you cannot build it from a controlled build environment 
and record the hash of the final .so?

It seems that it would be pretty non-trivial if not impossible to pull a .o 
file from a .so in the exact same format that it went in, such that you could 
check the hash. Being able to check if a .c file is in the same state in the 
.so afterwards seems pretty much impossible given all the things that would 
change in the code with compiling and linking in between the .c state and the 
final .so state.

On Mon, Mar 14, 2016 at 5:30 PM, Satya Das 
> wrote:

Hello,



I have a simple problem I am trying to solve. I have built a fips capable 
openssl shared object (.so). I also have the sha1 hash of the fipscanister.o in 
a file called fipscanister.o.sha1. I also have the sha1 hash of fips_premain.c 
in a file called fips_premain.c.sha1. In order to make sure the build is good, 
I want to make sure that the .so was indeed built with these versions of 
fipscanister.o and fips_premain.



Is there a way to do this ? I am on centos 6.6 x86_64 and linking to object 
module 2.0.11 from openssl 1.0.1e with patches.



Thanks

--
openssl-users mailing list
To unsubscribe: 
https://mta.openssl.org/mailman/listinfo/openssl-users


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

[Ethan Rahn]

Is there a reason why you cannot build it from a controlled build
environment and record the hash of the final .so?

It seems that it would be pretty non-trivial if not impossible to pull a .o
file from a .so in the exact same format that it went in, such that you
could check the hash. Being able to check if a .c file is in the same state
in the .so afterwards seems pretty much impossible given all the things
that would change in the code with compiling and linking in between the .c
state and the final .so state.

On Mon, Mar 14, 2016 at 5:30 PM, Satya Das  wrote:

> Hello,
>
>
>
> I have a simple problem I am trying to solve. I have built a fips capable
> openssl shared object (.so). I also have the sha1 hash of the
> fipscanister.o in a file called fipscanister.o.sha1. I also have the sha1
> hash of fips_premain.c in a file called fips_premain.c.sha1. In order to
> make sure the build is good, I want to make sure that the .so was indeed
> built with these versions of fipscanister.o and fips_premain.
>
>
>
> Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> object module 2.0.11 from openssl 1.0.1e with patches.
>
>
>
> Thanks
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

[Satya Das]

Hello,

I have a simple problem I am trying to solve. I have built a fips capable 
openssl shared object (.so). I also have the sha1 hash of the fipscanister.o in 
a file called fipscanister.o.sha1. I also have the sha1 hash of fips_premain.c 
in a file called fips_premain.c.sha1. In order to make sure the build is good, 
I want to make sure that the .so was indeed built with these versions of 
fipscanister.o and fips_premain.

Is there a way to do this ? I am on centos 6.6 x86_64 and linking to object 
module 2.0.11 from openssl 1.0.1e with patches.

Thanks
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [Question] What are the current secure Configure Parameter?

[Richard Moore]

On 14 March 2016 at 21:19, Oliver Niebuhr 
wrote:

> Am 14.03.2016 um 21:43 schrieb Richard Moore:
> > On 10 March 2016 at 04:42, Oliver Niebuhr  > > wrote:
> ​​
> > I am using OpenSSL from within the Qt Project / QtWebEngine.
> >
> > The Qt Wiki says, the following Parameters are minimum recommended:
> > no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
> >
> >
> > ​Please could you provide a link since these options are a bit dubious,
> > and don't match what I'd expect as the qtnetwork maintainer. I've looked
> > on the wiki myself and I don't see them.
> >
> > Cheers
> >
> > Rich.
>
> Evening.
>
> The following Link
> https://wiki.qt.io/Compiling_OpenSSL_with_MinGW
>
> (relatively outdated)
> under Section "How to Build" mentions not the no-ssl$ stuff.
>
>
​Yes, the no-ssl2 is fine, but the no-ssl3 seems unlikely to work with many
sites. Also Qt Web Engine uses the chromium network stack so the
requirements are different. I've asked the qtwebengine guys what the score
is.​



> But there was another Link which I can not find anymore - the last time
> I saw it, was around late of Summer 2015. It most likely got deleted
> during one of the "Wiki Cleanup Weeks".
>
> It was definitely not from the Nokia times and it was from a Digia
> Member - sorry my schizophrenic Brain is bad with Names.
>

​I'm afraid without more info I can't look into it - the wiki records the
history but I have to know what to look for.

Never mind.

Rich.
​
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [Question] What are the current secure Configure Parameter?

[Oliver Niebuhr]

Am 14.03.2016 um 21:43 schrieb Richard Moore:
> 
> 
> On 10 March 2016 at 04:42, Oliver Niebuhr  > wrote:
> 
> Hello.
> 
> I am using OpenSSL from within the Qt Project / QtWebEngine.
> 
> The Qt Wiki says, the following Parameters are minimum recommended:
> no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
> 
> 
> ​Please could you provide a link since these options are a bit dubious,
> and don't match what I'd expect as the qtnetwork maintainer. I've looked
> on the wiki myself and I don't see them.
> 
> Cheers
> 
> Rich.

Evening.

The following Link
https://wiki.qt.io/Compiling_OpenSSL_with_MinGW

(relatively outdated)
under Section "How to Build" mentions not the no-ssl$ stuff.

But there was another Link which I can not find anymore - the last time
I saw it, was around late of Summer 2015. It most likely got deleted
during one of the "Wiki Cleanup Weeks".

It was definitely not from the Nokia times and it was from a Digia
Member - sorry my schizophrenic Brain is bad with Names.

Greetings
Oliver



signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [Question] What are the current secure Configure Parameter?

[Richard Moore]

On 10 March 2016 at 04:42, Oliver Niebuhr 
wrote:

> Hello.
>
> I am using OpenSSL from within the Qt Project / QtWebEngine.
>
> The Qt Wiki says, the following Parameters are minimum recommended:
> no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
>

​Please could you provide a link since these options are a bit dubious, and
don't match what I'd expect as the qtnetwork maintainer. I've looked on the
wiki myself and I don't see them.

Cheers

Rich.
​
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [Question] What are the current secure Configure Parameter?

[Oliver Niebuhr]

Am 10.03.2016 um 14:49 schrieb Wall, Stephen:
> 
>> -Original Message-
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
>> Oliver Niebuhr
>>
>> The Qt Wiki says, the following Parameters are minimum recommended:
>> no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
>>
>> My Questions are:
>> 1.) Are there any other Parameters that should be used?
> 
> I also add no-comp -DOPENSSL_NO_HEARTBEAT no-md2.
> 
> no-md2 might be a default.
> 
> Check Configure Options at 
> https://wiki.openssl.org/index.php/Compilation_and_Installation for some 
> other things you might not need, like no-srp no-psk no-dtls no-npn no-krb5 
> etc.  If this is a dedicated library for your application, I suggest you 
> disable all features and ciphers you won't be using, for example, no-bf 
> no-sha1 no-md5 no-seed etc
> 
> If you control both ends, you could even distill it down to a single protocol 
> cipher suite, like ECDHE-ECDSA-AES128-GCM-SHA256 with TLS1.2.
> 
Thanks. I will take a look at it.

Oliver



signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Building 1.0.1g with "no-idea"

[Jason Schultz]

I have another question that was encountered at the same time as my previous 
one, but I believe it is two separate issues, so I created a different thread.

When building 1.0.2g and attempting to remove some ciphers at build time 
("no-idea"), I discovered that the Make scripting was attempting to build some 
of its files anyway:

[...]
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O2 -g 
-m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -std=gnu99 -Wa,--noexecstack -fomit-frame-pointer 
-DTERMIO -DPURIFY -DSSL_FORBID_ENULL -D_GNU_SOURCE -fstack-protector -Wall 
-Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM   -c -o e_bf.o e_bf.c
make[2]: *** No rule to make target `../../include/openssl/idea.h', needed by 
`e_idea.o'.  Stop.
make[2]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto/evp'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto'
make: *** [build_crypto] Error 1

It looks as though the "no-idea" removes some of the header files from the 
build, but then the make tries to compile the .c files anyway.

Has anyone else encountered this problem?

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Build of 1.0.1g fails

[Jason Schultz]

Greetings. I'm having problems building OpenSSL, starting with 1.0.1g. The 
scenario is as follows.

I'm not sure when the problem was introduced; however, with the compiling-out 
of SSLv2 *by default* in -1.0.2g, that change has exacerbated this problem.  
(That is, instead of affecting only those who selected "no-ssl2", it now 
affects everyone *except* those that explicitly select "ssl2".)

First, the existing package runs a self-test during the package build process.  
One of those tests verifies SSL (ssl/ssltest.c), and another verifies SSL usage 
when FIPS is active (test/testfipsssl).  The code in ssl/ssltest.c has a 
section that detects if the requested encryption mechanism has been disabled at 
build time ("compiled out").  If this situation is detected, an "OK" status is 
returned so that the test driver can determine what to do.  When FIPS is 
compiled, configured, and enabled, calling the SSL verification from 
test/testfipsssl to verify SSLv2 or SSLv3 support should result in a "Fail" 
status since neither SSLv2 nor SSLv3 is supported with FIPS.  However, when the 
"no-sslv2" and/or "no-sslv3" build options are selected, neither mechanism gets 
compiled in, so the SSL verification test detects this and immediately returns 
"OK" status.  Since FIPS is compiled, configured, and enabled, a "Fail" status 
is expected by test/testfipsssl instead, so the "OK" status that is re
 ceived because the ciphers are not present is handled as a test failure 
thereby aborting the build.

To make the package build correctly with "no-sslv2" or "no-sslv3" specified, I 
had to add the following:

Index: ssl/ssltest.c
===
--- ssl/ssltest.c (revision 4068)
+++ ssl/ssltest.c (working copy)
@@ -1203,8 +1203,20 @@
 if (no_protocol) {
 fprintf(stderr, "Testing was requested for a disabled protocol. "
 "Skipping tests.\n");
+#ifdef OPENSSL_FIPS
+/*
+ * If FIPS is enabled, then neither SSLv2 nor SSLv3 are permitted 
anyway.
+ * In this case, the fact that one or both are compiled-out is a good 
thing,
+ * so we continue onward to return the expected error status instead.
+ */
+if (!fips_mode || !FIPS_mode_set(1) || !(ssl2 || ssl3)) {
+ret = 0;
+goto end;
+}
+#else
 ret = 0;
 goto end;
+#endif
 }

 if (!ssl2 && !ssl3 && !tls1 && !dtls1 && !dtls12 && number > 1 && !reuse 
&& !force) {

Is this a known problem? Is there a solution available?

Thanks in advance.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 'makedepend' in openssl builds: clarify need and correct usage

[PGNet Dev]

On 03/14/2016 08:58 AM, PGNet Dev wrote:

On 03/14/2016 08:26 AM, PGNet Dev wrote:

Which I currently attempt to do, but get the reported errors about not
finding the stddef.h include etc.


Here,

  https://rt.openssl.org/Ticket/Display.html?id=4169=guest=guest

it simply says

  "fixed in 1.1"

There's no indication what the fix is -- use make depend, or don't use it?

And, no idea how we're _supposed_ to get to a successful/reliable build 
in 1.0.2x series.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 'makedepend' in openssl builds: clarify need and correct usage

[PGNet Dev]

On 03/14/2016 08:26 AM, PGNet Dev wrote:

Which I currently attempt to do, but get the reported errors about not finding 
the stddef.h include etc.


Specifically,

cd test
rm -rf *
wget https://www.openssl.org/source/openssl-1.0.2g.tar.gz
tar zxvf openssl-1.0.2g.tar.gz
cd openssl-1.0.2g

./config --openssldir=/home/work/sslTEST --libdir=lib64 \
 threads shared -D_GNU_SOURCE -DPURIFY -DTERMIO -fno-common 
-Wl,-rpath=/home/work/sslTEST/lib64 -Wa,--noexecstack 
-Wl,-z,relro,-z,now -Wall


...
Configured for linux-x86_64.

*** Because of configuration changes, you MUST do the following before
*** building:

make depend

make depend
making depend in crypto...
	make[1]: Entering directory 
'/home/work/openssl-1.0.2g/test/openssl-1.0.2g/crypto'
	makedepend: warning:  cryptlib.c (reading /usr/include/stdlib.h, line 
32): cannot find include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in ../include/stddef.h
not in /usr/include/stddef.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!

Already have
/usr/include/bits/types.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!

Already have
/usr/include/bits/types.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!

Already have
/usr/include/bits/types.h
	makedepend: warning:  cryptlib.c (reading /usr/include/sys/types.h, 
line 146): cannot find include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in ../include/stddef.h
not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/alloca.h, line 
24): cannot find include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in ../include/stddef.h
not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/string.h, line 
32): cannot find include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in ../include/stddef.h
not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/unistd.h, line 
226): cannot find include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in ../include/stddef.h
not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/stdio.h, line 
33): cannot find include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in ../include/stddef.h
not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/_G_config.h, 
line 15): cannot find include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in ../include/stddef.h
not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/wchar.h, line 
51): cannot find include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in ../include/stddef.h
not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/libio.h, line 
49): cannot find include file "stdarg.h"

not in ./stdarg.h
not in ../stdarg.h
not in ../include/stdarg.h
not in /usr/include/stdarg.h
	makedepend: warning:  cryptlib.c (reading ../include/openssl/buffer.h, 
line 68): cannot find include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in ../include/stddef.h
not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading ../include/openssl/bio.h, 
line 67): cannot find include file "stdarg.h"

not in ./stdarg.h
not in ../stdarg.h
not in ../include/stdarg.h
not in /usr/include/stdarg.h
	makedepend: warning:  o_str.c (reading o_str.h, line 63): cannot find 
include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in ../include/stddef.h
not in /usr/include/stddef.h
	makedepend: warning:  o_str.c (reading /usr/include/strings.h, line 
28): cannot find include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in ../include/stddef.h
not in /usr/include/stddef.h
	makedepend: warning:  o_dir.c (reading LPdir_unix.c, line 31): cannot 
find include file "stddef.h"

not in ./stddef.h
not in ../stddef.h
not in 

Re: [openssl-users] 'makedepend' in openssl builds: clarify need and correct usage

[PGNet Dev]

On 03/14/2016 08:24 AM, lists wrote:

Did you mean "./config ..."?


yep.


Must use it,

(1) https://wiki.openssl.org/index.php/Compilation_and_Installation
Dependencies

If you are prompted to run make depend, then you must do so.


Which I currently attempt to do, but get the reported errors about not 
finding the stddef.h include etc.



I cannot see exactly what is that you find confusing.


That the wiki says you don't need to,

"Compilation

 After configuring the library, you should run make. If prompted, 
there's usually no need to make depend since you are building from a 
clean download."


  ^^

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 'makedepend' in openssl builds: clarify need and correct usage

[lists]

On 03/10/2016 03:52 PM, PGNet Dev wrote:

I'm building openssl 1.0.2g on linux64.

After

./configure ...



Did you mean "./config ..."?


I'm prompted

Since you've disabled or enabled at least one algorithm, you need 
to do

the following before building:

make depend

Exec'ing the 'make depend' stage returns lots of warnings,

make depend
making depend in crypto...
make[1]: Entering directory 
'/usr/local/src/openssl/openssl-1.0.2g/crypto'
makedepend: warning:  cryptlib.c (reading 
/usr/include/stdlib.h, line 32): cannot find include file "stddef.h"

not in ./stddef.h
  [...]

On the distro, stddef.h is available at

/usr/include/linux/stddef.h
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/stddef.h
/usr/lib64/gcc/x86_64-suse-linux/5/include/stddef.h


Reading wiki & reports at openssl, there's confusing, if not 
conflicting, advice.


Must use it,

(1) https://wiki.openssl.org/index.php/Compilation_and_Installation
Dependencies

If you are prompted to run make depend, then you must do so. 
Its not just for developers who are updating sources. Its required to 
update the standard distribution once configuration options change.




In your specific case, it seems that you have disabled a protocol or 
cipher or whatever, in other words you have changed the default options.
I guess the "..." in your command means just that you are omitting some 
options.
So in such case you need "make depend". What is said in point (1) is 
correct.
For instance, if you compile some not-latest OpenSSL with -nossl2 (this 
is the current hype), compilation will fail unless you issue "make depend".
Sorry but I don't exactly understand how you are quoting the rest, so I 
cannot see exactly what is that you find confusing.



Don't need it

(2) https://wiki.openssl.org/index.php/Compilation_and_Installation
Compilation
After configuring the library, you should run make. If 
prompted, there's usually no need to make depend since you are 
building from a clean download.


(3) 
https://rt.openssl.org/Ticket/Display.html?id=3566=guest=guest
"Obviously this needs fixing but as a workaround: if 
you're building from scratch (or after "make clean") it should compile 
fine with without doing "make depend".




Re: 'makedepend',

https://en.wikipedia.org/wiki/Makedepend
makedepend was developed as part of MIT's Project Athena. It 
was used extensively in building X11 and ancillary packages, but has 
since become superseded by the dependency generation facilities of 
various compilers, and is now used primarily as a worst-case fallback, 
e.g. by depcomp and GNU Automake.


Further, a quick check (https://www.google.com/search?q=makedepend+stddef
) shows that there's a long history (unresolved?) re: not finding the 
sys's stddef.h


Digging around some more, I find that virtually the same issue was 
raised on openssl-dev in Apr 2015,


https://mta.openssl.org/pipermail/openssl-dev/2015-April/001263.html
[openssl-dev] `make depend`, advised by ./config, fails to find 
stddef.h in system/compiler path. old bug (#3566) says don't bother 
with `make depend`? true, or another bug?


with no reply at all.

What, then, IS the current need for 'makedepend' in openssl, and what, 
exactly, is the correct/recommended usage for its use in an openssl 
build?





--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] problems with s_client recognizing revoked intermediate/subordinate ca

[Michael]

This is not a check of the intermediate certificate as an actual
intermediate in a chain, this only checks it as a leaf certificate.
Your entire chain is just:



   root ---> revokedIntermediate


Yes - as a leaf of root, using the roots crl to see if any root-signed certs 
are revoked.


Try:
   openssl s_client -crl_check_all ...


Works! Great, thanks for the hint Viktor.
Just recognized, that the manpage lists the "crl_check_all" options right after the 
"crl_check", which i used... >_<

Using the crl_check_all it also complains about a missing crl now, when I 
remove the root's crl from the store.
This wasnt the case when using crl_check, which also wondered me a bit before.
Not it all makes sense :-)

Thanks again!


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users