关于 smx509 模块裁剪

[Trisia]

目前我正在将您的代码库向 g1.10 移植，为了支持Windows XP环境。

在移植的过程中我发现在smx509库内有大量的兼容性的代码例如crypto/ed25519 这个库，以及相关测试用例。

从代码清晰度与维护性上来说，造成确实造成了一定困扰。

是否可能有这样一个方案：

• 通过裁剪golang 官方crypto/x509模块，只保留必要的代码逻辑，按照《GMT 0015-2012 基于SM2密码算法的数字证书格式》重新设计smx509模块。

虽然失去了一定的兼容性，但是长久来说，标准的X509由Golang官方维护，符合国密标准的数字证书整个逻辑由社区独立维护，必要时提供的适配器来实现兼容，正如GoTLCP那样。

以上均为提案，我们可以讨论一下这样做是否具有价值。

PS: 感谢您长久以来对该库的维护！

[emmansun]

真有这么多过期XP用户吗？可能我对这个群体不了解。对于x509 package的剪裁问题，其实开始时也有讨论，最后选择“兼容”SDK，当然golang sdk发展很快，有些还是不兼容的。如果真要开发golang 1.10的国密x509，确实没必要兼容SDK了。适配器模式的话，可能对于TLS这样的通讯协议更合适一点，x509更多的是一些不同的结构、函数、方法，真要兼容的话可能要定义许多类似封装结构：

type Certificate struct {
  _internal interface{}
  …
}

[it512]

没必要吧，更换国产系统是趋势， 没必要在xp上死磕了吧， 另外建议考虑支持loong64的优化，按现在这个架势，未来服务器loong64也是必须支持了

[Trisia]

对于是否有那么多XP用户这不是我们讨论的范畴，在实际应用场景中存在大量的边缘设备，他们的迭代是需要时间和周期的，需要过渡。

关于该问题是否是为了兼容1.10 或向下兼容 我的回答是否 ，我们可以不用考虑这个问题！

我想讨论的主要是：

• 是否独立对数字证书模块进行维护

由于数字证书本身由ASN1构成，是一系列信息的集合打包，并没有太多复杂度。

当然我理解，确实0015与x509没有太大区别本质上，甚至是一个较老的版本，不支持部分特性和参数。说实话代码方面我整体也预览过，就算是独立裁剪其实大部分代码都是没有差别的，只是少数部分调整，然后删除一些与商用密码无关的兼容性代码。

是否有必要在不依靠Go官方独立的发展，之前和您层讨论向官方仓库合并问题，Go官方对于商用密码算法系列都不是特别上心。当然我认为要是能够融入Go官方我是非常接受和高兴的！

[emmansun]

之前也和 @xuyang2 讨论过：https://github.com/emmansun/gmsm/issues/14#issue-1108984488， 兼容golang SDK的好处是同步升级、修正bugs比较方便，当然golang 的版本升级比较快，gmsm由于不能并入golang， 并且最低golang版本的支持需求又有很多限制，所以也是尽力而为。主要想法还是以golang 官方为主，兼容、支持国密实现。

[emmansun]

可以考虑先单独新建一个smx509项目，看看效果。

[Trisia]

我正在考虑要是在我时间允许的时候，由我这边独立裁剪一个模块，到时是否能够有合并的可能？

另外其实在0015中还有这样的一个要求

[emmansun]

没问题啊，到时大家如果觉得这个方式更好，可以考虑合并。

[Trisia]

顺带请问下，目前将go sdk固定下来原因是什么？是出于兼容性考虑吗？

[emmansun]

顺带请问下，目前将go sdk固定下来原因是什么？是出于兼容性考虑吗？

你是指固定1.16.x?

• 从v0.17.0开始，支持最低golang 版本改为1.18.x #99
• [go1.10] 支持go1.10版本的编译使用 #101