GPG в убунту в Иксах. Делюсь опытом
Итак, поскольку постоянно обращаться к консоли при попытке прочесть чью-нибудь подпись несколько утомительно, я решил это немного автоматизировать. Успешным опытом чего собираюсь поделиться.
- Создаём дефолтный .xbindkeysrc:
- Для того чтобы выводить окно с результатом проверки на экран я использую gmessage. Если его нет – установить с помощью atp-get
- Для работы с клипбордом использую xclip. Если его нет – установить с помощью atp-get
- Редактируем .xbindkeysrc добавив в него следующее:
- Проверим что xbindkey запускается при старте X-сессии. В Убунту это так по дефолту.
Все. Теперь для проверки чьей-либо подписи просто выделяем текст мышью и жмем Ctrl-~ (Контрл-тильду). Появится окно с результатом проверки.
Я сделал то же самое для того чтобы аттачить свою подпись к выделенному фрагменту. Для этого добавим в .xbindkeysrc следующее:
Как видим, потребуется еще программа xte. Она позволяет генерировать события в X, в данном случае ее вызов аналогичен нажатию на кнопки Shift-Ins, что то же самое что вставка из буфера обмена. Теперь по нажатию Ctrl-1 выделенный текст будет заменяться на такой же, но подписанный. CAFC2EEE – это ID моего ключа. Соответственно, заменить на свой.
Следует учесть, что Убунту по дефолту запускает xbindkey когда gpg-agent еще не запущен. В этом случае он не сможет расшифровать секретный ключ для подписи на лету. Чтобы это все работало, надо запретить его старт автоматом из Xsession.d Для этого создаем пустой файл в хоумдире с именем .xbindkeys.noauto Теперь xbindkey не запускается сам. Запускаем его либо ручками после запуска сессии, либо добавив его в список автозапускающихся программ. Для этого служит утилита Startup Applications
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 1515 документов: 44 редакций: 5786
Вообще, это странно. Обычно, если порядок опций нарушен, gpg ругается, с чем я периодически сталкивался.
IMHO, достаточно зашифрованный файл попытаться расшифровать как gpg -vvv -d file, и сразу всё базовое будет видно (страховка от отправки незашифрованным).
Если за безопасно настроенную систему посадить пользователя, который клал на безопасность, безопасность улетучивается. Точно так же и для стратегических объектов: не так важно, как оно организовано, если во главе звена стоит человек, который не соблюдает технику безопасности.
Как сказали бы математики, безопасность — это предел, который за конечное число членов последовательности достигнут быть не может, но к нему можно подойти с любой наперёд заданной точностью (вопрос лишь в цене взятия этих дополнительных членов) :)
Имелся в виду суп из подходов: разные виртуалки, разные физические машины, запуск от разных пользователей, разные иксы, разные настройки; всякие jail'ы могут пригодиться и т.п.
комментариев: 1060 документов: 16 редакций: 32
Кстати, злополучная команда сохранилась? Вполне вероятно, что вы баг какой-то нашли :)
комментариев: 1515 документов: 44 редакций: 5786
комментариев: 9796 документов: 488 редакций: 5664
Да, удалось разобраться. Это не баг и не то чтобы фича. В команде присутствует --sign, а опцию --encrypt в конце забыл просто скопировать и вставить в нужное место, в таком виде и оставил в скрипте. При этом наличие опций --encrypt-to и --hidden-recipient просто тихо игнорируется, gpg не выдаёт никаких сообщений вида: "вы уверены, а зачем вам эти опции, если мы ничего не шифруем, может забыли поставить --encrypt?"
Вот немного изменённая версия с помощью стандартных средств убунту, без xbindkey:
- sudo apt-get install xsel xautomation
cat > "$HOME/signx" <<EOF#!/bin/sh
xte 'keydown Control_L' 'key a' 'keyup Control_L'
xsel -o | gpg --no-tty -a --no-emit-version -s | head -c -1 | xsel -ib
xte 'keydown Control_L' 'key v' 'keyup Control_L'
xsel -c
xsel -bc
EOF
Проверьте для теста в лоб, как написано в инструкции, для начала. Я сейчас перепроверил с двумя графическими терминалами под одними и теми же иксами, когда в одном терминале запускается xev, а в другом уже сделано su -l root (ещё до запуска xev) и производится ввод пассфразы для шифрования gpg симметричным ключом. Т.е. рут шифрует файл, вводит пароль, а юзер этот пароль записывает в FILE. Например, нажатые символы qw отображаются в FILE как
Давайте по порядку, может я тупой.
1. Запускаю две сакуры (Sakura – эмулятор терминала)
2. В одной пишу su -l root
3. Там же пишу gpg -c .rnd
4. Иду в другую сакуру, пишу xwininfo | grep "Window id", получаю
5. Там же ввожу xev -id 0x3a00004
6. Иду в первый терминал, начинаю вводить пароль
7. Получаю:
И т.д. (надеюсь нигде не спалился :) Причем вот эти PropertyNotify event – именно при нажатии на клавиши появляются.
Ах да, ось конечно далеко не бубунта, но линух. И в файл я не пишу, смотрю все в терминале. Отличий вроде больше нет.
...
Ладно, гружу в VirtualBox Tails, чтоб типа эталон был. Делаю все тоже самое, так вот там на нажатия клавиш вообще никакой реакции от xev.
После запуска xwininfo щёлкаете по выбранному окну (тому, где запущено gpg -c .rnd)?
А если просто, т.е. без всяких ssh и su? Один терминал с xev может ловить нажатия клавиш, которые происходят в другом терминале под тем же юзером?
Может быть, указанное поведение как-то отключается в настройках иксов и в Tails и/или новых версиях иксов отключено. Пусть другие читатели форума проверят. Unknown, у вас работает?
комментариев: 9796 документов: 488 редакций: 5664
Естественно, иначе откуда бы реакция на нажатия.
То же самое.
Короче, можно юзать su и sudo, я понял :)