标签 Opensource 下的文章

Rob Pike的“抱怨”与Go的“解药”:直面软件膨胀的四大根源

本文永久链接 – https://tonybai.com/2025/04/27/rob-pike-on-bloat

大家好,我是Tony Bai。

今年年初,Go语言之父、UTF-8编码的发明者Rob Pike的一篇题为”On Bloat”(关于膨胀)的演讲幻灯片(在2024年下旬做的)在技术圈,尤其是在Hacker News(以下简称HN)上,引发了相当热烈的讨论。Pike作为业界泰斗,其对当前软件开发中普遍存在的“膨胀”现象的犀利批评,以及对依赖管理、软件分层等问题的深刻担忧,无疑戳中了许多开发者的痛点。

HN上的讨论更是五花八门,开发者们纷纷从自身经历出发,探讨“膨胀”的定义、成因和后果。有人认为膨胀是“层层叠加的间接性”导致简单修改寸步难行;有人认为是“不必要的功能堆砌”;还有人归咎于“失控的依赖树”和“缺乏纪律的开发文化”。

那么,Rob Pike究竟在“抱怨”什么?他指出的软件膨胀根源有哪些?而作为我们Gopher,Go语言的设计哲学和工具链,能否为我们从纯技术层面提供对抗膨胀的“解药”呢?今天,我们就结合Pike的演讲精髓和HN的热议,深入聊聊软件膨胀的四大根源,并从Go的视角尝试寻找一下应对之道。

“膨胀”的真相:远不止代码大小和运行速度

在深入探讨根源之前,我们需要认识到,“膨胀”并不止是字面意义上我们理解的最终编译产物的大小或者应用的运行速度慢,Pike的观点和HN讨论中的“软件膨胀”体现在多个维度:

  • 复杂性失控: 过度的抽象层次、复杂的依赖关系、难以理解的代码路径,使得维护和迭代变得异常困难。
  • 维护成本剧增: 添加新功能的长期维护成本(包括理解、测试、修复Bug、处理兼容性)远超初次实现的成本,但往往被低估。
  • 不可预测性与脆弱性: 庞大且快速变化的依赖树使得我们几乎无法完全理解和掌控软件的实际构成和行为,任何更新都可能引入未知风险。

下面我们具体看看Pike指出的“膨胀”几个核心根源:

根源一:特性 (Features) —— “有用”不等于“值得”

Pike 指出,我们不断地为产品添加特性,以使其“更好”。但所有特性都会增加复杂性和成本,而维护成本是最大的那部分,远超初次实现。他警示我们要注意“有用谬论” —— 并非所有“有用”的功能都值得我们付出长期的维护代价。

HN讨论也印证了这一点:功能冗余、为了匹配竞品或满足某个高层“拍脑袋”的想法而添加功能、甚至开发者为了个人晋升而开发复杂功能的现象屡见不鲜。

技术层面:Go的“解药”在哪?

  • 简洁哲学: Go从设计之初就强调“少即是多”,鼓励用简单的原语组合解决问题,天然地抵制不必要的复杂性。
  • 强大的标准库: Go 提供了功能丰富且高质量的标准库,覆盖了网络、并发、加解密、I/O 等众多领域,减少了对外部特性库的依赖。很多时候,“自己动手,丰衣足食”(使用标准库)比引入一个庞大的外部框架更符合Go的风格。
  • 关注工程效率: Go的设计目标之一是提高软件开发(尤其是大型项目)的工程效率和可维护性,这促使Go社区更关注代码的清晰度和长期成本。

注:技术层面包括语言、工具以及设计思路和方法。

根源二:分层 (Layering) —— 在错误的层级“打补丁”

Pike 认为,现代软件层层叠加(硬件 -> 内核 -> 运行时 -> 框架 -> 应用代码),当出现问题时,我们太容易在更高的层级通过包装(wrap)来“修复”问题,而不是深入底层真正解决它。这导致了层层叠叠的“创可贴”,增加了复杂性和维护难度。他列举了ChromeOS文件App的例子,并强调要在正确的层级实现功能和修复

在HN的讨论中,有开发者描述的修改按钮颜色需要穿透17个文件和多个抽象层的例子,正是这种“错误分层”或“过度抽象”的生动体现。

