Gpg

Программы семейства GPG (GNU Privacy Guard) / PGP (Pretty Good Privacy) позволяют "прозрачно" подписывать и зашифровывать все типы цифровой информации. По своей сути, названные инструменты являются лишь удобной обёрткой, упрощающей практическое использование открытых алгоритмов ассиметричной криптографии.

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

В этой статье рассмотрим приложение с открытым исходным кодом для работы с инструментарием GPG в графической оболочке находка для новичков и тех, кто просто избегает загадочного черного окна командной строки. Благодаря кроссплатформенности Клеопатры, статья одинаково полезна для пользователей Windows, Linux и FreeBSD.

Установка

Во многих unix-like операционных системах Клеопатра имеется в репозиториях по умолчанию. В Debian установка выглядит так: sudo apt-get install kleopatra.

Для Windows программа распространяется в пакете GPG4Win, объединяющем в себе несколько полезных инструментов: непосредственно Kleopatra, GpgEX - удобный плагин для проводника Windows, который добавляет в контекстное меню пункты "Зашифровать", "Подписать", "Расшифровать", "Проверить контрольные суммы" и некоторые другие, GPA еще один более простой на вид и менее функциональный менеджер ключей, GpgOL плагин для почтового клиента Outlook).

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

Создание пары ключей

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

По умолчанию используется шифрование RSA с длиной ключа в 2048 бит (2048 нулей и единиц машинного кода). С учетом развития квантовых технологий, данное шифрование всё менее и менее кажется надежным. В настоящее время себя хорошо зарекомендовало использование криптографии на эллиптических кривых. Подобные алгоритмы имеют невероятную криптостойкость и хорошую производительность, благодаря небольшой длине ключа.

Чтобы создать пару ключей на эллиптических кривых, переходим в дополнительные параметры. Пункт ECDSA/EdDSA то, что нам надо. Дополнительный чекбокс (галочка) "+ECDH" даст ключу возможность шифровать, без нее сертификат можно будет использовать только для подписи и идентификации, так как ECDSA/EdDSA алгоритмы подписи, а не шифрования. В выпадающих списках предлагается выбрать один из алгоритмов: ed25519, brainpool и NIST.

1. ed25519 (Curve25519) эталонная и непатентованной реализация криптографии на эллиптической кривой, имеет 128-битную длину. Является ключом EdDSA самым актуальным алгоритмом цифровой подписи (считается, что без закладок от силовых структур каких-либо стран).

2. brainpool алгоритм, разработанный немецким сообществом криптографоф, в число которых входят университеты, государственные ведомства и коммерческие организации, например, компания Bosch. Поддерживает длины в 256, 384 и 512 бит. При подписи использует несколько устаревший алгоритм ECDSA.

3. NIST американский алгоритм, разработанный Национальным Институтом Стандартов и Технологий. Рекомендован для использования государственными органами США. Поддерживает длины в 256, 384 и 521 бит. По оценке некоторых специалистов, NIST лучше brainpool по производительности. При подписи использует несколько устаревший алгоритм ECDSA.

Для примера в обоих случаях используется алгоритм brainpool с максимальной длиной ключа. По умолчанию ключ создается со сроком годности в два года. Этот параметр можно изменить, либо вовсе отключить, тогда ключ будет бессрочным.

На следующем шаге задается пароль, который является последним рубежом защиты секретного ключа. Не следует передавать кому-то секретный ключ, но если так все-таки вышло, будет лучше, когда вы задали очень надежный пароль. Рекомендуется использовать специальные знаки (символы пунктуации и прочее) для надежной защиты от брутфорса. Лучшим вариантом будет длинный пароль, полученный из генератора случайных символов, однако не забывайте про золотую серидину между использованием и безопасностью. Например, вводить на телефоне очень длинный и сложный пароль с символами из расширенной таблицы ASCII, не имея возможности его скопировать из менеджера паролей, будет весьма проблематично.

