TLC Meeting - June 11, 2026
Meetings are happening on the #selenium-tlc channel on Selenium Slack.
To add items to the agenda for the next meeting, please see our public Rolling Agenda
The next meeting will be Thursday, June 18 at 0700 Pacific / 1000 Eastern / 1500 UK / 1930 India.
Participation
Agenda
- Security CVE assessment for Selenium Manager archive extraction
- ADR proposal and process
Meeting Summary
The meeting covered whether the Selenium Manager archive extraction hardening in selenium#17668 should be treated as a CVE, then focused on the proposed ADR process for cross-binding design decisions. The group treated the archive issue as code hardening rather than a security advisory, and agreed in principle to use ADRs as the durable GitHub record for design decisions.
Decisions
- The archive extraction issue in selenium#17668 should be hardened, but the recorded outcome was that it does not need a CVE or security advisory.
- Participants agreed in principle to proceed with the ADR process introduced in selenium#17665, with the expectation that the process can be adjusted as the project uses it.
- ADR discussions that affect a decision should leave a GitHub record. Meeting minutes can summarize the discussion, but substantive objections, approvals, and requested changes should also be reflected in the relevant pull request.
Discussion Notes
Security CVE Assessment
AutomatedTester explained that the reported archive extraction issue depends on assumptions such as receiving a malicious archive from a trusted browser vendor or using an untrusted mirror. The group agreed that the code should still be hardened, but treated those scenarios as outside the scope for a Selenium CVE or broad security advisory. titusfortner explicitly supported AutomatedTester’s assessment, and no objection was recorded. AutomatedTester said he would reply to the reporter with that assessment.
ADR Process
Participants discussed the proposed design decision record process as a way to avoid cross-binding drift, especially for BiDi-related APIs. titusfortner said that agreeing only on syntax is not enough, because language bindings need to agree on behavior and tradeoffs as well. AutomatedTester emphasized iterating on good decisions instead of blocking on a perfect process.
The group discussed how ADRs should track implementation work. The ADR itself can remain the canonical decision record, while related issues and pull requests can be linked so contributors can find per-language implementation tasks. diemol noted that ADRs should stay focused on the decision and reasoning, with links to implementation details where needed.
titusfortner proposed publishing a weekly TLC agenda that lists outstanding ADRs and decisions that need attention. AutomatedTester suggested that ADRs not discussed in one TLC meeting should roll to the next meeting, and that lack of continued objection may allow the Selenium Project Lead to move them forward. titusfortner and diemol preferred not to over-specify every edge case, leaving the Selenium Project Lead to judge whether there has been enough discussion.
Participants also discussed what ADRs need to contain. AutomatedTester asked for concrete examples of expected API shape, including examples of approaches considered good or bad, so an implementer can act without waiting for additional clarification. titusfortner agreed that ADRs should include enough semantic detail to execute, while avoiding unnecessary low-level implementation requirements.
BiDi API Shape
titusfortner used the BiDi discussion as an example of why ADRs are needed, describing how current implementations in different bindings have started to diverge, including in how low-level generated code is exposed and how internal APIs are marked. The group discussed that high-level APIs should be user-facing and consistent across browsers, while BiDi implementation details should not become the public API surface.
AutomatedTester raised an expect-style API concept as an example of the type of API shape that should be written down before debate. titusfortner raised concern that assertion-like APIs may belong in test frameworks rather than Selenium itself. diemol asked that the group avoid settling the design without an ADR.
A geolocation example clarified the same pattern. Existing low-level approaches can already set geolocation in some cases, but the goal under discussion was a cohesive, cross-browser, user-facing Selenium API layered on top of BiDi.
Action Items
- AutomatedTester will reply to the reporter that the archive extraction issue should be hardened but does not need a CVE or security advisory.
- titusfortner will continue refining the ADR material with concrete examples and specific semantic details from the discussion.
- AutomatedTester will write ADRs for API topics that need more detailed review before the group debates them further, including the expect-style API and geolocation API.
