forum.opennet.ru - "В Python устранена уязвимость в реализации TLS" (33)

"В Python устранена уязвимость в реализации TLS"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"В Python устранена уязвимость в реализации TLS"	+/–
Сообщение от opennews (??), 25-Авг-23, 11:01
Опубликованы корректирующие обновления языка программирования 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
Ответить \| Правка \| Cообщить модератору

Оглавление

О дыряшка и ее дефективные нультерминированные строки будет еще годами портит, Анонин (?), 11:21 , 25-Авг-23, (3) –8

Зато все ненавидят Паскаль и его строки с явно указанной длинной и даже не вспом, Аноним (5), 11:49 , 25-Авг-23, (5) +4

Какой дос Это пошло еще с PDP-10 11, а это на минуточку 1970е , Анонин (?), 11:58 , 25-Авг-23, (6)

Сорян, я не застал PDP, я помню только ДОС с его бакстерминатед строками Смысл , Аноним (5), 12:04 , 25-Авг-23, (7) +1
Ой, add конечно Стек же у нас на PC вверх растет , Аноним (5), 12:09 , 25-Авг-23, (9) –1

кроме строк с терминатором в виде нуля во всех языках, наверно, есть функции чит, анон (?), 14:43 , 25-Авг-23, (17)

Конечно есть В с есть std getline, в расте stdin read_line Только наличие , Анонин (?), 14:59 , 25-Авг-23, (20)

Раст и С , это языки с слишком сложной реализацией, в этом их недостаток Язык , Аноним (39), 13:28 , 26-Авг-23, (39)

Паскаль - язык с очень простой реализацией, но в нём есть нормальные строки, Аноним (59), 17:29 , 08-Сен-23, (59)

Ну да, дьявол явно довольно потирал руки в тот момент, когда предлагал отцам-осн, User (??), 12:08 , 25-Авг-23, (8) +1

А чем не естесственно использовать для присваивания Это же соответсвует нап, Аноним (14), 14:27 , 25-Авг-23, (14) –1

Да, но в математике оно не приводит к непредсказуемым результатам А в программир, Анонимусс (?), 14:34 , 25-Авг-23, (16)

Тут скорее тогда проблема не с символом присвоения, а с символом сравнения И на, анон (?), 14:46 , 25-Авг-23, (18) +1

но оно работает только с константамиесли у тебя сравниваются A и B, то все будет, Анонимусс (?), 14:50 , 25-Авг-23, (19)
Просто присвоение не должно работать в выражениях В питоне, кстати, так и есть , Вы забыли заполнить поле Name (?), 00:05 , 26-Авг-23, (24) +1

Моржовый оператор с вами не согласен, Аноним (57), 18:24 , 05-Сен-23, (57)

Ну это отдельный оператор Обычное в выражениях не работает , Вы забыли заполнить поле Name (?), 01:44 , 07-Сен-23, (58)

Йода не поможет никак если слева будет переменная, Вы забыли заполнить поле Name (?), 23:53 , 25-Авг-23, (23)
Ну да Антибаг if 42 myNumber как минимум в сишке провалится с треском Ста, Аноним (47), 03:58 , 28-Авг-23, (47) +1

Не соответствует В математике а в с не означает взять значения в и с, сложи, Аноньимъ (ok), 15:39 , 25-Авг-23, (21) +7
Не соответствует по большей части a 1 a 2 a b совершенно корректная зап, Котофалк (?), 15:39 , 04-Сен-23, (56)

А при чём тут сам язык Ведь это просто набор функций из библиотеки Возьмите др, Аноним (36), 07:40 , 26-Авг-23, (36) +1

Ну вот в каждой библиотеке будет своя строка Разве это хорошо , Вы забыли заполнить поле Name (?), 20:57 , 26-Авг-23, (43)

таки да хорошо С - это низкоуровневый язык где-то нужны тяжелые строки где-то , Аноним (36), 10:18 , 27-Авг-23, (45)

