Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

pkg-config и файлы pc

Почему это важно для SCA/OSA

pkg-config и его .pc-файлы — это слой, через который Autotools-, Meson- и многие CMake-проекты узнают, как линковаться с библиотекой. .pc-файл — текстовый, читаемый и содержит ровно те поля, которых не хватает SCA: Version:, Requires:, Libs:, Cflags:. Для аудитора это не слепая зона, а наоборот — готовый источник evidence: по Version: и Requires: можно восстановить и версию компонента, и его прямые зависимости, не разбирая бинарь.

Но есть две тонкости. Поле Version: проставляет упаковщик дистрибутива вручную, и оно не обязано совпадать с реальной версией кода библиотеки (особенно у форков и пропатченных пакетов). И .pc различает Requires: и Requires.private: — второе нужно только при статической линковке, и его легко пропустить.

Как это проявляется

Типичный .pc-файл — это структурированное evidence:

# /usr/lib/x86_64-linux-gnu/pkgconfig/libssl.pc
Name: OpenSSL-libssl
Version: 3.0.13
Requires.private: libcrypto
Libs: -L${libdir} -lssl
Cflags: -I${includedir}

Как достать поля программно

pkg-config --modversion libssl        # 3.0.13  — версия из .pc
pkg-config --print-requires libssl    # прямые Requires
pkg-config --print-requires-private --static libssl   # Requires.private (для .a)
pkg-config --variable=pcfiledir libssl

PKG_CONFIG_PATH управляет тем, какой .pc найдётся первым, — на сборочной машине это может быть не системный, а вендоренный .pc из third_party/.

Поле .pc Что даёт SCA Подвох
Version: версия компонента проставлена упаковщиком, может не совпадать с кодом
Requires: прямые зависимости (динамика и статика) —
Requires.private: зависимости только для статической линковки теряется без --static
Libs.private: флаги линковки для статики то же

Слепая зона или приём

Здесь скорее приём, чем слепая зона: .pc — это harvestable-источник, который часто игнорируют. Но есть и риск — Version: из .pc нельзя принимать на веру для пропатченных и форкнутых пакетов: упаковщик мог оставить апстрим-версию, добавив свои патчи. И Requires.private: без флага --static не виден, а именно он закрывает транзитивные зависимости статически слинкованного кода.

Снимайте Requires вместе с Requires.private Всегда запрашивайте и публичные, и приватные зависимости (--static). Версию из .pc сверяйте с реальным источником (changelog пакета, dpkg -s), особенно если библиотека пришла из вендоренного каталога, а не из дистрибутива.

Что делать на проекте

  1. Найдите все .pc-файлы в путях PKG_CONFIG_PATH и в дереве сборки; вендоренные .pc из third_party/ отметьте отдельно.
  2. Соберите по каждому Version:, Requires:, Requires.private: — это evidence по версии и прямым зависимостям.
  3. Запросы делайте с --static, иначе потеряете Requires.private статической линковки.
  4. Сверьте Version: с реальной версией кода для форков/пропатченных пакетов; расхождение — повод понизить confidence.
  5. Смаппьте имена из .pc на пакеты дистрибутива (dpkg -S/rpm -qf по пути .pc-файла).
  6. Поля .pc используйте как дополнение к ldd/readelf, а не вместо них: .pc отражает намерение сборки, бинарь — результат.

Связь