Времеви печат на изходен код и Git хранилище
Датите на къмитите в Git не показват кога кодът ви е съществувал. Всеки може да ги зададе произволно, а един rebase ги пренаписва. За да фиксирате дата на кодова база, която непознат, клиент или съд трябва да приеме, вземете едно точно моментно копие на кода – обикновено ZIP архив на маркиран с таг къмит – и поставете квалифициран електронен времеви печат върху неговия цифров отпечатък. От компютъра ви излиза само отпечатъкът, затова методът работи и за частен, и за собственически код. По-долу е точната процедура, какво установява тя и какво не.
Това е обща информация за доказателствата, а не правен съвет по конкретен спор.
Защо историята в Git не е независимо доказателство за дата
Git записва две дати на всеки къмит – датата на автора и датата на къмитъра – и двете идват от машината, на която е направен къмитът. Никой не ги проверява. Ако зададете GIT_AUTHOR_DATE и GIT_COMMITTER_DATE преди къмит или изпълните git commit --amend --date, получавате история, която казва каквото пожелаете. Интерактивният rebase, squash сливанията и cherry-pick пренаписват датите като страничен ефект от обикновената работа.
Това не прави историята ви безполезна. Тя е отлично доказателство за това как е изграден кодът: малки стъпки, мотиви в съобщенията на къмитите, задачи, ревюта, изоставени клонове. Слабо доказателство е обаче за това кога, защото човекът, който се позовава на нея, е същият, който е могъл да я напише.
Хостинг платформите помагат, но не запълват празнината. GitHub, GitLab и Bitbucket записват кога даден push е стигнал до тях, но тези записи се държат от частна компания, може да е трудно да ги получите по-късно и изчезват заедно с изтрито хранилище или профил. Един force-push заменя това, което е било там.
Какво добавя квалифицираният времеви печат
Квалифицираният електронен времеви печат се издава от доставчик на удостоверителни услуги под надзор съгласно Регламента eIDAS на ЕС. Според член 41, параграф 2 съдилищата във всяка държава членка приемат за презумпция, че датата и часът му са точни и че данните, които обхваща, не са променени оттогава. Датата не идва от вас, затова не може да бъде оспорена с довода, че вие сте я задали.
Времевият печат е свързан с цифровия отпечатък SHA-256 на един файл. Промените ли дори един байт, отпечатъкът вече не съвпада. Затова методът по-долу се свежда до това да изберете и запазите един точен файл.
Метод 1: времеви печат на ZIP архив на маркиран къмит (най-силният)
- Маркирайте с таг състоянието, което искате да фиксирате.
git tag v1.4.0(или използвайте къмит, който вече сте маркирали). - Експортирайте точно това състояние.
git archive --format=zip -o myproject-v1.4.0.zip v1.4.0. Архивът съдържа следените файлове в този къмит и нищо друго: без.env, без резултати от компилация, без незаписани промени. - Издайте сертификат за този ZIP. Отпечатъкът се изчислява в браузъра ви; самият ZIP не се качва. Приемат се файлове до 500 MB.
- Съхранявайте ZIP архива непроменен до PDF сертификата, на поне две места. Не го разархивирайте и архивирайте наново: нов архив на същите файлове може да има различен отпечатък.
Защо ZIP, а не папката: сертификатът обхваща един файл. Архивът превръща цялото дърво в един файл, чийто отпечатък можете да изчислите отново по-късно с всеки инструмент за SHA-256. Резултатът от git archive може да се различава между версиите на Git – именно затова пазите архива, на който е поставен печатът, вместо да разчитате, че ще го генерирате отново.
Метод 2: времеви печат на запис за къмит (олекотеният)
Ако искате евтино да датирате много къмити или хранилището е по-голямо от 500 MB, напишете кратък текстов файл и поставете времеви печат на него:
repository: git@example.com:me/myproject.git
tag: v1.4.0
commit: 3f9c2e7d0a5b8c1e4f6a9d2b7c0e3f5a8b1d4c6e
tree: 9b2e4d6f8a0c1e3b5d7f9a1c3e5b7d9f0a2c4e6b
note: версия-кандидат, изпратена на клиента по негово исканеПопълнете редовете commit и tree с реалните стойности от git rev-parse v1.4.0 и git rev-parse v1.4.0^{tree}. Идентификаторът на къмит в Git е хеш на дървото на къмита, родителите му и съобщението му, така че свързва времевия печат с точно това състояние на кода и с цялата история преди него. Пазете хранилището, включително този къмит, на сигурно място; текстовият файл сам по себе си не показва нищо без него.
Компромисът: връзката между текстовия файл и кода ви зависи от собственото хеширане на Git. Повечето хранилища все още използват SHA-1 за идентификаторите на обектите, а срещу SHA-1 има известни колизионни атаки, макар Git да има вградено откриване на известната атака. За рутинен етап това обикновено е достатъчно. За версията, на която най-вероятно ще се позовете при спор, използвайте Метод 1 – там времевият печат обхваща самите файлове.
Кой метод кога
| Ситуация | Метод | Защо |
|---|---|---|
| Преди да изпратите код на клиент, инвеститор или потенциален работодател | Метод 1 | Фиксира точно файловете, които предстои да предадете |
| Преди отваряне на кода или смяна на лиценза | Метод 1 | Фиксира какво е съществувало при старите условия |
| При край на договор за свободна практика или на сътрудничество | Метод 1 | Фиксира състоянието в момента, в който отговорностите се променят |
| Месечни етапи или етапи при всяко издание | Метод 2 | Евтино е и всеки запис обхваща и цялата предишна история |
| Хранилище над 500 MB | Метод 2 или Метод 1 само за папките с изходния код | Файлът с печата остава под ограничението за размер |
Частен и собственически код
Отпечатъкът се изчислява на вашето устройство. Освен ако изрично не изберете да съхраните копие на файла, StampR получава само отпечатъка, името и размера на файла и данните, които въвеждате. От отпечатъка не може да се възстанови кодът. За собственически код оставете опцията за съхраняване и показване на оригинала неотметната: съхраненият оригинал се показва на публичната страница на сертификата.
Изберете името на файла и описанието със същото внимание. И двете се отпечатват на сертификата. myproject-v1.4.0.zip е наред; име, което издава непредставен още продукт, може да не е.
Какво това не прави
- Не показва, че вие сте написали кода. Показва, че точно този код е съществувал в този момент и че сте декларирали, че е ваш. Историята на къмитите, задачите и бележките по дизайна показват как е свършена работата.
- Не решава кой притежава кода. В ЕС, когато служител създаде програма при изпълнение на задълженията си, работодателят има право да упражнява имуществените права, освен ако в договора не е уговорено друго (Директива 2009/24/ЕО, член 2, параграф 3). При работа на свободна практика и за агенции всичко зависи от договора. Времевият печат фиксира дати; той не отменя споразумение.
- Не обхваща идея или алгоритъм като такива. Авторското право върху софтуер в ЕС обхваща изразяването на програмата, а не идеите и принципите, които стоят зад нея (Директива 2009/24/ЕО, член 1, параграф 2). Въпросите за патенти са отделни и публикуването може да им повлияе.
- Не замества лиценз. Ако публикувате код, изберете и приложете лиценз; времевият печат е доказателство, а не разрешение.
Поставете времеви печат на моментно копие на кода си – първият сертификат с профил струва 4,90 €.
Проверка по-късно
Всеки може да провери сертификата, без да трябва да ви вярва. Изпълнете sha256sum myproject-v1.4.0.zip (macOS: shasum -a 256, Windows: Get-FileHash) и сравнете резултата с отпечатъка на сертификата или го въведете на страницата за проверка. Съвпадението означава, че файлът е байт по байт същият, на който е поставен времевият печат.
Свързани статии
- Стотици файлове с един сертификат – методът с манифест, когато ZIP архивът не е практичен.
Често задавани въпроси
Могат ли датите на къмитите в Git да служат като доказателство кога е написан кодът?
Могат да бъдат представени, но са слаби по отношение на времето, защото се задават от машината, която прави къмита, и могат да се променят с променливи на средата, amend или rebase. Те са силно доказателство за това как се е развивала работата и действат най-добре заедно с независима дата, например квалифициран времеви печат.
Трябва ли да кача изходния си код?
Не. Цифровият отпечатък SHA-256 се изчислява в браузъра ви и се изпраща само отпечатъкът, освен ако не изберете да съхраните копие на файла. За собственически код не съхранявайте копие.
На какво да поставя времеви печат – на ZIP архива или на хеша на къмита?
ZIP архивът на маркиран къмит е по-силният вариант, защото времевият печат обхваща директно файловете. Текстов файл с идентификатора на къмита е по-евтин за редовни етапи и обхваща цялата предишна история, но връзката му с кода зависи от собственото хеширане на Git.
Достатъчен ли е часът на push в GitHub?
Той е полезно допълнително доказателство, но се държи от частна платформа, може да е трудно да го получите по-късно и изчезва, ако хранилището или профилът бъдат изтрити. Квалифицираният времеви печат се държи от вас и съдилищата в ЕС приемат, че е точен.
Показва ли времевият печат, че кодът е мой?
Не. Собствеността зависи от това кой го е написал и от трудовите договори или договорите за свободна практика. Времевият печат фиксира, че точно този код е съществувал в даден момент и че сте декларирали, че е ваш.
Колко често да поставям времеви печат?
В моментите, към които може по-късно да ви се наложи да се позовете: преди да предадете код на някого, преди смяна на лиценза, при края на договор и при големи издания. Много разработчици добавят и месечен запис за къмит между тях.