gnupg: Ошибки при попытке gpg --gen-key
Я разместил этот вопрос более года назад и никогда не был полностью удовлетворен отсутствием окончательной документации. Я подумал, что снова проверю документацию Linux на наличие обновлений, и был счастлив увидеть это :
Абстрактные сокеты
Разрешения на сокеты не имеют значения для абстрактных сокетов: процесс umask (2) имеет не влияет на привязку абстрактного сокета, а изменение владельца и разрешений объекта (через fchown (2) и fchmod (2)) не влияет на доступность сокета.
Абстрактные сокеты автоматически исчезают, когда все открытые ссылки на сокет закрываются.
Кроме того, Интерфейс программирования Linux , автор Майкл Керриск , охватывает этот вопрос (перекрестная ссылка из , этот другой ответ ):
57.6 Краткое изложение Linux Пространство имен сокетов
Так называемое абстрактное пространство имен - это особенность Linux, которая позволяет нам привязать сокет домена UNIX к имени без создания этого имени в файловой системе. Это дает несколько потенциальных преимуществ:
- Нам не нужно беспокоиться о возможных конфликтах с существующими именами в файловой системе.
- Нет необходимости отключать путь к сокету, когда мы закончили использовать сокет. Абстрактное имя автоматически удаляется при закрытии сокета.
- Нам не нужно создавать путь в файловой системе для сокета. Это может быть полезно в среде chroot или если у нас нет доступа на запись в файловую систему.
Чтобы создать абстрактную привязку, мы указываем первый байт поля sun_path как нулевой байт (\ 0). [...]
Я считаю, что вместе с ответом @ user3188445 это очень точно проясняет вопрос.
Тем не менее, здесь все еще сделано предположение, что все открытые сокеты для процессов SIGKILL будут закрыты. Это кажется разумным предположением, но у меня нет документации, определяющей такое поведение.
У меня была такая же проблема. Важно понимать, что существуют две основные версииGnuPG («классическая» и «стабильная», а также существует «современная» 2.1): gpgи gpg2(в Fedora Core они предоставляются пакетами gnupgи gnupg2соответственно).
Я долго искал в Интернете информацию о trustdb, удалил ~/.gnupg, но нашел очень мало информации, и это не помогло.
Поскольку в репозитории моей ОС была старая версия gpg, я скачал с официального сайта «современную» gpg. Была проблема с libgrypt, мне нужно было установить более новую версию библиотеки для работы gpg. Когда я сделал это вручную, моя система вообще отказалась загружаться. Думаю скоро исправлю, но сейчас работаю с другого ноута.
Наконец я понял, что есть пакет gnupg2, и использовал команду gpg2вместо gpg. Это работало безупречно.
Вы можете установить bash псевдоним gpg=gpg2в своем .bash_profile, если хотите вообще забыть о числах.
Я столкнулся с похожей проблемой, когда поиск _в хеш-таблице завершился сбоем из-за Unknown system error.
Я полагал, что это произошло после импорта закрытого ключа через gpg (, а не через gpg2 )с использованиемgpg --allow-secret-key-import --import private.key
После установки уровня доверия после этого поста ошибка исчезла.