On Mon, Jan 16, 2017 at 12:17:39PM +0100, Emmanuel Hocdet wrote:
> > I think this one is wrong :
> >
> > @@ -6769,13 +6779,12 @@ static struct cli_kw_list cli_kws = {{ },{
> > #if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
> > { { "show", "tls-keys", NULL }, "show tls-keys [id|*]: show tls keys
> > references or dump tls ticket keys when id specified",
> > cli_parse_show_tlskeys, NULL },
> > { { "set", "ssl", "tls-keys", NULL }, NULL, cli_parse_set_tlskeys, NULL
> > },
> > - { { "set", "ssl", "ocsp-response", NULL }, NULL,
> > cli_parse_set_ocspresponse, NULL },
> > #endif
> > + { { "set", "ssl", "ocsp-response", NULL }, NULL,
> > cli_parse_set_ocspresponse, NULL },
> > { { NULL }, NULL, NULL, NULL }
> > }};
> >
> > The conditions didn't change in cli_parse_set_ocspresponse(). OK it should
> > probably not depend on TLS_TICKETS_NO but this should be addressed as part
> > of a build fix that's independant on boringssl.
> >
>
> cli_parse_set_ocspresponse have #ifdef in the fonction and display error
> message if not available.
> It should always declare in kw_list to avoid warning at compile time (not
> used).
OK I see, thanks for the explanation.
> It break only some primary test to build with borring, and yes could be out
> this fix.
>
> > By the way, regarding the #ifdef cleanup, I think we can consider all this :
> > - SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB is always set, at least since 0.9.8
> > so we should remove these ifdefs
> >
> > - TLS_TICKETS_NO is always set, though not necessarily > 0. I think we
> > should remove all the #ifdefs around and assume it's always > 0. The
> > compiler will catch the rare occurrences where it's forced to zero
> > (or we can even #error on this one).
> >
> > That would remove quite some #ifdef. And possibly there are other conditions
> > that can be considered as granted since 0.9.8 which we can remove.
> >
> > What do you think ?
> >
>
> I think drop all out-dated openssl support will be a very good thing.
> out-dated is about security: who want only obsolete cipher support than
> disappear
> from internet? sslv3 is drop, current mouvement is to drop support < tls 1.2.
Keep in mind that "the internet" is very different from "internal networks".
Most often people just want something which works internally and are even
fine with the cheaper sslv3 and rsa1024 algos between the LB and the servers.
> Yes, we can remove 0.9.8 support in 1.8dev :)
That's not what I was saying, I said "prior to 0.9.8". Once we do this
cleanup, I guess most of the #ifdefs will be gone. I don't think there
are still many there only for 0.9.8. I'd rather keep it supported if
it requires a low effort, because some LTS distros still have it (eg:
SLES11 is supported till Mar 2019 for general use). We certainly want
users to upgrade their openssl, but we also want them to upgrade their
haproxy so better not force them to stay on an old version just because
of openssl. And building openssl oneself is even worse for security
because nobody thinks about updating it when there's a vulnerability.
Cheers,
Willy
