I *think* this question on Stack Overflow is due to changing the
define associated with protocol negotiations: "Building curl from
sources - undefined reference to SSL_CTX_set_alpn_protos"
(http://stackoverflow.com/q/36404426). That is, OpenSSL 1.0.2 used
'no-npn' and OPENSSL_NO_NPN, while 1.1.0 us
On Mon, Apr 4, 2016 at 9:59 AM, Richard Levitte wrote:
> In message
> on
> Mon, 4 Apr 2016 13:56:03 +, "Salz, Rich" said:
>
> rsalz>
> rsalz> > I think we're deleting all engine code from LibreSSL, but at least
> one hunk of
> rsalz> > this diff is relevant to OpenSSL:
> rsalz> >
> rsalz>
Hi Everyone,
I'm working from Master, and testing an i686 build on x86_64. Is
building for i686 on x86_64 a supported configuration?
If so, I'm not sure what to make of this. Does this require a
full-blown cross-compile? (I feel like adding `-m32` is the wrong
thing to do because the configuratio
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/
On Tue, Mar 29, 2016 at 4:28 AM, Richard Levitte wrote:
> I suggest you read the docs, such as INSTALL. If you go down a bit,
> you'll find the section "Installation in Detail", and a little bit
> further, you'll find "1c. Configure OpenSSL for building outside of
> the source tree."
Perfect, th
>>> $ 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,
>>>
I'm trying to test an out-of-tree build. Configure does not appear to
document the switch; cf.,
http://github.com/openssl/openssl/blob/master/Configure.
There are $blddir and $srcdir variables, but searching for the
variables, 'tree' and 'build' don't appear to provide a hint.
Using a naive "--bl
This patch can be tightened further, if interested.
According to MS docs, the define _CRT_NONSTDC_NO_DEPRECATE is
available for Visual Studio 2005 (cl.exe=14.00). Also see
http://msdn.microsoft.com/en-us/library/ms235384(v=vs.80).aspx.
Testing on Visual Studio 2003 (cl.exe=13.10) shows the change
> # if defined(OPENSSL_SYS_UEFI) && !defined(ssize_t) # define ossl_ssize_t
> int # define OSSL_SSIZE_MAX INT_MAX # endif
>
> It's testing for a #define, not a typedef.
>
>
> Then I suppose this comes down to understanding precisely what the test is
> trying to achieve. Do you mean it's explicitl
On Sun, Mar 27, 2016 at 10:41 AM, Salz, Rich wrote:
> Is this a real problem or a theoretical one?
UEFI will be a problem on non 32-bit systems as it assume 32-bit
environment. I don't know if there are any of them in the wild,
however.
non-UEFI code is a problem in some restricted environments,
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
--
op
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
It looks like ordinals are changing and/or being removed for functions
exported by the Windows DLL. Its causing pain points for users in the
field, and it appears to be trending. Confer:
* WAMP OpenSSL ordinal 372 error, http://stackoverflow.com/q/36238887
* The Ordinal 112 could not be located
>> noloader> I don't believe you can test for a type by using 'defined(t)'. Also
>> noloader> see
>> http://stackoverflow.com/questions/12558538/how-can-i-check-a-certain-type-is-already-defined-in-c-compiler.
>>
>> ... unless it's defined with a macro
>
> Yeah, I kind of knew about that. But a ty
x and NetBSD.
Jeff
On Fri, Mar 25, 2016 at 11:39 AM, Jeffrey Walton wrote:
> 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:
X, Linux and NetBSD.
Jeff
On Fri, Mar 25, 2016 at 12:31 PM, Jeffrey Walton wrote:
> 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.
> Drepp
I'm on CentOS 5 with GCC 4.1.2. It appears there are side effects to
the union for the down level compiler.
Removing the union squashes the warning, but I like Viktor's idea and
placing a few of the larger types in it. I think its safer in the long
run.
Naming the union squashes the warning. The
On Sat, Mar 26, 2016 at 11:10 PM, Richard Levitte wrote:
> In message
> on Sat,
> 26 Mar 2016 18:14:05 -0400, Jeffrey Walton said:
>
> noloader> e_os2.h has this around line 260:
> noloader>
> noloader> # if defined(OPENSSL_SYS_UEFI) && !defined(ssize_t)
On Sat, Mar 26, 2016 at 6:44 PM, Viktor Dukhovni
wrote:
> On Sat, Mar 26, 2016 at 06:14:05PM -0400, Jeffrey Walton wrote:
>
>> e_os2.h has this around line 260:
>>
>> # if defined(OPENSSL_SYS_UEFI) && !defined(ssize_t)
>> # define ossl_ssize_t int
>>
Is this a supported configuration (no-ui and apps)?
There's a fair number of warnings when configuring with no-ui:
apps/enc.c:357:13: warning: implicit declaration of function
‘EVP_read_pw_string’ [-Wimplicit-function-declaration]
i = EVP_read_pw_string((char *)strbuf, SIZE, prompt,
e_os2.h has this around line 260:
# if defined(OPENSSL_SYS_UEFI) && !defined(ssize_t)
# define ossl_ssize_t int
# define OSSL_SSIZE_MAX INT_MAX
# endif
I don't believe you can test for a type by using 'defined(t)'. Also
see
http://stackoverflow.com/questions/12558538/how-can-i-check-a-certain-
On Thu, Mar 17, 2016 at 11:38 PM, Jeffrey Walton wrote:
> Hi Everyone,
>
> Looking at the code in engines/afalg/e_afalg.c, there is the following:
>
> ...
> #define K_MAJ 4
> #define K_MIN1 1
> #define K_MIN2 0
> #if LINUX_VERSION_CODE <= KERNEL
OpenSSL has a few scripts it uses for platforms like Android and iOS.
In addition, there are other helper scripts like incore_macho used on
the platforms.
As far as I know, the bits are not under version control. They are
available from the OpenSSL website once you know where to look. There
are al
On Fri, Mar 25, 2016 at 2:28 PM, Richard Levitte wrote:
> In message
> on Fri,
> 25 Mar 2016 14:16:59 -0400, Jeffrey Walton said:
>
> noloader> > Why do you want to be able to build on an OS released in 2012
> with a
> noloader> > C89-only compiler? I'
> It's the fact of its being defined which indicates features - it's tested in
> the GNU headers to decide what functionality to make visible. The norm is
> just to define it, or to define it to 1; setting it to __STRICT_ANSI__ would
> be a very confusing thing to do since the whole point of defini
> Just out of interest, what requirement is there to be able to build with
> compilers which support only a 27 year old version of C which was superseded
> 17 years ago? I can't imagine much need to build now with compilers which
> don't support at least the most popular features of C99 like inline
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
> Looking at the code in engines/afalg/e_afalg.c, there is the following:
>
> ...
> #define K_MAJ 4
> #define K_MIN1 1
> #define K_MIN2 0
> #if LINUX_VERSION_CODE <= KERNEL_VERSION(K_MAJ, K_MIN1, K_MIN2)
> # warning "AFALG ENGINE requires Kernel Headers >= 4.1.0"
> # warning "Skip
>> > $ 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_node_usage_stats_bio(const _LHASH *lh, BIO
>> > *out)
>> > $ 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_node_usage_stats_bio(const _LHASH *lh, BIO
>> > *out)
> You might want to try this:
>
> make CC=clang++ test
Doh, you're right. That's why I used 'export CC=clang++' in the first place.
http://www.youtube.com/watch?v=dO37Ql91qqM
> noloader> Is it being tested? If so, how is it being tested (I'd like to
> verify
> noloader> the results)?
>
> No
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
>> quality gate, and make the code pass through i
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
On Mon, Mar 21, 2016 at 4:02 AM, Richard Levitte wrote:
> Yes, there is such a configuration option: no-nextprotoneg
>
Thank you very much. That leads to:
gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
-DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSS
Is no-npn a supported configuration option for 1.1.0?
Its causing a test script to fail:
Testing no next protocol negotiation
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring OpenSSL version 1.1.0-pre5-dev (0x0x1015L)
* Unsupported options: no-npn
FAILED
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
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
> Point is, if any of the the assertions are triggered into faulting,
> there's a but in the library and it shouldn't get released. That's
> the whole point. The tests are supposed to catch those and basically
> raise a big red flag.
>
> Are you telling me that according to Apple's App Store poli
>> This is bad news... A 32-bit pointer's sign extension is
>> implementation defined, which means it may as well be undefined
>> behavior...
>>
>> GCC sign extends. I think you can get around it with an intermediate
>> cast to uintptr_t:
>>
>>cb->aio_buf = (uint64_t)(uintptr_t)buf;
>
> The ker
> noloader> Allowing a library to make policy decisions for the application is a
> noloader> philosophical debate.
>
> The few places we're using something that drastic is when the internal
> structures can only be seen as corrupt by our own fault. That's a
> point where you can expect things to g
On Sat, Mar 19, 2016 at 7:31 PM, Richard Levitte wrote:
> In message on Sat, 19
> Mar 2016 23:08:17 +, "noloa...@gmail.com via RT" said:
>
> rt> On Sat, Mar 19, 2016 at 6:44 AM, Richard Levitte via RT
> wrote:
> rt> > I think that's a discussion that deserves its own new thread on
> open
On Sat, Mar 19, 2016 at 6:44 AM, Richard Levitte via RT
wrote:
> I think that's a discussion that deserves its own new thread on openssl-dev.
>
> A RT ticket is *not* the right place for a philosophical discussion. Closing
> this. Please don't respond on this message, create a new thread instead.
On Fri, Mar 18, 2016 at 9:18 AM, Matt Caswell via RT wrote:
>
>
> On 18/03/16 12:52, noloa...@gmail.com via RT wrote:
>> I've configured with:
>>
>> ./config enable-afalgeng
>>
>> When I run the self tests, I see:
>>
>> ../test/recipes/30-test_afalg.t ... skipped: test_afalg not
>> s
On Thu, Mar 17, 2016 at 8:43 PM, Viktor Dukhovni
wrote:
>
>> On Mar 17, 2016, at 8:25 PM, noloa...@gmail.com via RT
>> wrote:
>>
>> Yeah, this looks fishy... According to the libc manual, 13.10 Perform
>> I/O Operations in Parallel
>> (https://www.gnu.org/software/libc/manual/html_node/Asynchron
>> Yeah, this looks fishy... According to the libc manual, 13.10 Perform
>> I/O Operations in Parallel
>> (https://www.gnu.org/software/libc/manual/html_node/Asynchronous-I_002fO.html):
>>
>>volatile void *aio_buf
>>
>>This is a pointer to the buffer with the data to
>>be writte
This might be a philosophical difference, but:
$ test/aborttest
test/aborttest.c:15: OpenSSL internal error: Voluntary abort
Abort trap
I don't believe its the library's place to shutdown an application.
Libraries don't make policy decisions for applications.
I think in this case, the libr
On Fri, Mar 18, 2016 at 9:46 PM, Richard Levitte via RT
wrote:
> In this case, though, it's an application that explicitely calls an
> aborting function. No subterfuge at all there, so if you wanted to
> complain, this is a particularly bad example.
>
> We do use OPENSSL_assert() in some places,
Hi Everyone,
Looking at the code in engines/afalg/e_afalg.c, there is the following:
...
#define K_MAJ 4
#define K_MIN1 1
#define K_MIN2 0
#if LINUX_VERSION_CODE <= KERNEL_VERSION(K_MAJ, K_MIN1, K_MIN2)
# warning "AFALG ENGINE requires Kernel Headers >= 4.1.0"
# warning "Skippin
On Fri, Mar 18, 2016 at 8:56 PM, Richard Levitte via RT
wrote:
> This is a non issue, the test comes through ok as expected. The printout is a
> bit ugly, sure, but...
>
> And I'd love if someone could figure out a good way not to have that output.
> My
> attempts failed miserably...
Oh, sorry
On Mon, Mar 14, 2016 at 10:52 AM, Andy Polyakov via RT wrote:
> On 03/14/16 03:58, noloa...@gmail.com via RT wrote:
>> Working from Master...
>>
>> gentoo@Gentoo-2012 ~/openssl $ ./config
>> Operating system: x86_64-whatever-linux2
>> ...
>
> Can you confirm that it's not a problem to compile "hel
On Mon, Mar 14, 2016 at 3:24 PM, Blumenthal, Uri - 0553 - MITLL
wrote:
> In that bug description I see a reference to code in “enc.c” that aborts
> if the cipher is AEAD or XTS (and an offer to submit PR that hasn’t
> materialized so far).
>
> Would you be able to elaborate why those checks that f
Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
32-bit tests OK.
The relevant snippets are:
$ make test
...
../test/recipes/90-test_async.t ... 1/1
# Failed test 'running asynctest'
# at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
# Looks like you failed 1 t
On Sun, Mar 13, 2016 at 7:56 PM, Richard Levitte via RT
wrote:
> Vid Sun, 13 Mar 2016 kl. 23.16.45, skrev noloa...@gmail.com:
>> On Sun, Mar 13, 2016 at 7:09 PM, Richard Levitte via RT
>> wrote:
>> > Vid Sun, 13 Mar 2016 kl. 22.05.21, skrev noloa...@gmail.com:
>> >> $ perl --version
>> >> This i
On Sun, Mar 13, 2016 at 7:09 PM, Richard Levitte via RT
wrote:
> Vid Sun, 13 Mar 2016 kl. 22.05.21, skrev noloa...@gmail.com:
>> $ perl --version
>> This is perl, v5.8.8 built for x86_64-linux-thread-multi
>
> This is a problem. We don't really support perl older than 5.10, so 5.8.x is
> potentia
>> static const uint64_t blake2b_IV[8] =
>> {
>> 0x6a09e667f3bcc908U, 0xbb67ae8584caa73bU,
>> 0x3c6ef372fe94f82bU, 0xa54ff53a5f1d36f1U,
>> 0x510e527fade682d1U, 0x9b05688c2b3e6c1fU,
>> 0x1f83d9abfb41bd6bU, 0x5be0cd19137e2179U
>> };
>>
>> I've run into this before, but in C++. I think
> static const uint64_t blake2b_IV[8] =
> {
> 0x6a09e667f3bcc908U, 0xbb67ae8584caa73bU,
> 0x3c6ef372fe94f82bU, 0xa54ff53a5f1d36f1U,
> 0x510e527fade682d1U, 0x9b05688c2b3e6c1fU,
> 0x1f83d9abfb41bd6bU, 0x5be0cd19137e2179U
> };
>
> I've run into this before, but in C++. I think you need
On Sun, Mar 13, 2016 at 6:48 AM, Richard Levitte via RT
wrote:
> Could you check again? I believe it should have been fixed when I did away
> with
> `sed` for dependency post-processing.
>
Yes, you're right. My bad.
Close it.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org
On Sun, Mar 13, 2016 at 6:57 AM, Kurt Roeckx via RT wrote:
> On Sun, Mar 13, 2016 at 10:30:54AM +, noloa...@gmail.com via RT wrote:
>> crypto/blake2/blake2b.c:27: warning: integer constant is too large for
>> 'unsigned long' type
>
> That's a uint64_t. Why do you have an "unsigned long" as 64
On Sun, Mar 13, 2016 at 6:14 AM, Richard Levitte via RT
wrote:
> Identified and corrected, waiting to pass internal review. I've attached the
> fix for your viewing and application before it lands in master.
>
It looks like the change was pushed with 6d505f2.
It tested OK under both 32-bit and
> ...
> Another potential pain point is PERL:
>
> grep -iIR perl * | grep '#' | grep -v 'env' | wc -l
> 232
>
> It looks like most uses of PERL are expected to be at
> /usr/local/bin/perl. 160 of them use /usr/bin/env, but 230 or so use
> the potentially incorrect path.
This is testing OK
On Thu, Mar 10, 2016 at 2:29 PM, noloa...@gmail.com via RT
wrote:
> Working from Master:
>
> $ git reset --hard HEAD && git pull
> HEAD is now at fb04434 In the recipe using "makedepend", make sure the
> object file extension is there
> Already up-to-date.
>
> $ ./config
> ...
> $ make depend && m
> OK, I've got two hung processes from two attempts to debug this:
>
> $ ps -A | grep afalgtest
> 1030 pts/000:00:00 afalgtest
> 1196 pts/000:00:00 afalgtest
>
> Both appear to be hanging in syscall 248:
>
> via:test$ sudo cat /proc/1030/syscall
> 248 0xb7fd6000 0x1 0x
>> It looks like the hang is still present as of 603358d.
>>
>> When the following runs:
>>
>> ../test/recipes/30-test_afalg.t
>>
>> What is actually running? How can I get it under a debugger?
>
>
> $ ./config -d
> $ make
> $ make test/afalgtest
> $ cd test
> $ OPENSSL_ENGINES=../engines/afalg
>> It looks like the hang is still present as of 603358d.
>>
>> When the following runs:
>>
>> ../test/recipes/30-test_afalg.t
>>
>> What is actually running? How can I get it under a debugger?
>
>
> $ ./config -d
> $ make
> $ make test/afalgtest
> $ cd test
> $ OPENSSL_ENGINES=../engines/afalg
The issue is present under 64-bit OS X PowerPC builds, also.
On Sat, Mar 12, 2016 at 11:33 PM, noloa...@gmail.com via RT
wrote:
> Working from Master at 4c1cf7e.
>
> $ KERNEL_BITS=32 ./config
> ...
> $ make depend && make clean && make
> ...
>
> cc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> -
I think this was closed earlier... retesting at 4c1cf7e confirmed the
issue was cleared.
On Thu, Mar 10, 2016 at 3:41 PM, noloa...@gmail.com via RT
wrote:
> Working from Master on a BeagleBone Black...
>
> $ git reset --hard HEAD && git pull
> HEAD is now at 0d4d5ab check reviewer --reviewer=emil
Bump... Still present in Master at 4c1cf7e.
On Fri, Mar 4, 2016 at 9:22 PM, noloa...@gmail.com via RT
wrote:
> cc -I.. -I../.. -I../modes -I../include -I../../include -DDSO_DLFCN
> -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE
> -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MO
On Fri, Mar 11, 2016 at 7:26 PM, Richard Levitte via RT
wrote:
> In message
> on Fri,
> 11 Mar 2016 19:12:27 -0500, Jeffrey Walton said:
>
> noloader> >> What is actually running? How can I get it under a debugger?
> noloader> >
> noloader> >
> n
>> What is actually running? How can I get it under a debugger?
>
>
> $ ./config -d
> $ make
> $ make test/afalgtest
> $ cd test
> $ OPENSSL_ENGINES=../engines/afalg gdb ./afalgtest
>
Ooh, -d looks like a new option. Would that be for Debug builds?
Jeff
--
openssl-dev mailing list
To unsubscribe
Close it; it was cleared around bb26842d1c8f99c1267b45361a2fc76822c0f913.
On Fri, Mar 11, 2016 at 5:11 AM, noloa...@gmail.com via RT
wrote:
> Working from Master.
>
> $ make test
> make: don't know how to make usr/include/stddef.h. Stop
>
> make: stopped in /root/openssl
--
openssl-dev mailing l
On Thu, Mar 10, 2016 at 2:29 PM, noloa...@gmail.com via RT
wrote:
> Working from Master:
>
It looks like the hang is still present as of 603358d.
When the following runs:
../test/recipes/30-test_afalg.t
What is actually running? How can I get it under a debugger?
Jeff
--
openssl-dev mail
On Fri, Mar 11, 2016 at 5:14 AM, Richard Levitte via RT
wrote:
> In message on Fri, 11
> Mar 2016 10:11:43 +, "noloa...@gmail.com via RT" said:
>
> rt> Working from Master.
> rt>
> rt> $ make test
> rt> make: don't know how to make usr/include/stddef.h. Stop
> rt>
> rt> make: stopped in /r
> noloader> Testing master on real hardware is showing some minor issues on a
> few
> noloader> platforms, including ARM32, ARM64, PowerPC and i686. In addition,
> noloader> there seems to be one-off issues on other combinations, like VIA's
> C7
> noloader> processor on Linux.
> noloader>
> noloa
Hi Everyone,
Testing master on real hardware is showing some minor issues on a few
platforms, including ARM32, ARM64, PowerPC and i686. In addition,
there seems to be one-off issues on other combinations, like VIA's C7
processor on Linux.
In addition to the base issues, there are other minor issu
On Thu, Mar 10, 2016 at 4:05 AM, Richard Levitte via RT
wrote:
> Sometimes, things happen fast.
>
> The diff I posted got into master just moments ago, commit
> d46057277f3b805e5f198e31fc81a892bf5c9141
>
> Still, please try it and report back so I can (hopefully) close this ticket.
OK, so I'm cl
On Tue, Mar 8, 2016 at 8:43 AM, Thomas Brunnthaler via RT
wrote:
> CURL not working since upgrade to 1.0.2g on windows. I use PHP 5.2.17 VC6
> x86 TS. Error Message: OS cannot load %1 or so.
>
Is it possible to release an out-of-band update for this fix?
Many folks are experiencing pain points b
On Mon, Mar 7, 2016 at 6:29 PM, Matt Caswell via RT wrote:
> Fix already on the way.
>
Thanks. I'm not sure what's triggering it on OS X because those
defines don't seem to show up in the configuration gear:
$ egrep -R 'EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK|OPENSSL_NO_MULTIBLOCK' * |
cut -d ':' -f 1
On Mon, Mar 7, 2016 at 3:57 PM, Jeffrey Walton wrote:
> On Sun, Mar 6, 2016 at 6:05 PM, Andy Polyakov wrote:
>>>> Hmm. So why do I see this on my macbook?
>>>>
>>>> $ arch
>>>> i386
>>>
>>> Try "uname -m"
>>
On Sun, Mar 6, 2016 at 6:05 PM, Andy Polyakov wrote:
>>> Hmm. So why do I see this on my macbook?
>>>
>>> $ arch
>>> i386
>>
>> Try "uname -m"
>
> This is not reliable. Because it must have changed recently, it used to
> be i386 even on 64-bit systems. sysctl -n hw.optional.x86_64 is the way
> to
On Mon, Mar 7, 2016 at 12:11 PM, Kaduk, Ben via RT wrote:
> On 03/04/2016 08:21 PM, noloa...@gmail.com via RT wrote:
>> OpenBSD uses GCC 4.2.1
>>
>
> This report would be more useful if it gave some indication of what
> version of the openssl source it corresponded to.
Oh, sorry about that Ben.
> Browsers have largely decided to implement GCM-modes only with AES128.
> Chrome is now about to change that. Not sure if other browsers will
> follow.
>
> Right now if you configure a server with openssl's cipher suite
> ordering it is likely that a connection will happen with AES256 in CBC
> mod
Hi Andy,
On Wed, Mar 2, 2016 at 6:59 AM, Andy Polyakov via RT wrote:
>> Patch attached. This is just a little cleanup change to fix not everything
>> using the OPENSSL_armcap constants. (Existing ones already are using them,
>> so I'm assuming this is okay.)
>
> Applied. Thanks.
Forgive my ignor
On Sun, Feb 28, 2016 at 12:18 AM, Viktor Dukhovni
wrote:
>
>> On Feb 27, 2016, at 7:42 PM, Jeffrey Walton wrote:
>>
>> Please ensure this is documented somewhere. I'm having trouble finding
>> information on the new rules.
>>
>> There's 15 or 20
>> Correct me if I am wrong... API's that start with capitol letters are
>> public. Private interfaces use lowercase letters.
>> Documented/undocumented does not really factor things.
>
> You're wrong. Once OpenSSL's past sins are remediated, public
> interfaces are precisely those that are docume
On Fri, Feb 26, 2016 at 12:42 PM, Viktor Dukhovni
wrote:
> On Fri, Feb 26, 2016 at 12:37:22PM -0500, Jeffrey Walton wrote:
>
>> It seems like (to me) the the most direct way to mark a function as
>> private is to add a comment in the source code stating such.
>
> Nonsense.
On Fri, Feb 26, 2016 at 12:29 PM, Salz, Rich wrote:
> As just about the only team member who trolls through RT and closes things
> with any quantity, I am not sure that I agree that fixing a bug requires
> documentation if the API isn't already documented.
+1. Concepts seem to be cross-pollinat
>> > I'd like to propose a policy of no bug fixes to undocumented public
>> > interfaces. If the interface is useful enough to fix, it has to be
>> > documented. Anyone care to produce manpages for EC_KEY_priv2buf or
>> > EC_KEY_priv2oct?
>> >
>> Correct me if I am wrong... API's that start with
>> > I have PR https://github.com/openssl/openssl/pull/739 with the below
>> > changes, please have a look.
>> >
>> > - In EC_KEY_priv2buf(), check for pbuf sanity.
>> > - If invoked with NULL, gracefully returns the key length.
> ...
> I'd like to propose a policy of no bug fixes to undocumented p
> ...
> F:\MingW32\src\inet\Crypto\OpenSSL\ssl\s3_lib.c :
> fatal error C1001: An internal error has occurred in the compiler.
> (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246)
>To work around this problem, try simplifying or changing the program near
> the locations l
On Sun, Feb 21, 2016 at 2:50 AM, Richard Levitte via RT
wrote:
> Would you try the attached patch, please?
>
Looks good for both 1.0.2 and Master.
Its also nice to see CHACHA_ENC and POLY1305_OBJ in the list below.
=
openssl-git $ ./config
Operating system: x86_64-pc-cygwin
Configuring fo
> I believe that the auto-detecting script, ./config, is lacking detection of
> architecture for Cygwin. Does one preferably recognise a x86_64 Cygwin from
> `uname -m` or is there something in `uname -s` that should be used as an
> indicator?
Yes, that seems to be the issue at hand for OpenSSL 1.
On Thu, Feb 11, 2016 at 3:46 PM, Andy Polyakov via RT wrote:
> Hi,
>
>> $ uname -a
>> Linux hikey 3.18.0-linaro-hikey #1 SMP PREEMPT Mon Nov 30 00:11:03 UTC
>> 2015 aarch64 GNU/Linux
>>
>> $ make test
>> ...
>> ../test/recipes/80-test_dane.t ok
>> ../test/recipes/80-test_ocsp.t ..
On Tue, Nov 17, 2015 at 12:43 PM, Jun Sun via RT wrote:
> Hi,
>
> I just found the perl script for x86_64 assembly failed to detect Xcode 7
> environment (Apple LLVM 7.x), and skipped generating AVX code for MAC OS
> ($avx variable is always false). The reason is Apple since Xcode 7.0 removed
>
1 - 100 of 133 matches
Mail list logo
