| 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, то вот он дефолтный вариант. Последний взять будет сложнее, потому что сначала надо будет сверится с количеством элементов в массиве. Средний будет взять ещё сложнее, потому что мало всех тех делений, которые придётся производить, будет неопределённость что делать, в случае чётного количества элементов.
   |  |   |   
 |   
 |   
 |   
 
 
 |