1.3, Аноним (3), 09:09, 09/10/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> В ssh-keygen добавлена экспериментальная поддержка упрощённой схемы создания и верификации цифровых подписей
Много лет ждал. "Классическая" схема GnuPG с импортом в хранилище, доверием и неочевидными опциями ком. строки сделана явно не для людей.
| |
|
2.7, Аноним (7), 09:56, 09/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
> В цифровую подпись встраивается информация о пространстве имён для исключения путаницы при применении в различных областях (например, для email и файлов);
Зато теперь есть немного больше информации о владельце.
| |
2.14, Аноним (14), 12:39, 09/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Хранилище ключей нужно для реализации web of trust, которая частично реализована в ssh через вручную редактируемую базу ключей в ALLOWED SIGNERS файле
| |
|
3.17, Аноним (3), 13:28, 09/10/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
Понимаю зачем нужен GnuPG, но иногда хочется чего-то более простого. Мои типичные юзкейсы: зашифровать и расшифровать бэкап, подписать и проверить подпись пакета. Ни то, ни другое не выходит за пределы моей инфраструктуры, и этой инфраструктуре я полностью доверяю. Мне не нужны цепочки доверия, не нужен сервер ключей, не нужен централизованный отзыв, не нужен gpg-agent, не нужны пароли и не нужно ещё сто тысяч возможностей GnuPG, о которых я даже не знаю.
Новый простой и стандартный инструмент для узкой задачи взамен раздутого 10Мб GnuPG - это прекрасно.
| |
|
4.20, Аноним (20), 16:37, 09/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Но ALLOWED SIGNERS вам всё равно придётся создать насколько я понял, не ясно чем это тогда проще gpg --homedir dir и создания отдельной базы ключей под конкретную задачу "зашифровать и расшифровать бэкап, подписать и проверить подпись пакета".
| |
|
|
|
1.6, Ilya Indigo (ok), 09:55, 09/10/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> rsa-sha2-512
Оказывается, помимо sha и sha3, существует sha2?
А почему именно sha2, а не sha3?
| |
1.19, Аноним (19), 15:39, 09/10/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
> В списках алгоритмов шифрования для ssh и sshd для вставки предлагаемых по умолчанию алгоритмов теперь можно использовать символ "^". Например, для добавления ssh-ed25519 к списку по умолчанию можно указать "HostKeyAlgorithms ^ssh-ed25519"
Не самое интуитивно понятное назначение. Я бы скорее принял такую запись за исключение, а не добавление, по аналогии с набором символов в [] в регулярках.
| |
|
2.21, Ordu (ok), 00:08, 10/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
В C -- это исключающее или, что довольно интуитивно объясняет запись ^ssh-ed25519.
| |
|
3.23, Аноним (22), 02:32, 10/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Раньше для этой цели интуитивно использовали or, типа: aaa | bbb | ccc
| |
|
4.24, Ordu (ok), 03:53, 10/10/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Раньше для этой цели интуитивно использовали or, типа: aaa | bbb |
> ccc
И что подсказывает интуиция на тему того, какой из вариантов дефолтный? Мне она подсказывает, что первый, но не потому что "или", а потому что так программу выбора писать проще: надо взять нулевой элемент из массива, и если он не-NULL, то вот он дефолтный вариант. Последний взять будет сложнее, потому что сначала надо будет сверится с количеством элементов в массиве. Средний будет взять ещё сложнее, потому что мало всех тех делений, которые придётся производить, будет неопределённость что делать, в случае чётного количества элементов.
| |
|
|
|
|