Storage Buckets: validate bucket names at the Mojo boundary

Storage Bucket 이름 검증을 Mojo IPC 경계에서도 수행하도록 시도한 변경입니다. 구현 자체뿐 아니라 변경의 필요성, 리뷰 비용, 향후 예정된 Mojo argument-validation 구조를 두고 리뷰 과정에서 의견 차이가 있었으며, 최종적으로 현재 시점의 이점 대비 리뷰·유지보수 비용을 고려해 중단했습니다.

문제 설명

웹에서 생성되는 Storage Bucket 이름에는 길이와 허용 문자에 대한 제약이 있지만, 해당 invariant는 renderer 측 검증에 주로 의존하고 있었습니다. 잘못된 값이 Mojo IPC를 통해 browser process로 전달되는 경우를 경계에서 검증하는 방법을 검토했습니다.

초기 패치는 CustomBucketName Mojo 타입의 deserialization 단계에서 bucket name을 검증하는 방향으로 작성했습니다.

리뷰 과정에서는 다음 쟁점이 제기되었습니다.

renderer와 Mojo 계층에 서로 다른 bucket-name validator가 존재하면 두 정의가 나중에 달라질 수 있다는 문제
validation 추가에 따른 binary-size 비용 대비 실제 benefit
향후 도입 예정인 일반화된 Mojo argument-validation mechanism을 기다리는 것이 더 나은지 여부

해결 내용

초기 리뷰에서 중복 validator 문제가 지적된 뒤, 기존 bucket-name validator를 Blink common 영역으로 이동하고 다음 경로가 같은 검증 구현을 공유하도록 변경했습니다.

renderer-side bucket name validation
Mojo CustomBucketName deserialization
Clear-Site-Data bucket-name 처리

이를 통해 web-facing bucket name의 정의가 여러 위치에서 따로 유지되는 문제를 피하려고 했습니다.

이후 리뷰에서는 "이 변경이 실제로 어떤 현재 문제를 해결하거나 어떤 미래 문제를 예방하는가"라는 보다 근본적인 benefit 질문이 제기되었습니다. 리뷰 과정에서는 다음 원칙으로 대응했습니다.

binary-size regression이나 runtime cost가 판단 근거라면 가능한 경우 실제 측정 결과를 기준으로 논의하도록 요청했습니다.
오래된 이슈라는 사실만으로 의도적으로 수정하지 않았던 문제라고 단정하기보다, 원래 이슈가 어떤 문제를 포착하려 했는지와 기존 설계 배경을 함께 확인하려고 했습니다.
기술적 리뷰와 별개의 AI 사용·작업 방식 관련 우려가 제기된 경우에는 코드의 correctness 논의와 분리해 적절한 별도 채널에서 다루는 편이 낫다고 판단했습니다.
특정 리뷰어와의 의견 차이보다 관련 code owner 전체의 기술적 판단을 기준으로 변경을 계속할지 결정하려고 했습니다.

Ari Chivukula는 향후 custom struct traits 없이 Mojo argument를 검증할 수 있는 새로운 mechanism을 준비 중이며, 해당 방식이 준비된 뒤 이 코드를 다시 정리할 수도 있다는 배경을 공유했습니다.

최종적으로 현재 얻을 수 있는 직접적인 이점에 비해 리뷰 및 유지보수 비용이 커졌고, 향후 더 적절한 공통 validation mechanism이 예정되어 있다는 점을 고려해 이 CL을 abandon했습니다. 필요성이 더 명확해지거나 새 validation mechanism을 사용할 수 있게 되면 다시 검토할 수 있습니다.

테스트 방법

bucket 관련 unit test를 로컬에서 확인했습니다.
bucket-name 관련 WPT를 확인했습니다.
CQ dry run을 반복 실행했고 최종 패치셋은 CQ를 통과했습니다.
중간에 Fuchsia binary-size trybot이 49,152 byte 증가를 보고했지만 바로 다음 실행에서는 동일 실패가 재현되지 않았습니다.

따라서 해당 단일 trybot 결과만으로 현재 패치의 지속적인 binary-size regression이 확인되었다고 보지는 않았습니다.

후속 구현과 기여의 연결 (2026-10-08 확인)

이 CL을 abandon한 이후, IPC 보안 리뷰어였던 Ari Chivukula가 원본 CL 8506058의 리뷰 스레드에 "Mocked this up in https://crrev.com/c/8527210"이라고 후속 구현을 알렸습니다. Ari의 CL 8527210 ([Storage Buckets] Force validation of custom bucket names in IPC)의 commit message에도 "This is building on work in: https://crrev.com/c/8506058"이라고 원본 CL을 명시적으로 참조했습니다.

두 CL 모두 잘못된 custom Storage Bucket 이름을 Mojo IPC 경계에서 검증하고, 여러 경로의 bucket-name validator를 통합한다는 목표를 공유합니다. 다만 구현 접근은 다릅니다.

원본 CL은 custom StructTraits::Read()에서 직접 이름을 검증했습니다.
후속 CL은 Mojo CL 8527867의 새로운 untrustworthy 인자 검증 기능을 활용하여 IPC 역직렬화에서 검증하는 방향으로 작성되었습니다.
Ari는 기반 Mojo 변경에 대한 관련 OWNER의 의견에 따라 후속 CL이 실제로 커밋되기까지 시간이 걸릴 수 있다고 설명했습니다.

이는 원본 CL이 merge되었다는 뜻이 아니며, 원본의 최종 상태는 abandoned로 유지합니다. 다만 해결하려던 문제와 검증 경로 통합 작업이 후속 구현의 기반으로 명시적으로 인용된 사실을 기록합니다. 새 CL의 최종 landing 여부는 별도로 확인해야 합니다.

배운 점

이번 변경에서는 코드 작성보다 리뷰 과정에서 변경의 존재 이유를 설명하고 의견 차이를 관리하는 경험이 더 컸습니다.

구현이 기술적으로 가능하다는 사실만으로 landing 가치가 자동으로 생기지는 않으며, reviewer가 요구하는 benefit을 현재 문제와 미래 risk의 관점에서 구체적으로 설명해야 합니다.
반대로 변경 비용이나 regression을 이유로 반대할 때도 가능한 경우 실제 측정 결과와 기존 설계 근거를 기준으로 논의를 좁히는 것이 생산적이었습니다.
오래된 이슈라는 사실만으로 수정해야 한다거나 수정하지 않아야 한다는 결론을 내릴 수 없으며, 이슈가 처음 등록된 이유와 현재 코드의 상태를 함께 확인해야 합니다.
기술적 disagreement와 개인의 작업 방식·정책 준수에 대한 우려는 가능하면 서로 다른 채널에서 다루는 편이 코드 리뷰를 기술적 논점에 집중시키는 데 도움이 됩니다.
모든 CL을 끝까지 landing하는 것이 목표일 필요는 없습니다. 현재 benefit, 리뷰 비용, 유지보수 비용과 향후 플랫폼 방향을 함께 고려해 중단하는 것도 오픈소스 기여 과정의 하나입니다.
원본 CL을 abandon하더라도 해결하려던 문제와 기술적 접근이 후속 구현에서 인용될 수 있습니다. 이때 원본 CL의 상태와 후속 기여의 관계를 구분해 정확히 기록해야 합니다.