在6月的运作报告中提到希望 openEuler 能够围绕垂直领域拓展合作的范围，本月有了重量级的进展。sig-openstack 是由联通沃云团队发起的，计划将围绕 OpenStack 和 openEuler 开展集成和优化的工作。联通沃云作为国内有影响力的云计算提供商，主动拥抱 openEuler，充分体现了双方对于开源生态的构建拥有共同的理念和目标。
除了行业 SIG 的成立，sig-wine 由个人爱好者发起，将聚焦 wine 这个工具，从而使能在 openEuler 中执行 Windows 程序。sig-desktop-apps 是华为员工希望解决自己日常使用时的痒点。最后，新增的 sig-bootstrap 是为了解决需要引入二进制来解决自举困难。这些 SIG 的成立会逐步提升 openEuler 的易用性和构建的便捷性。
从统计看，7月社区的活跃程度和6月基本相当，可以认为之前吸引的开发者已经沉淀下来。
作为多样化推广的一部分，openEuler 本月在 openEuler B站直播间[1] 上已经举办6场直播活动。不过除此之外，技术委员会建议还要关注在垂直领域的推广。
和过去几个月一样，openEuler 社区依然保持很快的迭代演进速度。从技术委员会角度，在看到优势的同时，我们把关注的重点集中在几个问题上。
- SIG 运作情况的改进
- 构建系统变化；
- 安全漏洞的修复与披露
- 组件供应链管理
SIG 运作情况的改进
上月报告中，提到需要关注不活跃的 SIG。7月，大部分 SIG 运作有了明显的变化：
- UKUI 3.0 的基础版本已经移植到 openEuler 上，并且也提供了独立的 REPO，便于用户在 openEuler 环境中安装 UKUI 3.0。整体的移植，涉及的安装和构建需要更多的依赖包，开发人员和 openEuler 团队密切配合，正在加紧开发过程中。
- ceph 的开发人员已经在 openEuler 上构建 16.0.0，这个过程中还发现了 openEuler 中的一个 bug。
- 在 sig-Kubernetes 依然不活跃的情况下，sig-Container 依然将 Kubernates 带到 openEuler 上，openEuler 的容器生态在逐步完整中。
- 其他 SIG 也都有比较快的进展。除了提交代码上库之外，在基于 openEuler 平台的开发过程中，各个 SIG 的开发者也帮助 openEuler 发现了很多问题，提出了中肯的批评。
技术委员会对所有开发者的贡献表示感谢。
构建系统的变化
我们简单回顾一下 openEuler 的配置管理和构建架构。openEuler 的基础设置构架在 Gitee 和 Open Build Service(OBS) 上，运作中遵循“净室”原则。代码和配置提交审核过程必须通过 ci bot 和 Jenkins 门禁，构建过程则由 OBS 全封闭执行。
可见 openEuler 的运作极度依赖自动化系统，这个系统的成熟和稳定是 openEuler 演进的基础。在过去一段时间，我们观察到这样一些问题：
- Jenkins 门禁输出对开发者不友好，有用信息经常淹没在海量输出中；
- 代码，配置管理，构建三个环境之间的一致性不能保证。提交到 src-openeuler 中的代码，并没有自动出现在配置管理用的 src-openeuler/obs_meta 中，这造成提交的代码不进入 OBS；
- 配置管理自身不一致，体现在 obs_meta 中，有些软件重复出现在 Mainline，bringInRely 和 Factory 中；配置管理变更也缺少过程记录；
- 下层软件更新时，如果有 API 变化需要上层软件重新构建，则依赖开发者干预，否则无法更新问题；
- 本地构建、门禁构建和 OBS 构建都可能不一致，开发人员要全程关注不同环境的差异。
我们在7月初启动了一次对自动化系统改进的攻关，预计在7月底前能看到这个系统的很多改进。更重要的是，本月已经在技术委员会例会上讨论，将设置一个新的 SIG，把 openEuler 的配置管理和构建架构作为一个开源项目来运作。希望通过开源开放，让更多开发者参与帮助提高。此外，技术委员会也建议通过直播，公众号，博客等途径宣传 openEuler 的实践；便于新进入社区的开发人员更快熟悉整个流程。
安全漏洞处理与披露
自从5月13日 openEuler 社区首次发布安全公告以来，技术委员会一直关注社区安全漏洞的修复和披露实践。技术委员会经过分析发现，CVE 的漏洞修复和披露时间上不连续，呈现波峰式的修复开发披露漏。
我们请安全委员会整理了当前所有 CVE 相关 issue 的列表。对所有这些 issue 当前处理情况作了分析，能看到 openEuler 这方面能力和流程上存在需要改进的地方。
| 对应代码仓 | 高级别 CVE 数量 | 实际处理情况 |
|---|---|---|
| src-openEuler/dovecot | 1 | 7天内有回复，尚未修复 |
| src-openEuler/firefox | 21 | 7天内有回复，尚未修复 |
| src-openEuler/gcc | 1 | 开发人员认为 issue 中没有指定关联分支，因此没有分析 LTS 版本，直接关闭。实际上是 LTS 基线中已经包含了相应的修复。这是分析错误的案例。 |
| src-openEuler/gnutls | 1 | 7天内未回复，未修复 |
| src-openEuler/gstreamer1 | 1 | 这个 issue 提到 gstreamer1，分析者认为 patch 对应的文件在版本中不存在，所以不涉及。但实际上这个问题存在于 gstreamer1-plugins-base。需要重新提交分析。 |
| src-openEuler/icu | 3 | 分析结论不清晰。认为已经修复，但是没有找到具体修复的 PR。 |
| src-openEuler/redis | 1 | 7天内回复，9天 PR 合入。但 issue 未关闭。 |
| src-openEuler/libpng12 | 1 | 只在 mainline 上处理，没有兼顾 LTS。团队反馈从大约3周前开始同步处理。 https://gitee.com/src-openeuler/libpng12/issues/I1KXR3 |
| src-openEuler/libjpeg-turbo | 1 | 7天内未回复，未修复 |
| src-openEuler/net-snmp | 1 | 7天内未回复，未修复 |
| src-openEuler/open-iscsi | 1 | 漏洞是关于 rstlib 的，和 open-iscsi 无关 |
| src-openEuler/openjpeg2 | 1 | 7天内未回复，未修复 |
| src-openEuler/openssh | 1 | 7天内未回复，未修复 |
| src-openEuler/osc | 1 | 7天内有回复，尚未修复 |
| src-openEuler/pcre | 1 | 7天内未回复，未修复 |
| src-openEuler/perl | 3 | 7天内未回复，未修复 |
| src-openEuler/python-pandas | 1 | 7天内有回复，尚未修复 |
| src-openEuler/python-pillow | 1 | 已经完成分析，待确认（谁确认？） |
| src-openEuler/python-rsa | 1 | 7天内未回复，未修复 |
| src-openEuler/python-rtslib | 1 | 未分析 |
| src-openEuler/python-scikit-learn | 1 | 未分析 |
| src-openEuler/qemu | 1 | 未分析 |
| src-openEuler/qt5 | 1 | 未分析 |
| src-openEuler/ruby | 1 | 6月23日的 PR11 提交了补丁文件到 LTS 分支中，但是没有相应修改 spec 文件；7月9日有一个补充 PR，在 spec 中引用了相应 patch，但是，这个 PR14 到现在也没有合入。 |
| src-openEuler/slf4j | 1 | 未分析 |
| src-openEuler/traceroute | 1 | 7天内未回复，未修复 |
| src-openEuler/unbound | 2 | 7天内未回复，未修复 |
| src-openEuler/wireshark | 3 | 7天内有回复，尚未修复 |
这里体现的问题是多方面的。
首先，安全委员会确认 CVE issue 的提交的时间是不均匀的。在6月到7月间，仅有 gstreamer 和 icu 等寥寥几个问题。而7月中旬之后则涌现了大批量需要分析的问题。我们还缺少一个有效的长期机制来自动化的识别和提交 CVE issue。这部分安全委员会在积极跟进。希望能尽快看到进展。同时，我们对 CVE 的修复也是阶段性的。
其次，openEuler 当前设置的漏洞响应 SLA，7分以上14天以内解决，9分以上7天内解决。明显从这次的统计中看到，我们有压线解决问题的习惯。而很多分析工作没有完成前，我们甚至不确定漏洞的级别，这种情况下，压线是很冒险，尤其像 Firefox 这样大量的 CVE。
再次，问题大多是具体软件的开发人员负责的。技术委员会认为，CVE issue 的关闭应该只授权到 SIG 的 maintainer。另外，开发者往往集中一点，不及其余，这样和我们当前的漏洞跟进机制配合上会出现问题。比如 gstreamer 的漏洞分析，虽然确实是 issue 提交错了，但正确的做法应该是转发给相应的组件。我们认为 SIG 的 maintainer 应该有相应的视野和理解，不能因为 issue 提交的仓错误就一关了之。
最后，CVE issue 的跟踪应该通过构建发布来闭环，像 ruby 这样，提交了 patch，但是没有跟踪构建，晾了两周没有闭环，也是非常错误的。
在分析过程中，我访谈了相关的开发人员：
- 有开发者认为 issue 应该主动关联分支，不然分析的责任不在他。建议开发团队也要对齐目标。如果 CVE issue 只提交到仓，那开发者就应该分析这个 CVE 对所有分支的影响。
- SIG 的 maintainer 对 issue 在流程上没有管理能力。有 maintainer 反映，issue 都还没看过就关掉了。
- 漏洞分析的时间被版本开发过程中选型和升级工作挤占。这个也是现实情况，但是依然建议把分析动作提前。尤其是对于 master 分支，如果可以通过升级解决的问题，似乎没有理由去做回合补丁的动作。
虽然社区 CVE 等处理流程还不仅完善，但是我们看到，截至当前，超出 SLA 承诺的仅有两个组件，一个是 gstreamer1-plugins-base，如前所述，是 issue 提交错了仓，而开发者错误的简单关闭。另一个是 icu，开发者的分析和实际处理结果没有形成对应。此外的组件尚在 SLA 接受的范围之内，技术委员会下月会继续跟进。
当然，具体到一些软件包，我们也有很多开发人员是非常负责的。比如 GCC 的 maintainer，正是因为我们的代码基线了从一开始就修复了这些漏洞，才没有让错误的分析导致真正的问题。
应该说，单纯从 SLA 的满足程度上来说，安全委员会的运作还是值得肯定的，但是其中也确实蕴含了一些错误和值得改进的地方。openEuler 社区将安全放在了极为重要的地位，安全委员会也是平行于技术委员会单独运作，其目的也是希望安全能够作为高优先级的响应来处理。我们希望社区共同督促和协作，进一步提升安全能力的提升和流程的完善。
组件的供应链管理
openEuler 当前由 5000 多个开源软件组成，技术委员会关注 openEuler 版本中集成的这些组件的完整性是否得到保护，License 是否合规，以及长期是否可维护。
其中长期可维护，集中体现了开发者和使用者之间的矛盾。
举例来说，openEuler 中集成了 procmail，这款软件虽然有广泛的使用，但是很早就不维护了。作者本人在 openbsd 社区中曾明确表示，希望删除 procmail[2]，但是我们看到大部分开源发行版依然坚持在集成和使用 procmail。从使用者角度来看，惯性依赖是难于改变的，即便是已经没有 upstream 的维护者，即便这款软件在 fuzz 测试过程中不断发现新的问题。
技术委员会希望对 openEuler 中所有软件进行梳理，识别所有的风险。这项工作的开展依赖社区开发者的配合。
过去一个月中，openEuler 社区基本上完成了对引入开源软件的上游梳理，绝大部分手动引入的软件包都会有一个相应的 YAML 数据文件来描述这款软件的上游如何追溯，在此感谢所有开发人员的参与。
基于比较准确的上游信息，我们开始启动对 openEuler 所集成开源组件的可维护性分析。
@licihua[3] 带领团队对 openEuler 中的940款软件做了抽样分析，其中存在可维护性风险的软件占到146款。这些存在可维护性风险的软件可分为两大类：
一类是代码缺少 upstream 的维护者：
- 原开发者已经放弃这款软件，同时社区出现了更好的替代软件。比如可以替代 procmail 的 fdm, dovecot-pigeonhole 等等。
- 软件过于简单，甚至就没有作为一个开源项目维护，有些只是开发者邮件贴出来的完整功能代码，比如 chrpath。但这些代码往往被广泛依赖。
- 软件有断代演进，比如 gtk2->gtk3，python2->python3。但是依赖上一代的工具还没有切换。
- 软件本身从开源变成了闭源，比如 libdb。但是依赖这个软件的工具还没有切换。
- 软件所提供的功能逐步边缘化，相对稳定的同时，开发人员也在流失。比如 cdrkit 和 telnet。
另一类是本身只是数据：
- 配合硬件提供的 firmware，有些硬件发布已经很久了，firmware 也有很多年没有更新。
- 字体墙纸等系统需要的数据。
技术委员会建议 openEuler 演进中采取有针对性的策略：
- 对于原开发者已经放弃，社区已经有明确替代软件的，openEuler 应该引入替代软件，并且将原软件移入 sig-recycle 管理。
- 对于软件过于简单，或者一直就缺少正式开源项目的，openEuler 应该考虑主动成为这些软件的上游社区，将 openEuler 本身的测试能力覆盖到这些软件。
- 对于已经断代演进，或者已经闭源的，openEuler 需要识别所依赖的软件，和上游社区一起加快切换过程。
- 对于边缘化的功能，openEuler 可以考虑移入 sig-recycle。这些策略执行是有相当难度的。比如依赖 libdb 的软件中，有 rpm, sendmail, subversion, postfix, python 等非常基础的软件。移除这个依赖，需要和上游的长期紧密配合。但从另一个角度看，挑战这些社区存在多年的问题，势在必行，也是 openEuler 社区对开发者和使用者负责的体现。此外，技术委员会例会中也讨论到 Java 语言生态中 Maven 如何引入和管理。预计在8月会有进展。
总结和展望
软件行业这些年的快速发展，我们看到成功者基本上都体现了一个共性：能够聚焦最重要的代码开发。在这个开源软件积累极大丰富的时代，帮助开发者快速找到并复用已有的代码或者服务，并且能把业务核心代码解耦出来独立演进，这是平台在开发者生态上提供的竞争力。openEuler 可以成为这样一个平台。
参考
[1]
openEuler B站直播间: https://space.bilibili.com/527064077
[2]
procmail: https://marc.info/?l=openbsd-ports&m=141634350915839&w=2
[3]
@licihua: https://gitee.com/licihu
更多阅读openEuler 内核系列 | Linux内核发展史 02openEuler 内核系列 | Linux 内核发展史01