Итак, пара ключей создана! Обратите внимание на отпечаток, это уникальный идентификатор вашего ключа. Даже если кто-то захочет представиться вами, создав ключ с такими же именем и электронной почтой, его отпечаток будет отличаться. Именно поэтому важно сверять отпечатки получаемых ключей.
Клеопатра предлагает сделать резервную копию ключей, что по факту является экспортом закрытого ключа. Эту операцию в дальнейшем можно произвести в любой момент.

Открыв экспортированный ключ в текстовом редакторе, мы увидим специфичный фрагмент текста, начинающийся словами "BEGIN PGP PRIVATE KEY BLOCK". Будьте внимательны, не отправьте его кому-то по ошибке! Открытые ключи, предназначенные для передачи вторым лицам, начинаются со слов "BEGIN PGP PUBLIC KEY BLOCK".

Большое преимущество GPG перед другими средствами идентификации заключается в легкой переносимости ключа. Например, его можно распечатать на бумаге или выучить наизусть. Хранить можно только приватный ключ, так как при необходимости кому-то передать публичный, мы всегда можем экспортировать его из секретного (выводится математическим путём).

Экспорт и импорт

Для операций с ключом, щелкните по нему правой кнопкой мыши.

Для импорта ключей (нашего уже существующего на новом устройстве или полученного публичного), воспользуемся кнопкой "Импорт". Также можно использовать двойной клик по файлу ключа, это автоматически откроет Клеопатру и импортирует выбранный ключ. GPG-файлы встречаются с расширениями *.asc, *.pgp и *.gpg. Это не имеет большого значения, так как расширение нужно больше для удобства пользователя и лишь немного приложений. Файл будет корректно прочитан и в случае, когда специальное расширение изменено или удалено.

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

Программа попросит удостовериться в подлинности ключа. В настоящее время самым простым и эффективным способом является сравнение отпечатка, поэтому его публикуют вместе с ключом. Если отпечаток совпадает с заявленным, заверяем сертификат.

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

Шифрование и подпись

Чтобы зашифровать и подписать файл, воспользуемся соответствующим пунктом меню на верхней панели.

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

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

Также возможна подпись без шифрования. Чаще всего применимо к текстовой информации. Механизм подписания строится на хеш-сумме: позволяет сравнить актуальное состояние информации с тем, какой она была, когда ее подписывал отправитель. Для примера откроем "блокнот".

Назначив отсутствие шифрования для кого-либо, оставляем только подпись и нажимаем кнопку "Подписать".

После ввода пароля от ключа, видим, что к фразе "Отличная работа" добавился дополнительный текстовый блок с хеш-функцией SHA512.

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

В случае подписи файла без шифрования, в директории файла создается сигнатура с расширением *.sig, которую следует передавать вместе с исходным файлом. Если в файле изменится хотя бы один бит, проверка подписи выдаст ошибку.

Постскриптум

Все локальные ключи централизованно хранятся на устройстве в специальной папке. Все программы, взаимодействующие с GPG, будут их видеть. Для общения по протоколу XMPP (Jabber), защищенного GPG-шифрованием, можно использовать Gajim, который также является кроссплатформенным. Для ведения защищенной почтовой переписки удобно использовать этичный клиент Thunderbird, в который необходимо будет импортировать секретный ключ, так как он имеет свое изолированное хранилище ключей.

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

Git очень мощный инструмент, который практически каждый разработчик должен использовать ежедневно, но для большинства из нас git сводится к нескольким командам: pull commit push. Однако, чтобы быть эффективным, продуктивным и обладать всей мощью git, необходимо знать ещё несколько команд и трюков. Итак, в этой статье мы исследуем функции git, которые просто запомнить, применять и настроить, но которые могут сделать ваше время с git гораздо более приятным.

Прокачиваем базовый рабочий процесс

Прежде чем мы воспользуемся даже самыми базовыми командами pull, commit и push, необходимо выяснить, что происходит с нашими ветками и изменёнными файлами. Для этого можно воспользоваться git log довольно известной командой, хотя не все знают, как сделать его вывод на самом деле читабельным и красивым:

Такой граф даст хороший обзор, однако часто нужно копать немного глубже. Например, посмотреть историю (эволюцию) определённых файлов или даже отдельных функций; в этом поможет git log с флагом -L::).

