kriskwiatkowski
commented
6 years ago I don't think introducing new package in TLS lib in order to break dependency cycle isn't right thing to do.
In C you would simply do " #ifndef #define #endif" to solve this particular problem. In go, "interface" is a first thing which comes to my mind. Something like:
-
package DC contains all implementation imports "tls" ** implements package initialization ("func init()"). Package calls "dc_interface.RegisterExtension(Extension_ID, NewDCExtension())
-
package DC_Interface doesn't import neither tls nor dc implements DCextension interface Implements "RegisterExtension()" Implements "Extension()" -> return type is an interface. It returns object which implements the interface.
-
package "tls" ** imports DC_Interface
This way you break dependency and don't need to change "tls". It's also DIP from SOLID. There is maybe one more thing which is bottering me, but I need to read DC RFC first.
cjpatton
Note: This PR is one commit ahead of #91. Review that first.
The DC extension has its own package (
crypto/tls/delegated_credential). This is useful because its API is not only invoked by the TLS client and server, but also by the backend delegator (the entity that signs delegated credentials for use by the TLS server). Thus, if we wanted to implement DC in thecrypto/tlspackage, we would need to change its exported API. It seems cleaner to leave this API alone.The problem is that the DC extension needs to import some constants from
crypto/tls: in particular the identifiers for signature schemes and the protocol version. But sincecrypto/tlsimportscrypto/tls/delegated_credential, there is a circular dependency. This PR removes this circular dependency by defining these constants in a new packagecrypto/tls/constants.This solution is somewhat inelegant in that we still need the names of the constants in the
tlspackage. In fact, there are external packages in golang that use names liketls.VersionTLS12.