Re: keybase.io (was: Публикация GPG-ключей)
Tim Sattarov wrote: > А вот кстати, что благородные доны думают про keybase.io? А что именно думать? Если в контексте ветки, то ничего — по UIDʼу там найти ключ нельзя. А вообще: очередная собственническая социальная сеточка, коих не счесть: от Линкедина до (прости господи) Тиктока — у каждой должна быть какая-то «изюминка», иначе непонятно, в чем отличие от Фэйсбука. Ну вот эти решили заработать имя и набрать начальную пользовательскую базу на верификации PGP ключей — отсюда и название. Потом запилили мессенджер, провозгласив себя «безопасной» альтернативой Слаку (это, если что, еще одна собственническая сеточка для групповых чатов по служебным нуждам), но что-то не взлетело, — и теперь уже они, кажется, сами толком не понимают, что́ конкретно они собой представляют. signature.asc Description: PGP signature
Re: Публикация GPG-ключей
*** Tim Sattarov [2020-06-14 22:20]: >А вот кстати, что благородные доны думают про keybase.io? Лично я особо ничего не могу про него сказать, так как с ходу даже не помнил что именно это за ресурс. Ну ещё один способ получить ключ, с которым связаны всякие сторонние ресурсы. Не знаю что сказать :-). Не все захотят разглашать о себе свои связи между различными ресурсами, кто не против, то почему бы и нет. Но лично я не припомню чтобы оттуда загружал чьи-либо публичные ключи. Да и свой загружать туда смысла нет, ибо я мало на каких ресурсах имею имею учётные записи, поэтому связанных identities, кроме личного домена и подобных, не будет. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: Публикация GPG-ключей
On Monday, 15 June 2020 05:20, Tim Sattarov wrote: > On 2020-06-14 13:02, Sergey Matveev wrote: > > > Я ещё раз резюмирую: без разницы как и откуда вы по Интернету получили > > публичный ключ корреспондента -- доверие по любому методу получения > > одинаковое. > > А вот кстати, что благородные доны думают про keybase.io? Я не благородный дон, но ещё до покупки этого сервиса компанией Zoom скептически к ним относился. Зачем давать всем пользователям облако на 250 Гб бесплатно? Они за несколько лет так и не смогли придумать бизнес модель и ввести платные услуги, [1] предпоследний абзац. [1] https://book.keybase.io/docs/files signature.asc Description: OpenPGP digital signature
Re: Публикация GPG-ключей
On 2020-06-14 01:54, Dmitry Alexandrov wrote: > Так в Дебиане он теперь (вопреки апстриму) и прописан [1]. А вот у вас, судя > по выводу ниже, как раз старый SKS-пул — то ли это у вас Дебиан старый > (старше 10-го), то ли вы ванильный GPG собрали, то ли таки на уровне > пользователя поменяли. то ли у меня просто gpg.conf пару лет не менялся > > И, упаси боже, это никак не надо понимать как рекомендацию настраиваться на > keys.openpgp.org как на основной. Но в ‘auto-key-locate’ добавить не > помешает, да: > > # keyserver here stands for the default keyserver, as specified in > # dirmngr.conf. Namely, one of entrypoints to the old SKS pool. > Specified the > # last as keyserver.ubuntu.com carries most of its content. > auto-key-locate cert dane pka wkd hkps://keyserver.ubuntu.com > hkps://keys.mailvelope.com hkps://keys.openpgp.org keyserver > Спасибо, попробую >> вот кстати сейчас он вполне даже нашёл твой ключ, похоже, что-то >> синхронизировалось или ты его догрузил :) >> 10:32 $ gpg -v --receive-keys 0xC8B0F8548EE7F3E7 >> gpg: data source: https://192.146.137.140:443 >> gpg: armor header: Version: SKS 1.1.6 >> gpg: armor header: Comment: Hostname: pgpkeys.uk >> gpg: pub ed25519/C8B0F8548EE7F3E7 2020-05-04 Dmitry Alexandrov >> >> gpg: key C8B0F8548EE7F3E7: "Dmitry Alexandrov " not changed >> gpg: Total number processed: 1 >> gpg: unchanged: 1 > Ну, отсюда как раз недвусмысленно следует, что что у вас и раньше таки был. > ;-) Если Enigmail не нашёл, значит не было. Но это уже не важно так как ключ уже появился. А то каждый раз тормозит на открытии твоих писем.. >>> Позвольте полюбопытствовать: а сколько вы так ключей накопили? >> неважно сколько ключей, > Позвольте, но откуда вы знаете, что мне важно, а что — нет? Понятия не имею, что для тебя важно, а что нет. Речь про скорость обработки и влияние (важность) количества ключей для оной. > > В свое время, раздумывая, не включить ли мне этот ‘auto-key-retrieve’, я > отказался от этой идеи именно потому, что не хочу видеть в ключнице кучу > людей, про которых вообще ничего могу сказать даже приблизительно — кто это > такие и где я их письма мог встречать. Возможно, это глупость; ну да ладно... Я GPG не только для писем использую. GPG в почтовой переписке сейчас это больше развлечение. На мой взгляд ничего оно не гарантирует, если только нет договорённости с корреспондентом и большого желания "всё зашифровать".
Re: Публикация GPG-ключей
On 2020-06-14 13:02, Sergey Matveev wrote: > Я ещё раз резюмирую: без разницы как и откуда вы по Интернету получили > публичный ключ корреспондента -- доверие по любому методу получения > одинаковое. А вот кстати, что благородные доны думают про keybase.io?
Re: Публикация GPG-ключей
*** Dmitry Alexandrov [2020-06-14 19:25]: >А от кого бы вы хотели защититься? Это вы начали говорить про X.509 и что у вас WKD из-за trust anchor-а не сработал. А я говорю что доверие в обоих случаях одинаковое и поэтому какая разница сошёлся у вас trust anchor для X.509 сертификата TLS или нет. >> WKD с недоверенным trust anchor-ом (как в вашем случае) >Пардон? В чём вопрос? >Как вы понимаете, есть всего два потенциально реальных злоумышленника — ваш >почтовый (жабберный, виртуальной машины и т. д.) провайдер и провайдер вашего >корреспондента. Интересно кто это так решил и ограничил злоумышленника всего этими двумя случаями. >Так вот, WKD в большинстве случаев находится в руках одного из них. То есть >его можно и нужно сравнить скорее с отправкой ключа по тому же каналу, который >и собрались шифровать. Прибавляет удобства, но не доверия. Я повторю: во всех случаях, как бы вы не получили ключ, доверия это не может добавлять. Доверие вы должны по WoT-у определять или заранее где-то узнавая например отпечаток ключа. WKD это исключительно про удобство его получения, не более. Если факт получение ключа от третьих лиц вам добавляет доверие к ключу -- ну, ok, вам добавляет, а бы нисколько. И мне не хочется чтобы ещё одни третьи лица знали про факты связи людей между собой (интересуются ключами друг друга -- наверное хотят связаться). >> И в том и в другом случае вы наверняка будете использовать WoT... >...для которой на практике нужен публичный кейсервер в том или ином виде. Это с чего вы взяли? >И да, вы не могли бы назвать хотя бы один домен, что его использует? ;-) https://wiki.gnupg.org/WKD в самом низу. Плюс куча персональных доменов людей, типа моего. >Обнародовать ключ на распределенной, а значит неподконтрольной никому >конкретному платформе — _единственный_ реально возможный вариант. >Альтернативой мог быть быть, например, блокчэйн, но никак не централизованная >WKD. >Наличие ключа — контролируете во много большей степени, чем с WKD на >общественном домене, и пожалуй даже в большей степени, чем с WKD на вашем >личном домене. >А отсутствие — да, не контролируете. И никто не контролирует. В этом-то и >вся фишка. >Почему же «не говоря»? Говоря про WKD и DNS вы необходимость удостовериться в >подлинности ключа упомянули, а здесь — не станете? ;-) Не понимаю что вы тут говорите про контроль ключа. С ключевых серверов я не могу удалить свой ключ. Я не могу удалить "лишние" подписи и UID-ы. О каком контроле тут идёт речь? А с WKD -- что выложил, то и лежит. С ключевыми серверами частая проблема в том, что люди любят без спросу на них выкладывать ваши ключи (например связанные с работой) или подписывать ваш ключ и публиковать это без спросу. Согласен что это не проблема ключевых серверов как таковая, а это вопрос этики, уважения, воспитанности и грамотности людей, но... keyserver даёт возможность легко нагадить человеку, а с WKD вы сами контролируете что публикуется. Я ещё раз резюмирую: без разницы как и откуда вы по Интернету получили публичный ключ корреспондента -- доверие по любому методу получения одинаковое. Возможно, факт получения ключа И через CA TLS-authenticated WKD, И через DNSSEC DANE запись, И через hkps может и увеличит доверие, но всё это powerful adversary может атаковать. Доверять вы можете или надёжно полученному отпечатку или по WoT. Выбор между keyserver, WKD, DANE, whatever -- это выбор исключительно удобства получения ключа. Зная UID (email) -- вы знаете как долбануться до WKD, удобно, без привлечения третьих лиц, без мусора в ключе (что выложил, то и получишь). >Мне кажется, выше удалось наглядно показать, что «геморройно» (а для >«конечного пользователя» и просто невозможно) получить ваш ключ как раз из >подконтрольной вам WKD. Тогда как с кейсервера — легко и непринужденно. Геморрой тут добавил не я, а авторы WKD, обязывающие использовать PKI. Ничего с ними я тут не могу поделать. С ключевым сервером аналогично геморрой: как вы сможете узнать какой именно KS, какую именно "сеть" KS использовать для того чтобы узнать мой ключ? Я могу загрузить на KS сервер который не связан с вашими предпочитаемыми. Ориентироваться на централизованную точку в руках третьих лиц? Вы серьёзно? Плюс, сливать в эту централизованную (стремящуюся быть такой одной, единственной) сеть факты связи со мной (раз запросили мой ключ, то хотите связаться наверное). Плюс иметь шанс получить в довесок к моему ключу, ещё и много десятков килобайт мусора (подписей непойми кем проставленных) или устаревших UID-ов. Нет, спасибо, но этой KS помойки, не нужно. Мне кажется за последние лет пять все ключи которые я получал, то небольшую часть получал через WKD/DANE, а всё остальное через поиск домашней странички человека и нахождения там инструкций по получению ключа. Да, иногда все ссылки ведут на ключевой сервер и наверное 80% времени когда я долблюсь до KS-ов, то они не отвечают, выдают ошибки и, возможно у меня какая-нибудь корявая версия dirmngr, но зачастую помогает только killall dir
Re: Публикация GPG-ключей
Sergey Matveev wrote: > *** Dmitry Alexandrov [2020-06-14 14:48]: >>Да вот чтобы далеко не ходить — возьмем хотя бы вас. Откуда я могу ваш ключ >>получить без проблем, как не с кейсервера? Из WKD? А вот шиш: WKD, как вы >>совершенно справедливо пишете, опирается X.509, а ваша директория подписана >>самопальным сертификатом: > > Keyserver -- ничем не защищённый источник А от кого бы вы хотели защититься? > WKD с недоверенным trust anchor-ом (как в вашем случае) Пардон? > точно такой же недоверенный источник. Но так или иначе — нет, определенно не точно такой же. Как вы понимаете, есть всего два потенциально реальных злоумышленника — ваш почтовый (жабберный, виртуальной машины и т. д.) провайдер и провайдер вашего корреспондента. Так вот, WKD в большинстве случаев находится в руках одного из них. То есть его можно и нужно сравнить скорее с отправкой ключа по тому же каналу, который и собрались шифровать. Прибавляет удобства, но не доверия. Тогда как кейсервер (даже проприетарный), как правило, находится в каких-то других руках. > И в том и в другом случае вы наверняка будете использовать WoT... ...для которой на практике нужен публичный кейсервер в том или ином виде. > Плюс из DANE можно достать ещё попробовать, который возможно "защищён" > DNSSEC-ом... ...от подделки, но не от прослушивания. Ну а по существу — та же самая незадача, что и с WKD. И да, вы не могли бы назвать хотя бы один домен, что его использует? ;-) > Всё это методы получения ключа, не более. Точно так. Тогда как кейсервера по меньшей мере задумывались как нечто большее. > Keyserver не вариант Не вариант чего? Обнародовать ключ на распределенной, а значит неподконтрольной никому конкретному платформе — _единственный_ реально возможный вариант. Альтернативой мог быть быть, например, блокчэйн, но никак не централизованная WKD. > я не контролирую что там за ключ Наличие ключа — контролируете во много большей степени, чем с WKD на общественном домене, и пожалуй даже в большей степени, чем с WKD на вашем личном домене. А отсутствие — да, не контролируете. И никто не контролирует. В этом-то и вся фишка. > Не говоря про загрузку ключей с такими же UID-ами как и у меня Почему же «не говоря»? Говоря про WKD и DNS вы необходимость удостовериться в подлинности ключа упомянули, а здесь — не станете? ;-) > конечному пользователю, пытающемуся получить мой ключ, это только геморрой. > А DANE, WKD -- это то, что под моим контролем. Мне кажется, выше удалось наглядно показать, что «геморройно» (а для «конечного пользователя» и просто невозможно) получить ваш ключ как раз из подконтрольной вам WKD. Тогда как с кейсервера — легко и непринужденно. signature.asc Description: PGP signature
Re: Публикация GPG-ключей
*** Dmitry Alexandrov [2020-06-14 14:48]: >(Да и вообще, мне казалось, что SRV указатели типа >_openpgpkey._tcp.stargrave.org из стандарта выкинули, не?) Похоже и "wkd." нету тоже теперь и вместо него "openpgpkey.": https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-09 https://wiki.gnupg.org/WKDHosting -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: Публикация GPG-ключей
*** Dmitry Alexandrov [2020-06-14 14:48]: >Да вот чтобы далеко не ходить — возьмем хотя бы вас. Откуда я могу ваш ключ >получить без проблем, как не с кейсервера? Из WKD? А вот шиш: WKD, как вы >совершенно справедливо пишете, опирается X.509, а ваша директория подписана >самопальным сертификатом: Keyserver -- ничем не защищённый источник (возможно PKI). WKD с недоверенным trust anchor-ом (как в вашем случае): точно такой же недоверенный источник. И в том и в другом случае вы наверняка будете использовать WoT для решения можно ли доверять полученному ключу. Плюс из DANE можно достать ещё попробовать, который возможно "защищён" DNSSEC-ом, и точно также всё равно потребует WoT например. Всё это методы получения ключа, не более. Некоторые дополнительно могут предоставлять какие-то trust anchor-ы от которых вы *возможно* сможете отталкиваться (PKI (CA для TLS, root в DNSSEC)). Keyserver не вариант: я не контролирую что там за ключ, какие подписи на нём -- любой может там поставить какую-нибудь подпись и загрузить на сервер. А мне не хочется отвечать за мусор там расположенный. Не говоря про загрузку ключей с такими же UID-ами как и у меня: конечному пользователю, пытающемуся получить мой ключ, это только геморрой. А DANE, WKD -- это то, что под моим контролем. >(Да и вообще, мне казалось, что SRV указатели типа >_openpgpkey._tcp.stargrave.org из стандарта выкинули, не?) Надо будет посмотреть. Если выкинули, то уберу за ненадобностью, поднимал то давно. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: Публикация GPG-ключей
Sergey Matveev wrote: > На тему разных вариантов получения ключей я как-то статью написал: > https://www.opennet.ru/tips/2986_pgp_gnupg_key_sign.shtml > *** Dmitry Alexandrov [2020-06-14 08:54]: >>Вернер Кох (мэйнтейнер GPG), когда весь этот бардак только начинался, мне >>вообще сообщил, что сервера ключей не нужны, и должны умереть как класс. > > Тоже поддерживаю эту идею что keyserver-а не нужны как класс. А что вместо? Статью я проглядел, она определенного ответа на этот вопрос не дает. Да вот чтобы далеко не ходить — возьмем хотя бы вас. Откуда я могу ваш ключ получить без проблем, как не с кейсервера? Из WKD? А вот шиш: WKD, как вы совершенно справедливо пишете, опирается X.509, а ваша директория подписана самопальным сертификатом: $ dirmngr WKD_GET stargr...@stargrave.org S SOURCE https://wkd.stargrave.org:443 dirmngr[2844.0]: number of system provided CAs: 126 dirmngr[2844.0]: TLS verification of peer failed: status=0x0042 dirmngr[2844.0]: TLS verification of peer failed: The certificate is NOT trusted. The certificate issuer is unknown. dirmngr[2844.0]: DBG: expected hostname: wkd.stargrave.org dirmngr[2844.0]: DBG: BEGIN Certificate 'server[0]': dirmngr[2844.0]: DBG: serial: 5E9AD0152F440F0D64C1A854 dirmngr[2844.0]: DBG: notBefore: 2020-04-18 10:01:57 dirmngr[2844.0]: DBG:notAfter: 2021-04-18 10:01:57 dirmngr[2844.0]: DBG: issuer: CN=ca.cypherpunks.ru,C=RU dirmngr[2844.0]: DBG: subject: CN=wkd.stargrave.org dirmngr[2844.0]: DBG: hash algo: 1.2.840.10045.4.3.4 dirmngr[2844.0]: DBG: SHA1 fingerprint: AE9E4633FD459F3B1ECA659FDDD0DC5CA6828515 dirmngr[2844.0]: DBG: END Certificate dirmngr[2844.0]: DBG: BEGIN Certificate 'server[1]': dirmngr[2844.0]: DBG: serial: 01 dirmngr[2844.0]: DBG: notBefore: 2020-04-18 09:34:23 dirmngr[2844.0]: DBG:notAfter: 2030-04-16 09:34:23 dirmngr[2844.0]: DBG: issuer: CN=ca.cypherpunks.ru,C=RU dirmngr[2844.0]: DBG: subject: CN=ca.cypherpunks.ru,C=RU dirmngr[2844.0]: DBG: hash algo: 1.2.840.10045.4.3.4 dirmngr[2844.0]: DBG: SHA1 fingerprint: DB25A14A2FCE82DA988CFE279AA41E93CB7314E5 dirmngr[2844.0]: DBG: END Certificate dirmngr[2844.0]: TLS connection authentication failed: General error dirmngr[2844.0]: error connecting to 'https://wkd.stargrave.org:443/.well-known/openpgpkey/hu/s8kd45yyt8ymu6uttefkjkngyagsui5x?l=stargrave': General error dirmngr[2844.0]: command 'WKD_GET' failed: General error ERR 1 General error (Да и вообще, мне казалось, что SRV указатели типа _openpgpkey._tcp.stargrave.org из стандарта выкинули, не?) signature.asc Description: PGP signature
Re: Публикация GPG-ключей
*** Dmitry Alexandrov [2020-06-14 08:54]: >GPG по-умолчанию WKD для retrievingʼа¹ вполне себе использует. В том числе, >емнип, и в Дебиане. На тему разных вариантов получения ключей я как-то статью написал: https://www.opennet.ru/tips/2986_pgp_gnupg_key_sign.shtml > >Вернер Кох (мэйнтейнер GPG), когда весь этот бардак только начинался, мне >вообще сообщил, что сервера ключей не нужны, и должны умереть как класс. Тоже поддерживаю эту идею что keyserver-а не нужны как класс. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: Публикация GPG-ключей
Tim Sattarov wrote: > On 2020-06-13 04:26, Dmitry Alexandrov wrote: >> Tim Sattarov wrote: >>> я вот тоже не в порядке придирки, если письмо подписывается GPG ключом, то >>> может выложить его куда нибудь уже >> Безотносительно того, что ниже, ключ есть в WKD. Как бы вы к ней лично не >> относились, но теперь дело такое, что если ваша GPG-совместимая утилита — >> будь это сама GPG, Openkeychain или еще какой-нибудь зверек — WKD >> игнорирует, то она, надо думать, мисконфигурирована. > Я использую стандартные средства Debian для работы с GPG/PGP, Gnupg и в почте > Enigmail. GPG по-умолчанию WKD для retrievingʼа¹ вполне себе использует. В том числе, емнип, и в Дебиане. Вернер Кох (мэйнтейнер GPG), когда весь этот бардак только начинался, мне вообще сообщил, что сервера ключей не нужны, и должны умереть как класс. - ¹ Зд.: получение ключей для проверки подписи, в противопоставление «locatingʼу» — получению ключей для шифрования, где, впрочем, тоже использует. >> Ну уж пардоньте, я не знаю, что у вас там за «the keyserver». На Hockeypuck >> в лице hkps://keyserver.ubuntu.com он есть. На старый SKS-пул я отправлял, >> но конкретно сейчас обратно получить действительно не могу — вылетает по >> таймауту, или, проще говоря, висит. Впрочем, он теперь в таком состоянии, >> что это совсем не удивительно. Так или иначе, благодарю за сигнал, я сейчас >> попробую его туда еще раз окольным путем как-нибудь запихнуть. >> >> А если у вас проприетарный сервис типа keys.openpgp.org вместо кейсервера, >> то уж нет, спасибо, пока обойдусь как-нибудь. > У меня то что по дефолту прописано в настройках. Так в Дебиане он теперь (вопреки апстриму) и прописан [1]. А вот у вас, судя по выводу ниже, как раз старый SKS-пул — то ли это у вас Дебиан старый (старше 10-го), то ли вы ванильный GPG собрали, то ли таки на уровне пользователя поменяли. И, упаси боже, это никак не надо понимать как рекомендацию настраиваться на keys.openpgp.org как на основной. Но в ‘auto-key-locate’ добавить не помешает, да: # keyserver here stands for the default keyserver, as specified in # dirmngr.conf. Namely, one of entrypoints to the old SKS pool. Specified the # last as keyserver.ubuntu.com carries most of its content. auto-key-locate cert dane pka wkd hkps://keyserver.ubuntu.com hkps://keys.mailvelope.com hkps://keys.openpgp.org keyserver [1] https://salsa.debian.org/debian/gnupg2/-/blob/debian/master/debian/patches/Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch > вот кстати сейчас он вполне даже нашёл твой ключ, похоже, что-то > синхронизировалось или ты его догрузил :) > 10:32 $ gpg -v --receive-keys 0xC8B0F8548EE7F3E7 > gpg: data source: https://192.146.137.140:443 > gpg: armor header: Version: SKS 1.1.6 > gpg: armor header: Comment: Hostname: pgpkeys.uk > gpg: pub ed25519/C8B0F8548EE7F3E7 2020-05-04 Dmitry Alexandrov > > gpg: key C8B0F8548EE7F3E7: "Dmitry Alexandrov " not changed > gpg: Total number processed: 1 > gpg: unchanged: 1 Ну, отсюда как раз недвусмысленно следует, что что у вас и раньше таки был. ;-) >>> А то каждый раз тормозит на открытии твоих писем.. >> Позвольте полюбопытствовать: а сколько вы так ключей накопили? > неважно сколько ключей, Позвольте, но откуда вы знаете, что мне важно, а что — нет? В свое время, раздумывая, не включить ли мне этот ‘auto-key-retrieve’, я отказался от этой идеи именно потому, что не хочу видеть в ключнице кучу людей, про которых вообще ничего могу сказать даже приблизительно — кто это такие и где я их письма мог встречать. Возможно, это глупость; ну да ладно... signature.asc Description: PGP signature
Re: Публикация GPG-ключей (was: To: undisclosed-recipients:;)
On 2020-06-13 04:26, Dmitry Alexandrov wrote: > Tim Sattarov wrote: >> я вот тоже не в порядке придирки, если письмо подписывается GPG ключом, то >> может выложить его куда нибудь уже > Безотносительно того, что ниже, ключ есть в WKD. Как бы вы к ней лично не > относились, но теперь дело такое, что если ваша GPG-совместимая утилита — > будь это сама GPG, Openkeychain или еще какой-нибудь зверек — WKD игнорирует, > то она, надо думать, мисконфигурирована. Я использую стандартные средства Debian для работы с GPG/PGP, Gnupg и в почте Enigmail. >>> The key with ID 0xC8B0F8548EE7F3E7 is not available on the keyserver. > Ну уж пардоньте, я не знаю, что у вас там за «the keyserver». На Hockeypuck > в лице hkps://keyserver.ubuntu.com он есть. На старый SKS-пул я отправлял, > но конкретно сейчас обратно получить действительно не могу — вылетает по > таймауту, или, проще говоря, висит. Впрочем, он теперь в таком состоянии, > что это совсем не удивительно. Так или иначе, благодарю за сигнал, я сейчас > попробую его туда еще раз окольным путем как-нибудь запихнуть. > > А если у вас проприетарный сервис типа keys.openpgp.org вместо кейсервера, то > уж нет, спасибо, пока обойдусь как-нибудь. У меня то что по дефолту прописано в настройках. вот кстати сейчас он вполне даже нашёл твой ключ, похоже, что-то синхронизировалось или ты его догрузил :) 10:32 $ gpg -v --receive-keys 0xC8B0F8548EE7F3E7 gpg: data source: https://192.146.137.140:443 gpg: armor header: Version: SKS 1.1.6 gpg: armor header: Comment: Hostname: pgpkeys.uk gpg: pub ed25519/C8B0F8548EE7F3E7 2020-05-04 Dmitry Alexandrov gpg: key C8B0F8548EE7F3E7: "Dmitry Alexandrov " not changed gpg: Total number processed: 1 gpg: unchanged: 1 ✔ ~ >> А то каждый раз тормозит на открытии твоих писем.. > Позвольте полюбопытствовать: а сколько вы так ключей накопили? неважно сколько ключей, важно, что он каждый раз безуспешно пытается скачать/проверить на сервере и из-за этого возникает задержка. я по работе активно использую разного типа шифрование и GPG в их числе, так что ключей у меня достаточно много.
Re: Публикация GPG-ключей (was: To: undisclosed-recipients:;)
Tim Sattarov wrote: > я вот тоже не в порядке придирки, если письмо подписывается GPG ключом, то > может выложить его куда нибудь уже Безотносительно того, что ниже, ключ есть в WKD. Как бы вы к ней лично не относились, но теперь дело такое, что если ваша GPG-совместимая утилита — будь это сама GPG, Openkeychain или еще какой-нибудь зверек — WKD игнорирует, то она, надо думать, мисконфигурирована. >> The key with ID 0xC8B0F8548EE7F3E7 is not available on the keyserver. Ну уж пардоньте, я не знаю, что у вас там за «the keyserver». На Hockeypuck в лице hkps://keyserver.ubuntu.com он есть. На старый SKS-пул я отправлял, но конкретно сейчас обратно получить действительно не могу — вылетает по таймауту, или, проще говоря, висит. Впрочем, он теперь в таком состоянии, что это совсем не удивительно. Так или иначе, благодарю за сигнал, я сейчас попробую его туда еще раз окольным путем как-нибудь запихнуть. А если у вас проприетарный сервис типа keys.openpgp.org вместо кейсервера, то уж нет, спасибо, пока обойдусь как-нибудь. > А то каждый раз тормозит на открытии твоих писем.. Позвольте полюбопытствовать: а сколько вы так ключей накопили? signature.asc Description: PGP signature
