Chromium Chronicle #15: como restringir a visibilidade do público-alvo

Episódio 15:por Joe Mason em Montreal, PQ (novembro de 2020)
Episódios anteriores

O Chrome é um grande projeto com muitos subsistemas. É comum encontrar códigos escrita para um componente que seria útil em outro lugar, mas que poderia ter escondido restrições. Por motivos de segurança, limite o acesso externo a recursos perigosos. Por exemplo, uma função personalizada ajustada para necessidades específicas de desempenho:

// Blazing fast for 2-char strings, O(n^3) otherwise.
std::string ConcatShortStringsFast(const std::string& a, const std::string& b);

Há várias maneiras de restringir o acesso. Código de parada das regras de visibilidade de GN fora do seu componente para que ele não dependa de um destino. Por padrão, as metas são visível para todos, mas é possível modificar isso:

# In components/restricted_component/BUILD.gn
visibility = [
  # Applies to all targets in this file.
  # Only the given targets can depend on them.
  "//components/restricted_component:*",
  "//components/authorized_other_component:a_single_target",
]
source_set("internal") {
  # This dangerous target should be locked down even more.
  visibility = [ "//components/restricted_component:privileged_target" ]
}

As declarações de visibilidade são validadas com gn check, que é executado como parte de cada versão de GN.

Outro mecanismo é o DEPS include_rules, que limita o acesso aos arquivos de cabeçalho. Cada diretório herda include_rules do pai e pode modificar esses no próprio arquivo DEPS. Todos os arquivos de cabeçalho incluídos de fora os diretórios precisam ter permissão do include_rules.

# In //components/authorized_other_component/DEPS
include_rules = [
  # Common directories like //base are inherited from
  # //components/DEPS or //DEPS. Also allow includes from
  # restricted_component, but not restricted_component/internal.
  "+components/restricted_component",
  "-components/restricted_component/internal",
  # But do allow a single header from internal, for testing.
  "+components/restricted_component/internal/test_support.h",
]

Para garantir que essas dependências sejam adequadas, as mudanças que adicionam um diretório para include_rules precisam ser aprovados pelos OWNERS do diretório. Não aprovação é necessária para restringir um diretório usando include_rules. Você pode garanta que todos que estão mudando os componentes se lembrem de não usar certos cabeçalhos adicionando um include_rule a proibindo-os.

include_rules são verificadas pelo pré-envio. Por isso, não haverá erros até tentar fazer o upload de uma alteração. Para testar include_rules sem fazendo upload, execute buildtools/checkdeps/checkdeps.py <directory>.

Recursos