А два разных размера там зачем Чтобы можно было по неинициализированой памяти п, Аноним (47), 01:54 , 28-Авг-23, (46)

чтобы не перевыделять память при каждом добавлении символа в строку в с строк, anonymous (??), 10:10 , 29-Авг-23, (50)

Беда конечно в Python c шифрованием столько развели библиотек и все они то устар, Аноним (37), 08:37 , 26-Авг-23, (37) –1

openssl, boringssl, libressl, wolfssl, polarssl mbedtls , gnutls - это конечно , User (??), 07:41 , 28-Авг-23, (48) +2

А что не так делай import openssl as ssl и всего делов, но вот зоопарк в ви, Аноним (52), 14:34 , 30-Авг-23, (52)

gt оверквотинг удален Да хрен там плавал openssl в базовой библиотеке нет - в, User (??), 16:25 , 30-Авг-23, (54)

Так и название репозитория намекает Можно Конду взамен пробовать, может там кол, Аноним (55), 10:16 , 04-Сен-23, (55)

Интересно, все эти диалоги выше кто-то заранее придумывает , СвидетельСвидетеляЛюбви (?), 17:40 , 29-Авг-23, (51) +1

Закусывать надо , Аноним (52), 14:35 , 30-Авг-23, (53) +1

Сообщения [Сортировка по времени | RSS]

3. "В Python устранена уязвимость в реализации TLS" –8 +/–

Сообщение от Анонин (?), 25-Авг-23, 11:21

О... дыряшка и ее дефективные нультерминированные строки будет еще годами портить жизнь людям...

Ответить | Правка | Наверх | Cообщить модератору

5. "В Python устранена уязвимость в реализации TLS" +4 +/–

Сообщение от Аноним (5), 25-Авг-23, 11:49

Зато все ненавидят Паскаль и его строки с явно указанной длинной и даже не вспоминают, что мода на нультерминирование пошла в какие-то древние времена ДОСа, когда модно было писать программы в стиле "Пока не ноль посылать символ в консоль", а сейчас это наоборот тупая трата времени, т.к. каждый раз приходится сначала считать длину строки, а только потом ее обрабатывать.

Ответить | Правка | Наверх | Cообщить модератору

6. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Анонин (?), 25-Авг-23, 11:58

Какой дос? Это пошло еще с PDP-10/11, а это на минуточку 1970е!

Ответить | Правка | Наверх | Cообщить модератору

7. "В Python устранена уязвимость в реализации TLS" +1 +/–

Сообщение от Аноним (5), 25-Авг-23, 12:04

Сорян, я не застал PDP, я помню только ДОС с его бакстерминатед строками. Смысл в том, что тот, кто придумывал Си, очень сильно заморачивался по поводу оптимизации, но проблема в том, что в итоге оказалось, что в среднем это приводило только к ухудшению производительности, т.к. например на один случай, когда оставленные в стеке параметры действительно оказывались нужны, приходилось 10 случаев, когда операция "sub [e|r]sp, n" оказывалась тупо лишней.

Ответить | Правка | Наверх | Cообщить модератору

9. "В Python устранена уязвимость в реализации TLS" –1 +/–

Сообщение от Аноним (5), 25-Авг-23, 12:09

Ой, add конечно. Стек же у нас на PC вверх растет.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

17. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от анон (?), 25-Авг-23, 14:43

кроме строк с терминатором в виде нуля во всех языках, наверно, есть функции читающие строку, где эта функция ждет символ новой строки.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

20. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Анонин (?), 25-Авг-23, 14:59

Конечно есть. В с++ есть std::getline, в расте stdin().read_line.
Только наличие таких функций не значит, что строки в этих языках null-terminated.
getline возвращает нормальный std::string, read_line изменяет String.
Да, и там, и там есть null-terminated.
И по странному стечению обстоятельств они называются CString или как-то похоже.

Ответить | Правка | Наверх | Cообщить модератору

39. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Аноним (39), 26-Авг-23, 13:28

