Git and Non Repudiation, повторный просмотр
Joe SchaeferЭто эссе действительно относится к DVCS в целом, а не только git per se. Но мы сосредоточим внимание на git, потому что он остается самой популярной DVCS на сегодняшний день.
Благодаря традиционному централизованному инструменту управления версиями такие записи легко доступны из истории фиксаций. Каждая фиксация в системе проходит через механизм авторизации, чтобы гарантировать, что лицо, внесшее изменение, имеет право загрузить его. Эти записи имеют жизненно важное значение для предприятия, чтобы обеспечить точные записи, которые указывают, кто несет ответственность за загрузку каждой строки кода в соответствующее программное обеспечение.
с git или распределенным контролем версий в целом, Существует четкое различие между историей «обязательства» и историей «загрузки». — который я буду называть «push records». Фиксации в git не аутентифицированы, потому что они происходят локально, с локальными, непроверенными метаданными, добавленными в историю. Шаг загрузки, ака толчок
С Фонд Apache Software Foundation.
Почему это важно? Для начала позвольте мне обратиться к распространенному заблуждению о необходимости лицензионных соглашений (ICLA) для участников Apache. Многие люди, похоже, не понимают, что в отношении индивидуальных произведений автора нет разницы между применимым языком в ИКЛА и Лицензия Apache 2.0.
То, что предоставляют push-записи, – это способ отследить каждую строку кода в выпуске, индивидуальный фиксатор, ответственный за передачу этого кода в репозиторий git ASF. Это критически важно в определении происхождения стороннего вклада с git, потому что, к сожалению, такой вкладчик может «уйти» от своего вклада в git-проект из-за распределенного характера журналов фиксации DVCS. Ответственная сторона, по данным ICLA, становится тем, кто продвигал код.
Ранние и правильные стратегии смягчения последствий вращаются вокруг устранения оставленного вклада, но ущерб проекту, возможно, уже был нанесен. И без push-записей у нас буквально не было бы авторитетного процесса для определения того, как этот код на самом деле попал в наш репозиторий, за исключением поиска альтернативных записей в трекерах проблем или переписке. Опираясь только на журналы merge-commit для определения происхождения не очень удовлетворительно с точки зрения безопасности, потому что это требует жесткого соблюдения определенного типа рабочего процесса, который мы не хотим диктовать.
Без таких вещей нам нужно было бы поручить, по крайней мере, подписывать PGP обязательства каждого участника, что обременительно для многих проектов. Записи фоновой рассылки обеспечивают прозрачный процесс, который не влияет на поток операций проекта, за исключением того, что репозиторий git ASF является истинным главным репозиторием.
Обновление ## 2025
Git имеет встроенную поддержку SSH-SK-ED25519@openssh.com
Бесполезное раздувание и сложность полной инфраструктуры PGP больше не имеют отношения к решению проблем, не связанных с отказом от ответственности, обсуждавшихся выше, в рамках организации или на уровне каждого проекта. И хорошая интеграция GitHub облегчает эти усилия в полном объеме.