技术层面:Go的“解药”在哪?

  • 小接口哲学: Go 鼓励定义小而专注的接口,这使得组件之间的依赖更清晰、更松耦合。当问题出现时,更容易定位到具体的接口实现层去修复,而不是在外部层层包装。
  • 组合优于继承: Go 通过组合(struct embedding)而非继承来实现代码复用,避免了深度继承带来的复杂性和脆弱性,使得在“正确层级”修改代码更易操作。
  • 显式错误处理: if err != nil 的模式强制开发者在调用点处理错误,使得问题更难被“隐藏”到上层去统一“包装”处理,鼓励在错误发生的源头附近解决或添加上下文。

根源三:依赖 (Dependencies) —— 看不见的“冰山”

这是Pike演讲中着墨最多、也最为忧虑的一点。他用数据(NPM 包平均依赖 115 个其他包,每天 1/4 的依赖解析发生变化)和实例(Kubernetes 的复杂依赖图)强调:

  • 现代软件依赖数量惊人且变化极快。
  • 我们几乎不可能完全理解自己项目的所有直接和间接依赖。
  • 依赖中隐藏着巨大的维护成本、Bug 和安全风险
  • 简单的 npm update 或 audit 无法解决根本问题

他强烈建议要理解依赖的成本严格、定期地审视依赖树,并推荐了 deps.dev 这样的工具。

HN 社区对此深有同感,纷纷吐槽“为了一个函数引入整个库”、“脆弱的传递性依赖”、“供应链安全”等问题,并呼唤更好的依赖分析工具。

技术层面:Go的“解药”在哪?

  • Go Modules: 相比 NPM 等包管理器,Go Modules 提供了相对更好的依赖管理机制,包括语义化版本控制、go.sum 校验和、最小版本选择 (MVS) 等,提高了依赖的可预测性和安全性,但也要注意Go module并非完美
  • 强大的标准库: 这是 Go 对抗依赖泛滥的最有力武器。很多功能可以直接使用标准库,避免引入外部依赖。
  • 社区文化: Go 社区相对而言更推崇稳定性和较少的依赖。引入一个大型框架或过多的外部库在 Go 社区通常需要更充分的理由。
  • 工具支持: Go 提供了 go mod graph, go mod why 等命令,可以帮助开发者理解依赖关系。结合 deps.dev,可以在一定程度上实践 Pike 的建议。

根源四:开源模式 (Open Source Development) —— “大门敞开” vs “严格把关”

Pike 对比了两种开源开发模式:

  • “真正的开源方式” (The true open source way): 接受一切贡献 (Accept everything that comes)。他认为这是膨胀和 Bug 的巨大来源
  • 更好的方式: 设立严格的代码质量、标准、评审、测试、贡献者审查等“门槛”,对允许合入的内容有标准。这种方式维护成本低得多。

他暗示 Go 项目本身更倾向于后者,强调“先做好再提交”(make it good before checking it in)。可能很多Gopher也感受到了这一点,Go项目本身对代码质量的review非常严格,这一定程度上也“延缓”了一些新特性进入Go的时间点。

HN 的讨论中也涉及了类似 “Bazaar vs Cathedral” 的模式对比,但观点更加复杂,认为现实中的项目往往处于两者之间的某个位置,并且“完全不接受外部贡献”也并非良策。

技术层面:Go的“解药”在哪?

  • Go 自身的开发模式: Go 语言本身(由 Google 主导)的开发流程相对严谨,对代码质量和向后兼容性有较高要求,可以看作是“严格把关”模式的体现。
  • 标准库的设计: Go 标准库的设计精良、接口稳定,为开发者提供了一个高质量的基础平台,减少了对外部“随意贡献”的依赖。
  • 社区项目实践: 观察 Go 社区一些知名的开源项目,其贡献流程和代码标准通常也比较严格。

反思与现实:Go 也非万能,“警惕与纪律”仍是关键

虽然 Go 的设计哲学和工具链在对抗软件膨胀方面提供了许多“天然优势”和“解药”,但我们必须清醒地认识到,Go 语言本身并不能完全免疫膨胀

正如 Pike 在其“建议”(Advice) 中反复强调的,以及 HN 讨论中部分开发者指出的,最终软件的质量很大程度上取决于开发者和团队的“警惕与纪律” (vigilance and discipline)

  • 我们是否真正理解并避免了增加不相称成本的特性
  • 我们是否努力在正确的层级解决问题
  • 我们是否审慎地评估和管理了每一个依赖
  • 我们是否坚持了高标准的开发和评审流程

如果缺乏这些,即使使用 Go,项目同样可能变得臃肿、复杂和难以维护。同时,HN 讨论也提醒我们,软件膨胀背后还有更深层次的组织、文化和经济因素,这些往往超出了单纯的技术和开发者纪律所能解决的范畴。

小结:拥抱 Go 的简洁,但需务实前行

Rob Pike 的“抱怨”为我们敲响了警钟,Hacker News 的热议则展现了软件膨胀问题的复杂性和普遍性。它确实是我们在工程实践中需要持续对抗的“熵增”现象。

Go 语言以其简洁、显式、组合的设计哲学,以及强大的标准库和相对稳健的依赖管理,在技术层面上,为我们提供了对抗膨胀的有力武器。理解并拥抱这些 Go 的“基因”,无疑能在一定程度上帮助我们构建更健康、更可持续的软件系统。

当然,Pike 的观点也并非金科玉律。有批评者指出,他的视角可能带有一定的“NIH(非我发明)倾向”,并且存在两个关键的“盲点”:

  1. 忽视了“不使用依赖”同样是巨大的技术债。 每一行自写的代码都需要永远维护。
  2. 现实中的选择往往不是“使用依赖 vs 自己实现”,而是“使用依赖 vs 根本不做这个功能”。 面对复杂的合规要求(如 ADA、GDPR)、第三方集成或 FIPS 认证等,从零开始构建的成本(可能需要数百人年)往往让“自己实现”变得不切实际。为了让产品能够及时上线并满足用户(哪怕是 Pike 本人可能也在使用的“缓慢”网站)的需求,引入依赖和一定的“膨胀”有时是必要且务实的选择。

注:“NIH(非我发明)倾向”是一种心理现象,指的是人们对他人提出的想法或创新持有偏见,通常因为这些想法不是自己发明的。这种倾向使得人们倾向于低估或拒绝其他人的创意,尽管这些创意可能是有价值的。

这种批评也提醒了我们,虽然 Pike 对简洁和纪律的呼吁值得我们高度重视,但在真实的商业环境和复杂的工程约束下,我们必须做出务实的权衡。纯粹的技术理想有时需要向现实妥协。

最终,我们每一位 Gopher 都需要在理解 Go 简洁之道的同时,保持批判性思维和务实态度。 在日常的每一个决策中,审慎地权衡简单与复杂、理想与现实、引入依赖与自主掌控,才能在这场与“膨胀”的持久战中,找到最适合我们项目和团队的平衡点,交付真正有价值且可持续的软件。

你如何看待 Rob Pike 对软件膨胀的观点?你认为他的批评切中要害,还是忽视了现实的复杂性?欢迎在评论区分享你的思考与实践!

参考资料

  • Rob Pike – On Bloat – https://docs.google.com/presentation/d/e/2PACX-1vSmIbSwh1_DXKEMU5YKgYpt5_b4yfOfpfEOKS5_cvtLdiHsX6zt-gNeisamRuCtDtCb2SbTafTI8V47/pub?slide=id.p
  • HN:On Bloat – https://news.ycombinator.com/item?id=43045713
  • Pike is wrong on bloat
  • On Bloat – https://commandcenter.blogspot.com/2025/02/on-bloat-these-are-slides-from-talk-i.html

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

Go安全版图再添利器:OpenPubkey SSH开源,用SSO彻底改变SSH认证

本文永久链接 – https://tonybai.com/2025/03/31/openpubkey-ssh-open-source

对于许多开发者和运维工程师而言,管理SSH密钥是一项繁琐且易出错的任务。正如SSH发明者、芬兰计算机科学家Tatu Ylonen所指出的,许多组织中过时授权密钥的数量甚至远超员工人数,这带来了巨大的安全隐患。现在,一个基于Go语言生态的创新项目——OpenPubkey SSH (OPKSSH),旨在彻底改变这一现状。近日,随着Cloudflare将OPKSSH代码捐赠给Linux基金会下的OpenPubkey项目并将其开源,开发者们终于可以拥抱一种更便捷、更安全的SSH认证方式:使用熟悉的单点登录(SSO)系统。本文将简要介绍OPKSSH项目及其技术基石OpenPubkey技术。

1. 核心看点:OPKSSH 开源与价值解读

