Skip to content

[WIP] Allow using test logs from all_log_list.json for SCTs, in non-prod environments #8157

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

mcpherrinm
Copy link
Contributor

@mcpherrinm mcpherrinm commented May 4, 2025

This was a quick idea, not complete. Just opening for early feedback and CI run right now.

Chrome's all_logs_list has test logs marked as such. It would be good to restrict them to non-production environments to prevent configuration mistakes. Those logs don't have a status ("Qualified"/"Usable", etc), so that shouldn't be checked.

It's only handling Issuance right now, and may not be quite the right configuration scheme.

I'm also considering that the entire subset logic might not be the right thing to do - Should this just validate that the list of logs are configured properly, and return an error if they aren't? If at startup/config validation time, that would probably be more robust to configuration mistakes without silent unexpected behaviour.

@mcpherrinm mcpherrinm changed the title WIP - draft PR for CI [WIP] Allow using test logs from all_log_list.json for SCTs, in non-prod environments May 5, 2025
@aarongable
Copy link
Contributor

I think I'd prefer a boolean "SubmitToTestLogs: true". And then only care about the value of that boolean and the status of the log when constructing the list of SCTLogs -- the sets of InfoLogs and FinalLogs can submit to whatever logs we list, regardless of state and test status.

@mcpherrinm
Copy link
Contributor Author

I agree a "Submit to test logs" boolean is probably better. One thing about Google's log list schema is that they don't explicitly enumerate the set of log types, and recently added one ("monitoring_only") that we might want to submit to, so I wasn't eager to either accept all types or hardcode the current two

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants