Опубликованы корректирующие обновления языка программирования Python 3.11.5, 3.10.13, 3.9.18 и 3.8.18, в которых устранена уязвимость (CVE-2023-40217) в классе ssl.SSLSocket, позволяющая обойти стадию согласования TLS-соединения и связанные с ним процессы, такие как проверка сертификата. Успешная атака может привести к обработке незашифрованных данных так, как если бы они были переданы с использованием корректного TLS-соединения...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59660
О... дыряшка и ее дефективные нультерминированные строки будет еще годами портить жизнь людям...
Зато все ненавидят Паскаль и его строки с явно указанной длинной и даже не вспоминают, что мода на нультерминирование пошла в какие-то древние времена ДОСа, когда модно было писать программы в стиле "Пока не ноль посылать символ в консоль", а сейчас это наоборот тупая трата времени, т.к. каждый раз приходится сначала считать длину строки, а только потом ее обрабатывать.
Какой дос? Это пошло еще с PDP-10/11, а это на минуточку 1970е!
Сорян, я не застал PDP, я помню только ДОС с его бакстерминатед строками. Смысл в том, что тот, кто придумывал Си, очень сильно заморачивался по поводу оптимизации, но проблема в том, что в итоге оказалось, что в среднем это приводило только к ухудшению производительности, т.к. например на один случай, когда оставленные в стеке параметры действительно оказывались нужны, приходилось 10 случаев, когда операция "sub [e|r]sp, n" оказывалась тупо лишней.
Ой, add конечно. Стек же у нас на PC вверх растет.
кроме строк с терминатором в виде нуля во всех языках, наверно, есть функции читающие строку, где эта функция ждет символ новой строки.
Конечно есть. В с++ есть std::getline, в расте stdin().read_line.
Только наличие таких функций не значит, что строки в этих языках null-terminated.
getline возвращает нормальный std::string, read_line изменяет String.Да, и там, и там есть null-terminated.
И по странному стечению обстоятельств они называются CString или как-то похоже.
Раст и С++, это языки с слишком сложной реализацией, в этом их недостаток. Язык программирования с нуль-терминированной строкой - единственно правильный путь.
Паскаль - язык с очень простой реализацией, но в нём есть нормальные строки
Ну да, дьявол явно довольно потирал руки в тот момент, когда предлагал отцам-основателям сиё техническое решение. По масштабу порожденных проблем не знаешь, с чем и сравнить - разве что с идеей использовать "=" для присваивания...
А чем не естесственно использовать "=" для присваивания? Это же соответсвует написанию математических формул.
Да, но в математике оно не приводит к непредсказуемым результатам.
А в программировании if (myNumber = 42) может отстрелить ногу. Yoda conditions придумали не просто так.
И по хорошему эти понятия нужно было максимально визуально оделить.
Тут скорее тогда проблема не с символом присвоения, а с символом сравнения. И на этот счет есть правило - переменная всегда должна быть справа при сравнении. В яп с неизменяемыми данными это проблема стоит менее просто.
> переменная всегда должна быть справа при сравнениино оно работает только с константами
если у тебя сравниваются A и B, то все будет так же плохо))
Просто присвоение не должно работать в выражениях. В питоне, кстати, так и есть.
Моржовый оператор := с вами не согласен
> Моржовый оператор := с вами не согласенНу это отдельный оператор. Обычное = в выражениях не работает.
> Yoda conditions придумали не просто такЙода не поможет никак если слева будет переменная
> А в программировании if (myNumber = 42) может отстрелить ногу. Yoda conditions
> придумали не просто так.Ну да. Антибаг. if (42 = myNumber) как минимум в сишке провалится с треском. Стандартная практика там где это важно. Впрочем сейчас как минимум в сях на вон то компилеры норовят варнинг кинуть и без этого. Чтоб неповадно так делать было.
> И по хорошему эти понятия нужно было максимально визуально оделить.
Это не то чтобы визуально должно быть, а на уровне синтаксис чекера. Питону это есс ноне грозит, у него почти все факапы в рантайм вылезают и ему это мертвому припарка.
Не соответствует.
В математике а = в + с не означает (взять значения в и с, сложить их, и записать результат а)= в математике утверждение, а не последовательность действий.
Не соответствует по большей части.a = 1; a = 2; a = b; совершенно корректная запись в программировании и по большей части бессмыслица с т.з. математики. a = f(x) в математике прекрасно существует при неопределённом x, в программировании - по большей части нет. 42 = а и a = 42 в математике эквивалентны, в программировании сразу встаёт вопрос это про сравнение или про присвоение. Короче, паскалевское := больше не кажется глупостью. Ещё внезапно понимаешь зачем в некоторых языках let, но решая идеологическую проблему, let создаёт не сильно-то оправданную многословность и некрасив чисто технически. Да и в целом - изрядная часть математики это про преобразования с сохранением равенства (или в более общем смысле - условия), программирование это про вычисление значений.
А при чём тут сам язык? Ведь это просто набор функций из библиотеки. Возьмите другую библиотеку и строка уже выглядит так
typedef struct
{
gchar *str; // Pointer to the actual string data
gsize len; // Current length of the string
gsize allocated_len; // Total allocated memory for the string
} GString;
> А при чём тут сам язык? Ведь это просто набор функций из
> библиотеки. Возьмите другую библиотеку и строка уже выглядит такНу вот в каждой библиотеке будет своя строка. Разве это хорошо?
таки да хорошо. С - это низкоуровневый язык. где-то нужны тяжелые строки где-то достаточно нул-терминированных. какие надо такими и пользуетесь. А если не надо то берете тот же питон или ноду и вперёд ))
А два разных размера там зачем? Чтобы можно было по неинициализированой памяти при случае покататься, как раз устроив HeartBleed какой лишний раз? :)
чтобы не перевыделять память при каждом добавлении символа в строку. в с++ строки выглядят примерно так же.
Беда конечно в Python c шифрованием столько развели библиотек и все они то устаревают то обновляют их чем-то ... ошущещние какого-то бардака...
openssl, boringssl, libressl, wolfssl, polarssl(mbedtls?), gnutls - это конечно же другое :)
А что не так делай:```
import openssl as ssl
```
и всего делов, но вот зоопарк в видеPyCrypt, PyAesCrypt, Crypt, Cryptodome и т.д. вот что на самом деле раздражает,
так как нет понимания что и куда уходит корнями.Все эти пристроечки, которые даже непонятно куда идут в какую библиотеку или даже сами
реализуют полторы функции.И не было бы проблемы если бы все это худо бедно работало, но проблема не в этом,
а в том что авторы просто забивают и ты берешь программу, а в ней используеться брошенная
библиотека и все тебя устраивает, но нужно искать замену и патчить программу и все это на уровне
чуть ли не пеереписать все.
>[оверквотинг удален]
> Все эти пристроечки, которые даже непонятно куда идут в какую библиотеку или
> даже сами
> реализуют полторы функции.
> И не было бы проблемы если бы все это худо бедно работало,
> но проблема не в этом,
> а в том что авторы просто забивают и ты берешь программу, а
> в ней используеться брошенная
> библиотека и все тебя устраивает, но нужно искать замену и патчить программу
> и все это на уровне
> чуть ли не пеереписать все.Да хрен там плавал. openssl в базовой библиотеке нет - вместо него есть crypt, который deprecated и будет removed, переписывайте код под hashlib, aesчего-тотам с чем-то там и ваще. И да, под винду pyopenssl не то, чтобы везде-и-всюду нормально протащить можно. Г*но, г*но, ничего кроме г*на(Ц)
> Беда конечно в Python c шифрованием столько развели библиотек и все они то устаревают то обновляют их чем-то ... ошущещние какого-то бардака...Так и название репозитория намекает. Можно Конду взамен пробовать, может там коллекционеры более адекватные. Не довелось понять.
А сам язык получился хороший.
Интересно, все эти диалоги выше кто-то заранее придумывает?
Закусывать надо...