Hi, Isn’t the version release notes sufficient? Maybe add a "breaking changes" section? https://tip.golang.org/doc/go1.23
> On Aug 26, 2024, at 4:20 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Mon, Aug 26, 2024 at 8:31 AM Creaky <whatexerc...@gmail.com> wrote: >> >> Want to discuss the impacts from the implementation of the proposal >> crypto/tls: disable RSA key exchange cipher suites by default #63413 and >> possible ways forward beyond go change some code (whilst it may fix the >> issue in the short term, has certain drawbacks, takes time, and is >> impractical in some cases). >> >> This proposal was introduced in Go Version 1.22 for crypto/tls and brought a >> significant behavioural change impacting client server connectivity with >> very little announcement. >> >> People are seeing TLS handshake failures causing complete failure of >> connectivity and not knowing where the issue is. As tooling starts to take >> on the 1.22 / 1.23 Golang changes, the impacts from this change are now >> bubbling to the surface. >> >> I can see why the motivation behind the change is from a good place. There >> are weaknesses in using TLS with RSA encrypted key exchange. However, the >> change as implemented is producing poor outcomes. >> >> From a high level perspective, it is far better to protect communication >> with possibly vulnerable encryption than being completely in the clear. >> However this breakage is encouraging some people to revert to in clear >> connectivity for lacking (unknowing) a better option. >> >> Reading through the original proposal it appears considerations of change >> impact narrowly focused on Internet connected clients and servers and did >> not consider the various audience groups impacted by the proposed (and now >> accepted) change. >> >> This change is now causing one of the more costly failure types, that being >> in the field failures. >> >> What can be done now this proposal is implemented? >> >> Can the proposal and its implementation be reversed? Or removed and >> reintroduced with better communication? > > Thanks for the detailed note. > > My takeaway here is that the Go team needs to provide better > communication about the consequences that people will see from this > kind of change, and how to better communicate those consequences and > how to work around them. That is, I believe that the change is a good > one for the overall ecosystem. But people can encounter this change > and not know what caused it and not know the relatively simple > workarounds that are available. > > As you know, those workarounds are described at > https://go.dev/doc/godebug. People working with an executable program > can set the GODEBUG variable in the environment. People developing a > program from source can do that, and can also add a go:debug directive > to the main package and/or a godebug setting in a go.mod or go.work > file. There are no plans to remove the tlsrsakex setting. > > Still you're absolutely right that the average user will see some sort > of failure to communicate, and will have no clear way to translate > that into what they need to do to change. So the question is: how can > we communicate that better? What are the right channels? Would a Go > blog entry be sufficient? Also, what kinds of errors will users see > in practice, and how can we get those errors to direct them to the > GODEBUG setting? > > Thanks. > > Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWTRwuFjZh_FEEAnJATS_io1VxP5c%2BS4Dv_oeshX-%2B0qA%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/59ECA4AB-CD15-4BA7-BFAC-540804A7D1C4%40ix.netcom.com.
