1.4, Аноним (4), 08:42, 05/10/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Половина чэнжлога устранение проблем вызванных неправильной работой с памятью.
| |
|
2.7, Аноним (7), 09:17, 05/10/2022 [^] [^^] [^^^] [ответить]
| +12 +/– |
Чейнжлог как бы намекает, что тебе (лично тебе) нужно срочно переписать эту программу на безопасном языке. Не подведи нас, на тебя вся надежда.
| |
2.22, Ivan_83 (ok), 14:47, 05/10/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Этим ошибкам 20+ лет, они ещё с оригинального кода, ам и другие ошибки есть.
Просто утилиты не критичны для работы и всем пофик что они там есть.
| |
|
3.55, Аноним (55), 08:29, 09/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
>они ещё с оригинального кода
Какого-такого оригинального кода?
| |
|
|
|
|
3.11, Аноним (-), 10:10, 05/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
Carbon почти такой же страшный, как rust, а по возможностям уступает D. Поэтому, сразу на свалку истории.
| |
|
|
3.19, Аноним (19), 12:58, 05/10/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
Идейный аноним-апологет Rust с опеннета никогда не спросит про деньги. Этим пистонисты грешат.
| |
|
4.48, TydymBydym (?), 01:47, 07/10/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Почему не спросит? Спросит. "Сколько я вам должен заплатить за позволение кодить вашу задачу на Расте?"
| |
|
|
|
1.12, Аноним (12), 10:32, 05/10/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
>> Переносимая редакция OpenSSH переведена на использование SSH-ключей для заверения цифровой подписью коммитов и тегов в Git.
А можно вот то же самое, но использовать для подписания писем в тундроптице или прочих сообщений (вместо всяких PGP)?
И как их потом верифаить по пачке ключей открыто лежащих в https://github.com/USERNAME.keys ?
| |
|
2.15, Аноним (15), 11:38, 05/10/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Нифига себе. А с каких пор ключи лежат открыто на гитхабе? Оно же публички доступа показывает в том числе, которые как-бы и не подразумевают что ты ими будешь подписывать код, всего-лишь логиниться. Какая-то анти-privacy фича получается
| |
|
3.16, Аноним (12), 11:44, 05/10/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
ммм... вот и подъехали типичные спецы во всём, которые не отличают открытого ключа от закрытого...
| |
|
2.25, OpenEcho (?), 15:42, 05/10/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
> А можно вот то же самое, но использовать для подписания писем в тундроптице или прочих сообщений (вместо всяких PGP)?
>И как их потом верифаить по пачке ключей открыто лежащих в https://github.com/USERNAME.keys ?
'''
namesapce="Unique_Abracadabra"
File='/path/to/file/to/be/signed'
# sign, на выхлопе выдаст File.sig
/usr/bin/ssh-keygen \
-n "${namespace}" \
-Y sign \
-f "${ssh_prv_key}" "${File}"
# verify
wget https://github.com/USERNAME.keys
echo "namespaces=\"${namespace}\" $(<cat USERNAME.keys)" > "${signersPubKey}"
<"${File}" ssh_keygen -Y verify \
-f ${signersPubKey} \
-I "$( ssh_keygen -Y find-principals -s "${File}.sig" -f "${signersPubKey}" )" \
-n "${namespace}" -s "${File}.sig" &&
echo 'Valid signature file.' ||
echo 'Invalid signature file !!!'
'''
| |
|
1.13, PnD (??), 10:58, 05/10/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
DSA похоже так и не смогли проломить. Поэтому молча выпиливают.
* Если я не прав, ткните носом в пруф реализованной атаки. (Кроме "это можно будет сделать на квантовом компьютере". Там вообще много чего можно будет. Но надо сначала сделать его самого.)
| |
|
|
3.31, PnD (??), 18:19, 05/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Попробуйте начать с Википедии.
"Если не рандомна подпись, то и ключик утечёт." Таки да.
Но это можно контролировать, в отличие от (к примеру) качества выбранной кривой в EC-алгоритмах.
Суть моей претензии — в замене верифицированного алгоритма, с известными условиями эксплуатации, на не верифицированные. Скорее даже "отмене".
| |
|
|
1.26, Аноним (26), 16:49, 05/10/2022 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Это что же выходит, даже Тео ненастоящий сишник? Что ж аноны с опеннета ему не расскажут как надо всего лишь быть более внимательным и не освобождать память два раза?
| |
|
2.32, Аноним (32), 19:06, 05/10/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Как там радукс? Уже все утечки памяти пофиксили, раз комменты на опеннете пишете?
| |
|
3.43, Аноним (26), 00:18, 06/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
Не знаю, кто такой радукс, покемонами не интересуюсь. А вот то, что на сях никто не умеет хорошо программировать — факт, за которым стоит полвека разработки на этом языке.
| |
|
|
1.28, Аноним (28), 17:59, 05/10/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
когда в rust впилят модификатор madvise, чтобы в нём можно было заниматься криптографией?
| |
|
|
3.33, Аноним (33), 20:05, 05/10/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
надо будет запилить форк раста с модификаторами из флагов madvise и навесить на него плашку cryptographically secure, растфаундейшен сразу же обанкротится.
| |
|
|
1.35, BrainFucker (ok), 20:14, 05/10/2022 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Хочу из коробки опцию нешифрованного соединения или с каким-то слабым шифрованием. Нужно в основном для использования sftp и sshfs в локальной сети, где подслушивать и так некому.
| |
|
2.37, john_erohin (?), 21:57, 05/10/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
1) это противоречит идеологии "zero trust" (она же "нулевое доверие").
2) такая настройка неизбежно расползется из локальной сети куда попало, в т.ч. туда куда не надо.
| |
|
3.38, BrainFucker (ok), 22:05, 05/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
Ну, во-первых с чего бы ей расползаться, если по дефолту выключено и надо вручную в конфиг опцию прописать.
Во-вторых, вы слишком плохого мнения о серверных пользователях.
В третьих, постоянное затачивание системы под дураков делает её адекватным людям неюзабельным, это прямая дорога в скатывание в Шindoшs. Давайте ещё пароли запретим, сделаем обязательным OTP через какие нибудь облака гугла, а то дураки вечно простые пароли ставят и палят случайно где нибудь, да и ключи тоже можно случайно спалить.
| |
|
4.40, john_erohin (?), 22:46, 05/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
> во-первых с чего бы ей расползаться
А) удобство важнее безопастности.
Б) перекачивать терабайты через sftp, не загружая CPU шифрованием/дешифрованием - очень удобно.
В) вывод - сперва это будет временной мерой для больших трансферов, потом забудут убрать, а потом наплевать уже.
> Во-вторых, вы слишком плохого мнения о серверных пользователях.
имею право, знаю вопрос изнутри, в т.ч. и на себе.
| |
|
5.41, BrainFucker (ok), 23:35, 05/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
> потом забудут убрать, а потом наплевать уже.
Значит это какой-то любительский сервер, не настолько важный, чтобы там париться об этом.
Нет никакого смысла жертвовать гибкостью ради защиты дураков, которые всё равно найдут где обосраться.
Ну ок, опцию можно сделать только чтобы действовала на указанный диапазон IP, как например в конфиге постфикса permit_mynetworks, например.
> знаю вопрос изнутри, в т.ч. и на себе.
Такая себе выборка.
| |
|
|
|
|
|
|
5.51, BrainFucker (ok), 00:08, 08/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
> У samba с портами проще будет
Самбой пользовался когда-то, но перестал, когда в руки попал sshfs. В целом он хорош и удобнее.
| |
|
4.53, Аноним (26), 01:59, 09/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Хочу из коробки опцию нешифрованного
> в локальной сети, где подслушивать и так некому.
И в чём проблема с портами? Ах, ну да, это ж опеннетчик, шашечки важнее вы ем ехать.
| |
|
|
2.47, Аноним (47), 22:06, 06/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
Зачем тебе делать шифрованное соединение нешифрованным. Так и используй простой ftp. Если для обмена файлами то используй rsync, он умеет умного синхронизировать файлы.
| |
|
3.52, BrainFucker (ok), 00:15, 08/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Так и используй простой ftp.
Лишняя сущность, когда и так есть sftp.
> Если для обмена файлами то используй rsync, он умеет умного синхронизировать файлы.
Rsync использует ssh либо запускать специальный демон rsync, но в таком случае опять лишняя сущность как и с ftp.
Плюс нет нормального rsyncfs по подобию sshfs.
| |
|
|
|