Регистрация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
Вообще, лучше не делать заявлений, а погуглить и разобраться, почему на одних системах это работает, а на других нет. Анонимность/безопасность наугад — плохой метод.
Ничего не понял в этом хамстве и мате (если это мне).
Ещё раз, если кто не понял: описанное свойство есть, наблюдается не только у меня. Если в каких-то системах оно не работает, то не стоит неосмотрительно кидаться в крайность «всё хорошо, мне ничего не грозит». Может так оказаться, что всё же «грозит», но для этого надо использовать другие команды/интерфейсы. Если где-то в одном месте работает, а в другом — нет, нужно разобраться почему, что вызывает разницу. Только после этого можно быть уверенным в том, что оно безопасно от таких трюков.
Форум публичный, никто никому не обязан, и я не должен рыть землю, только чтобы дать исчерпывающий ответ на то, почему у кого-то где-то оно не сработало. Потрудитесь разобраться сами и написать ответ здесь. Если позже у меня возникнет понимание, из-за чего такое может прозойти, отпишусь, но личного интереса гуглить эту тему и вникать сейчас нет. К тому же, su/sudo — не единственные способы обхода механизма. Если юзер потнециально скомпрометирован, в любом случае нельзя дать никакой гарантии.
P.S. Есть у sudo ещё и такая тонкость, как подцепление переменных из текущего шелла, что может быть легко использовано для компрометации. Чтобы этого избежать, советуют писать su -l username или su -- (не помню, один там минус или два должно быть).
комментариев: 9796 документов: 488 редакций: 5664
Проверка базы — это взаимная верификация подписей на ключах, которая действительно занимает очень много времени при большой связке, поэтому результаты кэшируются, а сама эта проверка для обновления кэша запускается с определённой периодичностью (не устарели ли подписи? и др.) и, возможно по ещё каким-то критериям. Но, по идее это чисто оффлайновая процедура.
Иногда работает, иногда – нет. Так, если я запускаю через gksu gnome-terminal под другим юзером, xev ни с одной, ни с другой стороны не показывает вводимые в нем знаки (хотя вскую лабуду показывает, не связанную с клавиатурой, не совсем понимаю, что это, типа такого:
xev под "родным" терминалом тоже не видит букв, например, что я ввожу сейчас в этой форме.
А вот если запустить скайп из-под одного юзера в другом, xev в терминале первого видит все буквы, вводимые в окошке скайпа.
Как это объяснить?
P.S. Что-то странное, не получается залогиниться в другого юзера на локальной машине через ssh (и с X-форвардингом, который включен, и без):
Хотя с удаленных машин логинюсь. Туплю что-то. Вроде никаких специальных настроек раньше не требовалось...
комментариев: 11558 документов: 1036 редакций: 4118
ssh -v поможет в отладке.
– настройки фаервола (прозрачной торификации) мешают.
Сейчас попробовал, между незаторенными юзерами все нормально проходит.
P.S. Если открыть возможность локального коннекта между прозрачно заторенными юзерами – это будет "дыра"? Или лучше локально gksu использовать, если не очень критично?
А если открыть возможность внутрисетевого (в домашней сети, где все компы как бы доверенные, если сетку не ломанули, конечно) – насколько большая получиться дыра?
Критично или нет — понятие растяжимое. Кому-то критично до такой степени, что параметры машины пытаются замаскировать, запуская ОС в вирталке. Если оба юзера прозрачно торифицированы, то, казалось бы, можно сделать между ними связь, но раз их два, а не один, отличие между ними есть. Например, с каждым юзером может быть связан свой профиль, а смешивание профилей быть нежелательным. В этом случае наличие прямого коннекта от одного юзера к другому облегчает атаку на связывание профилей.
В идеале торифицированные юзеры
- Не должны ходить куда-либо в обход Tor, даже локально.
- Работать в ОС, которая должна откатываться в предыдущее «чистое» состояние после каждой рабочей сессии.
- Не должны иметь доступ к параметрам железа и файлам той ОС, под которой ведётся неанонимная работа.
Каждый может ослаблять эти общие правила для себя в зависимости от паранои и резонности.А как это сделать? Первый пункт решается настройкой Privoxy\Polipo, третий тоже более-менее ясен. Скажите, а как быть со вторым пунктом.
Как все сложно!!!
Говорят, можно пострелять себе в т.ч. в ногу, если сильно хочется, но я бы не пользовался так называемым выборочным цитированием, как вы это пытаетесь. Если вы про это, то