Раст и С++, это языки с слишком сложной реализацией, в этом их недостаток. Язык программирования с нуль-терминированной строкой - единственно правильный путь.

Ответить | Правка | Наверх | Cообщить модератору

59. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Аноним (59), 08-Сен-23, 17:29

Паскаль - язык с очень простой реализацией, но в нём есть нормальные строки

Ответить | Правка | Наверх | Cообщить модератору

8. "В Python устранена уязвимость в реализации TLS" +1 +/–

Сообщение от User (??), 25-Авг-23, 12:08

Ну да, дьявол явно довольно потирал руки в тот момент, когда предлагал отцам-основателям сиё техническое решение. По масштабу порожденных проблем не знаешь, с чем и сравнить - разве что с идеей использовать "=" для присваивания...

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

14. "В Python устранена уязвимость в реализации TLS" –1 +/–

Сообщение от Аноним (14), 25-Авг-23, 14:27

А чем не естесственно использовать "=" для присваивания? Это же соответсвует написанию математических формул.

Ответить | Правка | Наверх | Cообщить модератору

16. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Анонимусс (?), 25-Авг-23, 14:34

Да, но в математике оно не приводит к непредсказуемым результатам.
А в программировании if (myNumber = 42) может отстрелить ногу. Yoda conditions придумали не просто так.
И по хорошему эти понятия нужно было максимально визуально оделить.

Ответить | Правка | Наверх | Cообщить модератору

18. "В Python устранена уязвимость в реализации TLS" +1 +/–

Сообщение от анон (?), 25-Авг-23, 14:46

Тут скорее тогда проблема не с символом присвоения, а с символом сравнения. И на этот счет есть правило - переменная всегда должна быть справа при сравнении. В яп с неизменяемыми данными это проблема стоит менее просто.

Ответить | Правка | Наверх | Cообщить модератору

19. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Анонимусс (?), 25-Авг-23, 14:50

> переменная всегда должна быть справа при сравнении
но оно работает только с константами
если у тебя сравниваются A и B, то все будет так же плохо))

Ответить | Правка | Наверх | Cообщить модератору

24. "В Python устранена уязвимость в реализации TLS" +1 +/–

Сообщение от Вы забыли заполнить поле Name (?), 26-Авг-23, 00:05

Просто присвоение не должно работать в выражениях. В питоне, кстати, так и есть.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

57. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Аноним (57), 05-Сен-23, 18:24

Моржовый оператор := с вами не согласен

Ответить | Правка | Наверх | Cообщить модератору

58. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Вы забыли заполнить поле Name (?), 07-Сен-23, 01:44

> Моржовый оператор := с вами не согласен
Ну это отдельный оператор. Обычное = в выражениях не работает.

Ответить | Правка | Наверх | Cообщить модератору

23. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Вы забыли заполнить поле Name (?), 25-Авг-23, 23:53

> Yoda conditions придумали не просто так
Йода не поможет никак если слева будет переменная

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

47. "В Python устранена уязвимость в реализации TLS" +1 +/–

Сообщение от Аноним (47), 28-Авг-23, 03:58

> А в программировании if (myNumber = 42) может отстрелить ногу. Yoda conditions
> придумали не просто так.
Ну да. Антибаг. if (42 = myNumber) как минимум в сишке провалится с треском. Стандартная практика там где это важно. Впрочем сейчас как минимум в сях на вон то компилеры норовят варнинг кинуть и без этого. Чтоб неповадно так делать было.
> И по хорошему эти понятия нужно было максимально визуально оделить.
Это не то чтобы визуально должно быть, а на уровне синтаксис чекера. Питону это есс ноне грозит, у него почти все факапы в рантайм вылезают и ему это мертвому припарка.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

21. "В Python устранена уязвимость в реализации TLS" +7 +/–

Сообщение от Аноньимъ (ok), 25-Авг-23, 15:39

Не соответствует.
В математике а = в + с не означает (взять значения в и с, сложить их, и записать результат а)
= в математике утверждение, а не последовательность действий.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

56. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Котофалк (?), 04-Сен-23, 15:39

Не соответствует по большей части.
a = 1; a = 2; a = b; совершенно корректная запись в программировании и по большей части бессмыслица с т.з. математики.  a = f(x) в математике прекрасно существует при неопределённом x, в программировании - по большей части нет. 42 = а и a = 42 в математике эквивалентны, в программировании сразу встаёт вопрос это про сравнение или про присвоение. Короче, паскалевское := больше не кажется глупостью. Ещё внезапно понимаешь зачем в некоторых языках let, но решая идеологическую проблему, let создаёт не сильно-то оправданную многословность и некрасив чисто технически. Да и в целом - изрядная часть математики это про преобразования с сохранением равенства (или в более общем смысле - условия), программирование это про вычисление значений.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

36. "В Python устранена уязвимость в реализации TLS" +1 +/–

Сообщение от Аноним (36), 26-Авг-23, 07:40

А при чём тут сам язык? Ведь это просто набор функций из библиотеки. Возьмите другую библиотеку и строка уже выглядит так
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;

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

43. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Вы забыли заполнить поле Name (?), 26-Авг-23, 20:57

> А при чём тут сам язык? Ведь это просто набор функций из
> библиотеки. Возьмите другую библиотеку и строка уже выглядит так
Ну вот в каждой библиотеке будет своя строка. Разве это хорошо?

Ответить | Правка | Наверх | Cообщить модератору

45. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Аноним (36), 27-Авг-23, 10:18

таки да хорошо. С - это низкоуровневый язык. где-то нужны тяжелые строки где-то достаточно нул-терминированных. какие надо такими и пользуетесь. А если не надо то берете тот же питон или ноду и вперёд ))

Ответить | Правка | Наверх | Cообщить модератору

46. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Аноним (47), 28-Авг-23, 01:54

А два разных размера там зачем? Чтобы можно было по неинициализированой памяти при случае покататься, как раз устроив HeartBleed какой лишний раз? :)

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

50. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от anonymous (??), 29-Авг-23, 10:10

чтобы не перевыделять память при каждом добавлении символа в строку. в с++ строки выглядят примерно так же.

Ответить | Правка | Наверх | Cообщить модератору

37. "В Python устранена уязвимость в реализации TLS" –1 +/–

Сообщение от Аноним (37), 26-Авг-23, 08:37

Беда конечно в Python c шифрованием столько развели библиотек и все они то устаревают то обновляют их чем-то ... ошущещние какого-то бардака...

Ответить | Правка | Наверх | Cообщить модератору

48. "В Python устранена уязвимость в реализации TLS" +2 +/–

Сообщение от User (??), 28-Авг-23, 07:41

openssl, boringssl, libressl, wolfssl, polarssl(mbedtls?), gnutls - это конечно же другое :)

Ответить | Правка | Наверх | Cообщить модератору

52. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Аноним (52), 30-Авг-23, 14:34

А что не так делай:
```
import openssl as ssl
```
и всего делов, но вот зоопарк в виде
PyCrypt, PyAesCrypt, Crypt, Cryptodome и т.д. вот что на самом деле раздражает,
так как нет понимания что и куда уходит корнями.
Все эти пристроечки, которые даже непонятно куда идут в какую библиотеку или даже сами
реализуют полторы функции.
И не было бы проблемы если бы все это худо бедно работало, но проблема не в этом,
а в том что авторы просто забивают и ты берешь программу, а в ней используеться брошенная
библиотека и все тебя устраивает, но нужно искать замену и патчить программу и все это на уровне
чуть ли не пеереписать все.

Ответить | Правка | Наверх | Cообщить модератору

54. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от User (??), 30-Авг-23, 16:25

>[оверквотинг удален]
> Все эти пристроечки, которые даже непонятно куда идут в какую библиотеку или
> даже сами
> реализуют полторы функции.
> И не было бы проблемы если бы все это худо бедно работало,
> но проблема не в этом,
> а в том что авторы просто забивают и ты берешь программу, а
> в ней используеться брошенная
> библиотека и все тебя устраивает, но нужно искать замену и патчить программу
> и все это на уровне
> чуть ли не пеереписать все.
Да хрен там плавал. openssl в базовой библиотеке нет - вместо него есть crypt, который deprecated и будет removed, переписывайте код под hashlib, aesчего-тотам с чем-то там и ваще. И да, под винду pyopenssl не то, чтобы везде-и-всюду нормально протащить можно. Г*но, г*но, ничего кроме г*на(Ц)

Ответить | Правка | Наверх | Cообщить модератору

55. "В Python устранена уязвимость в реализации TLS" +/–

Сообщение от Аноним (55), 04-Сен-23, 10:16

> Беда конечно в Python c шифрованием столько развели библиотек и все они то устаревают то обновляют их чем-то ... ошущещние какого-то бардака...
Так и название репозитория намекает. Можно Конду взамен пробовать, может там коллекционеры более адекватные. Не довелось понять.
А сам язык получился хороший.

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

51. "В Python устранена уязвимость в реализации TLS" +1 +/–

Сообщение от СвидетельСвидетеляЛюбви (?), 29-Авг-23, 17:40

Интересно, все эти диалоги выше кто-то заранее придумывает?

Ответить | Правка | Наверх | Cообщить модератору

53. "В Python устранена уязвимость в реализации TLS" +1 +/–

Сообщение от Аноним (52), 30-Авг-23, 14:35

Закусывать надо...

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

