The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск криптографической библиотеки OpenSSL 3.0.0

08.09.2021 11:24

После трёх лет разработки и 19 тестовых выпусков состоялся релиз библиотеки OpenSSL 3.0.0 с реализацией протоколов SSL/TLS и различных алгоритмов шифрования. Новая ветка включает изменения, нарушающие обратную совместимость на уровне API и ABI, но изменения не повлияют на работу большинства приложений, для перевода которых с OpenSSL 1.1.1 достаточно пересборки. Поддержка прошлой ветки OpenSSL 1.1.1 будет осуществляться до сентября 2023 года.

Значительное изменение номера версии связано с переходом на традиционную нумерацию "Major.Minor.Patch". Первая цифра (Major) в номере версии отныне будет меняться только при нарушении совместимости на уровне API/ABI, а вторая (Minor) при наращивании функциональности без изменения API/ABI. Корректирующие обновления будут поставляться с изменением третьей цифры (Patch). Номер 3.0.0 сразу после 1.1.1 выбран для избежания пересечений с находящимся в разработке FIPS-модулем к OpenSSL, для которого применялась нумерация 2.x.

Вторым важным для проекта изменением стал переход с двойной лицензии (OpenSSL и SSLeay) на лицензию Apache 2.0. Ранее применявшаяся собственная лицензия OpenSSL была основана на тексте устаревшей лицензии Apache 1.0 и требовала явного упоминания OpenSSL в рекламных материалах при использовании библиотек OpenSSL, а также добавления специального примечания в случае поставки OpenSSL в составе продукта. Подобные требования делали старую лицензию несовместимой с GPL, что создавало трудности при использовании OpenSSL в проектах с лицензией GPL. Для обхода данной несовместимости GPL-проекты вынуждены были применять специфичные лицензионные соглашения, в которых основной текст GPL дополнялся пунктом, явно разрешающим связывание приложения с библиотекой OpenSSL и упоминающим, что требования GPL не распространяется на связывание с OpenSSL.

