On Mon, Aug 26, 2024 at 2:59 PM robert engels <reng...@ix.netcom.com> wrote: > > I don’t think being concerned about the user is correct - I suspect that many > (most?) of the users have no idea the program is even written in Go… > > This is a builders responsibility imo to either fail at start-up with a user > understandable error, add mitigating code, or don’t build and release using > the latest release.
I think this case is more complex, because this involves a network communication with two different sides. It is possible for one or the other side to be rebuilt when the other is not. Ian > > On Aug 26, 2024, at 4:45 PM, Ian Lance Taylor <i...@golang.org> wrote: > > > > 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/CAOyqgcV_DC%3DQC_pihmac_oK0j0BjS4Lq%3DuTcLmzh34gyHLPJmg%40mail.gmail.com.
