文章揭露Ruby Central对RubyGems安全事件的不实指控。作者作为RubyGems.org十年运维者，强调自己的操作是出于保护服务的谨慎行为，且官方声明也确认其未造成数据泄露。事件源于Ruby Central混乱的管理行为，包括反复撤销团队权限等操作失误。

《关于RubyGems"安全事件"的事实澄清》

2025年10月9日，Ruby Central发布了一份存在诸多夸大和误导性陈述的《事件响应时间表》。作为RubyGems.org的前首席运维工程师（任职超十年），我需要澄清以下几点重要事实：

1. 事件背景

• Ruby Central在未提前沟通的情况下，突然撤销了包括全职开发人员在内的整个团队在GitHub的权限
• 权限在六天后恢复，但次日再次被撤销
• 技术负责人Marty Haught在邮件中承认操作失误，但后续沟通混乱矛盾

2. 我的应对措施

• 作为值班负责人，出于对账户可能被黑的担忧，我采取了保护性措施：
  • 锁定AWS账户但未更改邮箱所有权
  • 确保所有账户仍归属rubycentral.org团队邮箱
• 发现Ruby Central两周未撤销我的AWS root权限后，主动通过邮件披露此事
• 确认未下载/保留任何生产数据（包括日志和PII）

3. Ruby Central的管理疏失

• 未及时轮换共享凭证：
  • 混淆了"Ruby Central"与"RubyGems"两个1Password账户
  • 截至发文日仍未撤销我在关键系统的访问权限
• 对安全漏洞披露反应迟缓（3天后才回复）
• 在未沟通情况下，其律师指控我"黑客攻击AWS账户"

4. 争议焦点

• Ruby Central声明中称"没有证据表明Arko先生复制或保留了数据"
• 但同时又暗示我可能获取PII（个人身份信息），这与事实完全不符
• 其所谓"安全审计"存在明显漏洞，主要问题都是经我报告后才被发现

（本文写作由Spinel技术合作社赞助支持）

总结评论内容：

1. 对新管理团队能力的质疑

   • 评论2指出接管方未能兑现"提供可信管理"的承诺，认为双方都存在严重问题："Some are worse than others, but this is just a mess from top to bottom"
   • 评论4直接批评Ruby Central能力不足："Ruby central looks so incompetent it’s not even funny"

2. 密码重置事件的争议

   • 评论3质疑Arko延迟通知的行为："Why would Arko not immediately notify RC...According to RC’s timeline, the password reset happened on September 19, but Arko did not disclose until September 30"
   • 评论5指出沟通不透明是核心问题："There's a huge gap between how the two posts are framing the clarity of the communications"

3. 社区政治化的解读

   • 评论7认为事件本质是政治斗争："this incident may have more to do with politics"，并指出"Arko appeared to be a political activist"
   • 该观点引用DHH主张开源应去政治化："open source software should be a-political"作为佐证

4. 对社区分裂的担忧

   • 评论6表达旁观者的痛心："seeing it torn apart like this is tragic"
   • 评论7提到历史背景："For the past 10 years the Ruby community had been co-opted by political activists"

关键分歧点在于：
- 安全事件本身的性质（真实威胁vs政治借口）
- 各方沟通透明度（11天的密码重置通知延迟）
- 管理团队的执行能力（Ruby Central被多次质疑）

（注：所有评论评分均为None，故未体现认可度差异）