On Sun, Jun 30, 2013 at 5:54 PM, Andy Polyakov via RT wrote:
>>...
> OpenSSL doesn't have any floating point, at least not on
> performance-critical paths,
I believe the PRNG interface uses floating point operations
(specifically, for the estimate of entropy).
Jeff
___
Reference:
http://openssl.6102.n7.nabble.com/openssl-org-3068-PATCH-Safari-broken-ECDHE-ECDSA-workaround-td45432.html
and http://openssl.6102.n7.nabble.com/Apple-are-apparently-dicks-td45512.html.
BL > ...and don't intend to fix their broken ECDSA support in Safari.
Apple really needs to fix thei
On Tue, Dec 10, 2013 at 7:06 AM, Rob Stradling wrote:
> On 09/12/13 23:34, Jeffrey Walton wrote:
>>
>> Reference:
>> http://openssl.6102.n7.nabble.com/openssl-org-3068-PATCH-Safari-broken-ECDHE-ECDSA-workaround-td45432.html
>> and
>> http://openssl.6102.n7.nabb
*) Integrate hostname, email address and IP address checking with certificate
verification. New verify options supporting checking in opensl utility.
[Steve Henson]
*) Fixes and wildcard matching support to hostname and email checking
functions. Add manual page.
[Florian
Matt -
I have not forgot about this I can't find the machine I wrote the
code on (my place probably looks a lot like your place - different
computers and laptops with different OSes all over the place).
Looking at the return values, I don't believe Test 3 should have failed.
Also, add a test
> Since this may in future cover much more than just AES-NI...
Good observation Doctor, done. Attached is the updated text.
diff --git a/doc/crypto/EVP_EncryptInit.pod b/doc/crypto/EVP_EncryptInit.pod
index f6e4396..8d7636c 100644
--- a/doc/crypto/EVP_EncryptInit.pod
+++ b/doc/crypto/EVP_EncryptIn
On Sun, Jul 6, 2014 at 6:06 PM, David Jacobson wrote:
>> On 7/6/14 1:44 PM, Andy Polyakov via RT wrote:
>> ...
>>
>> As for warning. I personally would argue that we are looking at
>> platform-specific i.e. implementation-defined behaviour, not undefined.
>> Once again, this applies to all three t
On Tue, Jul 8, 2014 at 4:33 PM, Andy Polyakov via RT wrote:
> As for warning. I personally would argue that we are looking at
> platform-specific i.e. implementation-defined behaviour, not undefined.
> Once again, this applies to all three tickets. One is effectively
> identical to
On Wed, Aug 20, 2014 at 10:12 AM, Salz, Rich wrote:
>> Minor clarification is appropriate. MSDOS is supported in single "stance",
>> namely DJGPP, which is 32-bit environment.
>
> Good point.
>
> So the idea is that MSDOS gets turned into DJGPP. BEOS and OS/2 are removed
> in HEAD (i.e., after 1
Oops, thanks Rich.
On Tue, Aug 26, 2014 at 10:06 AM, Rich Salz via RT wrote:
> The key is not optional with the -hmac option.
> This is fixed in the rsalz-monolith branch of akamai/openssl on github, to be
> rpart of release after 1.0.2
> thanks.
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.
Thanks for the patch.
Is there a way to compile without the patch? I think I would rather
'config no=ssl3' and omit the additional complexity. Its additional
protocol complexity and heartbleed is still fresh in my mind.
Also, are there any test cases that accompany the patch? I'm trying to
figure
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 ..
> 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 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
> ...
> 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
>> > 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
>> > 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
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
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.
>> 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 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
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
> 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
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.
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 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 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 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 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
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
> 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
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
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
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
>> 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
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
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
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
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
> -
>> 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
> 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
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
> ...
> 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 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
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: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
> 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
>> 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
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
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
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 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
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 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
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 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,
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
>> 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
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
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 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 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
> 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
>> 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
> 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
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
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 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
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 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
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 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 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 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 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
> 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
>> > $ 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)
> 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
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
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
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
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
> 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
> 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
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'
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 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
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-
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,
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
>>
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)
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
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
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:
>> 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
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
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
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
1 - 100 of 133 matches
Mail list logo
