I'm working with a non-capable version of the library (I need to gt it
updated since release):
$ openssl version
OpenSSL 1.1.0-pre6-dev xx XXX
Looking at a question on another site, the OP provides:
With FIPS, compilation goes fine, but generates the following when run:
I'm working from the 1.0.2h tarball. The platform is Debian 8 (booted
with syscall.x32=y, but the X32 chroot was not entered). GCC is 5.2.1.
'-fPIC' was manually added after 'shared' caused the initial
"relocation R_X86_64_32 ..." error. Omitting 'shared' does not witness
an error.
$ reset && ./
On Tue, Jul 19, 2016 at 10:01 AM, Matt Caswell wrote:
>
>
> On 19/07/16 14:41, Richard Levitte via RT wrote:
>> Hi Jeff,
>>
>> I'm going to assume that a newer checkout of the master branch won't change
>> much, so if you please, try this command and send mack the result:
>
> Who is Mack? ;-)
>
>>
>> (gdb) r test/evptests.txt
>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>
>> Program received signal SIGBUS, Bus error.
>> CRYPTO_ccm128
> (gdb) bt full
> #0 0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
> No symbol table info available.
> #1 0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
> No symbol table info available.
> #2 0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
> No symbol table i
>> $ make test V=1
>>
>> ok 1 - running enginetest
>> ../util/shlib_wrap.sh ./enginetest => 0
>> ok
>> ../test/recipes/30-test_evp.t ..
>> 1..1
>> not ok 1 - running evp_test evptests.txt
>> ../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 135
>>
>> # Failed test 'running evp_
Attached is a patch that adds two Configure targets: linux-aarch32 and
linux-aarch32hf. It might make a good starting point for Aarch32
support.
The patch enables CRC and Crypto extensions by default. It allows the
library and users with custom engines to use the instructions to
offload to hardwar
Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
extensions, but includes vmull and crc32 (vmull include arrangements
other than u8). The gadget also runs Raspian, which is a 32-bit OS
with hard floats.
$ make t
Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
extensions, but includes vmull and crc32 (vmull include arrangements
other than u8). The gadget also runs Raspian, which is a 32-bit OS
with hard floats.
After Co
On Fri, Jul 8, 2016 at 8:33 AM, Salz, Rich via RT wrote:
> I don't know what you expect us to do. We don't use the LD variable.
Right. I'm just pointing out gaps.
It only gets worse for users. What happens when someone tries a
cross-compile by setting CC, AR, RANLIB, LD and a CFLAGS with
--sysr
On Fri, Jul 8, 2016 at 4:33 AM, Richard Levitte via RT wrote:
> On Fri Jul 08 07:47:14 2016, noloa...@gmail.com wrote:
>> $ ./config LD=ld.gold
>> Operating system: x86_64-whatever-linux2
>> Configuring for linux-x86_64
>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
>> target alread
$ ./config LD=ld.gold
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
target already defined - linux-x86_64 (offending arg: LD=ld.gold)
And:
$ LD=ld.gold ./config
Operating system: x86_64-whatever-linux2
Configuring
>From http://stackoverflow.com/q/38192458/608639:
jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
OPENSSL_cpuid_setup: error: undefined reference to 'sigfillset'
jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
OPENSSL_cpuid_setup: error: undefined reference
On Wed, Jun 29, 2016 at 5:19 PM, Richard Levitte via RT
wrote:
> This has nothing to do with Windows 10 per se, it's the space-in-directory
> issue that's come back.
> I'm working on a solution that should avoid that problem more consistently,
> going forward.
Close it; its good as of fe964f0c88
On Thu, Jun 30, 2016 at 12:52 PM, Salz, Rich via RT wrote:
>> I don't want either of them. I only want to install the library in the
>> directory of
>> my choosing :)
>
> #! /bin/sh
> make $* && cp *.a $MYDIR
>
> Less flippantly, not everything is supported :)
Thanks Rich.
So what are the new r
On Thu, Jun 30, 2016 at 11:29 AM, Jeffrey Walton wrote:
> On Thu, Jun 30, 2016 at 11:12 AM, Richard Levitte via RT
> wrote:
>> That's correct for 1.1.0. install_sw honors --prefix. We made that change to
>> get away from all the weird magic around the combinations of --prefix and
>> --openssldir
On Thu, Jun 30, 2016 at 11:12 AM, Richard Levitte via RT
wrote:
> That's correct for 1.1.0. install_sw honors --prefix. We made that change to
> get away from all the weird magic around the combinations of --prefix and
> --openssldir that happened in previous versions.
>
> In other words, it's no
Working on OS 10.8.5. Working from Master,
8a3c000c8f621cd01929313fcb7d0cc23fb516a6.
Using the following configure line:
$ KERNEL_BITS=64 ./config no-shared enable-ec_nistp_64_gcc_128
--openssldir=/usr/local/ssl/1.1.0
Later, when I attempt to compile:
$ gcc -I/usr/local/ssl/1.1.0/include test.c
Working on a Windows 10, 32-bit netbook. HEAD,
03cb37acec0c23a01bee4357cd59ec9f97e528ba.
It looks like configure dies if it can't find NASM. Perhpas it would
be better to automatically add no-asm.
Once NASM is added, Configure dies because it tries to write outside
%HOME%. Windows 8 used to toler
The attached adds Git repo information if its available.
In the "things work as expected" case, the repo information is
available. It will be submitted with bug reports when configuration
information is provided.
In the "its not a repo" case, then the call to system fails and
nothing is printed.
On Thu, Jun 23, 2016 at 6:18 AM, Jeffrey Walton wrote:
> Here's a couple more ways things don't work as expected:
>
> # ./config CFLAGS="-mx32"
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> target already de
>> # ./config -mx32
>> Operating system: x86_64-whatever-linux2
>> Configuring for linux-x86_64
>>
>> Perhaps the second case should fail at configure just like the first
>> case. Upon failure, it would be nice to tell the user what to do:
>> "Please configure with ./Configure linux-x32"
>
> Well,
On Thu, Jun 23, 2016 at 7:10 AM, Andy Polyakov via RT wrote:
A quick question about this configuration... Should Linux-x32 enable
ec_nistp_64_gcc_128 by default? Does anything prohibit
ec_nistp_64_gcc_128 in this configuration?
# ./Configure linux-x32
Configuring Open
I'm working on a Debian X32 system (http://wiki.debian.org/X32Port),
and working from HEAD:
# git rev-parse HEAD
b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92
Running 'make test' under a machine configured with './Configure
linux-x32 enable-ec_nistp_64_gcc_128' results in two failed self
test
On Thu, Jun 23, 2016 at 6:52 AM, Andy Polyakov via RT wrote:
>> A quick question about this configuration... Should Linux-x32 enable
>> ec_nistp_64_gcc_128 by default? Does anything prohibit
>> ec_nistp_64_gcc_128 in this configuration?
>>
>> # ./Configure linux-x32
>> Configuring OpenSSL version
On Thu, Jun 23, 2016 at 6:44 AM, Andy Polyakov via RT wrote:
>> you're not allowed to break the compile, regardless of whether there's
>> a proper "X32" kernel.
>
> I don't understand what do you mean by "break the compile". I'd say it's
> the kind of thing that lies on both parties. We are respon
On Thu, Jun 23, 2016 at 6:31 AM, Andy Polyakov via RT wrote:
>>> Here's a couple more ways things don't work as expected:
>>>
>>> # ./config CFLAGS="-mx32"
>>> Operating system: x86_64-whatever-linux2
>>> Configuring for linux-x86_64
>>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
>
On Thu, Jun 23, 2016 at 6:25 AM, Andy Polyakov via RT wrote:
>> Here's a couple more ways things don't work as expected:
>>
>> # ./config CFLAGS="-mx32"
>> Operating system: x86_64-whatever-linux2
>> Configuring for linux-x86_64
>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
>> targ
Here's a couple more ways things don't work as expected:
# ./config CFLAGS="-mx32"
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32)
# ./config -mx32
As far as I know, these are the two ways to detect the platform
because `uname` only provides x86_64/amd64 on some platforms:
# gcc -dM -E - -
> I'm working on a Debian X32 system (http://wiki.debian.org/X32Port),
> and worki
I'm working on a Debian X32 system (http://wiki.debian.org/X32Port),
and working from HEAD:
# git rev-parse HEAD
b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92
It appears Configure is mis-detecting the platform, and it results in
a compile failure:
make
...
gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDE
>> ../test/recipes/30-test_evp.t ..
>> 1..1
>> Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH
>> Expected:
>> 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4
The following is from a CubieBoard. I verified I performed a 'make
clean' and 'git pull'.
$ git rev-parse HEAD
13c03c8d6da334bb1cde6ce4133e7c75b3b76947
**
using V=1:
../test/recipes/30-test_evp.t ..
1..1
Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH
Expec
On Tue, Jun 14, 2016 at 3:43 AM, Richard Levitte via RT
wrote:
> Cool. That closes this ticket.
Thank you very much.
> BTW, you're right, we don't honor a CFLAGS env var. We never did. We take the
> cflags on the configuration command line.
There's always hope. Its eternal :)
Jeff
--
Ticke
On Tue, Jun 14, 2016 at 3:33 AM, Richard Levitte via RT
wrote:
> Is this enough to satisfy you?
>
> ./config -DNDEBUG -g3 -O0
Yes, that would be good.
no-asm and no-omit-frame-pointer on x86 may be good choices, too.
Jeff
> On Tue Jun 14 07:24:31 2016, noloa...@gmail.com wrote:
>> Working fro
Working from latest sources. I'm trying to build a "debug"
configuration with both -DNDEBUG (I don't want asserts firing) and -g3
(I want the symbolic constants).
$ ./config no-asm -g3 -O0 -fno-omit-frame-pointer
Operating system: i86pc-whatever-solaris2
Configuring for solaris64-x86_64-gcc
Config
Close. It looks like it was cleared with Commit
5ec84dd75f7965942a55ef5382aa34b8417336c5.
On Mon, Jun 13, 2016 at 4:12 PM, Jeffrey Walton wrote:
> Just pulled latest source (Camellia changes):
>
> $ git rev-parse HEAD
> 96d06c213d5a2c1af42dd3b5d7bcc4a65df90738
>
> Config OK, Make fails at. Verif
Just pulled latest source (Camellia changes):
$ git rev-parse HEAD
96d06c213d5a2c1af42dd3b5d7bcc4a65df90738
Config OK, Make fails at. Verified twice:
SHOBJECTS="./libcrypto.a "; ( :;LIBDEPS="${LIBDEPS:--lresolv
-lsocket -lnsl -ldl}"; SHAREDCMD="${SHAREDCMD:-gcc}";
SHAREDFLAGS="${SHAREDFLAGS
On Mon, Jun 13, 2016 at 12:32 PM, Matt Caswell via RT wrote:
> On Wed Jun 01 22:20:38 2016, matt wrote:
>> Hi Jeff
>>
>> Please could you try the attached patch?
>
>
> Jeff confirmed to me that the patch solved the problem. Pushed as commit
> 25b9d11c0.
Confirmed.
Its a good, clean patch. It det
On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT wrote:
> Please give us the full configuration command you used, including environment
> variables that may affect it. Just the presence of '-ansi' tells me that you
> didn't just say './config' without any arguments.
I know what happened her
On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT wrote:
> Please give us the full configuration command you used, including environment
> variables that may affect it. Just the presence of '-ansi' tells me that you
> didn't just say './config' without any arguments.
Sorry Richard. Yes, it w
So testing with 1.1.0-pre6 from 1 JUN 2016 appears to show some new issues.
./config detects as i686-linux-whatever. However, there are some
issues with CFLAGS. The '-arch x86_64' makes it appear to be
configured for quasi-OS X mode. I believe -m32 should be used if an
arch is needed. There's also
It looks like there's still some problems with our old friend afalgtest.
Below is from 1.1.0-pre6 on 1 JUN 2016
**
$ cat gentoo-result.txt
( cd test; \
SRCTOP=../. \
BLDTOP=../. \
PERL="/usr/bin/perl" \
EXE_EXT= \
OPENSSL_ENGINES=.././engines \
/usr/bin/perl .././test/run_t
On Tue, May 10, 2016 at 6:27 PM, Andy Polyakov via RT wrote:
>> This seems like an odd result considering the BeagleBone Black
>> processor is closer to a NEON.
>
> Well, ./config script should add -march=armv7-a option and that is more
> than enough to make it NEON-capable. In fact linux-armv4 ta
> Please could you try the attached patch?
It tested OK. 'make test' executed without any problems. Ship it and
close the ticket.
Jeff
On Wed, May 11, 2016 at 6:24 AM, Matt Caswell via RT wrote:
> On Sat Mar 05 02:22:00 2016, noloa...@gmail.com wrote:
>> cc -I.. -I../.. -I../modes -I../include
Hi Matt,
I'm testing this now.
Jeff
On Tue, May 24, 2016 at 6:42 PM, Matt Caswell via RT wrote:
> On Wed May 11 10:24:31 2016, matt wrote:
>> Hi Jeff
>>
>> Please could you try the attached patch?
>
> Hi Jeff
>
> Were you able to try out the patch?
>
> Thanks
>
> Matt
>
> --
> Ticket here: htt
Also see http://stackoverflow.com/q/37517730
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4547
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Close it; no longer seeing it with the 25c7844 pull.
On Sat, Apr 2, 2016 at 4:40 PM, The default queue via RT
wrote:
>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "Failed compile on ARM32 (BeagleBone Black)
Working from Master on another ARM32 gadget with more resources
LD_LIBRARY_PATH=.: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG
-DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_
Working from Master. It looks like the build system is having some
issues with resource constrained devices due to "Warning: end of file
in comment; newline inserted". It usually indicates a Out-Of-Memory
(OOM) kill occurred.
There's also a compile problem with Cha-Cha.
This appears to be new beh
On Tue, Mar 29, 2016 at 9:53 AM, Salz, Rich via RT wrote:
> We use strdup because none of the openssl machinery (error stack, etc) might
> be set up yet.
>
> The comment a few lines above says this!
Thanks.
That does not explain why this had not effect on Windows, even after
including "openssl/
>>> $ cat conf_lib.patch
>>> diff --git a/crypto/conf/conf_lib.c b/crypto/conf/conf_lib.c
>>> index f197714..7bc3ac0 100644
>>> --- a/crypto/conf/conf_lib.c
>>> +++ b/crypto/conf/conf_lib.c
>>> @@ -392,7 +392,7 @@ void
>>> OPENSSL_INIT_set_config_filename(OPENSSL_INIT_SETTINGS *settings,
>>>
Unix and Linux builds have problems when the path includes spaces.
In-tree is witnessing the issue, and out-of-tree may experience the
issue.
This problem was observed on Windows due to "C:\Program Files" and
"C:\Documents and Settings"; see Issues 4486 and 4490. Windows uses
UAC, which means make
Working from Master at c5c7700c9a1c1daa.
Strawberry PERL 5.22
Windows XP x64 (as fully patched as it can be)
Visual Studio 2005 (as fully patched as it can be)
Source directory: C:\openssl-src
Install directory: C:\OpenSSL
**
C:\openssl-src>nmake install
Microsoft (R) Program Maintenanc
_close
+# define strdup _strdup
+# define unlink _unlink
+# endif
# elif defined(OPENSSL_SYS_VMS)
/* VMS below version 7.0 doesn't have strcasecmp() */
# include "internal/o_str.h"
On Mon, Mar 28, 2016 at 2:59 AM, noloa...@gmail.com via RT
wrote:
> Working from master at c5c7700
On Windows, the fix below also depends upon the patch from Issue 4488
("The POSIX name for this item is deprecated. Instead, use the ISO C++
conformant name...").
This patch below also fixes some problems with the older standards on
Fedora, BSD and Linux.
$ cat conf_lib.patch
diff --git a/crypto/
Working from master at c5c7700c9a1c1daa.
The patch below fixes multiple "The POSIX name for this item is
deprecated. Instead, use the ISO C++ conformant name..." warnings on
Windows. There are about 20 of them, and an example is below.
diff --git a/e_os.h b/e_os.h
index f0a441e..c9765c2 100644
--
On Fri, Mar 25, 2016 at 8:10 AM, Hanno Boeck via RT wrote:
> Attached is a sample code that will test various inputs for the
> Poly1305 functions of openssl...
I'm seeing compiler conversion warnings about size_t to int
truncation. Do you have any vectors that cross the 2GB boundary?
Jeff
--
On Fri, Mar 25, 2016 at 7:05 PM, Richard Levitte via RT
wrote:
> I've attached a tentative patch for test/recipes/bc.pl. Would you be willing
> to
> try it out?
OpenSSL master (c828cd7) experienced what appeared to be the same
issue under Windows 7 Pro x64 with Strawberry PERL 5.22. The machine
There's a somewhat dirty compile under Windows 7 Pro x64 and Visual Studio 2012.
cl -DDSO_WIN32 -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_P
IC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENS
SL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DM
Using Strawberry PERL from a typical Windows user desktop and working
from Master at c828cd7...
> cls && perl Configure VC-WIN32
...
> nmake
Microsoft (R) Program Maintenance Utility Version 11.00.61030.0
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1073: don't
Updated to print the options used when a failure occurs; add
additional test configurations, like "no-asm -ansi".
The QA/Testing team should try the script. Its very revealing. Here's
what I am seeing:
$ grep '!!' openssl-result.txt
!!FAILED (no-aes)!!
!!FAILED (no
I'm thinking this should be closed because the compile problem can be
worked around with "./config no-async". "./config no-async" worked on
both CentOS 5 and BSD 5.7 (both lack the headers).
I suppose it can be kept open if someone feels Configure should
auto-detect the feature. I'm in this camp b
The rollup was updated to include both -ansi and -std=c90.
Nearly all the pieces were available to support it. The patch simply
needed better integration with existing library facilities. For
example, there's an OPENSSL_strdup() for strdup(), there's workarounds
for strncmpcase() that performs the
The rollup was updated to include both -ansi and -std=c90.
Nearly all the pieces were available to support it. The patch simply
needed better integration with existing library facilities. For
example, there's an OPENSSL_strdup() for strdup(), there's workarounds
for strncmpcase() that performs the
On Fri, Mar 25, 2016 at 1:00 PM, Richard Levitte via RT
wrote:
> Vid Fre, 25 Mar 2016 kl. 10.29.39, skrev noloa...@gmail.com:
>> gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
>> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC
>> -DOPENSSLDIR="\"/usr/local/ssl\""
>> -DENGINESDIR="\"/usr/local/lib/engi
On Fri, Mar 25, 2016 at 12:49 PM, Richard Levitte via RT
wrote:
> Vid Fre, 25 Mar 2016 kl. 16.31.14, skrev noloa...@gmail.com:
>> To configure:
>>
>> ./config shared no-asm -ansi -D_DEFAULT_SOURCE=__STRICT_ANSI__
>>
>> I'm not sure if Configure should set _DEFAULT_SOURCE=__STRICT_ANSI__
>> automa
Here's the rollup patch that makes -ansi work. Most of it was "inline"
-> "ossl_inline".
Some hoops were jumped through to get SSIZE_MAX defined correctly.
Drepper signed-off on roughly the same fix about 15 years ago for
glibc; see http://sourceware.org/ml/libc-hacker/2002-08/msg00031.html.
To c
Here's the rollup patch that makes -ansi work. Most of it was "inline"
-> "ossl_inline". Some hoops were jumped through to get SSIZE_MAX
defined correctly.
To configure:
./config shared no-asm -ansi -D_DEFAULT_SOURCE=__STRICT_ANSI__
I'm not sure if Configure should set
_DEFAULT_SOURCE=__STRI
Cancel this. This was not an ASM error; it was inline artifacts froma
previous build.
On Fri, Mar 25, 2016 at 11:11 AM, The default queue via RT
wrote:
>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "Ubuntu i
Working from Master at 7793e17440539b7. x86_64 is OK.
To get to e_afalg.c in the compile, you will need to change "inline"
-> "ossl_inline".
$ ./config shared no-asm -ansi -D_DEFAULT_SOURCE=__STRICT_ANSI__
...
$ make
...
engines/afalg/e_afalg.c: In function ‘afalg_fin_cipher_aio’:
engines/afal
This can be closed. Somehow it managed to split from the original bug.
On Thu, Mar 10, 2016 at 2:29 PM, The default queue via RT
wrote:
>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "VIA C7-D processor: Hang
This should fix the missing SSIZE_MAX on GNU systems when -ansi is in
effect (and posix is not available). Also see
https://sourceware.org/ml/libc-hacker/2002-08/msg00031.html.
diff --git a/include/openssl/e_os2.h b/include/openssl/e_os2.h
index bbd6116..73058c0 100644
--- a/include/openssl/e_os2.
$ git diff crypto/async/arch/async_posix.h > async_posix.h.patch
$ cat async_posix.h.patch
diff --git a/crypto/async/arch/async_posix.h b/crypto/async/arch/async_posix.h
index de80f95..968358f 100644
--- a/crypto/async/arch/async_posix.h
+++ b/crypto/async/arch/async_posix.h
@@ -74,7 +74,7 @@ typed
$ git diff crypto/async/arch/async_posix.h > async_posix.h.patch
$ cat async_posix.h.patch
diff --git a/crypto/async/arch/async_posix.h b/crypto/async/arch/async_posix.h
index de80f95..968358f 100644
--- a/crypto/async/arch/async_posix.h
+++ b/crypto/async/arch/async_posix.h
@@ -74,7 +74,7 @@ typed
It looks like the defines of interest here to use inline are:
$ gcc -ansi -dM -E - ansi.txt
$ gcc -dM -E - no-ansi.txt
$ diff ansi.txt no-ansi.txt
147a148
> #define linux 1
193d193
< #define __STRICT_ANSI__ 1
228a229
> #define unix 1
> Working from Master at 7793e17440539b71 on Ubuntu 14 mac
It looks like the defines of interest here to use inline are:
$ cc -ansi -dM -E - ansi.txt
$ cc -dM -E - no-ansi.txt
$ diff ansi.txt no-ansi.txt
65d64
< #define __GNUC_GNU_INLINE__ 1
67a67
> #define __GNUC_STDC_INLINE__ 1
140a141
> #define __STDC_VERSION__ 199901L
142d142
< #define __STRICT_ANS
Working from Master at 7793e17440539b71 on Ubuntu 14 machine. Also see
http://stackoverflow.com/questions/13870489/is-inline-asm-part-of-the-ansi-c-standard.
$ ./config shared no-asm -ansi
...
$ make -k
...
gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC
Working from Master at 7793e17440539b71 on OS X 10.8. Also see
http://stackoverflow.com/questions/13870489/is-inline-asm-part-of-the-ansi-c-standard.
$ KERNEL_BITS=64 ./config shared no-asm -ansi
...
$ make -k
...
cc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
-DOPENSSL_NO_STATIC_ENGINE -DOPENSS
Some of PKCS#12 is documented, others are not. This adds missing
documentation for PKCS12_newpass.
The documentation should be placed at "doc/crypto/PKCS12_newpass.pod".
The full test program for EXAMPLE is attached.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4478
Please log i
This clears what looks to be hundreds of alignment related warnings like below.
$ git diff include/openssl/lhash.h
diff --git a/include/openssl/lhash.h b/include/openssl/lhash.h
index 2edd738..5da5054 100644
--- a/include/openssl/lhash.h
+++ b/include/openssl/lhash.h
@@ -180,7 +180,7 @@ void lh_no
$ ./config -Wstrict-overflow
...
$ make
...
crypto/asn1/a_strex.c: In function ‘do_print_ex.constprop.3’:
crypto/asn1/a_strex.c:385:12: warning: assuming signed overflow does
not occur when simplifying conditional to constant [-Wstrict-overflow]
if (len < 0)
^
crypto/asn1/a_s
This turned out to be a kernel bug. The userland crypto interface was
known to have some problems, and the kernel checked in changes to the
2.6 kernel in January 2016. Distro's were cherry picking them for
2.8-4.5, but some needed ones got missed (q.v.).
According to and comment 3 at
https://bugs.
On Thu, Mar 24, 2016 at 3:41 AM, Richard Levitte via RT
wrote:
> Vid Thu, 24 Mar 2016 kl. 07.23.46, skrev levitte:
>> Vid Ons, 23 Mar 2016 kl. 23.47.19, skrev noloa...@gmail.com:
>> > I'm not sure if this is a supported configuration, but I'm guessing
>> > there are going to be users in the filed
On Thu, Mar 24, 2016 at 3:23 AM, Richard Levitte via RT
wrote:
> Vid Ons, 23 Mar 2016 kl. 23.47.19, skrev noloa...@gmail.com:
>> I'm not sure if this is a supported configuration, but I'm guessing
>> there are going to be users in the filed who find themselves in it,
>> like http://stackoverflow.
On Thu, Mar 24, 2016 at 12:52 AM, Viktor Dukhovni
wrote:
>
>> On Mar 24, 2016, at 12:38 AM, noloa...@gmail.com via RT
>> wrote:
>>
>> I can understand lack of resources.
>>
>> Lack of interest can be dealt with in the engineering process. Place a
>>
On Wed, Mar 23, 2016 at 10:16 PM, Salz, Rich via RT wrote:
>
>> The configuration should only be avoided/abandoned due to technical
>> reasons, and not philosophical principals.
>
> Lack of resources and interest.
I can understand lack of resources.
Lack of interest can be dealt with in the engi
On Wed, Mar 23, 2016 at 8:32 PM, Rich Salz via RT wrote:
> You can link C++ against openssl API because of the extern C wrapper we use.
That's what I was on my way to testing.
> You cannot compile openssl with a C++ compiler. Closing ticket. (The days of
> "C++ is a better C" went away a long lo
I'm not sure if this is a supported configuration, but I'm guessing
there are going to be users in the filed who find themselves in it,
like http://stackoverflow.com/q/36188982.
Working from the tip of Master...
$ export CC=g++
$ ./config
...
$ make
...
g++ -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_T
Updated to fix the additional options, like "-g2 -Os"
On Tue, Mar 22, 2016 at 8:53 AM, The default queue via RT
wrote:
>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "FEATURE: OpenSSL test script for configur
Hi Everyone,
Attached is a test script to repeatedly configure, build and test
OpenSSL under different configuration options. Options include the
usual suspects like "no-asm", "no-ssl2", "no-ssl3" and "no-comp". It
also includes other options, like Debug, Release, IPv4 and IPv6.
I understand some
Still present at 149bd5d6cb393648. If I './config shared', then the
issue goes away.
The only difference I see is the absence of "no-dynamic-engine
[forced]" when "shared" is used.
Here's the config with shared:
openssl> ./config shared
Operating system: x86_64-whatever-linux2
Configuring for li
$ ./config -fsanitize=undefined
...
$ make test HARNESS_VERBOSE=yes
...
../test/recipes/05-test_cast.t
1..1
crypto/cast/c_enc.c:78:5: runtime error: shift exponent 32 is too
large for 32-bit type 'unsigned int'
crypto/cast/c_enc.c:111:5: runtime error: shift exponent 32 is too
large f
INSTALL details the way to obtain verbose output is with:
HARNESS_VERBOSE=yes make test
That is kind of non-standard for autotools, cmake and kbuild users.
Users of those tools (including various OpenSSL package maintainers)
are accustomed to output being sometimes hidden from them, and they
Just pulled 89ff989 and the issue is gone. Close it.
On Sun, Mar 20, 2016 at 9:28 PM, The default queue via RT
wrote:
>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "No rule to make target 'crypto/include/int
On Sun, Mar 20, 2016 at 9:29 PM, Salz, Rich via RT wrote:
>
>> $ make depend && make clean && make
>> ...
>>
>> No rule to make target 'crypto/include/internal/blake2_locl.h'
>
> Shouldn't that be clean ; make depend?
>
> At any rate, yes, some header files moved around. Old dependencies are out
Working on Gentoo 13, x86_64 with a 4.1 kernel. Master at 89ff989d01314a61.
$ git reset --hard HEAD && git pull
HEAD is now at 89ff989 Add a comment on dane_verify() logic
Already up-to-date.
$ ./config
...
$ make depend && make clean && make
...
No rule to make target 'crypto/include/internal/b
On Sun, Mar 20, 2016 at 6:20 PM, David Benjamin via RT wrote:
> Patch attached. This is a mechanical change. BIO_new takes a non-const
> BIO_METHOD and the various BIO_METHODs defined in the library are also
> non-const, so they don't get placed in .rodata.
>
> The change to BIO_new and the BIO st
On Sun, Mar 20, 2016 at 2:45 PM, Richard Levitte via RT
wrote:
> '#include ' should be added in e_os.h rather than ssl/ssl_locl.h
>
Thanks.
Would it be possible to add , , and
? Then all these tickets can be closed.
It should also allow moving onto Android testing. Android, Cygwin and
early Fe
Well, this appears to be cleared as of commit 270862b470d43a28 (likely
well before the commit). The test programs compile and complete with
success.
Is this what is intended for command lines? It looks a tad bit odd to
me, and I wonder if there are potential problems lurking behind the
scenes.
gc
1 - 100 of 282 matches
Mail list logo
