Re: [PATCH, libressl] discuss: removal of padding extension?
On Wed, Jul 23, 2014, Ted Unangst wrote: > On Wed, Jul 23, 2014 at 10:20, Hanno B??ck wrote: > > Quick background: Some router firmwares from F5 have a bug that they > > fail if the SSL handshake is between 256 and 511 bytes. Is this the same problem discussed in Message-ID: <20140410170056.gi12...@mournblade.imrryr.org> on the openssl-users list? Subject: Re: openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error) > > Following up that openssl and other major ssl implementations > > introduced a TLS padding extension that does nothing else than padding > > the handshake if it is between these sizes. > hmm. the workaround isn't particularly intrusive imo. also, while our > policy has been minimal workarounds, i think that applies to the host > operating system. interop compat is a different beast. Yes -- if it is the problem referenced above then it breaks some other software, i.e., some MTAs.
Re: [PATCH, libressl] discuss: removal of padding extension?
> > Quick background: Some router firmwares from F5 have a bug that they > > fail if the SSL handshake is between 256 and 511 bytes. > > > > Following up that openssl and other major ssl implementations > > introduced a TLS padding extension that does nothing else than padding > > the handshake if it is between these sizes. > > hmm. the workaround isn't particularly intrusive imo. also, while our > policy has been minimal workarounds, i think that applies to the host > operating system. interop compat is a different beast. Indeed. Removal of this code would require proof that it causes no harm. I am quite frankly sick of being told that we are removing code we don't understand, when it is not true. In this case, we have no idea how many broken F5's there are out there, so there is no reason to remove this code. Proving the case would be up to you Hanno. You can start by trying to suggest that the OpenSSL folk should remove it...
Re: [PATCH, libressl] discuss: removal of padding extension?
On Wed, Jul 23, 2014 at 10:20, Hanno Böck wrote: > Hi, > > Quick background: Some router firmwares from F5 have a bug that they > fail if the SSL handshake is between 256 and 511 bytes. > > Following up that openssl and other major ssl implementations > introduced a TLS padding extension that does nothing else than padding > the handshake if it is between these sizes. hmm. the workaround isn't particularly intrusive imo. also, while our policy has been minimal workarounds, i think that applies to the host operating system. interop compat is a different beast. > IMHO this is the wrong way of doing things, because it hides bugs > instead of fixing them. And a bunch of alike workarounds in the past > are one of the reasons TLS is such a mess these days. i generally agree, but to play devil's advocate, i don't see this as a quality of implementation issue. > Also, there have already been devices found that break with this > workaround because they fail if the ssl handshake is above 512 bytes well, the same logic would demand that they fix those devices, too, right? :)
Re: [PATCH, libressl] discuss: removal of padding extension?
I think we can consider removing it, but I think it might be best to wait until after the forthcoming OpenBSD release. On Wed, Jul 23, 2014 at 8:01 AM, Brent Cook wrote: > > On Jul 23, 2014, at 8:04 AM, Bob Beck wrote: > >> An interesting thought Hanno - do we know what other implementations >> (Polar, GnuTLS, etc.) do by default? > > PolarSSL does not generate the extension, but tolerates it on the server side. > > GnuTLS generates it if you enable the %COMPAT or %DUMBFW priority strings. > >> I'm inclined to agree that it never should have been done. Having said >> that, before we nuke it we kind of >> need to know if this is has become de-facto standard behaviour thanks >> to OpenSSL doing this in the >> first place. >> >> -Bob >> >> >> On Wed, Jul 23, 2014 at 2:20 AM, Hanno Böck wrote: >>> Hi, >>> >>> Quick background: Some router firmwares from F5 have a bug that they >>> fail if the SSL handshake is between 256 and 511 bytes. >>> >>> Following up that openssl and other major ssl implementations >>> introduced a TLS padding extension that does nothing else than padding >>> the handshake if it is between these sizes. >>> >>> IMHO this is the wrong way of doing things, because it hides bugs >>> instead of fixing them. And a bunch of alike workarounds in the past >>> are one of the reasons TLS is such a mess these days. >>> Also, there have already been devices found that break with this >>> workaround because they fail if the ssl handshake is above 512 bytes >>> [3]. >>> >>> openssl unconditionally enables the padding extension. I propose a >>> simple step: Just remove it from libressl. >>> >>> >>> >>> [1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html >>> [2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html >>> [3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html >>> >>> cu, >>> -- >>> Hanno Böck >>> http://hboeck.de/ >>> >>> mail/jabber: ha...@hboeck.de >>> GPG: BBB51E42 >> >
Re: IEEE80211_DEBUG
Nathanael Rensen [nathan...@list.polymorpheus.com] wrote:
> The IEEE80211_DEBUG kernel option needs a little help to compile.
>
> Index: ieee80211_pae_input.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_pae_input.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 ieee80211_pae_input.c
> --- ieee80211_pae_input.c 22 Jul 2014 11:06:10 - 1.19
> +++ ieee80211_pae_input.c 23 Jul 2014 14:25:22 -
> @@ -978,7 +978,7 @@ ieee80211_recv_group_msg2(struct ieee802
>
> /* discard if we're not expecting this message */
> if (ni->ni_rsn_gstate != RSNA_REKEYNEGOTIATING) {
> - DPRINTF(("%s: unexpected in state: %d\n", ni->ni_rsn_gstate));
> + DPRINTF(("unexpected in state: %d\n", ni->ni_rsn_gstate));
probably want this:
+ DPRINTF(("%s: unexpected in state: %d\n", ic->ic_if.if_xname,
+ ni->ni_rsn_gstate));
Re: LibreSSL 2.0.3 released
2014-07-23 15:16 GMT+02:00 Martin Hecht : > ...the same (PASS: 42) for > > Ubuntu 12.04 > Scientific Linux 6.5 > SLES 11 SP 1 LTSS Count in current Arch Linux (x86_64): # TOTAL: 42 # PASS: 42 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 -- Michał Markowski
IEEE80211_DEBUG
The IEEE80211_DEBUG kernel option needs a little help to compile.
Index: ieee80211_pae_input.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_pae_input.c,v
retrieving revision 1.19
diff -u -p -r1.19 ieee80211_pae_input.c
--- ieee80211_pae_input.c 22 Jul 2014 11:06:10 - 1.19
+++ ieee80211_pae_input.c 23 Jul 2014 14:25:22 -
@@ -978,7 +978,7 @@ ieee80211_recv_group_msg2(struct ieee802
/* discard if we're not expecting this message */
if (ni->ni_rsn_gstate != RSNA_REKEYNEGOTIATING) {
- DPRINTF(("%s: unexpected in state: %d\n", ni->ni_rsn_gstate));
+ DPRINTF(("unexpected in state: %d\n", ni->ni_rsn_gstate));
return;
}
if (BE_READ_8(key->replaycnt) != ni->ni_replaycnt) {
Also a plug for a previous diff that may have fallen through the cracks:
http://marc.info/?l=openbsd-tech&m=140421855720135
Nathanael
Re: [PATCH, libressl] discuss: removal of padding extension?
On Jul 23, 2014, at 8:04 AM, Bob Beck wrote: > An interesting thought Hanno - do we know what other implementations > (Polar, GnuTLS, etc.) do by default? PolarSSL does not generate the extension, but tolerates it on the server side. GnuTLS generates it if you enable the %COMPAT or %DUMBFW priority strings. > I'm inclined to agree that it never should have been done. Having said > that, before we nuke it we kind of > need to know if this is has become de-facto standard behaviour thanks > to OpenSSL doing this in the > first place. > > -Bob > > > On Wed, Jul 23, 2014 at 2:20 AM, Hanno Böck wrote: >> Hi, >> >> Quick background: Some router firmwares from F5 have a bug that they >> fail if the SSL handshake is between 256 and 511 bytes. >> >> Following up that openssl and other major ssl implementations >> introduced a TLS padding extension that does nothing else than padding >> the handshake if it is between these sizes. >> >> IMHO this is the wrong way of doing things, because it hides bugs >> instead of fixing them. And a bunch of alike workarounds in the past >> are one of the reasons TLS is such a mess these days. >> Also, there have already been devices found that break with this >> workaround because they fail if the ssl handshake is above 512 bytes >> [3]. >> >> openssl unconditionally enables the padding extension. I propose a >> simple step: Just remove it from libressl. >> >> >> >> [1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html >> [2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html >> [3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html >> >> cu, >> -- >> Hanno Böck >> http://hboeck.de/ >> >> mail/jabber: ha...@hboeck.de >> GPG: BBB51E42 >
Re: LibreSSL 2.0.3 released
On Jul 23, 2014, at 8:16 AM, Martin Hecht wrote: > On 07/23/2014 10:09 AM, Dongsheng Song wrote: >> On Tue, Jul 22, 2014 at 10:01 AM, Bob Beck wrote: >>> We have released an update, LibreSSL 2.0.3 - which should >>> be arriving in the LibreSSL directory of an OpenBSD mirror near >>> you very soon. >>> >>> This release includes a number of portability fixes based on the >>> the feedback we have received from the community. It also includes >>> some improvements to the fork detection support. >>> >>> As noted before, we welcome feedback from the broader community. >>> >>> Enjoy, >>> >>> -Bob >>> >>> >> Thanks, all tests passed on Debian 6, 7 and 8 (testing): >> >> $ ./configure --prefix=/opt/libressl >> $ make -j4 >> $ make check >> >> Testsuite summary for libressl 2.0.3 >> >> # TOTAL: 42 >> # PASS: 42 >> # SKIP: 0 >> # XFAIL: 0 >> # FAIL: 0 >> # XPASS: 0 >> # ERROR: 0 >> >> >> Regards, >> Dongsheng >> > ...the same (PASS: 42) for > > Ubuntu 12.04 > Scientific Linux 6.5 > SLES 11 SP 1 LTSS > > is such a feedback useful for the developers? The installations have a > particular selection of installed packages, which may differ from a > standard installation. > > > Martin > Thanks Martin and Dongsheng, SLES is one I had not tried yet; glad to know, as its compiler settings can sometimes be more strict by default. We will hopefully at some point have automated build / regression testing, but until then such reports are appreciated. - Brent
Re: LibreSSL 2.0.3 released
On 07/23/2014 10:09 AM, Dongsheng Song wrote: > On Tue, Jul 22, 2014 at 10:01 AM, Bob Beck wrote: >> We have released an update, LibreSSL 2.0.3 - which should >> be arriving in the LibreSSL directory of an OpenBSD mirror near >> you very soon. >> >> This release includes a number of portability fixes based on the >> the feedback we have received from the community. It also includes >> some improvements to the fork detection support. >> >> As noted before, we welcome feedback from the broader community. >> >> Enjoy, >> >> -Bob >> >> > Thanks, all tests passed on Debian 6, 7 and 8 (testing): > > $ ./configure --prefix=/opt/libressl > $ make -j4 > $ make check > > Testsuite summary for libressl 2.0.3 > > # TOTAL: 42 > # PASS: 42 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 0 > # XPASS: 0 > # ERROR: 0 > > > Regards, > Dongsheng > ...the same (PASS: 42) for Ubuntu 12.04 Scientific Linux 6.5 SLES 11 SP 1 LTSS is such a feedback useful for the developers? The installations have a particular selection of installed packages, which may differ from a standard installation. Martin
Re: [PATCH, libressl] discuss: removal of padding extension?
An interesting thought Hanno - do we know what other implementations (Polar, GnuTLS, etc.) do by default? I'm inclined to agree that it never should have been done. Having said that, before we nuke it we kind of need to know if this is has become de-facto standard behaviour thanks to OpenSSL doing this in the first place. -Bob On Wed, Jul 23, 2014 at 2:20 AM, Hanno Böck wrote: > Hi, > > Quick background: Some router firmwares from F5 have a bug that they > fail if the SSL handshake is between 256 and 511 bytes. > > Following up that openssl and other major ssl implementations > introduced a TLS padding extension that does nothing else than padding > the handshake if it is between these sizes. > > IMHO this is the wrong way of doing things, because it hides bugs > instead of fixing them. And a bunch of alike workarounds in the past > are one of the reasons TLS is such a mess these days. > Also, there have already been devices found that break with this > workaround because they fail if the ssl handshake is above 512 bytes > [3]. > > openssl unconditionally enables the padding extension. I propose a > simple step: Just remove it from libressl. > > > > [1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html > [2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html > [3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html > > cu, > -- > Hanno Böck > http://hboeck.de/ > > mail/jabber: ha...@hboeck.de > GPG: BBB51E42
resume vs wsmoused vs X vs pms
Diff below changes pms(4) to make sure only one thread can change the
state, thus generating I/O, of the underlying device at the same time.
It fixes a race easily reproducible when a machine having wsmoused(8)
and X running is resumed. The problem is that the first program trying
to activate the mouse sleeps in pms_change_state() before changing the
state of the device. At this moment, the second program also tries to
enable the device and enqueue more commands before going to sleep...
While setting the state before going to sleep would also prevent this
particular race, it won't prevent the (very unlikely) scenario where a
program tries to disable the device while another one tries to enable
it.
Other mouse devices parent of wsmouse(4) might be subject to similar
races, but pms(4) is special because it can be the parent of two
wsmouses pointing to the same softc! So at this stage of the release
cycle I think it is safer to only fix this particular and problematic
device.
ok?
Index: pms.c
===
RCS file: /home/ncvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.52
diff -u -p -r1.52 pms.c
--- pms.c 12 Jul 2014 18:48:52 - 1.52
+++ pms.c 23 Jul 2014 11:00:40 -
@@ -26,6 +26,7 @@
#include
#include
+#include
#include
#include
#include
@@ -148,6 +149,8 @@ struct pms_softc { /* driver status inf
#define PMS_STATE_ENABLED 1
#define PMS_STATE_SUSPENDED2
+ struct rwlock sc_state_lock;
+
int sc_dev_enable;
#define PMS_DEV_IGNORE 0x00
#define PMS_DEV_PRIMARY0x01
@@ -762,8 +765,13 @@ int
pms_enable(void *v)
{
struct pms_softc *sc = v;
+ int rv;
+
+ rw_enter_write(&sc->sc_state_lock);
+ rv = pms_change_state(sc, PMS_STATE_ENABLED, PMS_DEV_PRIMARY);
+ rw_exit_write(&sc->sc_state_lock);
- return pms_change_state(sc, PMS_STATE_ENABLED, PMS_DEV_PRIMARY);
+ return (rv);
}
void
@@ -771,7 +779,9 @@ pms_disable(void *v)
{
struct pms_softc *sc = v;
+ rw_enter_write(&sc->sc_state_lock);
pms_change_state(sc, PMS_STATE_DISABLED, PMS_DEV_PRIMARY);
+ rw_exit_write(&sc->sc_state_lock);
}
int
@@ -789,8 +799,13 @@ int
pms_sec_enable(void *v)
{
struct pms_softc *sc = v;
+ int rv;
+
+ rw_enter_write(&sc->sc_state_lock);
+ rv = pms_change_state(sc, PMS_STATE_ENABLED, PMS_DEV_SECONDARY);
+ rw_exit_write(&sc->sc_state_lock);
- return (pms_change_state(sc, PMS_STATE_ENABLED, PMS_DEV_SECONDARY));
+ return (rv);
}
void
@@ -798,7 +813,9 @@ pms_sec_disable(void *v)
{
struct pms_softc *sc = v;
+ rw_enter_write(&sc->sc_state_lock);
pms_change_state(sc, PMS_STATE_DISABLED, PMS_DEV_SECONDARY);
+ rw_exit_write(&sc->sc_state_lock);
}
int
Re: [PATCH, libressl] discuss: removal of padding extension?
On 2014/07/23 10:36, Hanno Böck wrote: > On Wed, 23 Jul 2014 01:28:45 -0700 > Loganaden Velvindron wrote: > > > On Wed, Jul 23, 2014 at 10:20:23AM +0200, Hanno B?ck wrote: > > > Quick background: Some router firmwares from F5 have a bug that they > > > fail if the SSL handshake is between 256 and 511 bytes. > > > > F5 should issue fixes for their firmware. > > They did. The problem is people not updating their firmware. That needs a support contract. There are likely to be many website operators with a "value-for-money" ;) procurement policy unlikely to have access to updated firmware and they won't know about the problem because it will only show up client-side with clients that don't mitigate the bug. I wonder if Google could make available any stats on how common the bad firmware versions are. I imagine that they would know and that it would be pretty significant to be worth going to the effort of producing an internet-draft and getting a diff into OpenSSL.
Re: [PATCH, libressl] discuss: removal of padding extension?
On Wed, 23 Jul 2014 01:28:45 -0700 Loganaden Velvindron wrote: > On Wed, Jul 23, 2014 at 10:20:23AM +0200, Hanno B?ck wrote: > > Quick background: Some router firmwares from F5 have a bug that they > > fail if the SSL handshake is between 256 and 511 bytes. > > F5 should issue fixes for their firmware. They did. The problem is people not updating their firmware. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: [PATCH, libressl] discuss: removal of padding extension?
On Wed, Jul 23, 2014 at 10:20:23AM +0200, Hanno B?ck wrote:
> Hi,
>
> Quick background: Some router firmwares from F5 have a bug that they
> fail if the SSL handshake is between 256 and 511 bytes.
F5 should issue fixes for their firmware.
>
> Following up that openssl and other major ssl implementations
> introduced a TLS padding extension that does nothing else than padding
> the handshake if it is between these sizes.
>
> IMHO this is the wrong way of doing things, because it hides bugs
> instead of fixing them. And a bunch of alike workarounds in the past
> are one of the reasons TLS is such a mess these days.
> Also, there have already been devices found that break with this
> workaround because they fail if the ssl handshake is above 512 bytes
> [3].
>
> openssl unconditionally enables the padding extension. I propose a
> simple step: Just remove it from libressl.
>
>
>
> [1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
> [2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
> [3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html
>
> cu,
> --
> Hanno B?ck
> http://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: BBB51E42
> diff -Naur libressl-2.0.3/include/openssl/tls1.h
> libressl-2.0.3-1/include/openssl/tls1.h
> --- libressl-2.0.3/include/openssl/tls1.h 2014-07-11 18:50:56.0
> +0200
> +++ libressl-2.0.3-1/include/openssl/tls1.h 2014-07-23 10:12:34.081669530
> +0200
> @@ -230,12 +230,6 @@
> /* ExtensionType value from RFC5620 */
> #define TLSEXT_TYPE_heartbeat15
>
> -/* ExtensionType value for TLS padding extension.
> - *
> http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
> - * http://tools.ietf.org/html/draft-agl-tls-padding-03
> - */
> -#define TLSEXT_TYPE_padding 21
> -
> /* ExtensionType value from RFC4507 */
> #define TLSEXT_TYPE_session_ticket 35
>
> diff -Naur libressl-2.0.3/ssl/t1_lib.c libressl-2.0.3-1/ssl/t1_lib.c
> --- libressl-2.0.3/ssl/t1_lib.c 2014-07-14 01:04:03.0 +0200
> +++ libressl-2.0.3-1/ssl/t1_lib.c 2014-07-23 10:12:13.006933000 +0200
> @@ -635,35 +635,6 @@
> }
> #endif
>
> -#ifdef TLSEXT_TYPE_padding
> - /* Add padding to workaround bugs in F5 terminators.
> - * See https://tools.ietf.org/html/draft-agl-tls-padding-03
> - *
> - * NB: because this code works out the length of all existing
> - * extensions it MUST always appear last.
> - */
> - {
> - int hlen = ret - (unsigned char *)s->init_buf->data;
> - /* The code in s23_clnt.c to build ClientHello messages includes the
> - * 5-byte record header in the buffer, while the code in s3_clnt.c does
> - * not. */
> - if (s->state == SSL23_ST_CW_CLNT_HELLO_A)
> - hlen -= 5;
> - if (hlen > 0xff && hlen < 0x200) {
> - hlen = 0x200 - hlen;
> - if (hlen >= 4)
> - hlen -= 4;
> - else
> - hlen = 0;
> -
> - s2n(TLSEXT_TYPE_padding, ret);
> - s2n(hlen, ret);
> - memset(ret, 0, hlen);
> - ret += hlen;
> - }
> - }
> -#endif
> -
> if ((extdatalen = ret - p - 2) == 0)
> return p;
>
[PATCH, libressl] discuss: removal of padding extension?
Hi,
Quick background: Some router firmwares from F5 have a bug that they
fail if the SSL handshake is between 256 and 511 bytes.
Following up that openssl and other major ssl implementations
introduced a TLS padding extension that does nothing else than padding
the handshake if it is between these sizes.
IMHO this is the wrong way of doing things, because it hides bugs
instead of fixing them. And a bunch of alike workarounds in the past
are one of the reasons TLS is such a mess these days.
Also, there have already been devices found that break with this
workaround because they fail if the ssl handshake is above 512 bytes
[3].
openssl unconditionally enables the padding extension. I propose a
simple step: Just remove it from libressl.
[1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
[2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
[3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html
cu,
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
diff -Naur libressl-2.0.3/include/openssl/tls1.h libressl-2.0.3-1/include/openssl/tls1.h
--- libressl-2.0.3/include/openssl/tls1.h 2014-07-11 18:50:56.0 +0200
+++ libressl-2.0.3-1/include/openssl/tls1.h 2014-07-23 10:12:34.081669530 +0200
@@ -230,12 +230,6 @@
/* ExtensionType value from RFC5620 */
#define TLSEXT_TYPE_heartbeat 15
-/* ExtensionType value for TLS padding extension.
- * http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
- * http://tools.ietf.org/html/draft-agl-tls-padding-03
- */
-#define TLSEXT_TYPE_padding 21
-
/* ExtensionType value from RFC4507 */
#define TLSEXT_TYPE_session_ticket 35
diff -Naur libressl-2.0.3/ssl/t1_lib.c libressl-2.0.3-1/ssl/t1_lib.c
--- libressl-2.0.3/ssl/t1_lib.c 2014-07-14 01:04:03.0 +0200
+++ libressl-2.0.3-1/ssl/t1_lib.c 2014-07-23 10:12:13.006933000 +0200
@@ -635,35 +635,6 @@
}
#endif
-#ifdef TLSEXT_TYPE_padding
- /* Add padding to workaround bugs in F5 terminators.
- * See https://tools.ietf.org/html/draft-agl-tls-padding-03
- *
- * NB: because this code works out the length of all existing
- * extensions it MUST always appear last.
- */
- {
- int hlen = ret - (unsigned char *)s->init_buf->data;
- /* The code in s23_clnt.c to build ClientHello messages includes the
- * 5-byte record header in the buffer, while the code in s3_clnt.c does
- * not. */
- if (s->state == SSL23_ST_CW_CLNT_HELLO_A)
- hlen -= 5;
- if (hlen > 0xff && hlen < 0x200) {
- hlen = 0x200 - hlen;
- if (hlen >= 4)
-hlen -= 4;
- else
-hlen = 0;
-
- s2n(TLSEXT_TYPE_padding, ret);
- s2n(hlen, ret);
- memset(ret, 0, hlen);
- ret += hlen;
- }
- }
-#endif
-
if ((extdatalen = ret - p - 2) == 0)
return p;
signature.asc
Description: PGP signature
Re: LibreSSL 2.0.3 released
On Tue, Jul 22, 2014 at 10:01 AM, Bob Beck wrote: > > We have released an update, LibreSSL 2.0.3 - which should > be arriving in the LibreSSL directory of an OpenBSD mirror near > you very soon. > > This release includes a number of portability fixes based on the > the feedback we have received from the community. It also includes > some improvements to the fork detection support. > > As noted before, we welcome feedback from the broader community. > > Enjoy, > > -Bob > > Thanks, all tests passed on Debian 6, 7 and 8 (testing): $ ./configure --prefix=/opt/libressl $ make -j4 $ make check Testsuite summary for libressl 2.0.3 # TOTAL: 42 # PASS: 42 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 Regards, Dongsheng