По сравнению с веткой OpenSSL 1.1.1 в OpenSSL 3.0.0 добавлено более 7500 изменений, подготовленных 350 разработчиками. Основные новшества OpenSSL 3.0.0:

  • Предложен новый модуль FIPS, включающий реализацию криптографических алгоритмов, соответствующих стандарту безопасности FIPS 140-2 (в этом месяце планируется начать процесс сертификации модуля, получение сертификата FIPS 140-2 ожидается следующем году). Новый модуль значительно проще в использовании и его подключение ко многим приложениям будет не сложнее изменения файла конфигурации. По умолчанию модуль FIPS отключен и требует указания опции enable-fips для активации.
  • В libcrypto реализована концепция подключаемых провайдеров, пришедших на смену концепции движков (ENGINE API признан устаревшим). При помощи провайдеров можно добавлять собственные реализации алгоритмов для таких операций как шифрование, расшифровка, формирование ключей, вычисление MAC, создание и проверка цифровых подписей. Возможно как подключение новых, так и создание альтернативных реализаций уже поддерживаемых алгоритмов (по умолчанию для каждого алгоритма теперь используется встроенный в OpenSSL провайдер).
  • Добавлена поддержка протокола управления сертификатами CMP (Certificate Management Protocol, RFC 4210), который можно использовать для запроса сертификатов у сервера удостоверяющего центра , обновления сертификатов и отзыва сертификатов. Работа с CMP осуществляется при помощи новой утилиты openssl-cmp, в которой также реализована поддержка формата CRMF (RFC 4211) и передачи запросов через HTTP/HTTPS (RFC 6712).
  • Реализован полноценный клиент для протоколов HTTP и HTTPS, поддерживающий методы GET и POST, перенаправление запросов, работу через прокси, кодирование ASN.1 и обработку таймаутов.
  • Добавлен новый API EVP_MAC (Message Authentication Code API), упрощающий добавление новых реализаций имитовставок.
  • Предложен новый программный интерфейс для формирования ключей - EVP_KDF (Key Derivation Function API), упрощающий добавление новых реализаций KDF и PRF. Старый API EVP_PKEY, через который были доступны алгоритмы scrypt, TLS1 PRF и HKDF, переработан в форме прослойки, реализованной поверх API EVP_KDF и EVP_MAC.
  • В реализации протокола TLS предоставлена возможность использования встроенных в ядро Linux клиента и сервера TLS для ускорения операций. Для задействования предоставляемой ядром Linux реализации TLS требуется включение опции "SSL_OP_ENABLE_KTLS" или настройки "enable-ktls".
  • Добавлена поддержка новых алгоритмов:
    • Алгоритмы формирования ключей (KDF) - "SINGLE STEP" и "SSH".
    • Алгоритмы имитовставок (MAC) - "GMAC" и "KMAC".
    • Алгоритм инкапсуляции ключей RSA (KEM) "RSASVE".
    • Алгоритм шифрования "AES-SIV" (RFC-8452).
    • В API EVP добавлены вызовы с поддержкой инверсивных шифров, использующих алгоритм AES для шифрования ключей (Key Wrap): "AES-128-WRAP-INV", "AES-192-WRAP-INV", "AES-256-WRAP-INV", "AES-128-WRAP-PAD-INV", "AES-192-WRAP-PAD-INV" и "AES-256-WRAP-PAD-INV".
    • В API EVP добавлена поддержка алгоритмов заимствование шифротекста (CTS): "AES-128-CBC-CTS", "AES-192-CBC-CTS", "AES-256-CBC-CTS", "CAMELLIA-128-CBC-CTS", "CAMELLIA-192-CBC-CTS" и "CAMELLIA-256-CBC-CTS".
    • Добавлена поддержка цифровых подписей CAdES-BES (RFC 5126).
    • В AES_GCM реализован параметр AuthEnvelopedData (RFC 5083), позволяющий зашифровать и расшифровывать сообщения, аутентифицированные и зашифрованные с использованием режима AES GCM.
  • В публичный API вынесены функции PKCS7_get_octet_string и PKCS7_type_is_other.
  • В API PKCS#12 алгоритмы, применяемые по умолчанию в функции PKCS12_create(), заменены на PBKDF2 и AES, а для расчёта MAC задействован алгоритм SHA-256. Для восстановления прошлого поведения предусмотрена опция "-legacy". Добавлено большое число новых расширенных вызовов PKCS12_*_ex, PKCS5_*_ex и PKCS8_*_ex, таких как PKCS12_add_key_ex().PKCS12_create_ex() и PKCS12_decrypt_skey_ex().
  • Для платформы Windows добавлена поддержка синхронизации потоков при помощи механизма SRWLock.
  • Добавлен новый API для трассировки, включаемый через параметр enable-trace.
  • Расширен спектр ключей, поддерживаемых в функциях EVP_PKEY_public_check() и EVP_PKEY_param_check(): RSA, DSA, ED25519, X25519, ED448 и X448.
  • Удалена подсистема RAND_DRBG вместо которой предложен API EVP_RAND. Удалены функции FIPS_mode() и FIPS_mode_set().
  • Заметная часть API переведена в разряд устаревших - использование устаревших вызовов в коде проектов будет приводить в выводу предупреждения при компиляции. В том числе устаревшими официально объявлены низкоуровневые API, привязанные с определённым реализациям алгоритмов (например, AES_set_encrypt_key и AES_encrypt). Официальная поддержка в OpenSSL 3.0.0 теперь предоставляется только для высокоуровневых API EVP, абстрагированных от отдельных типов алгоритмов (к данному API относятся, например, функции EVP_EncryptInit_ex, EVP_EncryptUpdate и EVP_EncryptFinal). В одном из следующих значительных выпусков устаревшие API будут удалены. Реализации устаревших алгоритмов, таких как MD2 и DES, доступных через API EVP, перенесены в отдельный модуль "legacy", который отключён по умолчанию.
  • Значительно расширены документация и набор тестов. По сравнению с веткой 1.1.1 объём документации увеличился на 94%, а размер кода тестового набора на 54%.


  1. Главная ссылка к новости (https://www.mail-archive.com/o...)
  2. OpenNews: Обновление OpenSSL 1.1.1l с устранением двух уязвимостей
  3. OpenNews: Устаревание корневого сертификата AddTrust привело к сбоям в системах с OpenSSL и GnuTLS
  4. OpenNews: Ошибка в OpenSSL нарушила работу некоторых приложений openSUSE Tumbleweed после обновления
  5. OpenNews: Значительный выпуск криптографической библиотеки OpenSSL 1.1.1
  6. OpenNews: Проект OpenSSL переходит на лицензию Apache и меняет схему нумерации выпусков
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/55760-openssl
Ключевые слова: openssl, crypt, tls
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (88) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.5, ИмяХ (?), 12:09, 08/09/2021 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –13 +/
     
     
  • 2.80, Аноним (80), 01:02, 09/09/2021 Скрыто модератором
  • –1 +/
     
     
  • 3.83, WE (?), 04:22, 09/09/2021 Скрыто модератором
  • +1 +/
     
     
  • 4.90, Аноним (90), 11:53, 09/09/2021 Скрыто модератором
  • +/
     
     
  • 5.99, Michael Shigorin (ok), 17:25, 09/09/2021 Скрыто модератором
  • +1 +/
     

     ....ответы скрыты модератором (4)

  • 1.6, Тот_Самый_Анонимус (?), 12:11, 08/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –13 +/
    >Для обхода данной несовместимости GPL-проекты вынуждены были применять специфичные лицензионные соглашения, в которых основной текст GPL дополнялся пунктом, явно разрешающим связывание приложения с библиотекой OpenSSL и упоминающим, что требования GPL не распространяется на связывание с OpenSSL.

    Это не проблема других лицензий же, так ведь, гпльщики?
    Когда гпл ворует код из апача и нет возможности вернуть его обратно из-за паразитности гпл, то вы говорите что это проблема апача. Интересно что вы скажите про этот случай. Жду применения шаблона «это другое, понимать надо» и доказательств того, что стрелочка обратно не поворачивается.

     
     
  • 2.8, пох. (?), 12:15, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > Это не проблема других лицензий же, так ведь, гпльщики?

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

    И да, очень интересно, а автора ssleay они спросили?

     
     
  • 3.73, Аноним (73), 23:00, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > И да, очень интересно, а автора ssleay они спросили?

    Спросили всех контрибуторов в OpenSSL, и это вообще-то многомесячный процесс был, ото всех ответы получить.

     
  • 2.10, Аноним (10), 12:21, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В лицензии Apache это by design. Если бы использующим эту лицензию это не нравилось, они взяли бы другую, но их, очевидно, всё устраивает.
     
     
  • 3.57, Тот_Самый_Анонимус (?), 18:38, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >В лицензии Apache это by design.

    В приведённой мною цитате страдали именно гпльщики. Своими оценками поделились семеро, а мнение почему-то не высказали. Мне бы хотелось услышать их мнение почему «это другое», и почему они позасовывали языки кой-куда, вместо того, чтобы объяснить, почему такое возможно с божественной лицензией.

     
  • 2.66, anonymous (??), 20:42, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты в курсе, что в мире софта GPLесть достойные библиотеки? Я тебе их перечислю: GnuTLS, Libgcrypt, Nettle. Выбирай какая больше нравится и подходит под твои задачи.
     
     
  • 3.84, Тот_Самый_Анонимус (?), 05:27, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как это оправдало страдания гпльщиков, вынужденных есть кактус, как в приведённой цитате? Дан конкретный пример, и вопрос был почему в этом случае страдания оправданы. Не как этого избежать, а почему это хорошо и «это другое».
     
     
  • 4.126, anonymous (??), 20:57, 11/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Люди, которые ценят свою свободу и чистоту кода не буду пользоваться лицензиями отличными от GPL. Ответ достаточный?
     
  • 2.67, Аноним (67), 21:10, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ничего ты не понимаешь. Это другое. Когда используют код ГПЛ и не раскрывают свой - это воровство. А когда ГПЛ использует чужой код делая непозволительные собственной лицензией действия - это щедрость. Так что раньше, когда проекты гпл использовали опенссл, это опенссл воровал код, но гпл своей доброй волей их прощал.
     
     
  • 3.104, Аноним (104), 23:33, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы так говорите, как будто это плохо. Хотя в bsd-like лицензиях черным по белому написано "используйте и унижайте меня как хотите, мне это нравится".
     

  • 1.7, Аноним (7), 12:13, 08/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Почему шифры ГОСТ не добавили?
     
     
  • 2.11, Аноним (10), 12:23, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Были PR, зависти в бесконечном кругу "долго ждУТ ревью – ещё дольше ждут исправлений после review – GOTO 10" с экспоненциальным увеличением времени ожидания на каждой итерации.
     
  • 2.13, Аноним (13), 12:24, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >В libcrypto реализована концепция подключаемых провайдеров, ... При помощи провайдеров можно добавлять собственные реализации алгоритмов для таких операций как шифрование, расшифровка, формирование ключей, вычисление MAC, создание и проверка цифровых подписей.

    Если стрибогим кузнечикам надо, сами добавят.

     
     
  • 3.44, Аноним (44), 16:47, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    На AES лапу-то поднять стрёмно. Кушайте АНБшной криптографии, не обляпайтесь.
     
     
  • 4.91, Аноним (90), 11:57, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Какое у вас бинарное мышление, "есть крипта не подчиняется товарищу майору, значит она АНБ-шное". По другому мыслить не умеете.
     
     
  • 5.94, Аноним (73), 12:46, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Это вам везде товарищи майоры мерещатся. А тут скорее ситуация, что есть нога кого надо нога, а есть нога людей второго сорта, их интересы как бы и не важны.
     
  • 5.103, Аноним (104), 23:31, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >  Какое у вас бинарное мышление, "есть крипта не подчиняется товарищу майору, значит она АНБ-шное".

    Докажите, что оно не АНБ-шное. В случае с зондами от товарища майора - доказательство тривиально.

     
     
  • 6.111, Аноним (111), 10:54, 10/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > В случае с зондами от товарища майора - доказательство тривиально.

    Что-то вроде Бритвы Мицгола, да?

     
  • 2.29, nmorozov (ok), 15:14, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Алгоритмы ГОСТ добавляются отдельным модулем. Кстати кроме указанного ченжлога в билиотеке есть заментное кол-во улучшений связанных именно с русской криптографией (ну и с китайской тоже)
     
     
  • 3.32, Qwerty (??), 15:38, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Шапочку из фольги уже можно сворачивать?
     
     
  • 4.35, Аноним (13), 16:01, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Никогда не стоит.
     
     
  • 5.48, Аноним (48), 17:38, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Простите, ударение на каком слоге?
     
     
  • 6.76, Аноним (76), 23:04, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В данном контексте, "не ст'оит".
     
  • 4.43, ryoken (ok), 16:47, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Клетка Фарадея вроде получше?
     
     
  • 5.46, Аноним (46), 17:01, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Смотря сколько фольги есть
     
  • 3.53, Анон123амм (?), 18:10, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    "русская криптография", "китайская криптография" -- какие ржачные термины)))
     
     
  • 4.64, Онаним (?), 20:40, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Суверенная, я бы сказал.
     
     
  • 5.68, Аноним (68), 21:24, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Осветлённая батюшкой. Теперь криптография в безопасности.
     
     
  • 6.119, Michael Shigorin (ok), 12:56, 11/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мне вот интересно -- ляпающие подобное вообще хоть в чём-то _для себя_ разобрались или слепо верят во всё, что в книжке (или на лопате), а чтоб как-то вроде бы как самооправдаться -- пытаются остро шютить?..
     
  • 5.95, Аноним (13), 13:18, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Скрепная
     
  • 3.77, Аноним (73), 23:14, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, китайскую, корейскую и японскую криптографию почему-то приняли в OpenSSL как внутренние алгоритмы с доступом через EVP API. А русскую криптографию единственную заставили переписать в виде ENGINE, механизм который вообще-то используется для подключения аппаратных шифроустройств. И использование алгоритмов через ENGINE естественно сложнее, чем просто через EVP API.
     
  • 2.33, Аноним (33), 15:55, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Потому что они небезопасны.
     
     
  • 3.47, Аноним (7), 17:32, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пруфов нет.
     
     
  • 4.49, Аноним (33), 18:05, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это криптография, солнышко, тут нужны пруфы что они безопасны. Нет алгоритма генерации сбоксов - нет пруфов. Нет пруфов - нет безопасности. Повторяю, они небезопасны.
     
     
  • 5.52, Аноним (52), 18:09, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Алгоритм существует. "Получить у уполномоченной организации".
     
     
  • 6.71, Аноним (76), 22:56, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Под пописку о неразгашении гостайны.
     
  • 5.59, Аноним (111), 18:47, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вся симметричная криптография - это security through obscurity.
    Вся ассиметричная основана на недоказанных предположениях.
     
  • 5.120, Michael Shigorin (ok), 12:58, 11/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Это криптография, солнышко, тут нужны пруфы что они безопасны.

    Вы готовы принимать такие доказательства на веру? (что неспособны их проверить -- и так вижу)

     
  • 4.54, Анон123амм (?), 18:13, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • –4 +/
    это там где для с-бокса, который должен быть рандомным, удалось написать код который его генерит, причем код в 4 раза меньше самого с-бокса, БУГАГА очень "безопасное" шиврование да!
     
     
  • 5.60, Аноним (7), 19:02, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А теперь докажите, что это влияет на стойкость.
     
     
  • 6.81, Аноним (81), 03:16, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я читал такое объяснение ситуации: некоторые варианты конфигурации могут быть слабее остальных. Никто не доказал, что выбранные значения слабые. Случайные же значения могут быть более слабыми, чем задумано.
     
  • 5.96, Аноним (73), 14:36, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А в AES S-box тоже не рандомный, но никого это почему-то не беспокоит
     
     
  • 6.112, Аноним (111), 10:55, 10/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    AES S-box сделан в соответствии с принципом "У меня в рукаве ничего нет".
     
     
  • 7.114, Аноним (73), 12:53, 10/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Все так про свои алгоритмы говорят
     

  • 1.12, suffix (ok), 12:24, 08/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    "QUIC is on our minds, but it will not be included in the OpenSSL 3.0 release."

    Значит пока в топку, ждём дальше.

     
     
  • 2.15, Аноним (13), 12:29, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +8 +/
    https://ru.wikipedia.org/wiki/QUIC
    Почему сетевой протокол должен быть добавлен в библиотеку криптографии?
     
     
  • 3.17, suffix (ok), 12:41, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Читайте:

    https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/

    А почему жду ?

    Потому что nginx заявили что в основную ветку добавят поддержку quic только когда подержка quic будет в openssl.

     
  • 2.28, Аноним (104), 15:10, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Значит пока в топку, ждём дальше.

    Не стоит. QUIC - это местечковый гугловый продукт, все, кто не гугл, используют его на свой страх и риск. Гугловцы допиливают его очень активно, и стандартизированные версии быстро устаревают. Поэтому, если нужен QUIC, кроме BoringSSL вариантов нет.

     
     
  • 3.30, suffix (ok), 15:17, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >  кроме BoringSSL вариантов нет.

    Сейчас да, но через пару лет (год на пока openssl разродится и год пока nginx интегрирует)надеюсь все болячки протокола уже победят.

    Так что я очень неспешно жду :)


     
     
  • 4.31, Аноним (104), 15:23, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +7 +/
    К тому времени гугловцы QUIC уже задепрекейтят и забросят, и сделают какой-нибудь FAST (HTTP/7) поверх DCCP :)
     
  • 3.61, qwerty (??), 19:35, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Помниться где то читал, что это будующий http 3 или 4, сколько их там уже. Или я его с чем то путаю?
     
     
  • 4.62, suffix (ok), 20:33, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    да,  http/3=quic
     
  • 3.79, Всем Анонимам Аноним (?), 00:23, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Конечно, чего уж там, все основные CDN поддерживают (половина трафика интернет). Конечно, фигня...
     

  • 1.14, Аноним (14), 12:27, 08/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Теперь старым играм и эту либу подкладывать придётся. Ну, чо, не в первый раз.
     
     
  • 2.50, Аноним (33), 18:06, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это что за игры которые либо нельзя пересобрать, либо не таскают с собой все библиотеки?
     

  • 1.22, Microsoft (?), 14:11, 08/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Закрыть, запретить и сделать EEE этому ненужному ненужно.
     
  • 1.40, Аноним (111), 16:37, 08/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Такая масштабная поломка API требует слоя совместимости со старыми программами. Чтобы можно было слинковать со слоем совместимости, который будет оборачивать новый API, и старые программы получили security-апдейты.
     
     
  • 2.51, Аноним (33), 18:08, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Под старыми программами вы подразумеваете программы которые не развиваются (иначе у них бы не было проблем перейти на новую версию openssl). Но такие программы сами по себе не получают security-апдейты, зачем им апдейты openssl? Другими словами, они априори дырявое гнильё, версией openssl это не вылечить.
     
     
  • 3.58, Аноним (111), 18:43, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Весь софт - гнильё, недырявых программ и библиотек не бывает, включая openssl новейшей версии. Да и вообще valar morghulis, улавливаешь?
     

  • 1.55, Аноним (55), 18:21, 08/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Осуждаю за сломанный abi. Если до 23 года не придумают какой-нибудь враппер, который позволит работать десктопным приложениям без перекомпиляции, это будет фейл.
     
     
  • 2.65, Онаним (?), 20:42, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Перетопчутся на libssl1.1.dll
     
  • 2.75, Аноним (76), 23:02, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Позволь поинтересоваться, ты в мире опенсорса или как? Неизменное ABI это для клозетсорщиков. Перекомпиляция при открытых исходниках это нормальное явление.
     
  • 2.97, Аноним (33), 14:38, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Никаких врапперов не будет, и это правильно. И не вижу с чем у вас проблема - что за непонятное желание обновить OpenSSL не обновляя софт его использующий? Хотите сидеть на гнилье - сидите на гнилье. Хотите свежего - будет свежий софт со свежим OpenSSL. ABI надо чуть ли не специально ломать, чтобы усложнить жизнь таким вот некрофилам. А то вы же ещё и issue пишете со своими странными хотелками, время сообщества тратите.
     
     
  • 3.100, Аноним (111), 17:57, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Этот фанат Xiaomi/Huawei/Oppo/OnePlus/ZTE/realme порвался, уносите.
     
  • 3.110, Аноним (110), 10:23, 10/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема в том, что некоторый софт обновится, а некоторый нет. А DLL hell никак не решается
     
  • 3.121, Michael Shigorin (ok), 13:08, 11/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Деточка, я ж возьму сейчас и напишу Вашему работодателю, из сети которого Вы в р... большой текст свёрнут, показать
     

  • 1.69, Ilya Indigo (ok), 21:53, 08/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Новая ветка включает изменения, нарушающие обратную совместимость на уровне API и ABI

    Это реально ВСЁ что она содержит!

    > но изменения не повлияют на работу большинства приложений, для перевода которых с OpenSSL 1.1.1 достаточно пересборки.

    Ага!
    https://build.opensuse.org/staging_workflows/openSUSE:Factory (зарегиться для OBS на SuSE нужно)
    Staging:Gcc7 openssl-3
    Там дохренища несобранных приложений (пока не соберётся (красный цвет) кол-во не собравшихся приложений будет не полным).

     
     
  • 2.70, Аноним (81), 22:48, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Попробуйте выкинуть доистрический компилятор для начала.
     
     
  • 3.122, Michael Shigorin (ok), 13:10, 11/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Попробуйте выкинуть доистрический компилятор для начала.

    Деточка, опять же с этим сперва к своему работодателю (можно непосредственному начальнику) -- для начала посмотрев версию gcc в каком-нить centos7.  Вот _там_ -- нет, не доисторическая, а по меркам эксплуатационщиков всего лишь почти вчерашняя.

     
     
  • 4.124, Аноним (81), 13:25, 11/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это не отменяет того, что актуальный софт зачастую не поддерживается доисторическими компиляторами и в лучшем случае кое-как собирается. А вот хамить не обязательно, я тоже могу тебе поводить кое-чем по губам, да вот тебе не понравится, ага?
     
     
  • 5.125, Michael Shigorin (ok), 14:06, 11/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    *sigh*

    Написал.

    PS: в смысле в яндекс написал, посоветовавшись со старым приятелем вдобавок.

     
  • 2.129, mikhailnov (ok), 16:33, 15/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А вот в LibreSSL такой фигни нет...
     

  • 1.74, Andrey_Karpov (ok), 23:02, 08/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Кто про что, а меня интересные баги интересуют. На этот раз приглянулось:

    static int dh_cmp_parameters(const EVP_PKEY *a, const EVP_PKEY *b)
    {
        return ossl_ffc_params_cmp(&a->pkey.dh->params, &a->pkey.dh->params,
                                   a->ameth != &ossl_dhx_asn1_meth);
    }

    Предупреждение PVS-Studio: V751 Parameter 'b' is not used inside function body. dh_ameth.c 312

    Классика :) https://pvs-studio.com/ru/blog/posts/cpp/0509/

     
     
  • 2.78, пох. (?), 23:22, 08/09/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >     return ossl_ffc_params_cmp(&a->pkey.dh->params, &a->pkey.dh->params,

    эпоха копипастеров :-( это вот насколько ж надо не уметь пользоваться клавиатурой, чтобы тут было быстрее (и неправильно) скопировать чем вручную набрать?

    вряд ли такой ляп можно внести руками.

     
  • 2.98, Аноним (33), 14:41, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Это определяется как warning обычным компилятором, для этого проприетарный анализатор который рекламируют спамом и враньём, и который на деле недалеко ушёл от тех же варнингов, а до взрослых анализаторов типа cppcheck ему вообще как до китая раком, для этого не нужен.
     
     
  • 3.101, Аноним (73), 18:42, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я сообщений про PVS-Studio за последние 12 месяцев видел, даже не помню сколько, но точно меньше 10 штук. Не тянет на спам.

    Потока вранья от Андрея тоже не вижу.

    И может потрудитесь дать ссылку на какое-нибудь сравнение анализаторов, которое доказывает, что "до взрослых анализаторов типа cppcheck ему вообще как до китая раком" ?

    А то как-то балабольством попахивает, аж 3 раза.

     
     
  • 4.102, Аноним (33), 21:47, 09/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Вы наверное профильных ресурсов вовсе не читаете Так-то моя бабушка тоже не вид... большой текст свёрнут, показать
     
     
  • 5.105, Аноним (73), 00:04, 10/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо за объяснение. Да, рассылка на спам пожалуй потянет. А на ЛОРе же вроде Андрей раньше спамил, а потом перестал, встал на путь исправления так сказать? Или нет, просто не очень слежу? А публикации на Хабре где были, на своём канале? Если да, то все коммерческие компании свои каналы на Хабре и других площадках как раз для саморекламы и используют, это обычная практика, я бы не назвал это спамом если Хабр не пихает те статьи в ленту всё время.

    А про враньё Андрея и низкий уровень PVS-Studio относительно cppcheck и других есть что-то? Как-то хочется верить в хорошее в людях.

     
     
  • 6.117, Аноним (33), 15:56, 10/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Залогинься, Андрей. Уж лучше оправдывайся чем из-под анонима себя пытаться выгородить, выглядит как детский сад.
     
  • 3.123, Michael Shigorin (ok), 13:13, 11/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > а до взрослых анализаторов типа cppcheck

    Деточка, сообщить миру "хочу на мороз" можно проще и прямее.

    И да, всякому хамству есть мера.  Тем более, повторюсь, прям в рабочее время из AS208722.

     
  • 3.128, Andrey_Karpov (ok), 11:49, 13/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Это определяется как warning обычным компилятором

    Хочется внести ясность. Судя по комментариям многие подумали, что анализатор PVS-Studio предупреждает про неиспользуемый аргумент функции. Это не совсем так. Вернее, это так, но анализатор действует более умно, чем большинство линтеров или компиляторов.

    Просто ругаться на неиспользуемые аргументы - плохая идея. Будет очень много ложных срабатываний, и именно поэтому многие программисты не смотрят (отключают) эти предупреждения компиляторов/анализаторов.

    В анализаторе реализуется некая эмпирическая "магия". PVS-Studio опирается на то, что есть однотипные аргументы, и при этом некоторые из них не используются, в то время как некоторые используются несколько раз. При этом действует ещё ряд дополнительных исключений из правила. Например, диагностика не сработает, если число неиспользуемых аргументов больше двух.

    Всё это позволяет диагностике V751 выдавать мало ложных срабатываний, что выгодно отличает инструмент от аналогов - https://pvs-studio.com/ru/blog/posts/0802/ . Собственно, при разработке PVS-Studio не реализуются правила, если невозможно их сделать лучше, чем у компиляторов. Благодаря описанной диагностике, удаётся находить вот такие интересные ошибки - https://pvs-studio.com/ru/blog/examples/v751/ .

    P.S. В анализаторе PVS-Studio есть и "тупой" вариант этой диагностики - V2537 - https://pvs-studio.com/ru/docs/warnings/v2537/ . Она разработана для проверки соответствия кода программы стандарту MISRA C и MISRA C++. Но это особенный случай, и по умолчанию эта диагностика отключена, как и все остальные диагностики, относящиеся к MISRA.

     

  • 1.109, Аноним (110), 10:22, 10/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >> Реализован полноценный клиент для протоколов HTTP и HTTPS, поддерживающий методы GET и POST

    Кто-то может объяснить что это и зачем? А метод PUT и другие?

     
  • 1.113, mumu (ok), 11:35, 10/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Реализован полноценный клиент для протоколов HTTP и HTTPS, поддерживающий методы GET и POST

    Ой. Мелькание в заголовках с очередной найденной дырой в реализации этого клиента в ближайшие пять лет им обеспечено. План был именно в этом?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру