Проверка подлинности зависимостей в автоматизированных системах сборки на основе Maven POM - PullRequest
Новая
       11

Проверка подлинности зависимостей в автоматизированных системах сборки на основе Maven POM

12 голосов
/ 22 июля 2010

Я только что указал на очень интересную статью о проблеме безопасности, которая называется Кросс Build Injection (XBI). По сути, это причудливое название для контрабанды плохого кода в приложение во время сборки через автоматизированные системы сборки, такие как ant, maven или ivy.

Эту проблему можно решить, введя проверку криптографической подписи для зависимостей, поскольку в настоящее время она используется во многих операционных системах для загрузки пакетов.

Для ясности: я не говорю о том, чтобы просто предоставлять хеш-коды md5 или sha1 для артефактов. Это уже сделано, но эти хеши хранятся в том же месте, что и артефакты. Поэтому, как только злоумышленник взломает репозиторий и сможет заменить артефакт, он также сможет заменить хэши.

Итак, что действительно необходимо, это какая-то PKI, которая позволяет разработчикам подписывать свои артефакты и maven для проверки этих подписей. Поскольку подпись выполняется с использованием закрытого ключа разработчика, она не может быть подделана, если скомпрометирован только репозиторий.

Кто-нибудь знает состояние этого в Maven?

Ответы [ 4 ]

6 голосов
/ 14 января 2016

ТЛ; др

Несуществующие механизмы проверки в Maven и отсутствующие языковые конструкции в DSL POM представляют серьезную угрозу безопасности. Пока MNG-6026 не будет адресовано, используйте что-то вроде Gradle Witness .

Введение

Ни один из предоставленных ответов, похоже, не решил проблему. Подписание артефактов - это только первый шаг в правильном направлении. Но условие, когда ключ, используемый для подписи артефакта, считается доверенным / действительным, очень непрозрачно. Например: Как pgpverify-maven-plugin или Nexus Professional действительно проверяет, что подпись действительна для артефакта? Недостаточно просто извлечь ключ из сервера ключей и проверить артефакт.

Sonatype кратко упоминает об этом в своем блоге :

Подписи PGP: еще один уровень

Что касается потребления, вы можете использовать Закупки в Nexus Professional. проверить на наличие подписи и на издательской стороне подписание ваших выпусков с подписью PGP и создание подписей PGP доступны на сервере открытых ключей поможет людям перепроверить, что Артефакты и контрольные суммы согласованы. Примечание: я думаю, что есть больше работа над созданием инструментов, поощряющих использование ключей PGP и, что более важно, дать администраторам хранилища некоторый контроль по каким ключам доверять.

(акцент мой)

Расширение объектной модели проекта (POM) информацией доверия

Нам нужна возможность смоделировать доверительные отношения от вашего проекта или артефакта к заявленным зависимостям. Таким образом, если все участвующие стороны заявляют о таком отношении, мы можем создать «цепочку доверия» от корня (например, проекта) по его зависимостям вплоть до самой последней переходной зависимости. Проектная объектная модель (POM) должна быть расширена элементом для зависимостей.

Текущая ситуация

Прямо сейчас у нас есть что-то вроде 

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.0</version>
</dependency>

Жесткие зависимости

Для жестких зависимостей может включать сумму артефакта sha256 и его файл POM: 

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.0</version>
  <verification>
    <checksum hash='sha-256'>
      <pom>[sha256 of junit pom file]</pom>
      <artifact>[sha256sum of artifact (junit.jar)]</artifact>
    </checksum>
  </verification>
</dependency>

Мягкие зависимости

Если используются мягкие или ранжированные зависимости, то мы могли бы указать открытый ключ (или несколько) пары ключей, используемой для подписи артефактов 

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>[4.0,4.5)</version>
  <verification>
    <openpgp>[secure fingerprint of OpenPGP key]</openpgp>
    <!-- possible further 'openpgp' elements in case the artifacts in the
         specified version range where signed by multiple keys -->
  </verification>
</dependency>

А сейчас?

Благодаря peter , который вызвал меня, я поднял запрос на добавление функций для Apache Maven: MNG-6026 . Посмотрим, что будет дальше.

