Épisode 15:de Joe Mason à Montréal, Québec (novembre 2020)
Épisodes précédents
Chrome est un projet de grande envergure avec de nombreux sous-systèmes. Il est fréquent de trouver du code écrit pour un composant qui serait utile ailleurs, mais qui aurait pu cacher de restrictions. Pour des raisons de sécurité, limitez l'accès externe aux fonctionnalités dangereuses. Par exemple, une fonction personnalisée adaptée à des besoins spécifiques en termes de performances:
// Blazing fast for 2-char strings, O(n^3) otherwise.
std::string ConcatShortStringsFast(const std::string& a, const std::string& b);
Il existe plusieurs façons de restreindre l'accès. Les règles de visibilité GN arrêtent le code en dehors de votre composant de dépendre d'une cible. Par défaut, les cibles sont visible par tous, mais vous pouvez modifier ceci:
# 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" ]
}
Les déclarations de visibilité sont validées avec gn check
, qui s'exécute dans le cadre
de chaque build GN.
Un autre mécanisme est DEPS include_rules
, qui limite l'accès aux fichiers d'en-tête.
Chaque répertoire hérite du paramètre include_rules
de son parent et peut modifier ces
dans son propre fichier DEPS
. Tous les fichiers d'en-tête inclus depuis l'extérieur
doivent être autorisés par 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",
]
Pour vous assurer que ces dépendances sont appropriées, les modifications qui ajoutent un répertoire
à include_rules
doit être approuvé par le service OWNERS
de cet annuaire. Non
L'approbation est requise pour restreindre l'accès à un répertoire à l'aide de include_rules
. Vous pouvez
vous assurer que toute personne qui modifie votre composant se souvient de ne pas utiliser certaines
des en-têtes en ajoutant un élément include_rule
pour les enchérir.
Les include_rules
sont vérifiées lors du préenvoi, vous n'en verrez donc pas
jusqu'à ce que vous tentiez d'importer une modification. Pour tester include_rules
sans
importer, exécutez buildtools/checkdeps/checkdeps.py <directory>
.