Теперь, когда мы немного представляем происходящее в репозитории, мы, возможно, захотим проверить различия между обновлёнными файлами и последним коммитом. Здесь можно воспользоваться git diff; опять же ничего нового здесь нет, но у diff есть кое-какие опции и флаги, о которых вы, возможно, не знаете. Например, можно сравнить две ветки: git diff branch -a branch -b, или даже конкретные файлы в разных ветках: `git diff <commit-a> <commit-b> -- <пути>`.

Иногда чтение git diff становится трудной задачей. Можно попробовать прописать игнорирующий все пробельные символы (white-space) флаг -w, и этим немного заспамить diff, или флаг --word-diff и работать вместо строк с раскрашенными словами.

Если простой статичный вывод в оболочке вас не устраивает, можно запустить difftool, вот так: git difftool=vimdiff, команда откроет файлы diff внутри vim в два окна слева и справа. Очевидно, что Vim не единственный вариант; можно запустить git difftool --tool-help, чтобы увидеть список всех инструментов, которые можно использовать вместе с diff.

Мы уже видели, как просматривать историю конкретных частей или строк в файла с помощью git log. Было бы удобно делать нечто подобное, например, стейджинг частей файлов, правда? И такое легко делается в в IDE, например, в IntelliJ; то же самое уже сложнее в git CLI, но, конечно же, по-прежнему возможно: в git add пропишите опцию --patch:

Команда открывает редактор, в котором отображается один "hunk" [кусок], представляющий собой кусок кода с несколькими отличающимися друг от друга строками в нём. Можно много чего сделать с этим куском, но самые важные опции это y принять изменения (делает стейджинг), n не принимать (не делать стейджинг) и e отредактировать кусок перед стейджингом (полный список опций здесь).

Когда закончите с интерактивным стейджингом, вы можете запустить git status, и увидите, что файл с частичным стейджингом находится в разделах "Changes to be committed:" и "Changes not staged for commit:". Кроме того, можно запустить git add -i (интерактивный стейджинг), а затем воспользоваться командой s (статус), которая покажет вам, какие строки находятся на стейджинге, а какие нет.

Исправление распространённых ошибок

Закончив со стейджингом, я (слишком) часто осознаю, что добавил то, чего добавлять не хотел. Однако на этот случай у git для файлов нет команды un-stage. Чтобы обойти ограничение, можно сбросить репозиторий командой git reset --soft HEAD somefile.txt. Вы также можете включить в git reset флаг -p, который покажет вам тот же UI, что и у git-add -p. Также не забудьте добавить туда флаг --soft, иначе вы сотрёте ваши локальные изменения!

Поменьше грубой силы

Теперь, когда мы закончили стейджинг, всё, что осталось, commit и push. Но что, если мы забыли что-то добавить или совершили ошибку и хотим исправить уже запушенные коммиты? Есть простое решение, использующее git commit -a и git push --force, но оно может быть довольно опасным, если мы работаем над общей веткой, например, master. Таким образом, чтобы избежать риска перезаписи чужой работы из-за того, что мы решили проблему грубой силой, мы можем воспользоваться флагом --force-with-lease. Этот флаг в отличие от --force запушит на изменения только в том случае, если за время работы никто не добавил никаких изменений в ветку. Если ветка была изменялась, код не будет отправлен, и этот факт сам по себе указывает на то, что перед отправкой кода мы должны выполнить git pull.

Правильное слияние веток

Если вы работаете над репозиторием, в котором участвует более одного разработчика, можно с уверенностью предположить, что вы работаете в отдельной ветке, а не в мастере. Это также означает, что рано или поздно вам придётся включить свой код в кодовую базу (главную ветку). Вполне вероятно, что, пока вы работали над своей веткой, кто-то другой уже добавил свой код в мастер, из-за чего ветка вашей функциональности отстаёт на несколько коммитов. Можно пойти напролом и выполнить слияние вашего кода в мастер с помощью git merge, но команда создаст дополнительный комммит слияния, а также, без необходимости на то, затруднит чтение истории и сделает её сложнее:

Подход гораздо лучше (не стесняйтесь спорить со мной по этому поводу, образно говоря, это та высота, на которой я готов умереть) заключается в том, чтобы сделать rebase ветки функции в master, а затем выполнить так называемую быструю перемотку (git merge --ff). Подход сохраняет историю линейной, читать такую историю легче, упрощается и последующий поиск коммитов с новым функционалом и коммитов виновников ошибок.

Но как нам сделать такой rebase? Можно выполнить rebase в его базовой форме с помощью git rebase master feature_branch, чего часто бывает достаточно (за этим следует push --force). Однако, чтобы получить от git rebase максимальную отдачу, также следует включить флаг -i, чтобы rebase был интерактивным. Интерактивный rebase удобный инструмент, чтобы, например, переформулировать, сжать или вообще очистить ваши коммиты и всю ветку. В качестве небольшой демонстрации мы можем даже сделать rebase ветки на саму себя:

Приём выше позволяет нам повторно применять последние 4 коммита и изменить их, получив полезный результат, например сжать одни коммиты и переформулировать другие:

Выше показан пример сеанса rebase. В верхней части показывается ветка перед перезагрузкой. Вторая часть фрагмента это список коммитов, представленных после запуска git rebase каждый из них можно выбрать, чтобы включить в работу (pick). Мы можем изменить действие для каждого из них, а также полностью переупорядочить коммиты. Как показано в третьем разделе примера, некоторые допустимые действия переформулирование (оно говорит git открыть редактор сообщений о коммите), сжатие коммита (объединяет коммиты в предыдущий) и исправление коммита: (исправление работает как сжатие, но при этом сбрасывает сообщение о коммите). После того как мы применим эти изменения и переформулируем изменённые коммиты, мы получим историю, которая показана на скриншоте выше, в его нижней части.

Если во время rebase вы столкнулись с каким-либо конфликтом, чтобы разрешить его, вы можете запустить git mergetool --tool=vimdiff, а затем продолжить rebase с помощью git rebase --continue. git mergetool может быть вам не знаком, на первый взгляд он может показаться пугающим. В действительности же это то же самое, что IDE вроде IntelliJ, просто в стиле Vim. Если вы не знаете хотя бы несколько сочетаний клавиш Vim, то, как и в случае с любым другим использующим этот редактор инструментом, вам, может быть, трудно даже понять, на что на самом деле вы смотрите. Если вам нужна помощь, я рекомендую прочитать эту исчерпывающую статью.

Если всё это кажется слишком сложным или вы просто боитесь работать с rebase, в качестве альтернативы создайте пул реквест на GitHub и нажмите кнопку Rebase and merge, чтобы сделать, по крайней мере, простые и быстрые rebase и merge с быстрой перемоткой.

Главное эффективность

Я думаю, что примеры выше показали несколько изящных советов и хитростей, но всё это может быть довольно сложно запомнить, особенно когда дело касается команд вроде git log. К счастью, чтобы разрешить эти трудности, можно воспользоваться глобальной конфигурацией git. Она находится в ~/.gitconfig и обновляется каждый раз, когда вы запускаете git config --global. Даже если вы не настраивали этот файл, он, вероятно, содержит кое-какие базовые вещи, такие как раздел [user], но можно добавить много других разделов:

Выше приведён пример некоторых из доступных опций конфигурации. Примечательно, что длинная команда git log это только псевдоним git graph. Автокоррекция установлена 10: такое значение включает её и заставляет ждать 1 секунду, прежде чем выполнить правильную команду, в которой была опечатка, и, наконец, последний раздел подписывание коммита GPG (подробнее об этом читайте ниже).

Настройка .gitconfig с кучей алиасов требует отдельной статьи. Есть довольно много хороших ресурсов и примеров того, что можно прописать в .gitconfig, поэтому вместо полного списка всех опций и псевдонимов я оставлю ссылки:

• https://github.com/jessfraz/dotfiles/blob/master/.gitconfig

• https://gist.github.com/pksunkara/988716

• https://github.com/mgedmin/dotfiles/blob/master/gitconfig

Автозавершение команд это инструмент не менее продуктивный, чем псевдонимы, и он просто устанавливается:

Extras