Другие подходы

Gradle Witness делает нечто подобное для Gradle. Но у него есть некоторые недостатки:

  • Он построен на вершине gradle (и встроен в POM)
  • Он допускает только жесткие зависимости, поскольку использует хэши.

То же самое относится и к плагину Maven Enforcer .

pgpverify-maven-plugin , по-видимому, также следует этому подходу. Хотя документация отсутствует, существует тест для так называемого свойства keysMap , который также отображается в файле конфигурации как keysMapLocation.

5 голосов
/ 22 июля 2010

Обновление: Упомянутые ниже контрольные суммы действительно предназначены только для проверок целостности и действительно хранятся вместе с артефактами, поэтому они не отвечают на вопрос.

На самом деле, необходимо подписать артефакты с помощью PGP, чтобы загрузить их в репозиторий, синхронизированный с центральным ( Плагин Maven GPG может помочь в этом шаге). Для проверки подписей во время загрузки вам предлагается использовать менеджер репозитория, поддерживающий эту функцию. От Как генерировать подписи PGP с Maven :

Если вы используете инструмент, который загружает артефакты из Центрального Maven хранилище, вы должны убедиться, что вы делаете попытку подтвердить что эти артефакты имеют действительный PGP подпись, которая может быть сверена с сервер открытого ключа. Если вы не проверить подписи, то у вас нет гарантия того, что вы есть загрузка является оригинальным артефактом. Один из способов проверить подписи на Артефакты это использовать хранилище менеджер, как Nexus Professional. В Nexus Professional вы можете настроить комплект закупок, чтобы проверить каждый загруженный артефакт для действительного PGP подпись и подтвердить подпись против открытого сервера ключей.

Если вы разрабатываете программное обеспечение с использованием Maven, вы должны сгенерировать PGP подпись для ваших релизов. Выпуск программного обеспечения с действующим подписи означает, что ваши клиенты можно проверить, что программный артефакт был сгенерирован оригинальным автором и что он не был изменен кто-нибудь в пути. Самый большой OSS кует, как Apache Software Фонд требует, чтобы все проекты были выпущен менеджером выпуска которого ключ был подписан другими участниками организации, и если вы хотите синхронизировать ваши программные артефакты в Maven Central вы обязаны предоставить подписи pgp .

Смотри также

Плагин установки Maven может быть настроен на создание контрольных сумм целостности (MD5, SHA-1), и вы можете настроить политику контрольной суммы для каждого хранилища (см. checksumPolicy).

Менеджеры репозитория Maven могут / должны иметь с ними дело. См. Например:

0 голосов
/ 15 августа 2014

Теперь возможно проверять подписи PGP в maven с помощью этого плагина: http://www.simplify4u.org/pgpverify-maven-plugin/index.html

Вот как настроить его в родительском pom.xml: 

<build>
    <plugins>

        <plugin>
            <groupId>com.github.s4u.plugins</groupId>
            <artifactId>pgpverify-maven-plugin</artifactId>
            <version>1.0.0</version>
            <configuration>
                <pgpKeyServer>https://pgp.mit.edu</pgpKeyServer>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>check</goal>
                    </goals>
                    <phase>install</phase>
                </execution>
            </executions>
        </plugin>           

    </plugins>

</build>

Эта конфигурация связывает проверку PGP с фазой install.

Если вы не хотите запускать проверку постоянно, удалите элемент <executions /> и запустите его вручную следующим образом: 

mvn com.github.s4u.plugins:pgpverify-maven-plugin:check
0 голосов
/ 29 июля 2010

"Эту проблему можно решить, введя проверку криптографической подписи для зависимостей, поскольку в настоящее время она используется во многих операционных системах для загрузки пакетов."

То, что вы ищете для подписания ваших jar-файлов.http://download -llnw.oracle.com / javase / 1.3 / docs / tooldocs / win32 / jarsigner.html

Вам необходимо защитить свой закрытый ключ с помощью соответствующих мер.Но если вы параноидально относитесь к такому самообладанию, вам, возможно, придется взглянуть на PKI, инфраструктуры открытых ключей.

...