密码学开发工具应用安全DevOps【免费下载链接】blackboxSafely store secrets in Git/Mercurial/Subversion项目地址https://gitcode.com/gh_mirrors/bl/blackbox点击查看免费下载本文基于仓库根目录的 RELEASE_ENGINEERING.md 展开系统讲解 BlackBoxGit/Mercurial/Subversion 仓库中的 GPG 安全加密存储工具维护者视角下的发布工程实践从 HEAD/stable/production 三级标签模型、make test测试门槛到 Stable 与 Production 两个阶段的完整发布操作、以及 MacPorts 软件源更新的自动与手动全流程。读完本文你将掌握 BlackBox 从开发到稳定再到生产的分级发布标准操作以及面向 macOS 发行渠道的 Portfile 生成与提交流程。一、发布工程的核心三级分支/标签模型RELEASE_ENGINEERING.md 明确规定了 BlackBox 仓库存在 3 个分支/标签构成一条清晰的风险递进发布阶梯HEAD开发的最前沿cutting edge随时可能变动适合开发者跟踪tag stable已经足够稳定、可供大多数人日常使用的版本tag production经过足够长时间的烧机验证burned in维护者确信它可以被广泛采用。三个标签的定位决定了使用者的跟踪策略如果你正在为 BlackBox 做发行打包packaging for distribution应当跟踪tag production同时可以额外提供一个跟踪tag stable的包供早期采用者使用。这一策略在 CHANGELOG.md 中也有印证——版本号统一采用v1.YYYYMMDD的日期制格式如Release v1.20220610、v1.20200429每个稳定/生产版本都以日期为刻度便于追溯。二、测试门槛发布前的质量闸门在进入任何发布流程之前必须先通过测试。文档给出的测试依赖安装建议如下平台依赖安装命令macOSbrew install gpg pinentryFreeBSDpkg install gpg gmakeCentOS 7yum install gpg运行整套测试的命令是cd ~/src/github.com/StackExchange/blackbox make test注意FreeBSD 上需使用gmake testGNU Make。make test到底在做什么从 Makefile 到 expect 脚本的调用链从仓库 Makefile 的源码看test目标就是confidence目标的别名test: confidence这与 CHANGELOG.md 中 make test is an alias for make confidence 的记录一致。confidence目标在执行前会做一系列环境防护检查检查~/.gnupg不存在——防止测试污染你真实的 GnuPG 配置若存在会直接报错并返回 false若检测到gpg-agent则先pkill gpg-agent并清理/tmp/tmp.*将bin/、PREFIX/bin及各平台常用路径注入PATH然后执行tools/auto_system_test测试结束后再次检查~/.gnupg是否被意外创建若被创建则判定为脚本污染 GnuPG 配置的 bug。真正运行的是 tools/auto_system_test它使用expect非交互式驱动 tools/confidence_test.sh脚本会在输出中告知测试口令my password is the lowercase letter a/bexpect 捕获后自动应答所有Passphrase:提示最多循环 300 次防止死循环。而 tools/confidence_test.sh 本身包含两层测试外部工具预检逐一确认blackbox_addadmin、blackbox_list_admins、blackbox_register_new_file、cat、git、gpg、gpg-agent、mkdir、pinentry、pinentry-tty、rm、tar、which是否在 PATH 中缺失即退出单元测试 系统测试先运行_blackbox_common_test.sh单元测试再创建两个隔离的临时 GNUPGHOMEfake_alice_home/fake_bob_home分别以pinentry-tty配置gpg-agent.conf并启动 daemon模拟 Alice/Bob 双管理员场景做完整的系统测试。另外文档特别提醒测试需要pinentry-tty在 macOS Nix 环境下可用nix-env -i pinentry安装。三、Stable Release发布稳定版的标准步骤Step 0先测软件发布前必须运行单元与系统测试make test测试通过才进入下一步。Step 1更新 CHANGELOG.md用git log查看自上次发布以来的变更并更新 CHANGELOG.md。对于新版本追加形如下面的版本头echo Release v1.$(date %Y%m%d)然后提交git commit -mUpdate CHANGELOG.md CHANGELOG.mdStep 2打 stable 标签git pull git tag -d stable git push origin :stable git tag stable git push origin tag stable上述命令依次完成拉取最新代码 → 删除本地旧的stable标签 → 删除远端旧标签git push origin :stable即删除远端引用→ 在当前 HEAD 重新打stable标签 → 推送新标签到远端。Step 3在日历上标记在日历上记下距今天 1 周的日期用于一周后检查该版本是否应升级为 production。四、Production Release稳定版的转正流程如果在stable标签推送后整整一周内没有 bug 报告就可以把该版本标记为 productiongit fetch git checkout stable git tag -d production git push origin :production git tag production git push origin tag production Rv1.$(date %Y%m%d) git tag $R git push origin tag $R这一系列操作完成了三件事检出 stable 代码git checkout stable保证 production 标签基于刚验证过的稳定版本迁移 production 标签先删本地与远端的旧production标签再在当前提交上重新打并推送打日期版本号用Rv1.$(date %Y%m%d)生成形如v1.20261006的具体版本标签并推送这个版本号与 CHANGELOG.md 中Release v1.20220610等条目一一对应。Step 4记录成绩在个人的每周成果文件中记录本次发布事实便于追踪维护者的发布节奏。五、Updating MacPorts自动流程BlackBox 通过 MacPorts 的vcs_blackboxport 面向 macOS 分发仓库提供了自动化升级脚本 tools/macports_report_upgrade.sh。Step 1生成 Portfiletools/macports_report_upgrade.sh 1.20150222参数是版本号不带 v 前缀脚本内部用${1?Arg 1 must be a version number like 1.20150222 (with no v)}强制校验。脚本执行后会产生两个产物Portfile-vcs_blackbox.diff升级差异补丁文件一段可直接粘贴的 ticket 提交说明。从脚本源码看其自动化逻辑非常完整用sed s/VERSION/版本号/g将 tools/Portfile.template 渲染成新Portfile在/opt/local/etc/macports/sources.conf顶部注入本地源file:///var/tmp/ports若不存在则用sudo sed -i首行插入重建本地端口树/var/tmp/ports/security/vcs_blackbox并复制 Portfile运行sudo portindex执行sudo port -v checksum vcs_blackbox——第一次故意用空的占位 checksum 让它失败从输出中通过 awk 抓取rmd160与sha256两个真实校验值匹配^Distfile checksum: .*rmd160与.*sha256行取最后一列用抓到的值再次sed替换模板中的RMD160与SHA256重新生成并校验从系统端口树拷贝原始Portfile为Portfile.orig用diff --ignore-matching-linesId: -u Portfile.orig Portfile生成补丁文件Portfile-vcs_blackbox.diff并通过open -R在 Finder 中定位。Step 2提交更新请求将 diff 文件作为附件按脚本输出的说明到 MacPorts 的 Tractrac.macports.org新建 ticket字段如下Summaryvcs_blackbox 1.20150222 Update to latest upstreamDescriptionNew upstream of vcs_blackbox. github.setup and checksums updated.TypeupdateComponentportsPortvcs_blackboxKeywordsmaintainer haspatch附件Portfile-vcs_blackbox.diffStep 3跟踪更新提交后持续关注 MacPorts 侧是否完成合入。六、Updating MacPorts手动流程手动流程是旧方法仅在自动化脚本失败时参考其最终产物同样是diff -u Portfile.orig Portfile的输出。新 Portfile 相比旧版必须有两处变更github.setup行换成新的版本号checksums行换成新的校验值。如何生成 checksums最省事的办法是先制作一份 checksum 故意写错的 Portfile再运行sudo port -v checksum vcs_blackboxport 命令会报错并提示本应是多少据此修正文件后反复尝试直到 checksum 通过为止。之后还需运行port lint vcs_blackbox确保没有任何 lint 错误。本地端口树操作命令在 sources.conf 中切换本地源用于测试 Portfilesudo vi /opt/local/etc/macports/sources.conf在文件靠前位置添加一行file:///var/tmp/ports免交互添加本地源若不存在则插入首行fgrep /dev/null -x file:///var/tmp/ports /opt/local/etc/macports/sources.conf || sudo sed -i -e 1s^file:///var/tmp/ports\$\n /opt/local/etc/macports/sources.conf移除本地源sudo sed -i -e \^file:///var/tmp/portsd /opt/local/etc/macports/sources.conf完整的本地验证流程sudo port uninstall vcs_blackbox sudo port clean --all vcs_blackbox rm -rf ~/.macports/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/security/vcs_blackbox/ rm -rf /var/tmp/ports mkdir -p /var/tmp/ports/security/vcs_blackbox cp Portfile /var/tmp/ports/security/vcs_blackbox cd /var/tmp/ports portindex sudo port -v checksum vcs_blackbox sudo port install vcs_blackbox这条命令链依次完成卸载旧 port → 清理缓存 → 删除系统端口树中的旧目录与本地测试树 → 建立/var/tmp/ports/security/vcs_blackbox并拷入新 Portfile → 重建端口索引portindex→ 校验 checksum → 实际安装验证。Portfile 模板解读tools/Portfile.template 是生成 Portfile 的元模板关键字段如下字段值说明PortGroupgithub 1.0使用 GitHub 端口组自动推导下载地址github.setupStackExchange blackbox VERSION v上游组织/仓库/版本号VERSION由脚本替换namevcs_blackboxport 名categoriessecurity安全类目platformsdarwin仅面向 macOSlicenseBSD许可证supported_archsnoarch纯脚本无架构依赖checksumsrmd160 RMD160 sha256 SHA256两处占位符由脚本从校验输出中回填use_configureno不运行 configurebuild{}无编译步骤destroot.destdirDESTDIR${destroot}${prefix}修正该项目 Makefile 对 DESTDIR 的错误用法destroot.targetpackages-macports安装阶段调用make packages-macports七、扩展发布相关的打包构建目标虽然 RELEASE_ENGINEERING.md 正文聚焦标签与 MacPorts但文档开头明确建议打包者跟踪production标签因此了解 Makefile 中与发布配套的构建目标对发布工程同样必要make packages-rpm调用 tools/mk_rpm_fpmdir 与文件清单 tools/mk_rpm_fpmdir.stack_blackbox.txt 生成 RPM该清单是主清单注释明确 All other packages should generate their list from itmake packages-debDEB 清单由sed从 RPM 主清单转换而来/usr/blackbox/bin/→/usr/bin/剔除 profile 脚本见 tools/mk_deb_fpmdir.stack_blackbox.txtmake packages-macportsMacPorts 清单同样由主清单转换/usr/blackbox/bin/→bin/见 tools/mk_macports.vcs_blackbox.txt并配合DESTDIR将 20 余个bin/blackbox_*命令安装到目标目录make update/make clean重新生成或清理上述派生清单文件。打包发行RPM/DEB/MacPorts时均应以tag production指向的代码为准保证分发给广大用户的版本经过了 stable 一周观察期的验证。总结BlackBox 的发布工程是一套测试 → stable → production逐级递进的严谨流程make test含 expect 驱动的 confidence 全链路测试是每轮发布的硬性门槛stable标签面向大多数用户一周无 bug 后升级为production并打上v1.YYYYMMDD日期版本号面向 macOS 的 MacPorts 分发则由 tools/macports_report_upgrade.sh 自动化完成 Portfile 版本号与 rmd160/sha256 校验值的回填并辅以手动流程兜底。维护者只需按照本文的 Step 0Step 4 顺序执行即可保持仓库、CHANGELOG 与各发行渠道的高度一致。赞分享密码学开发工具应用安全DevOps【免费下载链接】blackboxSafely store secrets in Git/Mercurial/Subversion项目地址https://gitcode.com/gh_mirrors/bl/blackbox点击查看免费下载相关推荐QGroundControl 发布与分支管理全指南语义化版本、Stable/Daily 双轨发布与 git tag 驱动的 CI 流程QGroundControl 发布与分支管理全指南语义化版本、Stable/Daily 双轨发布与 git tag 驱动的 CI 流程 导读 QGroundC无人机智能硬件PX4-Autopilot 发布流程全解析从 Alpha 到 Stable 的分支、打标签与发布治理PX4 Autopilot 发布流程全解析从 Alpha 到 Stable 的分支、打标签与发布治理 PX4 开源飞控采用一套完整的「基于分支 标签演进」嵌入式物联网机器人自动驾驶智能硬件Onivim 2 月度发布流程实战指南stable/staging 双分支管理、Signoff 测试与版本发布全解析Onivim 2 月度发布流程实战指南stable/staging 双分支管理、Signoff 测试与版本发布全解析 本指南基于 Onivim 2oni2开发工具代码编辑器桌面应用上一篇MicroWebSrv2模块开发教程从零开始创建自定义功能扩展下一篇如何用Excel2LaTeX快速生成学术论文表格5分钟上手教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考