This commit removes the cms and smime "-nooldmime" option on the grounds
that the flags they use "CMS_NOOLDMIMETYPE" and "PKCS7_NOOLDMIMETYPE"
are not used in the pkcs7/cms code.
But those flags *are* used.
In include/openssl/pkcs7.h we have:
# define PKCS7_NOOLDMIMETYPE 0x400
And in inc
fixed in master with commit b4b576d thanks!
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3454
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
bn_add.c was modernized in
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=7d6284057b66458f6c99bd65ba67377d63411090
and suggested modifications were "accumulated". Case is being dismissed.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3100
Please log in as guest with p
Hi,
Please find attached file
"0004-remove-defines-X509_STORE_set_verify_.-as-context-is.patch" with a
patch that removes two defines that access X.509 store members directly.
As the X509_STORE is opaque build of source that use those defines fail.
Regards,
Ro
fied; matt removed the dynlock reference.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4408
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listin
Commit 2e52e7df5 ("Remove the old threading API") left a dummy definition
of the CRYPTO_dynlock for compatibility, if OPENSSL_API_COMPAT < 1.1.0.
However, there's still a DEFINE_STACK_OF(CRYPTO_dynlock) in cryptlib.h
which isn't so masked, and breaks the build if you disabl
addressed in upcoming 1.1 release.
we went for consistency with OPENSLS_strdup, etc
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3700
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscri
fixed with 22e3dcb7808bb06cd18c3231e34a5930e796cc48 in master. thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3647
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://m
From: Cristian Stoica
cryptodev engine is initialized together with the other engines in
ENGINE_load_builtin_engines. The initialization done through
OpenSSL_add_all_algorithms is redundant.
Signed-off-by: Cristian Stoica
---
crypto/engine/eng_all.c | 12
crypto/engine/engine.h |
0.9.8? :) since been fixed.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This was rejected by the team.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> What about to remove declaration of FIPS_mode and FIPS_mode_set?
> Those functions could be used by external packages at configure time to
> detect that fips is not supported at all.
> Note 1.0.0 does not declare both functions.
For various reasons, the team want
> What about to remove declaration of FIPS_mode and FIPS_mode_set?
> Those functions could be used by external packages at configure time to
> detect that fips is not supported at all.
> Note 1.0.0 does not declare both functions.
For various reasons, the team want
Rich Salz via RT wrote:
> we did everything we want to do, closing this.
What about to remove declaration of FIPS_mode and FIPS_mode_set?
Those functions could be used by external packages at configure time to
detect that fips is not supported at all.
Note 1.0.0 does not declare both functi
we did everything we want to do, closing this.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This has been (partially) fixed, so it can probably be closed.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
In message on Fri, 15 Jan 2016 18:38:32 +,
"Blumenthal, Uri - 0553 - MITLL" said:
uri> On 1/15/16, 13:34 , "openssl-dev on behalf of Richard Levitte"
uri> wrote:
uri>
uri> >In message <569937f1.6000...@kippdata.de> on Fri, 15 Jan 2016 19:18:25
uri> >+0100, Rainer Jung said:
uri> >
uri> >
On 1/15/16, 13:34 , "openssl-dev on behalf of Richard Levitte"
wrote:
>In message <569937f1.6000...@kippdata.de> on Fri, 15 Jan 2016 19:18:25
>+0100, Rainer Jung said:
>
>rainer.jung> In addition one could wish to put the preferred major
>version (1.0.2?)
>rainer.jung> first in the list. Despite
e1 is listed above
rainer.jung> pre2. IMHO pre2 is what people should test and pre1 is no longer
rainer.jung> entitled to be listed on that page. So I suggest to remove pre1
from
rainer.jung> the list.
You're entirely correct. I'm going in and fixing now.
rainer.jung> I don
Hi,
the list of downloadable files on http://openssl.org/source/ contains
pre1 *and* pre2 files for 1.1. Furthermore pre1 is listed above pre2.
IMHO pre2 is what people should test and pre1 is no longer entitled to
be listed on that page. So I suggest to remove pre1 from the list.
I don&#
commit done awhile ago.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Tue, Dec 22, 2015 at 09:03:56AM +, Roumen Petrov via RT wrote:
> Hello,
>
> After remove of some global variables in export file left double
Patch applied.
Kurt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.or
Hello,
After remove of some global variables in export file left double
information for non existent functions.
For instance before:
X509_CERT_PAIR_it 3534
EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
X509_CERT_PAIR_it 3534
> So, does the above mean that my patch is not going to be merged?
No. It will be.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Sat, Oct 31, 2015 at 08:34:33am -0400, Steve Marquess wrote:
> On 10/31/2015 08:26 AM, Alessandro Ghedini via RT wrote:
> > Hi,
> >
> > I don't know what your intentions are with FIPS support in master, ...
>
> We would like to continue to provide a FIPS validated module for the 1.1
> (and sub
On October 31, 2015 2:09:50 PM GMT+01:00, Steve Marquess
wrote:
>On 10/31/2015 09:01 AM, Richard Levitte wrote:
>> Can't recall previous discussions on this, but would it be possible
>to have a FIPS engine?
>
>Of a sort, yes. I'll let Steve Henson speak to the details, but it is
>his hope (and
On 10/31/2015 09:01 AM, Richard Levitte wrote:
> Can't recall previous discussions on this, but would it be possible to have a
> FIPS engine?
Of a sort, yes. I'll let Steve Henson speak to the details, but it is
his hope (and mine) that FIPS module support for 1.1 and beyond would be
modular so
Hi,
in commit 070c233 I didn't notice that the CRYPTO_w_lock()/CRYPTO_w_unlock()
calls are now useless, so I made a patch to fix that.
See the following GitHub pull request:
https://github.com/openssl/openssl/pull/454
Cheers
___
openssl-bugs-mod maili
Can't recall previous discussions on this, but would it be possible to have a
FIPS engine?
Cheers
Richard
Steve Marquess skrev: (31 oktober 2015 13:34:33 CET)
>On 10/31/2015 08:26 AM, Alessandro Ghedini via RT wrote:
>> Hi,
>>
>> I don't know what your intentions are with FIPS support in ma
On 10/31/2015 08:26 AM, Alessandro Ghedini via RT wrote:
> Hi,
>
> I don't know what your intentions are with FIPS support in master, ...
We would like to continue to provide a FIPS validated module for the 1.1
(and subsequent) releases. Unfortunately the current module ("OpenSSL
FIPS Object Modu
Hi,
I don't know what your intentions are with FIPS support in master, but after
the removal of most if the fips/ code, several bits and pieces of now broken
code have remained in the codebase. IMO it'd be better to just remove it for
now.
See the following GitHub pull requ
Tracking ticket - if anyone has any concerns, please voice them now.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Message d'origine
De : Markus Rinne via RT
Date :24/08/2015 17:42 (GMT+01:00)
A :
Cc : openssl-dev@openssl.org
Objet : [openssl-dev] [openssl.org #4019] [PATCH] dgst.pod: Remove
redundant documentation of -hmac
Option -hmac was documented twice.
The issu
Option -hmac was documented twice.
The issue was reported here:
https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3930
---
doc/apps/dgst.pod | 5 -
1 file changed, 5 deletions(-)
diff --git a/doc/apps/dgst.pod b/doc/apps/dgst.pod
index 236e1b7..b156097 100644
--- a/doc
OpenSSL_1_0_0-stable 6c63867 RT3820: Don't call GetDesktopWindow()
OpenSSL_1_0_1-stable ee827ad RT3820: Don't call GetDesktopWindow()
OpenSSL_1_0_2-stable a659386 RT3820: Don't call GetDesktopWindow()
master bed2edf RT3820: Don't call GetDesktopWindow()
Author: Gilles Khouzam
Date: Fri May 1 22:2
.
2) OpenSSL versions affected: all versions running on Windows, starting Apr 7
2005.
Thank you,
Gunnar Kudrjavets
>From 7693250e03ea284c2fb3a565cd3cbceeb2512943 Mon Sep 17 00:00:00 2001
From: Gunnar Kudrjavets
Date: Thu, 23 Apr 2015 13:22:49 -0700
Subject: [PATCH] Remove an unnecessary call
cryptodev engine is initialized together with the other engines in
ENGINE_load_builtin_engines. The initialization done through
OpenSSL_add_all_algorithms is redundant.
Signed-off-by: Cristian Stoica
---
crypto/engine/eng_all.c | 12
crypto/engine/engine.h | 4
crypto/evp/c_a
Hi
The -subj parameter appears twice in the manpage of req for no reasons I
am aware of. This patch removes the second occurrence of the -subj
parameter. I have created a git commit and a git pull request for that
change.
https://github.com/openssl/openssl/pull/254
https://github.com/eriktews/ope
master f09e7ca Move build config table to separate files.
Author: Rich Salz
Date: Tue Feb 24 17:40:22 2015 -0500
Move build config table to separate files.
Move the build configuration table into separate files. The Configurations
file is standard configs, and Configurations.team is for openssl
No need to a keep a duplicate API.
---
crypto/crypto.h | 1 -
crypto/jpake/jpake.c | 5 +++--
crypto/mem.c | 8
3 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/crypto/crypto.h b/crypto/crypto.h
index 9762398..7dd2223 100644
--- a/crypto/crypto.h
+++ b/crypto/c
commit 24956ca00f014a917fb181a8abc39b349f3f316f
Author: Rich Salz
Date: Mon Feb 2 18:46:01 2015 -0500
Remove old DES API
Includes VMS fixes from Richard.
Includes Kurt's destest fixes (RT 1290).
Closes tickets 1290 and 1291
Reviewed-by: Kurt Roeckx
Reviewed-by: Richard Le
Closed in a series of commits.
6d23cf97443bfedf755341b4f2d0d7fce254e020
fcf64ba0ace1bb76c6e00ca7d0c7cf7f9bebe628
b5526482ef81ee7906b967e326d23a45fbcf3abc
32dfde107636ac9bc62a5b3233fe2a54dbc27008
6c23ca0cbb0181f803f38694e3f25e53e409a238
5ad4fdce41bb1ce7762b70fb50f732f70e3772cf
f2319414445ef5991d77c0
Hi,
It seems the DTLS heartbeat extension is still supported in current
OpenSSL versions (at least that's my impression while playing around
with `s_server` with verbose debug logging).
I've talked extensively to cryptographers and implementors about this
extension, I'm not aware of a single use
commit b5526482ef81ee7906b967e326d23a45fbcf3abc
Author: Rich Salz
Date: Mon Jan 5 16:05:54 2015 -0500
RT3546: Remove #define IRIX_CC_BUG
Leftovers from commit 448155e9bbda27cbba365ff549a7e2044a8a399f
Remove now-unused #define's
Reviewed-by: Matt Caswell
--
Rich Salz, OpenSSL dev tea
Thanks!
Norm
On 18/12/2014 9:26 AM, Rich Salz via RT wrote:
> MWERKS added back to nw_rand.c
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.org
>
> ___
> openssl-dev mailing list
> openssl-dev@openssl.org
> https://mta.opensslfoundation.net/mailman/li
Thanks!
Norm
On 18/12/2014 9:26 AM, Rich Salz via RT wrote:
MWERKS added back to nw_rand.c
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openss
MWERKS added back to nw_rand.c
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
master 5cf3795 RT3543: Remove #ifdef LINT
Author: Rich Salz
Date: Tue Sep 23 13:23:09 2014 -0400
RT3543: Remove #ifdef LINT
I also replaced some exit/return wrappers in various
programs (from main) to standardize on return.
Reviewed-by: Richard Levitte
--
Rich Salz, OpenSSL dev team; rs
Yes, I will revert the change.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager major
Yes, I will revert the change.
Hi Rich,
On 25.09.2014 00:09, Rich Salz via RT wrote:
All sorts of pre-OSx mac support has been removed.
commit 92c78463720f71e47c251ffa58493e32cd793e13
Author: Rich Salz
Date: Wed Sep 24 12:18:19 2014 -0400
RT3544: Remove MWERKS support
The following #ifdef tests were all removed
Hi Rich,
On 25.09.2014 00:09, Rich Salz via RT wrote:
> All sorts of pre-OSx mac support has been removed.
>
> commit 92c78463720f71e47c251ffa58493e32cd793e13
> Author: Rich Salz
> Date: Wed Sep 24 12:18:19 2014 -0400
>
> RT3544: Remove MWERKS support
>
> The foll
Thanks for your submission. However Steve Henson has already commited a similar
patch, therefore closing this ticket.
Matt
__
OpenSSL Project http://www.openssl.org
Development Mailing List
On 30/10/2014 9:58 AM, NormW wrote:
G/M,
On 25/09/2014 2:09 AM, Rich Salz via RT wrote:
Not a supported platform, per our roadmap.
__
OpenSSL Project http://www.openssl.org
Development Mailing Li
bert Kario via RT wrote:
> On Thursday 30 October 2014 23:26:15 Alin Năstac via RT wrote:
>> Some SSLv3 parts (e.g. SSLv3 ciphers)
>
> SSLv3 ciphers can be used with any version of TLS from TLSv1.0 to TLSv1.2
>
> if you remove ciphers that are marked as "SSLv3", you
On Thu, Oct 30, 2014 at 11:26:15PM +0100, Alin Nastac via RT wrote:
> Some SSLv3 parts (e.g. SSLv3 ciphers) are built in even if ssl3
> support is disabled.
"SSLv3 ciphers" are not specific to SSLv3, they can also be used
in TLS.
no-ssl3 doesn't disable the SSL3 methods. That is, you can still
bert Kario via RT wrote:
> On Thursday 30 October 2014 23:26:15 Alin Năstac via RT wrote:
>> Some SSLv3 parts (e.g. SSLv3 ciphers)
>
> SSLv3 ciphers can be used with any version of TLS from TLSv1.0 to TLSv1.2
>
> if you remove ciphers that are marked as "SSLv3", you
On Thursday 30 October 2014 23:26:15 Alin Năstac via RT wrote:
> Some SSLv3 parts (e.g. SSLv3 ciphers)
SSLv3 ciphers can be used with any version of TLS from TLSv1.0 to TLSv1.2
if you remove ciphers that are marked as "SSLv3", you actually remove all
ciphers that can be used wit
Some SSLv3 parts (e.g. SSLv3 ciphers) are built in even if ssl3
support is disabled.
Attached patch fixes it:
diff -Nru openssl-1.0.1j.orig/ssl/s3_clnt.c openssl-1.0.1j/ssl/s3_clnt.c
--- openssl-1.0.1j.orig/ssl/s3_clnt.c 2014-10-15 14:53:39.0 +0200
+++ openssl-1.0.1j/ssl/s3_clnt.c 2014-10
G/M,
On 25/09/2014 2:09 AM, Rich Salz via RT wrote:
Not a supported platform, per our roadmap.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
commit df8c39d52256c2e5327a636928b6d1ed05f695a2
Author: Rich Salz
Date: Tue Sep 30 17:30:19 2014 -0400
RT3549: Remove obsolete files in crypto
Reviewed-by: Andy Polyakov
The following files have been removed:
crypto/bf/asm/bf-686.pl
crypto/bf/asm/readme
crypto/bf/bf_opts.c
crypto/bf/bfspeed.c
The following files can be removed. There is another ticket (2910) that covers
a bunch of things in crypto/des.
crypto/bn/asm/x86/*
crypto/bn/asm/README
crypto/bn/bn.mul
crypto/bn/todo
crypto/bf/asm/readme
crypto/bf/asm/bf-686.pl
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
_
This ticket is a catch-all for removing a handful of unsupported platforms.
This list includes:
BEOS
NeXT
NEWS
SUNOS
MPE/iX
ReliantUNIX
SINIX
DGUX
NCR
Tandem
Cray
WIN16
The intent is that each one will be done as a single commit, separate from all
the others, and merged to main one at a time, but
Self-explanatory.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.
All sorts of pre-OSx mac support has been removed.
commit 92c78463720f71e47c251ffa58493e32cd793e13
Author: Rich Salz
Date: Wed Sep 24 12:18:19 2014 -0400
RT3544: Remove MWERKS support
The following #ifdef tests were all removed:
__MWERKS__
MAC_OS_pre_X
MAC_OS_GUSI_SOURCE
MAC_OS_pre_X
Not a supported platform, per our roadmap.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Can't find the "lint" program on a modern platform these days, and gcc/clang
warnings are much better anyway.
Remove that code.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
__
Remove BEOS and BEOS_R5 support.
Doesn't qualify to be a supported platform, per our roadmap.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
__
OpenSSL Project http://www.openssl.org
Develo
As drH says, not fixing this because being able to show obsolete OID's in text
form can be useful.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
__
OpenSSL Project http://www.openssl.org
Develop
Fixed in head. Aargh, thanks.
commit b0426a0f8c6ce7656411b037e0c45465320cb325
Author: Kurt Cancemi
Date: Sun Aug 31 18:18:21 2014 -0400
RT3508: Remove unused variable introduced by b09eb24
Reviewed-by: Tim Hudson
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
Hello,
The following patch removes an unused variable introduced by b09eb24,
this also fixes the build with -Werror.
>From 6e347fded0c050f4049e5bcbc2647bfdb742c48f Mon Sep 17 00:00:00 2001
From: Kurt Cancemi
Date: Thu, 28 Aug 2014 21:43:04 -0400
Subject: [PATCH] Remove unused varia
Fixed in rsalz-monolith branch of akamai/openssl fork on github.
To be part of post-1.0.2 release.
Thanks!
commit 15e5188312bc3bb199297be40ab58388d4141b3d
Author: Le Huang <4ta...@gmail.com>
Date: Wed Aug 27 14:53:34 2014 -0400
PR3006: Needless duplication in speed.c
Ror some reason, the "+F2:" t
Fixed in HEAD
commit a520ae36288e01c19cd13dfca885b74bfd37d0e2
Author: Jeffrey Walton
Date: Tue Aug 19 12:59:41 2014 -0400
RT3142: Extra initialization in state_machine
Remove extra initialization calls in the sample program.
Reviewed-by: Emilia Kasper
--
Rich Salz, OpenSSL dev team; rs
Already fixed, at least in HEAD. Thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openss
It was already fixed in the next release after 1.0.2; see rsalz-monolith branch
in akamai/openssl fork on github. thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
__
OpenSSL Project http://
Submitted, will be part of post-1.0.2 release; thanks!
commit 01e438f28844ad4f3fd7e8d772031524593d6441
Author: Hans Wennborg
Date: Fri Aug 15 00:54:00 2014 -0400
RT3023: Redundant logical expressions
Remove some redundant logical expressions
Reviewed-by: Emilia Kasper
--
Rich Salz, OpenSSL
Hi,
Currently (14-07-2014, commit f8571ce82) the master branch doesn't
compile on Windows (mingw64) when using the enable-ec_nistp_64_gcc_128
option. The same option does work however on the OpenSSL_1_0_2-stable
branch.
This is due to a small difference in the file crypto/ec/ec.h. On
11-02-2011,
- Original Message -
> From: "Benny Baumann"
> To: openssl-dev@openssl.org
> Sent: Friday, July 4, 2014 10:28:07 AM
> Subject: Re: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
Hubert Kario wrote:
>>>> - Original Message -
>>>>> From: "Benny Baumann" To:
>>>>> openbsd-t...@openbsd.org, openssl-dev@openssl.org Sent:
>>>>> Wednesday, 2 July, 2014 8:49:18 PM Subject: [PATCH]
>>>>>
CH]
>> LibReSSL/OpenSSL: Adjust/remove keysize restrictions
>>
>> Hi folks,
>>
>> I know the following patches will cause a controversy just like
>> the issues they resolve caused me and several other people
>> headaches when debugging them.
>>
>>
- Original Message -
> From: "Wilfried Klaebe"
> To: openssl-dev@openssl.org
> Sent: Thursday, 3 July, 2014 11:42:08 PM
> Subject: Re: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions
>
> Am Thu, Jul 03, 2014 at 07:20:46PM +0200 schrieb Kurt Roec
t;
> > > > To: openbsd-t...@openbsd.org, openssl-dev@openssl.org
> > > > Sent: Wednesday, 2 July, 2014 8:49:18 PM
> > > > Subject: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions
> > > >
> > > > Hi folks,
> > > >
> Sent: Wednesday, 2 July, 2014 8:49:18 PM
> > > Subject: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions
> > >
> > > Hi folks,
> > >
> > > I know the following patches will cause a controversy just like the
> > > issues they re
On Thu, Jul 03, 2014 at 08:08:52AM -0400, Hubert Kario wrote:
> - Original Message -
> > From: "Benny Baumann"
> > To: openbsd-t...@openbsd.org, openssl-dev@openssl.org
> > Sent: Wednesday, 2 July, 2014 8:49:18 PM
> > Subject: [PATCH] LibReSSL/OpenSS
- Original Message -
> From: "Benny Baumann"
> To: openbsd-t...@openbsd.org, openssl-dev@openssl.org
> Sent: Wednesday, 2 July, 2014 8:49:18 PM
> Subject: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions
>
> Hi folks,
>
> I know the followin
size of a received public key to
be increased from 516 bytes (just barely enough for 4 KBit RSA public
keys) up to 8200 bytes (enough for 64KBit RSA keys with some minor margin)
2. Remove the crippling of the DH/DSA routines for working with at most
10kBit parameters.
Find the patches attached to
On 15 Apr 2014, at 18:23, Richard Könning
wrote:
> Am 15.04.2014 14:35, schrieb Michael Tuexen:
>> On 15 Apr 2014, at 14:26, Fedor Indutny wrote:
>>
>>>
>>> Hello Hanno!
>>>
>>> Despite not a being an active community member, I'd like to share my
>>> thoughts
>>> on it, if you don't mind.
>
On 15 Apr 2014, at 16:43, Hanno Böck wrote:
> On Tue, 15 Apr 2014 14:35:36 +0200
> Michael Tuexen wrote:
>
>> On 15 Apr 2014, at 14:26, Fedor Indutny wrote:
>>
>>> I certainly agree that this extension has a quite faulty
>>> specification and very questionable use. But perhaps, instead of
>>>
Am 15.04.2014 14:35, schrieb Michael Tuexen:
On 15 Apr 2014, at 14:26, Fedor Indutny wrote:
Hello Hanno!
Despite not a being an active community member, I'd like to share my thoughts
on it, if you don't mind.
I certainly agree that this extension has a quite faulty specification and very
q
On Tue, 15 Apr 2014 14:35:36 +0200
Michael Tuexen wrote:
> On 15 Apr 2014, at 14:26, Fedor Indutny wrote:
>
> > I certainly agree that this extension has a quite faulty
> > specification and very questionable use. But perhaps, instead of
> > just removing it from OpenSSL, we should try to make
On 15 Apr 2014, at 14:26, Fedor Indutny wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello Hanno!
>
> Despite not a being an active community member, I'd like to share my thoughts
> on it, if you don't mind.
>
> I certainly agree that this extension has a quite faulty specifica
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Hanno!
Despite not a being an active community member, I'd like to share my
thoughts
on it, if you don't mind.
I certainly agree that this extension has a quite faulty specification and
very questionable
use. But perhaps, instead of just removi
Hi,
I think this question needs to be asked.
We have a TLS extension here that - as far as I can see - nobody uses.
I have asked in different contexts recently if anyone is aware of real
software that makes use of the heartbeat extension. I got often
answerts like "it could be used for X", but no
>> ... The SPARC "random"
>> instruction was never implemented and never will be implemented.
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=926725b3d7c1528f2dc116a48623c42264188277
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=e79d34c24b96943ae653dc93371bcae1902
... The SPARC "random"
instruction was never implemented and never will be implemented.
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=926725b3d7c1528f2dc116a48623c42264188277
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=e79d34c24b96943ae653dc93371bcae19021
As f
Feels like Oracle convention all of a sudden...
> I think we need to clarify why this should be done.
The lesson is to always report underlying reasons. Because as we see
here, it might turn out misleading.
> ... The SPARC "random"
> instruction was never implemented and never will be implemen
d, never-used code
> > in OpenSSL. The SPARC random instruction doesn't exist, OpenSSL never
> > used it and never can use it, but you don't want to remove the check
> > for it. It seems silly to me.
>
> Ok, how about we replace the random instruction detection with
't want to remove the check
for it. It seems silly to me.
Ok, how about we replace the random instruction detection with an
explicit forced illegal instruction test early in the sparc init code
that makes sure the SIGILL facility is working properly?
Hi Dave,
That's fine--it'
From: Dan Anderson
Date: Fri, 27 Dec 2013 09:37:10 -0800
> I really don't understand the desire to preserve dead, never-used code
> in OpenSSL. The SPARC random instruction doesn't exist, OpenSSL never
> used it and never can use it, but you don't want to remove the
1 - 100 of 236 matches
Mail list logo