OPKSSH (OpenPubkey SSH) 是一个巧妙的工具,它将OpenID Connect (OIDC) 等现代SSO技术与SSH协议集成起来,其核心目标是消除手动管理和配置SSH公私钥的需求,同时不引入除身份提供商(IdP)之外的任何新的可信第三方

此前,虽然底层的OpenPubkey协议已于2023年成为Linux基金会的开源项目,但OPKSSH作为BastionZero(现已被Cloudflare收购)的产品,一直是闭源的。Cloudflare的此次捐赠,使得整个OpenPubkey技术栈的关键应用层实现也完全开放,这对于Go社区和整个基础设施安全领域都是一个重要进展。

2. OPKSSH解决了什么痛点?

通常,我们在进行远程服务器管理和运维操作时会使用SSH免密登录,即通过生成SSH密钥对并将公钥复制到远程服务器来实现。但这种传统方式的SSH密钥管理存在诸多问题:

  • 密钥分发与轮换困难:需要手动将公钥部署到目标服务器,密钥泄露或员工离职后的吊销流程复杂。
  • 长期密钥风险:长期存在的私钥增加了泄露风险,一旦泄露,影响范围广。
  • 可见性差:难以清晰追踪谁拥有对哪些服务器的访问权限,公钥本身缺乏身份信息。

这些问题常常困扰企业的IT运维团队和安全管理人员,他们需要确保访问控制的安全性和可管理性,同时降低操作复杂性和人力成本。

那如何解决这些问题呢?OPKSSH带来了新的解决方案。

3. OPKSSH如何解决这些问题?

OPKSSH基于OpenPubkey协议,带来了革命性的改进:

  • 使用临时性密钥(Ephemeral Keys)提升安全性

OPKSSH使用按需生成的临时SSH密钥对取代长期密钥。用户通过SSO登录后,OPKSSH自动生成有效期较短(默认为24小时,可配置)的密钥。这大大缩短了密钥泄露的风险窗口。

  • 通过单点登录(SSO Login)增强易用性

用户只需运行opkssh login,通过熟悉的IdP (如Google, Azure AD等) 进行SSO认证,即可自动获取所需的SSH密钥。无需手动生成、复制或管理私钥文件,即可在任何安装了opkssh的机器上进行SSH连接。

  • 通过Identity-based Auth提升可见性与简化管理

授权不再基于难以管理的公钥列表(比如~/.ssh/known_hosts),而是基于易于理解和审计的用户身份(如Email地址)。管理员只需在服务器配置中指定允许访问的电子邮件地址列表即可。

到这里你可能会问:这么好用的OPKSSH是如何工作的呢?别急,我们下面就来介绍一下OPKSSH的工作原理。

4. OPKSSH的工作原理

Cloudflare的文章中有一个很好的介绍Opkssh工作原理的例子和示意图,这里也借用过来:

如图所示,当用户alice@example.com使用OPKSSH登录服务器,这个过程大致如下:

  • 用户本地执行命令opkssh login触发OIDC流程,用户向IdP认证。
  • OpenPubkey协议介入,在OIDC流程中巧妙地将用户临时生成的公钥与用户的身份信息绑定,生成一个PK Token(本质上是一个增强的ID Token,包含了公钥信息并由IdP签名)。
  • OPKSSH将此PK Token打包进一个临时的SSH 公钥文件(利用SSH证书的扩展字段)。
  • 当用户发起SSH连接时,这个特殊的公钥文件被发送到服务器。
  • 服务器配置了AuthorizedKeysCommand指令,调用opkssh verify(OpenPubkey验证器)。
  • 验证器检查PK Token的有效性(签名、有效期、颁发者),提取公钥和用户身份(Email),并根据服务器配置判断该用户是否有权访问。

关键在于,这一切无需修改现有的SSH客户端或服务器软件本身,仅需在服务器端sshd_config中添加两行配置即可启用,这个我们在本文后面会详细说明。

OPKSSH的魔力源于其底层的OpenPubkey协议。OpenPubkey本身是一个基于Go语言实现的Linux基金会项目 (github.com/openpubkey/openpubkey)。

OpenPubkey的核心创新在于,它通过一种客户端修改的方式,将用户持有的公钥(PKu)与OIDC的ID Token进行了加密绑定,而无需 OIDC 提供商(OP)作任何修改。这是通过巧妙利用OIDC流程中的nonce参数实现的。客户端不再生成完全随机的nonce,而是生成一个包含其公钥等信息的客户端实例声明(cic),并将cic的哈希值作为nonce发送给OP。OP在签发ID Token时会包含这个nonce。这样,最终得到的PK Token就同时承载了OP 对用户身份的认证以及用户对其公钥的所有权声明(通过客户端的额外签名防止身份误绑定攻击)。

这一机制将OIDC的认证模型从持有者认证(Bearer Authentication) 升级到了持有证明(Proof-of-Possession, PoP)。在Bearer模型下,任何窃取到ID Token的人都可以冒充用户;而在PoP模型下,用户需要证明自己持有与PK Token中公钥对应的私钥,从而有效抵御令牌重放(Token Replay)令牌泄露(Token Export) 攻击,安全性显著提高。

OpenPubkey的设计还考虑了可扩展性,例如引入MFA-Cosigner概念,可以进一步增强安全性,甚至在OP本身被攻陷的情况下也能提供保护。关于OpenPubkey协议设计的详细内容,可以参见参考资料中OpenPubkey的论文,这里就不赘述了。

了解了原理之后,下面我们来实际验证一下opkssh通过IdP实现SSO一键登录服务器的效果。

5. 使用opkssh实现免密登录服务器

这次验证的环境是这样的:

  • 客户端:macOS
  • 服务端:Ubuntu 22.04.1 LTS
  • IdP:microsoft (注:国内访问microsoft的服务器成功率高)

我们先来看看客户端的操作步骤:

5.1 opkssh在客户端的操作

首先在客户端安装opkssh,你可以选择直接下载编译好的opkssh二进制文件:

$curl -L https://github.com/openpubkey/opkssh/releases/latest/download/opkssh-osx-amd64 -o opkssh; chmod +x opkssh

由于opkssh是纯Go实现的,如果你本地有Go工具链,也可以选择通过源码安装(在国内,可能选择源码安装的速度更快):

$go install github.com/openpubkey/opkssh@latest

安装完成后,我们就来进行客户端的IdP认证。输入下面命令:

$opkssh login
INFO[0000] Opening browser to http://127.0.0.1:59638/chooser

该命令会打开本地浏览器,并展示下面页面:

截止到目前,opkssh支持选择Google、Microsoft或Gitlab作为IdP,这里我们选择Sign in with Microsoft

之后浏览器将跳转到下面页面:

这里使用我的Microsoft账号进行身份认证,点击“接受”,即完成认证,之后你可以关闭页面!

而命令行也会提示下面信息:

INFO[0002] listening on http://127.0.0.1:3000/
INFO[0002] press ctrl+c to stop
Writing opk ssh public key to /Users/tonybai/.ssh/id_ed25519.pub and corresponding secret key to /Users/tonybai/.ssh/id_ed25519Keys generated for identity
Email, sub, issuer, audience:
bigwhite.cn@hotmail.com AAAAAAAAAAAAAAAAAAAAAP5YMhbf2Ufl_eI1PdK12VE https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0 096ce0a3-5e72-4da8-9c86-12924b294a01

接下来,我们再来看看服务端要进行的操作与配置。

5.2 opkssh在服务端的操作

在要登录的服务器端安装opkssh,由于安装后还要进行一些设置,我建议直接采用opkssh项目提供的安装脚本进行安装:

$ wget -qO- "https://raw.githubusercontent.com/openpubkey/opkssh/main/scripts/install-linux.sh" | sudo bash
Detected OS is debian
Created group: opksshuser
Created user: opksshuser with group: opksshuser
Downloading version latest of opkssh from https://github.com/openpubkey/opkssh/releases/latest/download/opkssh-linux-amd64...
opkssh                           100%[========================================================>]  16.01M  83.4MB/s    in 0.2s
Installed opkssh to /usr/local/bin/opkssh
Configuring opkssh:
  Creating sudoers file at /etc/sudoers.d/opkssh...
  Adding sudoers rule for opksshuser...
Installation successful! Run 'opkssh' to use it.

之后我们需要修改一下服务端的sshd server的配置。SSH服务器支持一个名为AuthorizedKeysCommand的配置参数,该参数允许我们使用自定义程序来确定SSH公钥是否被授权。因此,我们通过对/etc/ssh/sshd_config文件进行以下两行更改,将SSH服务器的配置文件更改为使用OpenPubkey验证程序而不是SSH默认的验证程序:

AuthorizedKeysCommand /usr/local/bin/opkssh verify %u %k %t
AuthorizedKeysCommandUser opksshuser

