On Fri, Aug 11, 2017 at 5:20 PM, Matthew Hardeman via dev-security-policy < [email protected]> wrote:
> If one integrates a project like certlint/cablint into the cert issuance > pipeline, one suddenly takes on supplemental responsibility for certlint's > bugs or changes. > That's the case for any source code Let's Encrypt uses that was written by someone else. Like all software, there are third party dependencies in there somewhere, whether closed source or open source. (In Let's Encrypt's case, they are generally open source, which helps the team's ability to review it.) > The pace of change in certlint, just glancing at the git commits, is not > slow. New tests are added. Tests are revised. > That's a good thing. Even still... anywhere along the way, Mr. Bowen could go totally evil (I > seriously doubt this would happen) and decide that certlint should flag "E: > This CA is run by nasty people" anytime Issuer CN contains 'Maligned CA X1'. > You seem to be assuming that Let's Encrypt would just automatically pull down new code into its critical issuance code path without review. I would definitely not assume that. That code will be reviewed before deployment. > It seems reasonable to me that an implementing CA might want to add some > buffer between the initial commit/merge and their opportunity to perform > some manual review of the changes prior to incorporating into their > issuance environment. > Yes, of course. This is a lot of time to spend discussing the basics of project dependency management. There are definitely tradeoffs for Let's Encrypt to evaluate when considering something like integrating certlint into the issuance pipeline -- performance of the certlint tool, potential memory leaks, as well as the operations necessary to support a hosted service that keeps certlint in memory for rapid processing. If certlint proves to be too slow or take too much memory, then an integration push could either cause those issues to be fixed, or cause a new tool to be written that performs the same checks certlint does (now that the work has been done to map and isolate the BRs into specific technical checks). We should be understanding if engineering tradeoffs preclude immediate integration, but we should not dismiss the idea of relying on "someone else's code" in the issuance pipeline. I'm sure that's already the case for every CA in operation today. -- Eric _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