3. "В Python устранена уязвимость в реализации TLS"	–8 +/–
Сообщение от Анонин (?), 25-Авг-23, 11:21
О... дыряшка и ее дефективные нультерминированные строки будет еще годами портить жизнь людям...
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "В Python устранена уязвимость в реализации TLS"	+4 +/–
	Сообщение от Аноним (5), 25-Авг-23, 11:49
	Зато все ненавидят Паскаль и его строки с явно указанной длинной и даже не вспоминают, что мода на нультерминирование пошла в какие-то древние времена ДОСа, когда модно было писать программы в стиле "Пока не ноль посылать символ в консоль", а сейчас это наоборот тупая трата времени, т.к. каждый раз приходится сначала считать длину строки, а только потом ее обрабатывать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Анонин (?), 25-Авг-23, 11:58
	Какой дос? Это пошло еще с PDP-10/11, а это на минуточку 1970е!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "В Python устранена уязвимость в реализации TLS"	+1 +/–
	Сообщение от Аноним (5), 25-Авг-23, 12:04
	Сорян, я не застал PDP, я помню только ДОС с его бакстерминатед строками. Смысл в том, что тот, кто придумывал Си, очень сильно заморачивался по поводу оптимизации, но проблема в том, что в итоге оказалось, что в среднем это приводило только к ухудшению производительности, т.к. например на один случай, когда оставленные в стеке параметры действительно оказывались нужны, приходилось 10 случаев, когда операция "sub [e\|r]sp, n" оказывалась тупо лишней.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "В Python устранена уязвимость в реализации TLS"	–1 +/–
	Сообщение от Аноним (5), 25-Авг-23, 12:09
	Ой, add конечно. Стек же у нас на PC вверх растет.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	17. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от анон (?), 25-Авг-23, 14:43
	кроме строк с терминатором в виде нуля во всех языках, наверно, есть функции читающие строку, где эта функция ждет символ новой строки.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	20. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Анонин (?), 25-Авг-23, 14:59
	Конечно есть. В с++ есть std::getline, в расте stdin().read_line. Только наличие таких функций не значит, что строки в этих языках null-terminated. getline возвращает нормальный std::string, read_line изменяет String. Да, и там, и там есть null-terminated. И по странному стечению обстоятельств они называются CString или как-то похоже.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Аноним (39), 26-Авг-23, 13:28
	Раст и С++, это языки с слишком сложной реализацией, в этом их недостаток. Язык программирования с нуль-терминированной строкой - единственно правильный путь.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	59. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Аноним (59), 08-Сен-23, 17:29
	Паскаль - язык с очень простой реализацией, но в нём есть нормальные строки
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "В Python устранена уязвимость в реализации TLS"	+1 +/–
	Сообщение от User (??), 25-Авг-23, 12:08
	Ну да, дьявол явно довольно потирал руки в тот момент, когда предлагал отцам-основателям сиё техническое решение. По масштабу порожденных проблем не знаешь, с чем и сравнить - разве что с идеей использовать "=" для присваивания...
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	14. "В Python устранена уязвимость в реализации TLS"	–1 +/–
	Сообщение от Аноним (14), 25-Авг-23, 14:27
	А чем не естесственно использовать "=" для присваивания? Это же соответсвует написанию математических формул.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Анонимусс (?), 25-Авг-23, 14:34
	Да, но в математике оно не приводит к непредсказуемым результатам. А в программировании if (myNumber = 42) может отстрелить ногу. Yoda conditions придумали не просто так. И по хорошему эти понятия нужно было максимально визуально оделить.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "В Python устранена уязвимость в реализации TLS"	+1 +/–
	Сообщение от анон (?), 25-Авг-23, 14:46
	Тут скорее тогда проблема не с символом присвоения, а с символом сравнения. И на этот счет есть правило - переменная всегда должна быть справа при сравнении. В яп с неизменяемыми данными это проблема стоит менее просто.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Анонимусс (?), 25-Авг-23, 14:50
	> переменная всегда должна быть справа при сравнении но оно работает только с константами если у тебя сравниваются A и B, то все будет так же плохо))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "В Python устранена уязвимость в реализации TLS"	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Авг-23, 00:05
	Просто присвоение не должно работать в выражениях. В питоне, кстати, так и есть.
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	57. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Аноним (57), 05-Сен-23, 18:24
	Моржовый оператор := с вами не согласен
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 07-Сен-23, 01:44
	> Моржовый оператор := с вами не согласен Ну это отдельный оператор. Обычное = в выражениях не работает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 25-Авг-23, 23:53
	> Yoda conditions придумали не просто так Йода не поможет никак если слева будет переменная
	Ответить \| Правка \| К родителю #16 \| Наверх \| Cообщить модератору


	47. "В Python устранена уязвимость в реализации TLS"	+1 +/–
	Сообщение от Аноним (47), 28-Авг-23, 03:58
	> А в программировании if (myNumber = 42) может отстрелить ногу. Yoda conditions > придумали не просто так. Ну да. Антибаг. if (42 = myNumber) как минимум в сишке провалится с треском. Стандартная практика там где это важно. Впрочем сейчас как минимум в сях на вон то компилеры норовят варнинг кинуть и без этого. Чтоб неповадно так делать было. > И по хорошему эти понятия нужно было максимально визуально оделить. Это не то чтобы визуально должно быть, а на уровне синтаксис чекера. Питону это есс ноне грозит, у него почти все факапы в рантайм вылезают и ему это мертвому припарка.
	Ответить \| Правка \| К родителю #16 \| Наверх \| Cообщить модератору


	21. "В Python устранена уязвимость в реализации TLS"	+7 +/–
	Сообщение от Аноньимъ (ok), 25-Авг-23, 15:39
	Не соответствует. В математике а = в + с не означает (взять значения в и с, сложить их, и записать результат а) = в математике утверждение, а не последовательность действий.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	56. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Котофалк (?), 04-Сен-23, 15:39
	Не соответствует по большей части. a = 1; a = 2; a = b; совершенно корректная запись в программировании и по большей части бессмыслица с т.з. математики. a = f(x) в математике прекрасно существует при неопределённом x, в программировании - по большей части нет. 42 = а и a = 42 в математике эквивалентны, в программировании сразу встаёт вопрос это про сравнение или про присвоение. Короче, паскалевское := больше не кажется глупостью. Ещё внезапно понимаешь зачем в некоторых языках let, но решая идеологическую проблему, let создаёт не сильно-то оправданную многословность и некрасив чисто технически. Да и в целом - изрядная часть математики это про преобразования с сохранением равенства (или в более общем смысле - условия), программирование это про вычисление значений.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	36. "В Python устранена уязвимость в реализации TLS"	+1 +/–
	Сообщение от Аноним (36), 26-Авг-23, 07:40
	А при чём тут сам язык? Ведь это просто набор функций из библиотеки. Возьмите другую библиотеку и строка уже выглядит так 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;
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	43. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Авг-23, 20:57
	> А при чём тут сам язык? Ведь это просто набор функций из > библиотеки. Возьмите другую библиотеку и строка уже выглядит так Ну вот в каждой библиотеке будет своя строка. Разве это хорошо?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Аноним (36), 27-Авг-23, 10:18
	таки да хорошо. С - это низкоуровневый язык. где-то нужны тяжелые строки где-то достаточно нул-терминированных. какие надо такими и пользуетесь. А если не надо то берете тот же питон или ноду и вперёд ))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Аноним (47), 28-Авг-23, 01:54
	А два разных размера там зачем? Чтобы можно было по неинициализированой памяти при случае покататься, как раз устроив HeartBleed какой лишний раз? :)
	Ответить \| Правка \| К родителю #36 \| Наверх \| Cообщить модератору


	50. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от anonymous (??), 29-Авг-23, 10:10
	чтобы не перевыделять память при каждом добавлении символа в строку. в с++ строки выглядят примерно так же.
	Ответить \| Правка \| Наверх \| Cообщить модератору

