Odcinek 15: Joe Mason w Montrealu, PQ (listopad 2020 r.)
Poprzednie odcinki
Chrome to duży projekt obejmujący wiele podsystemów. Często można znaleźć kod napisany dla jednego komponentu, który byłby przydatny w innym miejscu, ale może mieć ukryte ograniczenia. Ze względów bezpieczeństwa ogranicz dostęp z zewnątrz do niebezpiecznych funkcji. Na przykład niestandardowa funkcja dostosowana do konkretnych potrzeb w zakresie wydajności:
// Blazing fast for 2-char strings, O(n^3) otherwise.
std::string ConcatShortStringsFast(const std::string& a, const std::string& b);
Dostęp można ograniczyć na kilka sposobów. Reguły widoczności GN zatrzymują kod znajdujący się poza komponentem zależnie od elementu docelowego. Domyślnie cele są widoczne dla wszystkich, ale możesz to zmienić:
# 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" ]
}
Deklaracje widoczności są weryfikowane w narzędziu gn check
, który działa w ramach każdej kompilacji GN.
Innym mechanizmem jest protokół DEPS include_rules
, który ogranicza dostęp do plików nagłówka.
Każdy katalog dziedziczy właściwość include_rules
ze swojego katalogu nadrzędnego i można modyfikować te reguły we własnym pliku DEPS
. Wszystkie pliki nagłówka pochodzące z zewnętrznych katalogów muszą być dozwolone przez 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",
]
Aby zapewnić, że te zależności są odpowiednie, zmiany, które dodają katalog do include_rules
, muszą zostać zatwierdzone przez OWNERS
tego katalogu. Aby ograniczyć katalog za pomocą polecenia include_rules
, nie musisz zatwierdzać go. Aby mieć pewność, że każda osoba zmieniająca komponent nie będzie używać określonych nagłówków, dodaj element include_rule
zabraniający ich stosowania.
include_rules
są sprawdzane przez wstępne przesyłanie, więc dopóki nie spróbujesz przesłać zmiany, nie zobaczysz żadnych błędów. Aby przetestować include_rules
bez przesyłania, uruchom buildtools/checkdeps/checkdeps.py <directory>
.