Можно не только писать свои псевдонимы, но и взять на вооружение плагин git-extras, он вводит много полезных команд, которые могут немного упростить вам жизнь. Я не буду вдаваться в подробности обо всех возможностях этого плагина посмотрите список команд, а я просто покажу один краткий пример из этого списка прямо здесь:

• git delta список файлов, которые в другой ветке отличаются.

• git show-tree древовидное представление коммитов всех ветвей, похожее на показанный ранее git log.

• git pull-request пул-реквест в командной строке.

• git changelog генерирует журнал изменений (changelog) из тегов и сообщений в коммитах.

Конечно, это не единственный крутой плагин. Например, есть ещё один удобный инструмент, позволяющий открыть репозиторий в браузере прямо из командной строки. Кроме того, в приглашении терминала можно настроить статус репозитория, это делается с помощью zsh или bash-it.

Подписываем коммиты

Даже если вы никогда не вкладывались в какой-либо проект Open Source, вы, вероятно, прокручивали историю коммитов такого проекта. В ней вы, скорее всего, видели значок подтверждённого (sign-off знак о правах на ПО), проверенного или подписанного коммита. Что это такое и зачем?

Первый значок используется, когда автор подтверждает, что соответствующий код написал именно он, или же значком вы подтверждаете, что, насколько вам известно, он был создан на основе соответствующей лицензии Open Source. Это делается по юридическим причинам, которые связаны со статусом авторских прав на код. Обычно вам не нужно пользоваться этим значком, но, если вы в какой-то момент захотите внести вклад в проект, который требует подтверждения прав, знак подтверждения ставится так:

Сверху видно, что в git commit с опцией --sign-off в конце сообщения о коммите автоматически добавляется строка Signed-off-by: , которая формируется на основе вашего имени пользователя в конфигурации git.

Что касается значка signed/verified, который вы, вероятно, заметили в некоторых репозиториях, он существует, потому что на GitHub довольно легко выдавать себя за других пользователей. Всё, что вам нужно сделать, изменить имя сделавшего коммит человека и электронную почту в вашей конфигурации и отправить изменения. Чтобы предупредить ситуацию, вы можете подписывать коммиты с помощью ключей GPG, подтверждающих, что автор коммита и отправитель изменений на самом деле является тем, за кого он себя выдаёт. Подпись коммита более распространена, чем подтверждение прав, поскольку важно знать, кто на самом деле внёс код.

Если вы хотите начать пользоваться этой функцией или, возможно, хотите внедрить её в вашей команде, можно сделать следующее:

Сначала вы генерируете пару ключей GPG (если у вас её ещё нет), затем устанавливаете ключи при помощи git config и, наконец, добавляете опцию -S, когда делаете коммит. Затем, посмотрев на информацию о коммите на GitHub, вы увидите значок, как на картинке ниже.

Однако, как видно на изображении, подпись не проверена, потому что GitHub не знает, что ключ GPG принадлежит вам. Чтобы это исправить, открытый ключ из нашей пары ключей нужно отправить на GitHub. Для этого экспортируем ключ командой gpg --export, как здесь:

Затем скопируйте этот ключ и вставите его в поле https://github.com/settings/gpg/new. Если вы проверите ранее подписанный коммит после добавления ключа, то увидите, что коммит теперь проверен (verified). Здесь предполагаем, что вы добавили на GitHub именно тот ключ, которым подписывали коммит:

Заключение

Git очень мощный инструмент, у которого слишком много подкоманд и опций, чтобы в одной статье описать их все. Если вы хотите глубже погрузиться в некоторые связанные с Git темы, я бы порекомендовал прочитать Debugging with Git, чтобы узнать больше о blame, bisect или Getting solid at Git rebase vs. merge, чтобы глубже понять rebase и merge. Помимо множества полезных статей в Интернете часто при поиске информации о некоторых тонкостях git лучший выбор это мануал, который выводится опцией --help, или версия в сети.

Узнайте подробности, как получить Level Up по навыкам и зарплате или востребованную профессию с нуля, пройдя онлайн-курсы SkillFactory со скидкой 40% и промокодомHABR, который даст еще +10% скидки на обучение.

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering