On Mon, Aug 26, 2024 at 2:28 PM robert engels <reng...@ix.netcom.com> wrote: > > Isn’t the version release notes > shttps://pkg.go.dev/net/http#Request.Hostufficient? Maybe add a "breaking > changes" section? https://tip.golang.org/doc/go1.23
This change was indeed mentioned in the release notes (https://go.dev/doc/go1.22#minor_library_changes, the crypto/tls entry). But there can be a pretty big gap between the person who builds a program with a new version of Go and the user who encounters a problem running that program. Also that release note is, frankly, pretty cryptic as to the consequences of the change. We want to make it as easy as possible for the user of the program to close that gap. Ian > > 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/CAOyqgcWXhnA6ZwsmvSMiPQ7C%2Bsbg7nUgbxG5DOcmkz6QS%2BUu5A%40mail.gmail.com.
