Comments (5)
Thanks for bringing this up.
I apologize for any inconvenience this has caused, this should not happen and I am terribly sorry. I will keep this in mind for any upcoming changes and try not to introduce conflicting APIs in the same major version.
No worries! Rather, thank you for maintaining uTLS 🙌 !
On a different note, I have to mention that uTLS, being a superset of
crypto/tls
, choose to respect all changes made tocrypto/tls
even if they could be breaking. It is my personal observation that Go std libraries are not being completely backward compatible across minor versions. In the most recent minor release (Go 1.21) quite a few existing APIs have been broken incrypto/tls
. It feels weird to bump up uTLS major version in this case while we want to try to not introduce a uTLS2 without really major improvements. It's still something I haven't been able to figure out, so I'm open for suggestions for the overall versioning policies for uTLS.
Great point! I have some direct, limited experience with this kind of issues because of our crypto/tls fork (whose set of patches on top of crypto/tls is very significantly smaller than the one in uTLS).
An alternative approach could perhaps have been to avoid tagging v1.0, given that v1.0 comes with its own sets of constraints in terms of API stability and import path changes.
But, given that v1.0 has already been released, this approach does not seem possible anymore.
And if it helps, I can definitely add the removed symbols back if you could provide a list of the missing symbols.
Again the intention for the symbol renaming is totally for the documentation accuracy, since Go 1.21 officially implements EMS, we are instead using the
crypto/tls
's implementation and therefore noting in the name that this extension is no longer uTLS-exclusive.
Thank you for explaining! It definitely makes sense to perform this kind of renaming in light of the upstream changes.
In the latest tagged version I added
u_alias.go
to "undo breaking" some of the APIs. For now I'm only linkingUtlsExtendedMasterSecretExtension
toExtendedMasterSecretExtension
but we can add more if needed.
Thank you for this! 🙌
However some of the upstream introduced breaking update (e.g.,
TLS13OnlyState
inu_public.go
is no longer compatible with older versions sincev1.5.0
due toclientHandshakeStateTLS13
's implementation has been changed, or renamings due tocrypto/tls
started to use one of the existing names in uTLS), we still need a good approach to a fix.
Thank you for further explaining other changes!
Let me know if you have other suggestions/comments, or would like me to "unbreak" some other changes by adding/linking some names back, I'd be happy to help.
For now, I have managed to find a compromise solution that has fixed the build of ooniprobe, where we're pinning to a version supported by psiphon and snowflake at the same time.
Regarding suggestions, the only one that comes to my mind is to investigate how the Go project manages to ensure they're not breaking their public API. My (limited) understanding is that they have a directory (https://github.com/golang/go/tree/master/api) in which they put textual files representing APIs, and run CI checks to make sure that new commits are not breaking the existing API definitions. Perhaps, this approach could be adapted to uTLS, and would allow you to know when a symbol that was previously existing has disappeared due to merging with upstream. The source code that implements these checks seems to be in ./src/cmd/api.
from utls.
@gaukas I have been thinking a bit more about this whole issue, especially after analyzing the situation of cross compatibility between Psiphon and Snowflake, which are two dependencies of OONI. They both depend on uTLS and the versions they depend on are incompatible, so we cannot upgrade Snowflake beyond v2.6.2.
Anyway, while thinking it occurred me that, if you bumped the major version number every time you chase a new version of Go and/or introduce new functionality (which maybe is a bit overkill but at least it's a simple rule of thumb), the problem we're having of mutually incompatible versions would disappear. In fact, by bumping the major version number, the import path changes, and we would therefore be able to build both the latest Snowflake and the latest Psiphon at the same time.
What do you think? Does that make sense to you?
from utls.
Thanks for bringing this up.
I apologize for any inconvenience this has caused, this should not happen and I am terribly sorry. I will keep this in mind for any upcoming changes and try not to introduce conflicting APIs in the same major version.
On a different note, I have to mention that uTLS, being a superset of crypto/tls
, choose to respect all changes made to crypto/tls
even if they could be breaking. It is my personal observation that Go std libraries are not being completely backward compatible across minor versions. In the most recent minor release (Go 1.21) quite a few existing APIs have been broken in crypto/tls
. It feels weird to bump up uTLS major version in this case while we want to try to not introduce a uTLS2 without really major improvements. It's still something I haven't been able to figure out, so I'm open for suggestions for the overall versioning policies for uTLS.
from utls.
And if it helps, I can definitely add the removed symbols back if you could provide a list of the missing symbols.
Again the intention for the symbol renaming is totally for the documentation accuracy, since Go 1.21 officially implements EMS, we are instead using the crypto/tls
's implementation and therefore noting in the name that this extension is no longer uTLS-exclusive.
from utls.
In the latest tagged version I added u_alias.go
to "undo breaking" some of the APIs. For now I'm only linking UtlsExtendedMasterSecretExtension
to ExtendedMasterSecretExtension
but we can add more if needed.
However some of the upstream introduced breaking update (e.g., TLS13OnlyState
in u_public.go
is no longer compatible with older versions since v1.5.0
due to clientHandshakeStateTLS13
's implementation has been changed, or renamings due to crypto/tls
started to use one of the existing names in uTLS), we still need a good approach to a fix.
Let me know if you have other suggestions/comments, or would like me to "unbreak" some other changes by adding/linking some names back, I'd be happy to help.
I will close this issue for now, but we can reopen or start a new one when needed. Thanks again and sorry for the inconvenience.
from utls.
Related Issues (20)
- panic: tls: setSessionTicketExt failed: invalid state HOT 3
- Support for padding extension HOT 6
- feat: GREASE ECH Extension HOT 4
- bump Auto parrot for Firefox and Chrome
- bug: configuration for GREASE ECH parrot for Chrome 120 doesn't match BoringSSL HOT 7
- HelloFirefox* gets an ECDSA verification failure HOT 4
- FingerprintClientHello support for GREASE ECH extension
- Weird observation regarding ClientId and Spec HOT 9
- B uTLS does not support 0xFB1A as max version,add ja3 tls error,roundTripper error HOT 7
- crypto/ecdh is not in GOROOT (Go 1.18) HOT 1
- Secured Renegotiation is not supported HOT 10
- What is the hash function of the fingerprint in utls? HOT 6
- HTTP2 (akamai) fingerprint always same? HOT 1
- Example ImportTLSClientHelloFromJSON HOT 6
- Towards better versioning policy HOT 4
- bug: `(*Conn).Handshake()` is called upon `(*UConn).Read()` HOT 3
- *.tlsfingerprint.io down? HOT 6
- Any plans implements in Python HOT 1
- UnmarshalClientHello returns nil
- Request for TLS 1.3 Fingerprint Draft 26 Support
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from utls.