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

Epiphanov Sergei =?iso-8859-1?q?serpiph_=CE=C1_nikiet=2Eru?=
Ср Июл 12 14:36:25 MSD 2006


В сообщении от 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. А почему не в другом порядке, не в других 
каталогах? Мне же будет удобнее их по другому называть. Где здесь 
обоснованная причина? Ясно же - унификация. Точно также и ключами: 
унификация. Зачем тысячу схем, ежели можно обойтись одной?

-- 
С уважением, Епифанов Сергей




Подробная информация о списке рассылки Devel