On 02/22/2016 11:04 AM, David Woodhouse via RT wrote:
> We are using OPENSSL_strcmp() as the cmp_func, where cmp_func takes
> a pair of (void *) pointers, not (char *). Which is fine; we know we're
> going to pass it strings in this case. So explicitly cast it to avoid
> the resulting compiler warn
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.
-Ben
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4378
Please log in as gues
On 03/29/2016 08:58 AM, noloa...@gmail.com via RT wrote:
> 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
On 05/02/2016 10:56 AM, Florent Gluck via RT wrote:
> Hi,
>
> When compiling for linux-armv4 there is a bug in the master branch,
> version d244dd559d0e6e594e4a0f911e49509e8a7b158b, there is a missing
> backslash in ssl/record/rec_layer_s3.c.
>
Already fixed in commit fbaf30d087a2db2b4e22279e819
As a bit of follow-up here, it looks like the behavior changed from
using "Email" as a shortname for this attribute to just using the long
form "emailAddress" in commit 30911232c17f309f947156959fcbbf504c1b66fe
back in 2002. The commit message there was pretty sparse, "Some more
OID enhancements",
We are patched locally and don’t really need the patch integrated upstream; I
mostly just wanted to note the issue in the bugtracker in case someone else ran
into it.
-Ben
On 6/15/16, 08:09, "Salz, Rich via RT" wrote:
>So are we still fixing SSLv2 bugs? Or are they too low on the priority li
On 08/03/2016 10:12 AM, Viktor Kolodrevskiy wrote:
> Hi,
>
> If I want to enable ssl2 under windows build, will need to pass
> parameters:
> no-asm enable-ssl2 -DOPENSSL_USE_IPV6=0 VC-WIN32
>
> So if I will need to build openssl under linux, parameters should be:
> no-asm enable-ssl2 -DOPEN
On 10/05/2016 07:56 AM, Richard Levitte via RT wrote:
> To be noted, there's more in section 2:
>
>Most extant parsers ignore blanks at the ends of lines; blanks at the
>beginnings of lines or in the middle of the base64-encoded data are
>far less compatible. These observations are cod
On 10/05/2016 09:15 AM, Kaduk, Ben via RT wrote:
> I refactored this stuff a while ago to add a flags field that would
> force the temporary read buffer to be allocated from the secure heap; I
> should really dig it up and clean it up for master.
That's https://github.com/openss
See https://github.com/openssl/openssl/pull/348
I was looking for something else but then saw this text about "normally
supplied by a function such as EVP_des_cbc()"; we should not be misleading
our users in such a fashion.
-Ben
___
openssl-bugs-mod ma
Please see https://github.com/openssl/openssl/pull/365 ; just a couple of
tweaks to preprocessor conditionals.
-Ben
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
__
It seems like this fine-grained level of detail may have been more
suitable for an earlier point in time when the subcomponents were used.
With the advent of shared libraries, there is less motivation to split
things up in that way, and perhaps the decision to have separate version
strings for each
It would be nice to get this or some other fix in; I have to go back and
cherry-pick this commit any time I want to build on OS X.
-Ben Kaduk
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Some tweaks in response to my review comments on f00a10b89734e84fe80
(after Rich pointed out where I was misreading the diff). Also available
via https://github.com/kaduk/openssl/commits/dsa (no pull request since
it's pretty minor)
-Ben
dsa.diff
Description: Binary data
_
SSLv2 support has been removed from master, but is still present in 1.0.2.
Adding a range check in ssl_get_prev_session() broke the SSLv2 codepath
because it supplied NULL as the 'limit' parameter that had not
previously been used for SSLv2 (or v3), so the fix is just to supply a
non-NULL limit.
I ran a build using clang's -Weverything to activate all warnings (setting
CFLAG in the top-level Makefile and removing all other warning-related
flags, especially -Werror). With the system clang on my mac, master at
4d04226c2ec7e7f69f6234def63631648e35e828 with the patch from #3984 gives
the foll
Ben's work on df2ee0e27d2db02660c1d15fe6a3e38be9df0a60 made a lot of this stuff
redundant; I rebased the branch at
https://github.com/kaduk/openssl/commits/warning-cleanup and generated a new
warning-cleanup1.patch, attached. Of note: the move of x509v3/ext_dat.h to
crypto/include/internal is
Now that everything's in git, the .cvsignore files seem to serve no
useful purpose, and should be removed.
-Ben
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
___
On 09/30/2015 10:12 AM, Salz, Rich via RT wrote:
>> If things like BIO_new_file() were inline, or macros, then the compiler could
>> *see* that they'd return NULL. And lots of code in the *calling* functions
>> (basically everything but the error path) could be elided from the compiled
>> result...
Updated patch series to address a couple of comments from Ben (made on
now-orphaned github commits).
Still available on github at a rebased
https://github.com/kaduk/openssl/commits/warning-cleanup .
-Ben
>From 4b8104dc7fc3450e43edc1a4fd52ece2ed35929a Mon Sep 17 00:00:00 2001
From: Benjamin Kaduk
Code inspection of crypto/evp/e_des3.c reveals that !! was used instead
of || (and then subsequently reformatted by a script):
272 # ifdef EVP_CHECK_DES_KEY
273 if (DES_set_key_checked(&deskey[0], &dat->ks1)
274 ! !DES_set_key_checked(&deskey[1], &dat->ks2))
275
crypto/evp/e_dsa.c contains only a single static struct variable, and
the file appears unreferenced from anywhere else in the tree.
It should be safe to remove.
-Ben
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org
On 10/15/2015 07:41 AM, Matt Caswell via RT wrote:
>
> In summary my opinion is:
> - I believe the sanity check does have some value in guarding against
> programmer error
> - If it were to be compiled away this does not have a detrimental impact
> on security (it just increases the likelihood of a
On 10/15/2015 05:44 AM, Emilia Käsper via RT wrote:
> Given OpenSSL's eternal type confusion, this check is meant to trap callers
> that get an error return (typically -1) from some API returning signed values
>
Hmm, do we have a sense for how typically "typically" is? Maybe just
adding a check fo
On 10/16/2015 03:32 AM, Matt Caswell via RT wrote:
>
> On 15/10/15 20:53, Alexander Cherepanov via RT wrote:
>> What was not entirely clear from the original bug report is that, while
>> the check is not compiled away, it's compiled into something completely
>> different from what is written in t
On 10/16/2015 11:50 AM, Matt Caswell via RT wrote:
>
> On 16/10/15 17:32, Viktor Dukhovni wrote:
>> My take is that we should generally stay clear of relying on any
>> remotely sensible outcome for undefined behaviour. If this thread
>> is about such a situation, then we may have to code around th
On 10/16/2015 04:35 PM, Kurt Roeckx via RT wrote:
> On Fri, Oct 16, 2015 at 06:50:36PM +, Kurt Roeckx via RT wrote:
>> On Fri, Oct 16, 2015 at 04:50:59PM +, Matt Caswell via RT wrote:
>>> In a well-behaved program there is no undefined behaviour. The "buf +
>>> len < buf" check will always
On 10/22/2015 01:02 PM, stefan.n...@t-online.de via RT wrote:
> Hi,
>
> Wouldn't
> if ( UINTPTR_MAX - (uintptr_t) buffer < len)
> be closer to the intention of the original check?
> Or is this undefined behaviour as well and I
> stupidly missed that fact?
>
That appears to be defined behavio
On 11/08/2015 05:37 AM, tamil.sel...@winfoware.com via RT wrote:
> Hi,
> I m getting this error : if you can solve this problem please reply to this
> mail.
> "_BIO_new_mem_buf", referenced from:
> "_PEM_read_bio_RSA_PUBKEY", referenced from:
> "_RSA_size", referenced from:
> "_RSA_public
On 11/09/2015 08:41 AM, Hubert Kario via RT wrote:
> Looks like rekeying is on the table again for TLSv1.3:
> https://www.ietf.org/mail-archive/web/tls/current/msg18295.html
The proposed rekeying mechanism is not looking like renegotiation...
> so I'd say this issue should get fixed or at least w
On 11/08/2015 05:37 AM, tosif tamboli via RT wrote:
> Hi ,
> I am compiling crypto in openssl for vxWorks version 5.4
> with 5.5.1 it compiles well
> But with 5.4 it gives error for below files
> bn_depr.c
> ccppc: Internal compiler error: program cc1 got fatal signal 6
>
> When checked it gives er
On 11/11/2015 07:06 AM, Kurt Roeckx via RT wrote:
> On Wed, Nov 11, 2015 at 12:37:56PM +, Alessandro Ghedini via RT wrote:
>> On Wed, Nov 11, 2015 at 11:52:56AM +, Kurt Roeckx via RT wrote:
>>> On Wed, Nov 11, 2015 at 11:16:56AM +, Alessandro Ghedini via RT wrote:
Also, FTR, appare
On 11/24/2015 05:06 AM, Pascal Cuoq via RT wrote:
> This issue is similar in nature to 4151
> (http://www.mail-archive.com/openssl-dev@openssl.org/msg40950.html ): it is
> about a dangling pointer being used, but not used for dereferencing, so it's
> not a memory error. The dangling pointer is u
It looks like SSL_CIPHER_description() will return a bunch of "unknown"s
for the recently added chacha20/poly1305 ciphersuites.
-Ben
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
On 01/11/2016 06:01 PM, Salz, Rich via RT wrote:
>> I am a bit worried when I see C-beginner mistakes like this in a security
>> suite:
>> When using sscanf on data you have not produced yourself, you should
>> always assume they will be bigger that your largest buffer/variable and deal
>> correct
It looks like in the #ifndef SIGALRM case, c[D_GHASH][0] is set, but not
c[D_GHASH][i] for larger i.
(Where is the no-SIGALRM code used?)
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bug
Since we can't remove EGD entirely yet, let's do the next best thing.
https://github.com/openssl/openssl/pull/547 contains a patch to add a
no-egd configure option and disable egd support by default.
-Ben
___
openssl-bugs-mod mailing list
openssl-bugs-
Part of the patch submitted to RT #844 includes a patch to the usage
message of CA.pl. Although the functionality itself of CA.pl was
rewritten for 1.1 (so that #844 was closed), the usage message remains
incomplete, and Debian continues to apply a local patch to add the usage.
So, as mentioned i
38 matches
Mail list logo
