Replies: 9 comments
-
|
真有这么多过期XP用户吗？可能我对这个群体不了解。对于x509 package的剪裁问题，其实开始时也有讨论，最后选择“兼容”SDK，当然golang sdk发展很快，有些还是不兼容的。如果真要开发golang 1.10的国密x509，确实没必要兼容SDK了。适配器模式的话，可能对于TLS这样的通讯协议更合适一点，x509更多的是一些不同的结构、函数、方法，真要兼容的话可能要定义许多类似封装结构： type Certificate struct {
_internal interface{}
…
} |
Beta Was this translation helpful? Give feedback.
-
|
没必要吧，更换国产系统是趋势， 没必要在xp上死磕了吧， 另外建议考虑支持loong64的优化，按现在这个架势，未来服务器loong64也是必须支持了 |
Beta Was this translation helpful? Give feedback.
-
|
对于是否有那么多XP用户这不是我们讨论的范畴，在实际应用场景中存在大量的边缘设备，他们的迭代是需要时间和周期的，需要过渡。 关于该问题是否是为了兼容1.10 或向下兼容 我的回答是否 ，我们可以不用考虑这个问题！ 我想讨论的主要是：
由于数字证书本身由ASN1构成，是一系列信息的集合打包，并没有太多复杂度。 当然我理解，确实0015与 是否有必要在不依靠Go官方独立的发展，之前和您层讨论向官方仓库合并问题，Go官方对于商用密码算法系列都不是特别上心。当然我认为要是能够融入Go官方我是非常接受和高兴的！ |
Beta Was this translation helpful? Give feedback.
-
|
之前也和 @xuyang2 讨论过：https://github.com/emmansun/gmsm/issues/14#issue-1108984488， 兼容golang SDK的好处是同步升级、修正bugs比较方便，当然golang 的版本升级比较快，gmsm由于不能并入golang， 并且最低golang版本的支持需求又有很多限制，所以也是尽力而为。主要想法还是以golang 官方为主，兼容、支持国密实现。 |
Beta Was this translation helpful? Give feedback.
-
|
可以考虑先单独新建一个smx509项目，看看效果。 |
Beta Was this translation helpful? Give feedback.
-
|
我正在考虑要是在我时间允许的时候，由我这边独立裁剪一个模块，到时是否能够有合并的可能？ 另外其实在0015中还有这样的一个要求
|
Beta Was this translation helpful? Give feedback.
-
|
没问题啊，到时大家如果觉得这个方式更好，可以考虑合并。 |
Beta Was this translation helpful? Give feedback.
-
|
顺带请问下，目前将go sdk固定下来原因是什么？是出于兼容性考虑吗？ |
Beta Was this translation helpful? Give feedback.
-
你是指固定1.16.x? |
Beta Was this translation helpful? Give feedback.
-
目前我正在将您的代码库向 g1.10 移植，为了支持Windows XP环境。
在移植的过程中我发现在
smx509库内有大量的兼容性的代码例如crypto/ed25519这个库，以及相关测试用例。从代码清晰度与维护性上来说，造成确实造成了一定困扰。
是否可能有这样一个方案：
crypto/x509模块，只保留必要的代码逻辑，按照《GMT 0015-2012 基于SM2密码算法的数字证书格式》重新设计smx509模块。虽然失去了一定的兼容性，但是长久来说，标准的X509由Golang官方维护，符合国密标准的数字证书整个逻辑由社区独立维护，必要时提供的适配器来实现兼容，正如GoTLCP那样。
以上均为提案，我们可以讨论一下这样做是否具有价值。
PS: 感谢您长久以来对该库的维护！
Beta Was this translation helpful? Give feedback.
All reactions