Хроники Chromium #15: Ограничение видимости цели

Эпизод 15: Джо Мейсон в Монреале, PQ (ноябрь 2020 г.)
Предыдущие серии

Chrome — это большой проект со множеством подсистем. Часто можно найти код, написанный для одного компонента, который может быть полезен в другом месте, но может иметь скрытые ограничения. В целях безопасности ограничьте внешний доступ к опасным функциям . Например, пользовательская функция, настроенная для конкретных потребностей в производительности:

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

Существует несколько способов ограничить доступ. Правила видимости GN не позволяют коду вне вашего компонента зависеть от цели . По умолчанию цели видны всем, но вы можете это изменить:

# 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" ]
}

Объявления видимости проверяются с помощью gn check , который запускается как часть каждой сборки GN.

Другой механизм — DEPS include_rules , который ограничивает доступ к файлам заголовков . Каждый каталог наследует include_rules от своего родителя и может изменять эти правила в своем собственном файле DEPS . Все файлы заголовков, включенные из внешних каталогов, должны быть разрешены параметром 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",
]

Чтобы гарантировать соответствие этих зависимостей, изменения, добавляющие каталог в include_rules , должны быть одобрены OWNERS этого каталога . Для ограничения каталога с помощью include_rules не требуется одобрение! Вы можете гарантировать, что каждый, кто меняет ваш компонент, запомнит не использовать определенные заголовки, добавив include_rule запрещающий их.

include_rules проверяются presubmit , поэтому вы не увидите никаких ошибок, пока не попытаетесь загрузить изменение. Чтобы протестировать include_rules без загрузки, запустите buildtools/checkdeps/checkdeps.py <directory> .

Ресурсы