Hi Sebastian, thanks for looking into this. Could you please comment
on the same PR?
If the author does not respond we can schedule the refactor, keep the
authorship and submit a new PR.
On Tue, Nov 26, 2019 at 9:53 AM Sebastian Laskawiec <slaskawi(a)redhat.com> wrote:
The change seems sensible to me. I've seen many companies that want to restrict TLS
version or ciphers used in their services.
Is there any chance to refactor the PR to use whatever latest/greatest provided by
default in Go when there's no explicit configuration of this? I'm trying to find a
way to minimize the impact of forgetting to align with the latest changes in Go.
On Tue, Nov 26, 2019 at 1:08 PM Bruno Oliveira <bruno(a)abstractj.org> wrote:
> The following PR
) is inspired
> by the idea of achieving higher scores on SSL Labs
> Even though I believe it's great to get high scores on SSL Labs, I can
> see some cons about this change:
> 1. ParseTLS() function needs to be updated for every new Golang
> 2. We shouldn't support TLS 1.0, TLS 1.1
> 3. There's a chance that SSLv3 will be removed in Go 1.14
> If we believe that's our desire to move forward with the idea behind
> this PR, probably some updates will be required. Anyways, feel free to
> comment on that.
> - abstractj
> keycloak-dev mailing list