37. "В Python устранена уязвимость в реализации TLS"	–1 +/–
Сообщение от Аноним (37), 26-Авг-23, 08:37
Беда конечно в Python c шифрованием столько развели библиотек и все они то устаревают то обновляют их чем-то ... ошущещние какого-то бардака...
Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "В Python устранена уязвимость в реализации TLS"	+2 +/–
	Сообщение от User (??), 28-Авг-23, 07:41
	openssl, boringssl, libressl, wolfssl, polarssl(mbedtls?), gnutls - это конечно же другое :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от Аноним (52), 30-Авг-23, 14:34
	А что не так делай: ``` import openssl as ssl ``` и всего делов, но вот зоопарк в виде PyCrypt, PyAesCrypt, Crypt, Cryptodome и т.д. вот что на самом деле раздражает, так как нет понимания что и куда уходит корнями. Все эти пристроечки, которые даже непонятно куда идут в какую библиотеку или даже сами реализуют полторы функции. И не было бы проблемы если бы все это худо бедно работало, но проблема не в этом, а в том что авторы просто забивают и ты берешь программу, а в ней используеться брошенная библиотека и все тебя устраивает, но нужно искать замену и патчить программу и все это на уровне чуть ли не пеереписать все.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "В Python устранена уязвимость в реализации TLS"	+/–
	Сообщение от User (??), 30-Авг-23, 16:25
	>[оверквотинг удален] > Все эти пристроечки, которые даже непонятно куда идут в какую библиотеку или > даже сами > реализуют полторы функции. > И не было бы проблемы если бы все это худо бедно работало, > но проблема не в этом, > а в том что авторы просто забивают и ты берешь программу, а > в ней используеться брошенная > библиотека и все тебя устраивает, но нужно искать замену и патчить программу > и все это на уровне > чуть ли не пеереписать все. Да хрен там плавал. openssl в базовой библиотеке нет - вместо него есть crypt, который deprecated и будет removed, переписывайте код под hashlib, aesчего-тотам с чем-то там и ваще. И да, под винду pyopenssl не то, чтобы везде-и-всюду нормально протащить можно. Гно, гно, ничего кроме г*на(Ц)
	Ответить \| Правка \| Наверх \| Cообщить модератору