No further feedback, assuming resolved.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://w
> [seggelm...@fh-muenster.de - Wed Apr 14 18:03:15 2010]:
>
> Yes, but the dtls1_buffer_message() function uses a PQ_64BIT pointer
>to pass a PQ_64BIT struct, which is accessed directly. However,
>passed is just the pointer to the array which holds the sequence
>number. This is not ver
On 14.04.2010, at 15:35, Stephen Henson via RT wrote:
>> [seggelm...@fh-muenster.de - Wed Apr 14 12:08:30 2010]:
>>
>> In my opinion the patch is also not necessary, because
>> dtls1_buffer_message() requires a pointer to some 64 bit data to be
>> used as the priority for the queue. However,
> [seggelm...@fh-muenster.de - Wed Apr 14 12:08:30 2010]:
>
> In my opinion the patch is also not necessary, because
>dtls1_buffer_message() requires a pointer to some 64 bit data to be
>used as the priority for the queue. However, s->s3->rrec.seq_num
>already is a pointer, since it is
In my opinion the patch is also not necessary, because dtls1_buffer_message()
requires a pointer to some 64 bit data to be used as the priority for the
queue. However, s->s3->rrec.seq_num already is a pointer, since it is an array.
Using &(s->s3->rrec.seq_num) usually returns the same value, i.e
Patch has already been reverted. Presumably the 0.9.8 one (Checkin
#19561) is OK?
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Proje
The recent checkin #19560 causes a bug by changing the third parameter from
rr->seq_num to &rr->seq_num in dtls_buffer_record() calls in d1_pkt.c. However,
this is not correct because rr->seq_num is an array, see ssl3.h:
unsigned char seq_num[8];
So it was referenced correctly, the change was n