然后通过opkssh添加授权的用户,这些用户登录后将具备root用户权限:

$opkssh add root bigwhite.cn@hotmail.com microsoft
Successfully added new policy to /etc/opk/auth_id

最后重启一下sshd服务:

$systemctl daemon-reload
$systemctl status sshd

5.3 ssh登录验证

注:为了避免使用之前的ssh免密登录,可以在服务端将.ssh/authorized_keys中的公钥删除!

服务端的opkssh命令行被sshd服务调用进行客户端验证时,会在/var/log/opkssh.log中打印相关日志,这也是opkssh起到作用的一个间接证明。

我在客户端依然以原先的ssh登录命令尝试登录服务器:

$ssh root@<your_server_ip>

我们在服务端opkssh.log中可以看到下面一些输出:

2025/03/29 02:57:43 /usr/local/bin/opkssh verify root AAAAKGVjZHNhLXNoYTItbDUQAAABVwZXJtaXQtWDExLWZvcndhcmRpbmcAAAAAAAAAF3Blcm1pdC1hZ2VudC1mb3J3YXJkaW5nAAAAAAAAABZwZXJtaXQtcG9ydC1mb3J3YXJkaW5nAAAAAAAAAApwZXJtaXQtcHR5AAAAAAAAAA5wZXJtaXQtdXNlci1yYwAAAAAAAAAAAAAAaAAAABNlY2RzYS1zaGEyLW5pc3RwMjU2AAAACG5pc3RwMjU2AAAAQQSXO9YZhMPnGkYfnwpFu/HeX29s7q0l4lK5qCgvaeaWh3zBSidDh49Nirsu5Iwh7YVRkKMa5q+hhnJEFAh7FL5LAAAAZAAAABNlY2RzYS1zaGEyLW5pc3RwMjU2AAAASQAAACEAqD5msj3BsQhlpszOJHBoIcmK3Ex/BwyNWKHgp6labScAAAAgULO5naYi9xOmzrShcGiVIprRbdSvdWltioSVKu63h6Y= ecdsa-sha2-nistp256-cert-v01@openssh.com
2025/03/29 02:57:43 Providers loaded:  https://accounts.google.com 206584157355-7cbe4s640tvm7naoludob4ut1emii7sf.apps.googleusercontent.com 24h
https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0 096ce0a3-5e72-4da8-9c86-12924b294a01 24h
https://gitlab.com 8d8b7024572c7fd501f64374dec6bba37096783dfcd792b3988104be08cb6923 24h

2025/03/29 02:57:44 warning: failed to load user policy: failed to read user policy file /root/.opk/auth_id: error reading root home policy using command /usr/bin/sudo -n /usr/local/bin/opkssh readhome root got output Failed to read user's home policy file: failed to open /root/.opk/auth_id, open /root/.opk/auth_id: no such file or directory
 and err exit status 1
2025/03/29 02:57:44 successfully verified

之后,我就成功登录到服务器上了!

6.小结

OPKSSH 的开源是 OpenPubkey 项目和 Go 安全生态的重要里程碑。它不仅提供了一个解决 SSH 密钥管理难题的实用方案,也展示了 Go 语言在构建安全、可靠的基础设施工具方面的强大能力。

我们鼓励对安全、身份认证和 Go 开发感兴趣的开发者们:

  • 试用 OPKSSH: 在你的开发或测试环境中体验 SSO 登录 SSH 的便捷。
  • 关注 OpenPubkey 项目: Star GitHub 仓库,了解最新动态。
  • 参与社区贡献: 通过 Pull Request、Issue 反馈、参与讨论等方式为项目贡献力量。可以在 OpenSSF Slack 的 #openpubkey 频道找到社区成员,或参加每月一次的社区会议。

随着 OPKSSH 的加入和持续发展,我们期待 OpenPubkey 能够在更多场景下发挥价值,例如代码签名 (Sigstore 集成)、端到端加密通信等,进一步丰富和巩固 Go 语言在云原生和安全领域的基础设施地位。

7. 参考资料


Gopher部落知识星球在2025年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。并且,2025年将在星球首发“Gopher的AI原生应用开发第一课”、“Go陷阱与缺陷”和“Go原理课”专栏!此外,我们还会加强星友之间的交流和互动。欢迎大家踊跃提问,分享心得,讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落,享受coding的快乐! 欢迎大家踊跃加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格6$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
  • Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats