供应标准库 (crypto/tls)答案

【问题标题】：Vendoring a standard library (crypto/tls)供应标准库 (crypto/tls)
【发布时间】：2017-05-17 10:49:51
【问题描述】：

我想对 Go crypto/tls 标准库进行一些更改。

在供应商文件夹中制作 crypto/tls 的副本是一种好方法吗？

它几乎可以工作，似乎在我编译应用程序（Caddy 网络服务器）时使用了 vendored 副本。除了一个错误，我得到：

go/src/github.com/user/caddy/caddytls/httphandler.go:40：不能使用“vendor/crypto/tls”.Config 文字（类型 *“vendor/crypto/tls”.Config）作为类型*"crypto/tls". 字段值中的配置

有没有一种方法可以解决这个错误？不过对我来说这听起来不太好。

我原以为总是会使用出售的副本，但似乎有些东西仍在使用标准的 crypto/tls 库？（我认为“net/http”是。我也必须提供这个吗？）

【问题讨论】：

“我想对 Go crypto/tls 标准库进行一些更改。”我希望你不要。
对于使用内置 crypto/tls 的所有代码，您将无法获得匹配的类型，因为就 Go 而言，它是一个不同的包。如果您也是供应商球童，这可能会起作用。如果你真的需要修改crypto/tls（我也希望你不要），我认为通过例如处理这个会更简单。用 go 的补丁版本构建一个容器（我猜你可以称它为标准库供应商？）
这将是全有或全无 - 如果你想使用 stdlib 的修改版本（它的任何部分），你必须 fork Go；这就是使它成为标准库的原因。还有第三次投票支持不修改加密/tls。

标签： go caddy

【解决方案1】：

我实际上必须这样做。最实用的方法是复制和修改包（以及它的内部依赖项）——这包括一些导入路径。而且它不是真正的vendored（vendoring基本上是使用未修改的包，否则vendoring工具将无法工作），它是一个fork，名称不同。我猜 caddy 不需要修改后的版本 - 如果需要，您还需要 fork 和修改 caddy。

不言而喻，但在修改 crypto/tls 包时要格外小心——例如，我必须做一个不会真正修改 TLS 操作的最小更改（我需要能够从会话主密钥中获取密钥材料和随机数）。

此外，您必须完全意识到这会带来巨大的成本 - 当新版本的 go 发布时，可能会更新 crypto/tls 包或其依赖项，您将不得不再次应用您的更改，手动。提交原始版本和您的版本之间的差异会有所帮助。我认为这对于重要的更改根本不实用（我的更改非常有限 - Config 中的一个新公共字段，握手中的几行代码，一个新界面）。

【讨论】：

【解决方案2】：

我需要相同的功能。似乎 crypto/tls 包不允许读取从客户端添加到 ClientHello 有效负载中的自定义 TLS 扩展。如果能够检查任何自定义扩展，然后相应地将它们编组出来，那就太好了。

遗憾的是，这不是一个单独的包，因为我们可以在 go.mod 文件中使用替换来指定自定义 TLS 包。

例如

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

然后运行go mod vendor。

./tls 是我应用了更改的本地版本。

【讨论】：

好的，所以我创建了代码库的一个分支，并成功地修改了 TLS 包。然后我继续为我所做的更改创建补丁文件，以便我可以针对任何未来版本运行它。然后我编译了二进制文件，一切正常。感谢您为我指明正确的方向。