Re: Публикация GPG-ключей

2020-06-15 Пенетрантность Sergey Matveev
*** 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-ключей

2020-06-14 Пенетрантность neo
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-ключей

2020-06-14 Пенетрантность Tim Sattarov
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-ключей

2020-06-14 Пенетрантность Tim Sattarov
On 2020-06-14 13:02, Sergey Matveev wrote:
> Я ещё раз резюмирую: без разницы как и откуда вы по Интернету получили
> публичный ключ корреспондента -- доверие по любому методу получения
> одинаковое. 
А вот кстати, что благородные доны думают про keybase.io?



Re: Публикация GPG-ключей

2020-06-14 Пенетрантность Sergey Matveev
*** 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 

Re: Публикация GPG-ключей

2020-06-14 Пенетрантность Dmitry Alexandrov
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-ключей

2020-06-14 Пенетрантность Sergey Matveev
*** 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-ключей

2020-06-14 Пенетрантность Sergey Matveev
*** 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-ключей

2020-06-14 Пенетрантность Dmitry Alexandrov
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-ключей

2020-06-14 Пенетрантность Sergey Matveev
*** 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-ключей

2020-06-13 Пенетрантность Dmitry Alexandrov
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:;)

2020-06-13 Пенетрантность Tim Sattarov
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:;)

2020-06-13 Пенетрантность Dmitry Alexandrov
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