[devel] I: возврат subkey в alt-gpgkeys

[Aleksey Avdeev]

Epiphanov Sergei пишет:
> В сообщении от Wednesday 12 July 2006 14:12 Aleksey Avdeev написал(a):
> 
>>Epiphanov Sergei пишет:
>>
>>>В сообщении от Wednesday 12 July 2006 12:59 Aleksey Avdeev написал(a):
>>>
>>>> Теоретически -- ничего не мешает. (И я не предлагаю ломать эту схему.)
>>>>Практически -- мне это не слишком удобно: начинал с такой схемы, но
>>>>умудрился в ключах запутаться... (Разруха она в головах, в данном случаи
>>>>-- в моей: мне проще иметь одни надёжные, походные, всепогодные ботинки,
>>>>чем каждый раз думать, какие будут погода и грунт на маршруте.)
>>>
>>>Аналогично будет и с подключами (аналогия: надеть галоши для луж,
>>>обёртки при
>>
>>                                             ^^^^^^^^^^^^^^^^^^^^^^
>>
>>
>>>входе в здание, ...).
>>
>>  Ну, выделенное не требуется: говорил о _хороших_ ботинках. :-)
> 
> 
> Всё равно , у нас в поликлиннике, в музее требуется надевать бахилы даже на 
> самые распрекрасные ботинки.

  Это есть. И этому есть железобетонное логичное объяснение.

> 
> 
>>>Так что надо лечить не следствие, а причину.
>>>
>>>
>>>> Просто, т. к. gpg допускает схему с подключами -- она должна работать
>>>>и для подписи пакетов. Иначе придётся как минимум её неработоспособность
>>>>у нас документировать. (И, возможно -- объяснять неработоспособность
>>>>подключай тем, кому их ненужность не очевидна.)
>>>
>>>Можно сказать по другому - внести в полиси для мантейнеров требование об
>>>использовании только ключей для подписи пакета. Мы же не обязаны
>>>выполнять все требования gpg. Также, как сейчас идёт переход на git,
>>>хотя нечто подобное можно сделать на svn, cvs. Точно такое же
>>>требование. Висят же на некоторых дверях "вход запрещён" и никто
>>>посторонний туда не входит, хотя технически возможно.
>>
>>  Не вижу серьёзных и обоснованных причин для данного требования:
>>идентификацию подписавшего обеспечивает любая из поддерживаемых gpg
>>схем. Почему предпочтение отдаётся только одной из них? (Пример с git,
>>svn и cvs не подходит: существенно разные вещи, с точки зрения
>>взаимодействия с репозитарием/его поддержки.)
> 
> 
> Это называется "Потому что". Когда написано "делать и так", придётся так и 
> делать независимо по какой причине.

  Если нет возможности поменять это самое "делать и так", на нечто более
очевидное/логичное/простое.

  Для данного случая: зачем вводить дополнительный ограничитель, который
не даёт значительных плюсов?

> Хорошо. Если Вам не нравится git в 
> сравнении с svn и cvs, возьмём другую аналогию: требование выкладывать в git 
> только в определённом порядке и, скорее всего, формировать необходимые 
> действия только через gear. А почему не в другом порядке, не в других 
> каталогах? Мне же будет удобнее их по другому называть. Где здесь 
> обоснованная причина? Ясно же - унификация.

  Да. Но не унификация-ради-унификации, а
унификация-для-удобства-автоматизации. Её плюсы понятны и весьма логичны.

> Точно также и ключами: 
> унификация. Зачем тысячу схем, ежели можно обойтись одной?

  А зачем менять привычное поведение, да ещё с добавлением
неопределённостей?

  Например, что у меня получилось (алгоритмически):

1. пакет подписан, но отвергнут.

2. при этом -- мой ключ в alt-gpgkeys есть

3. при этом rpmsign -Kv <пакет> на _моей_ системе мою подпись видит (оно
и понятно: все мои подключи у меня в связке...

  И только обращение в рассылку вскрыла причину этой проблемы...

  Так зачем раскладывать грабли, не обнаруживаемые простым образом, да
ещё и грабли, без очевидных плюсов?

-- 

С уважением. Алексей.

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 550 байтов
Описание: OpenPGP digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20060712/34c72c65/attachment-0001.bin>