0

I want to make some changes to the Go crypto/tls standard library.

Is making a copy of crypto/tls in the vendor folder a good way to do this?

It almost works, it seems the vendored is copy used when I compile the application (Caddy webserver). Apart from one error I get:

go/src/github.com/user/caddy/caddytls/httphandler.go:40: cannot use "vendor/crypto/tls".Config literal (type *"vendor/crypto/tls".Config) as type *"crypto/tls".Config in field value

Is there a way of casting to get around this one error? Doesn't sound like good practice to me though.

I would have thought that the vendored copy would always be used, but it seems something is still using the standard crypto/tls library? (I think "net/http" is. Do I have to vendor this too?)

user3340499
  • 189
  • 1
  • 10
  • 4
    "I want to make some changes to the Go crypto/tls standard library." I hope you don't. – Volker May 17 '17 at 12:09
  • 1
    You will not be able to get the types to match for all code that uses the built in `crypto/tls`, because as far as Go is concerned, it's a different package. This might work if you also vendor caddy. If you really need to modify `crypto/tls` (I also hope you don't), i think it would be simpler to handle this by e.g. building a container with a patched version of go (I guess you could call that vendoring the standard library?) – nothingmuch May 17 '17 at 12:50
  • 1
    It's going to be all-or-nothing - if you want to use a modified version of stdlib (any part of it), you must fork Go; that's what makes it the *standard* library. Also a third vote for not modifying crypto/tls. – Adrian May 17 '17 at 13:52

2 Answers2

0

I actually had to do that. The most practical way is to copy and modify the package (as well as its internal dependencies) - this includes some import paths. And it is not really vendored (vendoring is basically using unmodified packages, otherwise vendoring tools will not work), it is a fork, under a different name. I would guess that caddy does not need the modified version - if it does, you need to fork and modify caddy as well.

It goes without saying, but be extremely careful when modifying crypto/tls package - I for example has to make a minimal change that does not really modify TLS operation (I needed to be able to derive key material from the session master secret and randoms).

Also, you have to fully realize that this has significant cost - when a new version of go is out, one that potentially has updates for the crypto/tls package or its dependencies, you will have to apply your changes once again, manually. Committing a diff between the vanilla version and your version helps. I don't think this is at all practical for non-trivial changes (mine were quite limited - a new public field in Config, few lines of code in handshakes, a new interface).

Petar Donchev
  • 399
  • 4
  • 9
0

I need the same functionality. It seems like the crypto/tls package does not allow the reading of custom TLS extensions added from the client side in the ClientHello payload. It would be great to be able to check for any custom extensions and then marshal them out accordingly.

It is a pity that this is not a separate package as we could then in our go.mod file be able to use replace to specify a custom TLS package.

e.g

replace golang.org/x/crypto/tls => ./tls

Then running go mod vendor.

Where the ./tls is my local version with the changes applied.

Craig Newton
  • 95
  • 7
  • Ok so I created a fork of the codebase and modified the TLS package with very much success. I then proceeded to create patch files for the changes I made so I can run this against any future versions. I then compiled the binary and everything works perfectly. Thanks for pointing me in the right direction. – Craig Newton May 06 '21 at 12:19