On January 23, 2016 11:55:54 PM GMT+01:00, Tim Rice
wrote:
>On Sat, 23 Jan 2016, Corinna Vinschen wrote:
>
>> diff -upr origsrc/openssl-1.1-rc1/util/mkbuildinf.pl
>src/openssl-1.1-rc1/util/mkbuildinf.pl
>> --- origsrc/openssl-1.1-rc1/util/mkbuildinf.pl 2016-01-23
>21:02:18.386710976 +0100
On Jan 23 22:08, Richard Levitte wrote:
> In message <20160123202758.ga13...@calimero.vinschen.de> on Sat, 23 Jan 2016
> 21:27:58 +0100, Corinna Vinschen said:
> vinschen> Second, the build fails trying to compile crypto/cversion.c:
> vinschen>
> vinschen> crypto/cversion.c:62:23: fatal error: b
On Jan 23 22:12, Richard Levitte wrote:
> In message <20160123210116.gb13...@calimero.vinschen.de> on Sat, 23 Jan 2016
> 22:01:16 +0100, Corinna Vinschen said:
>
> vinschen> On Jan 23 21:35, Kurt Roeckx wrote:
> vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote:
> vins
On Jan 24 13:19, Corinna Vinschen wrote:
> On Jan 23 22:12, Richard Levitte wrote:
> > In message <20160123210116.gb13...@calimero.vinschen.de> on Sat, 23 Jan
> > 2016 22:01:16 +0100, Corinna Vinschen said:
> >
> > vinschen> On Jan 23 21:35, Kurt Roeckx wrote:
> > vinschen> > On Sat, Jan 23, 201
On Sun, Jan 24, 2016 at 01:19:00PM +0100, Corinna Vinschen wrote:
> On Jan 23 22:12, Richard Levitte wrote:
> > In message <20160123210116.gb13...@calimero.vinschen.de> on Sat, 23 Jan
> > 2016 22:01:16 +0100, Corinna Vinschen said:
> >
> > vinschen> On Jan 23 21:35, Kurt Roeckx wrote:
> > vinsch
Corinna Vinschen skrev: (24 januari 2016 13:19:00 CET)
>On Jan 23 22:12, Richard Levitte wrote:
>> In message <20160123210116.gb13...@calimero.vinschen.de> on Sat, 23
>Jan 2016 22:01:16 +0100, Corinna Vinschen said:
>>
>> vinschen> On Jan 23 21:35, Kurt Roeckx wrote:
>> vinschen> > On Sat, Jan
From: openssl-dev on behalf of Richard
Levitte
Sent: Friday, January 22, 2016 2:20 AM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [eng_rdrand] alloc and free
In message
on Thu, 21 Jan 2016 10:57:19 +, Catalin Vasile said:
cata.vasil
On Jan 24 14:41, Richard Levitte wrote:
> Corinna Vinschen skrev: (24 januari 2016 13:19:00 CET)
> >On Jan 23 22:12, Richard Levitte wrote:
> >> This is interesting, actually. OSSL_DYNAMIC_OLDEST has some design
> >> around it that's meant to permit EXACTLY that kind of mixture. It's
> >> in the
On Jan 24 14:35, Kurt Roeckx wrote:
> On Sun, Jan 24, 2016 at 01:19:00PM +0100, Corinna Vinschen wrote:
> > On Jan 23 22:12, Richard Levitte wrote:
> > > This is interesting, actually. OSSL_DYNAMIC_OLDEST has some design
> > > around it that's meant to permit EXACTLY that kind of mixture. It's
>
On January 24, 2016 3:52:19 PM GMT+01:00, Corinna Vinschen
wrote:
>On Jan 24 14:41, Richard Levitte wrote:
>> Corinna Vinschen skrev: (24 januari 2016
>13:19:00 CET)
>> >On Jan 23 22:12, Richard Levitte wrote:
>> >> This is interesting, actually. OSSL_DYNAMIC_OLDEST has some
>design
>> >> aro
--On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte
wrote:
A more portable fix would be
# !/usr/bin/env perl
Yes. Thanks for the reminder.
Hm, we did that in some script in Zimbra, and it ended up causing segfaults
on RHEL systems that were pulling in a different perl than the sys
In message on Sun, 24 Jan 2016
12:36:29 -0800, Quanah Gibson-Mount said:
quanah> --On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte
quanah> -- wrote:
quanah>
quanah> >> A more portable fix would be
quanah> >># !/usr/bin/env perl
quanah> >
quanah> > Yes. Thanks for the reminder.
quanah
--On Sunday, January 24, 2016 11:30 PM +0100 Richard Levitte
wrote:
In message on Sun, 24 Jan 2016
12:36:29 -0800, Quanah Gibson-Mount said:
quanah> --On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte
quanah> -- wrote:
quanah>
quanah> >> A more portable fix would be
quanah> >># !/us
In message on Sun, 24 Jan 2016
14:45:13 -0800, Quanah Gibson-Mount said:
quanah> --On Sunday, January 24, 2016 11:30 PM +0100 Richard Levitte
quanah> -- wrote:
quanah>
quanah> > In message on Sun, 24 Jan
quanah> > 2016
quanah> > 12:36:29 -0800, Quanah Gibson-Mount said:
quanah> >
quanah> > q
Is it possible to check for a heartbeat response without calling SSL_read?
I'm pretty sure the answer is no.
This is problematic for me. I'm trying to make a library layer on top of
OpenSSL that uses the heartbeat as an authenticated ack of earlier
messages, without changing the application layer
--On Monday, January 25, 2016 12:05 AM +0100 Richard Levitte
wrote:
quanah> Actually it was Ubuntu rather than RHEL. Unfortuantely, beyond
that, quanah> we're lacking on details, other than it was a perl found in
quanah> /usr/local/bin.
Ok, so I take it someone had made a local build and ins
TLS does this automatically with its record layer and MAC's. Why do you need
to repeat it?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
It's for research.
I need a way, using only SSL layer functionality, for a client to know with
certainty that the server has received a message. This is trivial at the
application layer, but that is not what is wanted.
In particular, the client needs to know that the server has completed a
resume
I don't think you can do this. You will have to have your layer wrap
application data in its own packaging layer. And of course, if there's a TCP
break, you have no idea how many bytes were sent/received on either end.
___
openssl-dev mailing list
To
I was hoping SSL_peek might work, but I can't find any documentation.
I do have the guarantee from the application layer that messaging occurs in
a strict client request -> server response sequence, without any
pipelining, etc. I know with certainty that the heartbeat response is the
next record
Like I said, I don't know that you can do it without changing some source. And
also, heartbeats for TLS (and maybe DTLS) are going away in the next release.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-d
Really? Strange. They are recommended for TLS 1.3
On Sun, Jan 24, 2016 at 5:17 PM, Salz, Rich wrote:
> Like I said, I don't know that you can do it without changing some
> source. And also, heartbeats for TLS (and maybe DTLS) are going away in
> the next release.
>
> ___
> Really? Strange. They are recommended for TLS 1.3
No they're not.
Start perhaps at this thread:
https://www.ietf.org/mail-archive/web/tls/current/msg12283.html
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/ope
The table in the following section of the latest draft for TLS 1.3 started
the confusion:
https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-11
On Sun, Jan 24, 2016 at 6:03 PM, Salz, Rich wrote:
> > Really? Strange. They are recommended for TLS 1.3
>
> No they're not.
>
> Start perha
Yes just means an RFC is on the standards track. Not TLS.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
25 matches
Mail list logo