* Hubert Kario:
> when I mark project as followed I'm getting messages from all issues
> and all PRs - likely dozens if not hundred messages a day
But isn't that the point?
My main concern with Github is that I have no record of my own
actions. (Their single-account policy is also a problem
* James Bottomley:
> On Sat, 2017-03-25 at 16:10 +, Salz, Rich via openssl-dev wrote:
>>
>> > Please, in the final OpenSSL license text add the paragraph linked
>> > in the above LLVM mailing list as an exception to the Apache
>> > license.
>> >
>> > We should make sure using OpenSSL in
* Kurt Roeckx:
> On Fri, Mar 24, 2017 at 08:02:25PM +0100, Florian Weimer wrote:
>> * Quanah Gibson-Mount:
>>
>> > Zero people that I know of are saying to switch to the GPL. What is
>> > being pointed out is that the incompatibility with the current
>> &g
* Quanah Gibson-Mount:
> Zero people that I know of are saying to switch to the GPL. What is
> being pointed out is that the incompatibility with the current
> OpenSSL license with the GPLv2 has been a major problem.
The alleged incompatibility of OpenSSL with the GPLv2 has been used to
promote
* Nico Williams:
> On Tue, Dec 08, 2015 at 11:19:32AM +0100, Florian Weimer wrote:
>> > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill?
>>
>> It seems to have trouble to keep up with new architectures.
>
> New architectures are not really a pro
* Nico Williams:
> Maybe http://trac.mpich.org/projects/openpa/ would fit the bill?
It seems to have trouble to keep up with new architectures.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On 11/25/2015 06:48 PM, Kurt Roeckx wrote:
> On Wed, Nov 25, 2015 at 01:02:29PM +0100, Florian Weimer wrote:
>> On 11/23/2015 11:08 PM, Kurt Roeckx wrote:
>>
>>> I think that we currently don't do any compile / link test to
>>> detect features but that we i
On 11/23/2015 11:08 PM, Kurt Roeckx wrote:
> I think that we currently don't do any compile / link test to
> detect features but that we instead explicitly say so for each
> platform.
>
> Anyway, the gcc the documentation is here:
> https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html
>
> TLS
* Viktor Dukhovni:
> If I were to guess, it would be that the base crypto implementations
> of IDEA, SEED and binary elliptic curves need to stay. We could
> perhaps get away with removing CAST and RIPEMD.
Just one data point: CAST5 is still the default for GnuPG when using
symmetric
* Kurt Roeckx:
> On Tue, Nov 17, 2015 at 07:10:00PM +0100, Florian Weimer wrote:
>> * Viktor Dukhovni:
>>
>> > If I were to guess, it would be that the base crypto implementations
>> > of IDEA, SEED and binary elliptic curves need to stay. We could
>>
On 06/15/2015 06:02 PM, Nico Williams wrote:
On Thu, Jun 11, 2015 at 10:41:58AM +0200, Florian Weimer wrote:
Detecting things in libcrypto is very difficult on GNU/Linux due to the
way dynamic linking works.
Details?
Detection based on weak symbols can break due to linking order
, and fixing that while preserving binary compatibility
with 0.9.8 is quite a challenge.)
--
Florian Weimer / Red Hat Product Security
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
avoid it.
If you have received advice to the contrary, your source of advice is
wrong. :-)
--
Florian Weimer / Red Hat Product Security
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
?
Which platform are you on?
--
Florian Weimer / Red Hat Product Security
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
reporting library critically depends on working locking
functions. You get strange results if you believe the FAQ that OpenSSL
is thread-safe, even if you do not use any objects across threads.
--
Florian Weimer / Red Hat Product Security
___
openssl-dev
On 04/03/2015 09:53 PM, Salz, Rich wrote:
If this will cause problems for you, please post on the list, ideally within
the next week.
PostgreSQL uses OpenSSL compression by default, and it is a deliberate
feature (there is no application-layer compression support).
--
Florian Weimer / Red
for the broken fallback behavior because it
is not a security vulnerability—it works as designed. This means that
the TLS_FALLBACK_SCSV patch currently has no CVE associated with it.
--
Florian Weimer / Red Hat Product Security
a limitation of the CVE authority
file in the light of its current applications.
--
Florian Weimer / Red Hat Product Security
__
OpenSSL Project http://www.openssl.org
Development Mailing List
or Windows prior to the Win32 API) are still supported, but this is
clearly not the case because a lot of bounds checks assume 32-bit ints.
--
Florian Weimer / Red Hat Product Security
__
OpenSSL Project
of bounds checks assume 32-bit ints.
Are there any of these platforms that would pass the Currency/Vendor
support criteria? If so which ones?
I fear that eComStation could fit these criteria, for the platforms I
mentioned.
--
Florian Weimer / Red Hat Product Security
implementation
which uses native thread-local storage, which should be mostly
contention-free.
--
Florian Weimer / Red Hat Product Security Team
__
OpenSSL Project http://www.openssl.org
Development
, this is about an
interoperability issue.
--
Florian Weimer / Red Hat Product Security Team
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
are protected by read locks?
Often, RW locks aren't a win because maintaining just the read locks
(without any writers) introduces contention at the hardware level, and
parallelism does not increase all that much as a result. Paul
McKenney's dissertation on RCU has some examples.
--
Florian Weimer
of the threading library
causes some other libraries to fall back to slower thread-safe variants.
This mostly affects libstdc++ and std::shared_ptr (where atomics are
used for maintaining the reference count), and to a lesser extend,
malloc in glibc itself.
--
Florian Weimer / Red Hat Product
(and int) of at
least 32 bits (in the sense that there are unguarded integer overflows
with 16-bit types). Wouldn't this rule out MS-DOS and 16-bit Windows as
useful platforms?
--
Florian Weimer / Red Hat Product Security Team
* Ben Laurie:
Is there an easy way to fix that? That is, I would expect it to show
me as the committer and the original author as the author.
git am does this, but merging from a Git repository does not because
it changes the commit hashes and would force the submitter to rebase.
In general,
---
ssl/d1_both.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ssl/d1_both.c b/ssl/d1_both.c
index d8bcd58..2c06fc2 100644
--- a/ssl/d1_both.c
+++ b/ssl/d1_both.c
@@ -679,8 +679,8 @@ dtls1_reassemble_fragment(SSL *s, struct hm_header_st*
msg_hdr, int *ok)
. It also sidesteps the
LinuxThreads issue.
--
Florian Weimer / Red Hat Product Security Team
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev
On 01/15/2014 05:44 PM, Dr. Stephen Henson wrote:
On Wed, Jan 15, 2014, Florian Weimer wrote:
Commit 3cd8547a2018ada88a4303067a2aa15eadc17f39 mixed the current
time into the randomness pool each time RAND_bytes is called. As
the resolution of gettimeofday() is limited, I propose to reseed
On 01/16/2014 01:57 PM, Dr. Stephen Henson wrote:
On Thu, Jan 16, 2014, Florian Weimer wrote:
The additional resolution of a tick counter might make reseeding
after fork unnecessary, but it's difficult to be sure. Something
not based on timing information looks desirable to me.
I should
On 01/16/2014 03:39 PM, Florian Weimer wrote:
I still propose to get rid of the time() call (md_rand-time.patch,
AFAICT num == 0 at this point, so I pulled the initialization out of the
loop).
Disregard the patches, this doesn't work.
--
Florian Weimer / Red Hat Product Security Team
for platforms where the
gettimeofday() call is prohibitively slow.
--
Florian Weimer / Red Hat Product Security Team
commit 136a8da88ff52ad32f894fb0ecbcab5f4205ca49
Author: Florian Weimer fwei...@redhat.com
Date: Wed Jan 15 16:46:17 2014 +0100
ssleay_rand_bytes: Re-seed on PID change
diff --git
it is mandatory]).
It's required by the amd64 ABI, and other things will break if this
requirement is violated.
--
Florian Weimer / Red Hat Product Security Team
__
OpenSSL Project http
GCC version?
--
Florian Weimer / Red Hat Product Security Team
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
.
This is likely a toolchain bug, and not something that can be reasonably
fixed in OpenSSL.
--
Florian Weimer / Red Hat Product Security Team
__
OpenSSL Project http://www.openssl.org
Development
extension. If *p is
unsigned, compilers are allowed to assume that (signed char)(*p) = 0 is
always true (because signed overflow is undefined).
--
Florian Weimer / Red Hat Product Security Team
__
OpenSSL Project
one of the existing *ancient* flags. Does
anyone really care about compatibility with a bug in SSLeay 0.80 for example?
Wouldn't it be better to reverse the meaning of the flag and not set it
in SSL_OP_ALL?
--
Florian Weimer / Red Hat Product Security Team
a protocol-compliant client hello without
explicitly disabling the cipher suites they do not support because they
will never supply the required key material.
--
Florian Weimer / Red Hat Product Security Team
From af125d1abb2af6dd4853188d2e6d99963ae959c2 Mon Sep 17 00:00:00 2001
From: Florian
this
in any standard, so I suggest removing it (idna.patch).
--
Florian Weimer / Red Hat Product Security Team
commit 373bf51bb3a64f4d91241752be7178104d0de28b
Author: Florian Weimer fwei...@redhat.com
Date: Mon Nov 19 11:04:56 2012 +0100
Adjust v3nametest.c return value checking to API
When x32 support was added to this file, the constraint was dropped,
allowing GCC to overlap register assignments for inputs and outputs,
resulting in broken assembler code.
--
Florian Weimer / Red Hat Product Security Team
commit 9dbf28460d10387c819d332b7a5c0397942b75ee
Author: Florian
Apparently, the IV initialization was moved to tls1_enc() t1_enc.c, so
the commented-put initialization is indeed superfluous. And indeed, the
IV on the wire appears to be random.
Could someone please double-check this? Thanks.
--
Florian Weimer / Red Hat Product Security Team
commit
There's a POD error in the manpage, resulting in quite misleading
documentation.
--
Florian Weimer / Red Hat Product Security Team
commit cb06d593d1a59c932614c4e97055b441fc66c4ec
Author: Florian Weimer fwei...@redhat.com
Date: Tue Nov 13 14:22:44 2012 +0100
Fix POD usage
an internal error. Right now, it is not possible to
tell match failures and internal errors apart.
Florian
--
Florian Weimer / Red Hat Product Security Team
diff --git a/crypto/x509v3/Makefile b/crypto/x509v3/Makefile
index 07e2df4..b54f540 100644
--- a/crypto/x509v3/Makefile
+++ b/crypto/x509v3
not verify that $FILE is a writable
file.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
__
OpenSSL
not verify that $FILE is a writable
file.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
to
derive it as well (from d and q).
OTOH, it's probably faster to calculate n = pq and not to rely CRT at
all.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685
46 matches
Mail list logo
