Comments 46
Отлично. У нас все зашифровано и любое малейшее изменение в файле ведет к полному изменению его зашифрованной копии.
Теперь посмотрим как работают pack-и git'а.
Они стараются хранить diff-ы файлов, чтобы предотвратить рост размера репозитория.
Проведите эксперимент — создайте два репозитория. Один в зашифрованном виде, другой — в незашифрованном.
Положите в них один и тот же файл размером в 50mb (для наглядности)
Измените в файле один символ и сделайте коммит.
Повторите это действие несколько раз. (На обоих репозиториях синхронно)
Теперь сделайте команду git gc на обоих репозиториях и сравните размер.
2. Моральный аспект:
«Если вы захотели воспользоваться публичным ресурсом вроде GitHub или GoogleDrive для хранения своего репозитория, но при этом не готовы делиться со всем миром результатами своего труда, то вам поможет»… приватный репозиторий от Github или собственный git-сервер.
Шифруя открытые репозитории, вы нарушаете свое соглашение с Github
Не понимаю зачем создавать публичный, открытый репозиторий и хранить в нем шифрованный контент.
По моему мнению создание репозитория на github и хранение на нём шифрованных данных вполне логично:
Автор почему‐то привёл в пример именно шифрование кодовой базы. Но вы можете, к примеру, сделать на этой основе свой парольный менеджер и хранить так пароли, при этом храня и историю их изменения, не опасаясь что‐то случайно удалить.
Ещё так можно публично хранить все.файлы скопом — в том числе .ssh — в зависимости от того, к чему именно вы имеете доступ такое может быть вполне приемлемо.
В моём первом предложении не случайно отсутствует слова «публичный» и «открытый». Шифрование репозитория просто значит «я не доверяю github, но не готов поддерживать свой сервер». Ничто не мешает взять и также зашифровать приватный репозиторий.
Заметьте, автор написал «воспользоваться публичным ресурсом». А не «публичным репозиторием».
Шифрование кодовой базы в публичном репозитории Github-а, у вас чудесным образом превращается в шифрование паролей на всего лишь публичном ресурсе…
Ну да, конечно, свои шифрованные пароли просто обязательно хранить в общедоступном месте, других мест — конечно же нет. :)
И вот уж совсем интересный поворот — предложение шифровать приватный репозиторий… м-да… :/
А вы не политиком? Я вот не вижу, чтобы автор писал про публичный репозиторий, не покажете? Может ещё скажете, что там же упомянутый GoogleDrive стал внезапно публиковать файлы по‐умолчанию? А в начале комментария про пароли я вообще написал «Автор почему‐то привёл в пример именно шифрование кодовой базы» а не «Автор на самом деле имел ввиду шифрование паролей».
Кроме того, где ваши предложения про «другие места»? Почему вам не нравится шифрование приватных репозиториев? В отличие от вас, я написал, какая может быть мотивация за этим действием.
В общем ваш комментарий практически не содержит смысла, но зато содержит пачку ораторских приёмов. Политику бы определённо подошёл.
Да видимо адвокат. На одно возражение — ушат претензий и обвинений....
По первому комментарию — за использование шифрования приходится платить. Как и за всё хорошее в этом мире.
По второму — едва ли хранение репозитория на гуглдрайве противоречит соглашению с гуглом. Зато ему полностью соответствует индексирование вашей почты и содержимого гуглдрайва гуглом. Я не желаю, чтоб мои файлы с паролями попадали в базы данных гугла.
А по поводу гитхаба — я предлагаю вам указать на пункт соглашения, который мешает мне шифровать некоторые файлы репозитория. Я читал это соглашение — а вы? А по поводу необходимости — есть некоторые случаи (например связанные с правами на код) которые могут помешать выложить часть кода в чистом виде. Если у вас проект находится на границе лицензий и какая-то его часть, к примеру, не может быть GPL. А если у вас подобной необходимости никогда не было, то непонятно почему вы развили такой спор под этой статьей.
GPL как раз не позволяет скрывать код. Никакой. Ни свой ни встроенный.
Но если вы хотите скрыть весь код (а именно это предложено в статье) то зачем тогда его располагать на публичном ресурсе?
Про гуглодрайв — речи не было. В статье именно на гитхаб заливается шифрованные исходники. Потому и тред развернулся...
Кстати держать репы в облаках — не очень удобно. Яндекс например упорно стирает права на исполнение файла (под linux).
Как это «про гуглдрайв не было речи», когда он упомянут ещё в аннотации? Фактически изначально я шифрование поднимал именно на гуглдрайве а на гитхаб переехал значительно позже.
К слову про гуглдрайв — на днях выложу статейку про «родное» криптование документов в гуглдоксах. Работает и на телефоне.
GPL позволяет скрывать весь свой код — пока вы не начали распространять программу, скрывайте сколько хотите. Можете сделать свой закрытый форк чего угодно с лицензией GPL, главное — не предоставляйте его клиентам, они могут потребовать от вас код, а вы не можете в ответ потребовать NDA: https://gcc.gnu.org/ml/gcc/2001-07/msg01342.html.
Если шифровать построчно, то вам понадобится сравнительно сложный скрипт построчного (де)шифрование и понимание криптографии на достаточно высоком уровне, чтобы скрипт не сделал шифрование хуже, чем бесполезным: напоминаю, что если шифровать именно код, то там будет очень много весьма предсказуемых строк вроде «пустая строка», «строка с пробелами и закрывающей фигурной скобкой» и какие‐нибудь #!/usr/bin/env bash. Одна ошибка в скрипте и эти строки выдают злоумышленнику пароль, всего лишь за возможное уменьшение размера репозитория.
В данном случае шифруется поблочно — режим ecb, сжатие не включено (openssl enc -d -base64 -aes-256-ecb -k $1; https://www.openssl.org/docs/man1.0.2/apps/enc.html) — https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_.28ECB.29 — т.е. каждый блок данных в 128 бит (16 байт) для данного ключа однозначно отображается в какой-то другой 16-байтный блок (еще в начале зашифрованного файла 8 байт Salt и в конце файла добавляется 1 блок PKCS#7 padding). Замена 1 символа в середине файла приведет к изменению 1 блока; добавление символов в середине файла приведет к сдвигу последующих данных, но добавление 16 байтов в середине (или кратного количества) не изменит последующую зашифрованную часть файла. Из-за base64 и переноса строк каждые 64 символа (хотя в вики заявляют про 80 символов) в строке помещается 3 блока по 16 байтов, поэтому добавлять или удалять текст из середины файла лучше размерами, кратными 48 байтам.
Режим ecb не самый безопасный — одинаковые блоки открытого текста в каждом файле всегда кодируются в такие же блоки шифротекста — см https://crypto.stackexchange.com/questions/20941/why-shouldnt-i-use-ecb-encryption "Why shouldn't I use ECB encryption? / You should use any authenticated encryption mode, such as GCM, EAX or OCB.) и классический bmp "The ECB Penguin" 
.
Да, зато получается "We are using AES-256 ECB mode as the encryption algorithm, as it turns out a deterministic encryption works best with git (we will explain later)." — https://gist.github.com/dstrctrng/3430823
2. Нужно понимать, что шифруется не всё, а указанные маски. Даже для opensource шифрование к примеру ключей подписи бинарников — весьма актуально. А хранить их в репозитарии со всем остальным удобно.
Вопрос по пункту 1.
Вы случайно не путаете git и mercurial?
https://git-scm.com/book/ru/v2/Введение-Основы-Git
git-scm.com/book/ru/v1/Git-изнутри-Pack-файлы
— Оба пункта относятся к шифрованию по маске **/*, т.е. полному шифрованию репозитория пофайлово.
— Как мне подсказывает KOLANICH в ToS Github нигде явно не зафиксировано, что в public репозиториях нельзя использовать обфурскацию/шифрование, так что стоит говорить лишь о fair use.
Также travis ci напрямую советует использовать шифрование.
Если, скажем, шифровать какие-либо ключи для travis ci — то оба мои возражения отпадают.
Технический — т.к. незашифрованные ключи обладают теми же свойствами, что и зашифрованные — они меняются не познаково, а целиком.
Моральный — т.к. кодом мы всё еще делимся, просто при этом защищаем наш pipeline от вандалов.
Использовать для других целей — слишком много информации утекает в открытом виде — имена и размеры файлов, сообщения коммитов.
Но подход интересный, не думал, что в Git есть что-то подобное.
В git шифрования нет, но гит настолько гибкий инструмент, что небольшими усилиями в него можно хоть черта в ступе прикрутить. И автор прикрутил шифрование.
Как по мне так это скрещивание бульдога с носорогом…
Ага, гибкий. Но даже аналога фаз из mercurial почему‐то нет, не говоря уже о чём‐то более фундаментальном вроде changeset evolution. Для чего‐то простого можно обвешаться атрибутами и хуками, и это гораздо проще, чем написать дополнение для mercurial или даже делать шифрование на «фильтрах» (аналогично атрибутам, вот только настройких не хранятся в репозитории), но если вам, к примеру, захочется иметь возможность объявлять «этот коммит опубликован, его нельзя менять (в т.ч. удаляя из ветки)» и «этот коммит не опубликован, его можно менять», то вам понадобятся, во‐первых, хуки, во‐вторых, отдельный сервер синхронизации фаз: средств добавления метаданных в коммиты нет вообще, тем более средств добавления метаданных, которые не учавствуют в расчёте хэша и могут быть изменены позднее.
Конкретно с фазами проблема частично решается запретом force-push в «публикующих» репозиториях, но это, во‐первых, менее удобно для пользователя, а, во‐вторых, поднятие проблемы, решаемой фазами, не является целью комментария вообще. Приведя данный пример, длительное время существовавший в виде дополнения я просто показываю, что дополнения в mercurial обеспечивают намного бо́льшую гибкость, чем позволяет архитектура git.
pass как раз так и делает для хранения паролей в гите
Вопрос: достаточно ли сделать rm -rf из dev/shm, чтобы гарантировать, что никто больше из этой области памяти не прочитает наши пароли?
Беглый гуглинг не дал результатов.
Просто всяческое crypto-по активно использует zeromemory и прочие гарантии удаления данных из памяти.
Как с этим в dev/shm?
С другой стороны — это супер идея, «я ее джва года ждал». Хранить под гитом пароли! Спасибо за наводку!
А как это в Linux сделать?
Keybase недавно запустили шифрование git:
https://keybase.io/blog/encrypted-git-for-everyone
You can have as many repositories as you want, but the total for your personal repositories can't exceed 100GB.
What if we're living in a simulation?
Keybase offers no guarantees against sophisticated side-channel attacks by higher-level entities.
Нюансы шифрования в Git