最新

证书透明度系统保护您免受恶意HTTPS证书的侵害。当CT日志具有可预测的私钥时，整个网络公钥基础设施（PKI）安全模型就会崩溃。这会影响到日志曾经签署的每一个证书——无论是过去、现在还是未来。 我报告了Google Chrome信任的证书透明度基础设施中的安全漏洞，但他们将其视为“非漏洞”，在未征得我同意的情况下公开了我的私人报告，然后在数小时后默默实施了我的修复措施。 发现： 在基准测试时，我使用了命令 `echo " " > seed.bin`（32个空格）。Sunlight接受了这个输入，并为CT日志生成了有效但可预测的私钥。没有任何警告，也没有错误。 为什么这很重要： 1. 操作员正确执行：`cat /dev/urandom > seed.bin` 2. 文件系统损坏使种子文件填充为零或空格（在生产环境中会发生） 3. Sunlight默默地从损坏的种子生成可预测的密钥 4. CT日志“正常”运行——有效的签名，没有错误 5. 任何知道损坏情况的人都可以重建私钥 没有校验和，即使是完美的操作员也会被默默地妥协。这是保护HTTPS证书的PKI基础设施。 这并不是假设——文件系统损坏在生产系统中是常见的。电力故障、内核崩溃和存储故障经常导致部分写入和空字节。 谷歌的回应： - “不是漏洞”：https://groups.google.com/a/chromium.org/g/ct-policy/c/qboz9s8b9j8/m/B6JXa2q1BAAJ - 未经同意发布了我的私人安全报告 - 数小时后实施了我的确切修复 - https://github.com/FiloSottile/sunlight/commit/f62f9084016c4c377d3855471720d7d0cdea3663 - https://github.com/FiloSottile/sunlight/commit/32cc3ea2524e89f93febb967683c6467753f484d - 因指出矛盾而禁止我发言：https://groups.google.com/g/certificate-transparency/c/u8SsXgSFbz4/m/14ePyeCrBAAJ 额外的漏洞： 他们使用用户代理字符串进行身份验证。任何人都可以伪造这些头信息，以绕过速率限制并压垮服务： - https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L176 - https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L148 这是今天被Google Chrome信任的生产代码（https://www.gstatic.com/ct/log_list/v3/all_logs_list.json），请查看“sunlight”日志。 导致我被禁止的确切邮件在这里：https://groups.google.com/g/certificate-transparency/c/u8SsXgSFbz4/m/14ePyeCrBAAJ - 请自行判断这是否违反了任何合理的行为准则。 是否还有其他人因负责任的安全披露而遭到报复？我们如何修复一个在报告漏洞时会被禁止，而问题却被悄悄修复的系统？

今天有一个供应商请求我们Kubernetes集群的日志。我们没有运行任何日志聚合工具（没有fluentd/fluentbit），除了DataDog，所以我需要从三个命名空间中的30多个部署中获取日志。 为了避免手动为每个部署运行kubectl logs，我构建了这个Python命令行工具，它可以一次性收集一个命名空间中所有部署的日志。它按日期和命名空间进行组织，支持并行收集，并处理常见的K8s边缘情况（每个部署多个Pod、失败的Pod等）。 使用非常简单：`klogger collect -n production` 虽然没有什么突破性的创新，但它为我节省了数小时的手动工作，并可能帮助处于类似情况的其他人。它基本上是一个kubectl的包装工具，专注于一件事情——在需要时进行批量日志收集。 GitHub: [https://github.com/christensen143/klogger](https://github.com/christensen143/klogger)

我开发了 RingtoneSmartKit —— 一个开源的 Kotlin 库，用于以简单可靠的方式管理 Android 铃声。 它支持： - 设置系统铃声：闹钟、通知和来电铃声 - 为联系人分配自定义铃声 - 直接处理来自资产或内容 URI 的音频 - 无需 Context 或 Activity，使得在应用中的集成更为简便 我们的目标是提供一个干净、可重用的铃声处理解决方案，而不依赖于复杂的平台代码。 欢迎反馈、测试和建议！