Поддерживает ли Perforce «подписанные изменения» или «подписанные коммиты»?

Question

Моя компания пытается удовлетворить требования PA-DSS для нашего приложения, одна из которых довольно неоднозначна в отношении «безопасного контроля источника», однако наш аудитор интерпретировал ее как необходимость в подписанных версиях. Я вижу «подписанные коммиты» в git и Hg, но ничего не обнаружил на стороне присутствия.

ревизоров пример, как к тому, что он хотел бы видеть следующий образом:

«Поставщик платежных приложений поддерживает целостность исходного кода в процессе разработки с использованием стандартного алгоритма хэширования, который создается и проверенный на коде регистрации по прибытию . в и проверяются, когда исходный код извлечен для модификации алгоритм хеширования используется: • (пример) SHA-256 • (пример) SHA-512 • (пример) MD5"

Если посмотреть на http://en.wikipedia.org/wiki/Comparison_of_revision_control_software , в таблице «Особенности» есть столбец «Подписанные ревизии» и секция perforce n говорит «Да» ... кто-то подумал, что это что-то вроде поддержки.

Это что-то, что можно было бы сделать, используя триггеры до/после фиксации? Создайте хэш в pre-commit, сохраните его (каким-то образом) и проверьте его против того, который мы создаем в after-commit? Я только узнал о триггерах по умолчанию 5 минут назад, поэтому я даже не знаю, поддержат ли они концепцию (не уверен, как сохранить значение в событиях триггеров, не уверен, что у меня есть доступ к содержимому файла в триггере перед проверкой, и т.д).

Answer 1

Действительно, файлы, представленные в Perforce, имеют криптографические дайджесты, которые вычисляются во время операции отправки.

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

Вы также можете просмотреть эти дайджесты, выполнив различные команды; например, вы можете запустить 'p4 fstat -Ol //depot/src/file.c' и посмотреть поле «дайджест».

Кстати, что такое «требования PA-DSS»? Это новый аббревиатура для меня.

Вот некоторое количество информации о файле переваривает, что сервер Perforce поддерживает:

1. http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_verify.html
2. http://kb.perforce.com/AdminTasks/BackupAndRecovery/BadErrorsFromP4Verify
3. http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_fstat.html

Если проблема предполагает сохранение записи из чтобы проверить, что изменения кода, которые были рассмотрены, являются теми, которые были фактически представлены, вы можете разработать рабочий процесс, основанный на команде «полка» Perforce.

Самым важным аспектом команды «сукно», которая помогает с этими видами рабочих процессов на самом деле в команде «подать»: «p4 представить -e» непосредственно подчиняется полку на своем сервере, без повторной передачи файлы с рабочей станции пользователя.

Таким образом, если ваш процесс только позволяет «представить -e» для покоряется некоторых защищенных областей вашего хранилища, и только позволяет ПРЕДСТАВЛЯЕТ полок, которые были рассмотрены (эти вещи были бы вы соблюдения с вашей change-submit), то вы уверены, что код, который был просмотрен, представляет собой код, который был отправлен.