The OpenNET Project / Index page

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

Значительный выпуск криптографической библиотеки OpenSSL 1.1.1

11.09.2018 18:46

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

Основные новшества OpenSSL 1.1.1:

  • Поддержка TLS 1.3 (RFC 8446), который представляет собой улучшенную версию протокола TLS и отличается удалением устаревших и ненадёжных криптографических примитивов (MD5, SHA-224) и возможностей (сжатие, повторное согласование, не-AEAD шифры, статический обмен ключами RSA и DH, указание unix-времени в Hello-сообщениях и т.п.), работает только в режиме forward secrecy (компрометации одного из долговременных ключей не позволяет расшифровать перехваченный сеанс), обеспечивает более высокую производительность, поддерживает режим 0-RTT (устраняет задержки при возобновлении ранее установленных HTTPS-соединений), поддерживает потоковый шифр ChaCha20, алгоритм аутентификации сообщений (MAC) Poly1305, ключи аутентификации на основе цифровых подписей Ed25519, HKDF (HMAC-based Extract-and-Expand Key Derivation Function), ключи на основе алгоритмов x25519 (RFC 7748) и x448 (RFC 8031);
  • Значительная переработка встроенного генератора псевдослучайных чисел. По умолчанию для генерации случайных чисел задействован метод AES-CTR DRBG (Deterministic Random Bit Generator), соответствующий требованиям стандарта NIST SP 800-90Ar1. Поддерживается использование цепочки из нескольких экземпляров DRBG, а также публичные и закрытые экземпляры DRBG и привязка отдельных экземпляров DRBG к каждому потоку. DRBG корректно обрабатывает операции fork() и может размещаться в отдельной защищённой области памяти;
  • Настройки конфигурации перенесены в файл configdata.pm;
  • Обеспечена возможность использования в сборочном скрипте Configure переменных для утилиты make в стиле GNU;
  • Определены пространства имён OSSL и OPENSSL, реализованные в виде префиксов;
  • Добавлена поддержка формирования ключей RSA на основе более чем двух случайных простых чисел (multi-prime, RFC 8017);
  • Реализованы криптографические хэши SM2, SM3 (GB/T 32905-2016) и SM4 (GB/T 32907-2016), стандартизированные для учреждений Китая;
  • Поддержка расширения TLS для согласования максимального размера фрагмента (Maximum Fragment Length);
  • Значительно усилена защита от атак по сторонним каналам;
  • Добавлен модуль STORE (OSSL_STORE), предоставляющий унифицированный API для доступа к ключам, сертификатам, CRL и другим объектам в хранилищах, используя схему на базе URI;
  • Поддержка алгоритма симметричного блочного шифрования ARIA;
  • Поддержка алгоритмов хэширования SHA3, SHA512/224 и SHA512/256;
  • Поддержка алгоритма создания цифровых подписей EdDSA, включая схемы Ed25519 и Ed448;
  • Поддержка хеш-функции SipHash;
  • Переписан движок devcrypto.


  1. Главная ссылка к новости (https://www.mail-archive.com/o...)
  2. OpenNews: OpenSSL переходит на новую лицензию, совместимую с GPL
  3. OpenNews: Значительный выпуск криптографической библиотеки OpenSSL 1.1.0
  4. OpenNews: OpenSSL 1.0.2 решено поддерживать до 2020 года
  5. OpenNews: Критическая уязвимость в OpenSSL
  6. OpenNews: Опубликован RFC для TLS 1.3
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/49255-openssl
Ключевые слова: openssl, crypt
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (64) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 19:02, 11/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А в RHEL даже 1.1.0 не завезли.
     
     
  • 2.4, IRASoldier (?), 19:11, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Комментарии на офсайте по этому поводу:

    https://access.redhat.com/discussions/3440141

     
  • 2.5, rhel (?), 19:13, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –11 +/
    потому что он нахрен не нужен. ну кроме больных, считающих, что чем больше цифирка тем круче шифрование.

    а вот поломать совместимость с чем-то, что, ну надо же, не использует модных-современных шифров (и вполне надежно защищено другими способами - периметром, внутренней аутентификацией и т д) - мы совершенно не хотим без острой необходимости.

     
     
  • 3.7, xl32 (ok), 19:48, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    TLS 1.3 очень нужен.
    Смотрю количество скачиваний апача и nginx на codeit.guru для RHEL/CentOS и диву даюсь, что не завозят даже 1.1.0 штатно.
     
     
  • 4.8, Аноним (8), 19:52, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Где логика? В 1.1.0 tls 1.3 нет. Он есть в 1.1.1, который релизнулся буквально сегодня. Зачем тащить в RHEL 1.1.0, если это и новый tls не даст, и совместимость сломает?
     
     
  • 5.30, xl32 (ok), 21:35, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Очень простой ответ: новые шифры, новые фичи. 1.0.2 же появился в RHEL взамен 1.0.1, появился ALPN.
     
     
  • 6.61, Виталик (??), 14:08, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Даже на попеннете нет 1.3, а вы говорите о тырпрайзе.
     
  • 4.10, Kido Katsuragi (?), 19:57, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А можно для нуба кратко объяснить зачем TLS 1.3 нужен? Что он дает админу или конечному потребителю? Я сам сетевик, в глубокие глубины работы http-серверов и https не залезал, дальше чем поставить apache для nextcloud/wordpress с lets encrypt чтобы в браузере открывалось не вникал.
     
     
  • 5.12, CHERTS (ok), 20:12, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А прочитать первый абзац в статье не можете?

    >>Поддержка TLS 1.3 (https://www.opennet.ru/opennews/art.shtml?num=49126), который представляет собой улучшенную версию протокола TLS и отличается удалением устаревших и ненадёжных криптографических примитивов (MD5, SHA-224) и возможностей (сжатие, повторное согласование, .....

     
  • 5.14, An (??), 20:27, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    режим - forward secrecy
     
     
  • 6.36, Ага (?), 22:20, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Perfect forward secrecy уже давно в ходу начиная tls 1.0 и шифрами использующими DH
     
     
  • 7.41, Аноним (41), 00:27, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Только теперь это единственный возможный режим. Раньше нужно было прикладывать усилия чтобы поотключать не-pfs шифры, это делали единицыи pfs по факту не было.
     
     
  • 8.52, пох (?), 07:14, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    умелец, умудрившийся настроить сервер так, чтобы выбрался не-pfs шифр или кто-то... текст свёрнут, показать
     
  • 5.26, пох (?), 21:20, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    объясняю: вам - низачем.
    админу локалхоста и конечному потребителю котиков он ничего и не дает.

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

    если вы - резидент шпионской сети иностранного государства, только прикидываетесь белым и пушистым админчегом локалхостика - то, теоретически, если вы успели с его территории унести ноги и ректальный криптоанализатор вам не грозит, tls1.3 способен слегка застраховать вас от явных глупостей в конфигурациях серверов, которые понапихал туда проспанный вами внедренный агент (потому что по ошибке это сделать просто невозможно), и сделать кратковременный успех товарищ майора, перехватившего ваши сессионные ключи слишком поздно, достаточно бесполезным для дела.

    но грамотно настроенный сервер с tls>1.0 в общем-то ничем не хуже, а tls=1.0 - весьма эфемерно хуже.
    Шанс присесть на бутылочку явно выше, чем шанс взлома товарищ-майором-фсб tls1.0, настроенного на от'сь, а не с заведомо диверсионной целью.

     
  • 5.29, xl32 (ok), 21:34, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Очень просто: новые шифры, новые фичи. 1.0.2 же появился в RHEL взамен 1.0.1, появился ALPN.
     
     
  • 6.53, пох (?), 07:19, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    от этого alpn хотя бы теоретическая польза есть (правда, практическая есть только если alpn у гугля/ставосьми других вонючих cdn с которых альтернативно-одаренный разработчик заставляет тебя грузить всякий мусор, но там нет редхата, там гугль либо последняя убунточка - а с основным сайтом, на который тебя угораздило зайти, видимой глазу пользы не будет) От 111 - никакой вообще.

     
  • 4.21, пох (?), 21:11, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –8 +/
    кому нужен? Ушибленным цифирками версий, неспособным понять, что он практически ничего им лично не добавит к безопасТносте, зато очень даже убавит совместимости?

    > Смотрю количество скачиваний апача и nginx на codeit.guru для RHEL/CentOS

    озабоченных безопасТностью идиотов с руками из задницы - полным-полно, кто бы в этом сомневался.

    впрочем, как и методичек, написанных такими же, требующими немедленно скачать самую распоследнюю версию незнамочего.

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

     
     
  • 5.31, xl32 (ok), 21:36, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Совместимость? Вы про SSLv2 и SSLv3, я полагаю?
     
  • 3.22, Аноним (22), 21:12, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    При этом им не помешало выпилить некоторые шифры, могли бы это как то через конфиг сделать.
     
     
  • 4.54, пох (?), 07:23, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    через конфиг это должны делать не они, а альтернативно-одаренные авторы софта, использующего библиотеку. Многие, между прочим, и сделали - лет этак десять назад.

    Но мы ж заботимся о пользователях с куриными мозгами (теперь эта "забота" просочилась и в мозги горе-разработчиков библиотек, которые вообще пользователь видеть не должен) - надо им все небезопасТное запретить, запретить, запретить!

    Ну а чего вы хотите, разработчики openssl небось тоже давно в гей эреа проживают.

     
  • 3.32, Michael Shigorin (ok), 21:50, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ну кроме больных, считающих, что чем больше цифирка тем круче шифрование.

    as in https://fedoraproject.org/wiki/Changes/OpenSSL110?

     
     
  • 4.55, Gemorroj (ok), 08:37, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Даунята, которые никогда не обновляются, как раз не обновляются потому что не читают ченжлоги. И считают что раз они нихрена не знают что же поменялось в новой версии, то ничего и не поменялось. Просто проф некомпетентность.
     
     
  • 5.62, Sw00p aka Jerom (?), 14:15, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    >>Даунята, которые никогда не обновляются

    а смысл обновлять, если зависимый софт при этом не обновился? И собственно качество openssl гавёное, такой софт должен быть стабильным, и не инкрементить номерки версий еженедельно.

    пс: работает - не трогай!

     
  • 5.79, Аноним (79), 06:37, 13/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это всё таки слишком сложно для них. По уму - выдачей предупреждений с последующим исправлением - этим должен заниматься менеджер пакетов, в котором должна быть отдельная функциональность в виде специализированной экспертной системы, которая сама фоново занимается поиском проблемных версий программ, библиотек и конфигов, тестирует безопасность машины. Слишком много всего в сети работает на всяких никсах, чтобы позволить себе не иметь такой важной и нужной вещи.
     
     
  • 6.80, Sw00p aka Jerom (?), 22:52, 13/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>Это всё таки слишком сложно для них.

    Должно ли быть всё сложно? Я думал, человек стремится к простоте, промолчу про "ад зависимостей", кто-то с места крикнет про автоматизацию, так вот в ответ - автоматизация разве решает сложности? Что есть сложность? - задумайтесь!

     
  • 3.47, Аноним (47), 01:10, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > а вот поломать совместимость с чем-то,

    А что, в редхатах нельзя поставить рядом две разных версии одной библиотеки?

     

  • 1.6, Kido Katsuragi (?), 19:16, 11/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    С каких пор релиз x.y.Z стал "значительным"? На Semantic Versioning совсем уже всем стало наплевать?
     
     
  • 2.9, Фуррь (ok), 19:56, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Уважаемый, смотрите на changelog, а не на цифирьки, что вы как хипстер, в самом деле.
     
     
  • 3.11, Kido Katsuragi (?), 19:59, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А "циферьки" тогда зачем? Можно же тогда как хром с лисой каждый релиз мажорную версию менять. SM же и придуман чтобы циферьки были не просто так, а несли в себе смысл.
     
     
  • 4.13, A.Stahl (ok), 20:18, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    За смыслом в "цифирьках" это вам к нумерологам или хотя бы в ближайшую церковь. Единственная логика в номере версии -- чем больше число, тем свежее код. И то не всегда.
     
     
  • 5.34, ююю (?), 22:03, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > За смыслом в "цифирьках" это вам к нумерологам или хотя бы в ближайшую церковь.

    И эти люди ещё пытаются что-то там критиковать... Куда катится опеннет.
    Хотя, понятно куда.

     
     
  • 6.77, Аноним (77), 23:55, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Дружок, а тебя не смущает, что ты пробил дно дна опеннета?
    Ведь твоя критика полностью подпадает под твою же критику.
     
  • 4.16, Аноним (16), 20:46, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Можно как с лисой, можно как не с лисой, кому как нравится. Не у вас же спрашивать как версию называть.

    А SemVer бесполезен. К прикладному софту он слабо применим, а для библиотек опирается на совместимость API, которой на деле не существует (про это хорошо рассказано в https://www.youtube.com/watch?v=tISy7EJQPzI), и игнорирует совместимость ABI.

     
     
  • 5.33, Michael Shigorin (ok), 21:55, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да ладно, бесполезен.  Тех, кто не читал дрепперовское dsohowto -- всё равно разве что нашим турбинским set versioning'ом на подлёте шмалять, и то кто-то да пролетит...
     
  • 5.35, ююю (?), 22:12, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А SemVer бесполезен. К прикладному софту он слабо применим

    Вот и выросло поколение Гарри Поттеров.
    Сам ты бесполезен, Анон. Ломаете совместимость - выпускайте мажорную версию.
    Поддержка ранее выпущенных мажорных "релизов" отдельный вопрос.

     
     
  • 6.38, Аноним (38), 23:25, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ломаете совместимость - выпускайте мажорную версию.

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

    Допустим, я исправил уязвимость при чтении некоторых типов файлов, в результате чего на некоторые читавшиеся ранее файлы приложение теперь ругается (даже если в них уязвимости нет). Должен ли я увеличить мажорную версию лишь потому, что совместимость пострадала?

     
     
  • 7.39, ююю (?), 23:49, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    1. нет
    2. нет
    Это крайние случаи, которых стоит избегать с помощью грамотного планирования разработки.
     
     
  • 8.43, Аноним (41), 00:33, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вот и вырасло поколение буратин-теоретиков Что ж ты не пришёл во все проекты ко... текст свёрнут, показать
     
     
  • 9.46, ююю (?), 01:09, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Анон, при всем уважении, ты задаёшь тупые вопросы В тех проектах, где я отвечал... текст свёрнут, показать
     
     
  • 10.60, Аноним (41), 13:15, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вопросы я не задаю, это раз Твой тепличный опыт яйца выеденного не стоит, это д... текст свёрнут, показать
     
  • 10.78, Аноним (77), 00:04, 13/09/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уважаемый, бесполезно говорить с малолетками на серьезные темы, они же ничего не... текст свёрнут, показать
     
  • 6.42, Аноним (41), 00:30, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты даже не удосужился пройти по ссылке. А ты пройди, много нового узнаешь. Совместимость - фикция, и для кого-то её может сломать даже незначительнфй багфикс не затрагивающий API.
     
     
  • 7.63, yet another anonymous (?), 15:19, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Таки да, в подавляющем большинстве --- фикция. Характерный пример --- библиотеки происходящие от GNOME-команды.
     
  • 4.45, AnonPlus (?), 01:05, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    К лисе (не знаю, как к хрому) SM не применим по простой причине - у лисы релиз не зависит от фич или багфиксов, а жёстко привязан к графику. Релиз каждые N недель, то есть, делается срез репозитория, обзывается бетой, неготовые фичи выключаются, отлавливаются баги.

    Что интересно, хающие лису не вспоминают про ядро Linux, которое точно так же релизиться примерно через равные промежутки времени, второе число в версии просто увеличивается на 1, а первое число отражает ощущение Линуса "ну, вроде уже пора" (поинтересуйтесь переходом 3.x -> 4.x").

     
  • 2.17, бедный буратино (ok), 20:49, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    патамучта она бинарно совместима с 1.1.0
     
  • 2.23, Никонор Бонифатич (?), 21:12, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    чтобы "стало плевать", сначала надо семверу следовать. А - тут открытие - не каждое ПО следует семверу.
     
     
  • 3.64, yet another anonymous (?), 15:23, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > чтобы "стало плевать", сначала надо семверу следовать.

    Ему следовать довольно проблематично. Должного покрытия тестами почти никогда нет, а метод пристального вглядывания --- ненадёжен.

     
  • 2.37, Аноним (38), 23:19, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > На Semantic Versioning совсем уже всем стало наплевать?

    Всем адекватным - да.

    Semantic Versioning изначально разрабатывалось для версионирования АПИ. У некоторых, из-за того, что они используют его не по назначению (а например, для версионирования версий софта, для которого оно в большинстве случаев не подходит), это приводит к проблемам, с которыми они отважно борются (можете их багтрекер на гитхабе почитать ради интереса, а не только главную страницу сайта). Другие же, невзирая на моду, просто не пытаются колоть орехи микроскопом.

     
     
  • 3.40, ююю (?), 23:58, 11/09/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > (а например, для версионирования версий софта, для которого оно в большинстве случаев не подходит), это приводит к проблемам

    А можно реальные примеры вашего примера? Желательно со ссылками.
    А то складывается впечатление, что у кого-то просто знания "матчасти" не хватает.
    Буду рад открыть для себя что-то новое.

     
     
  • 4.44, Аноним (41), 00:35, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там сверху ссылка на доклад. Не появляйся сдесь пока его целиком не посмотришь, пожалуйста.
     
     
  • 5.48, ююю (?), 01:11, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    С докладчиком не согласен. Тратить на тебя время тоже желание пропало.
     
     
  • 6.58, Аноним (41), 13:12, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо что честно признал свою неправоту.
     
  • 4.49, Аноним (38), 01:23, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Год-два назад я думал, что СемВер решит все мои проблемы, поэтому решил полазать... большой текст свёрнут, показать
     
     
  • 5.50, ююю (?), 02:13, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Огромное спасибо за такой развернутый ответ Респект ОК, спасибо за наводку ... большой текст свёрнут, показать
     
     
  • 6.56, Онанимус (?), 10:31, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > должны быть новые фичи, чтобы пользователь захотел поставить новую версию.

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

     
     
  • 7.69, your mom (?), 17:08, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, на практике такое встречается когда "проведен глубокий рефакторинг кода, снижено потребление памяти, улучшена стабильность приложения" - единственная фича нового релиза.
     
  • 6.70, yet another anonymous (?), 18:17, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > при этом patchlevel точно описывает: состояние, под какую ось, из какой ветки взят код, номер билда/хэш коммита/дату билда и т.п.

    Во-первых, избыточно (ср.: хеш и ветка; хотя без репозитория, содержащего этот коммит --- бесполезно); во-вторых, недостаточно (ABI, компилятор, etc.); в-третьих, бесполезно (под какую ось,... номер билда, дату билда).

     
  • 6.75, Аноним (75), 22:08, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ситуации разные бывают Представьте, что приложение работает через веб-сервис, а... большой текст свёрнут, показать
     

  • 1.66, timur.davletshin (ok), 16:07, 12/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А в debian зарегистрировали баг на тему совместимости ABI — https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908567
     
     
  • 2.71, пох (?), 19:26, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    это не несовместимость abi, это руки у авторов qt растут из ануса - сперва они требуют от библиотеки поддержки последней возможной в ней версии, вместо последней поддерживаемой собой, или уж не лезть кривыми руками куда не надо вообще, оставив все по-умолчанию, а потом, вдруг "ой, а она нам незнакома, мы не знаем что с этим делать".

    В abi ничего не изменилось, в api тоже - константа не превратилась вдруг в long double вместо int, функция не поменяла свое поведение.

     
     
  • 3.72, timur.davletshin (ok), 19:56, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > это не несовместимость abi, это руки у авторов qt растут из ануса
    > - сперва они требуют от библиотеки поддержки последней возможной в ней
    > версии, вместо последней поддерживаемой собой, или уж не лезть кривыми руками
    > куда не надо вообще, оставив все по-умолчанию, а потом, вдруг "ой,
    > а она нам незнакома, мы не знаем что с этим делать".
    > В abi ничего не изменилось, в api тоже - константа не превратилась
    > вдруг в long double вместо int, функция не поменяла свое поведение.

    Я всё это понимаю, но пользователю от этого не легче.

     
     
  • 4.73, пох (?), 21:05, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ну, следующие дятлы просто намертво залинкуются с libssl.so.1.1.0h, не используя при этом ни одной version-specific фичи (довольно, кстати, распространенный вид идиотизма, как и наоборот, непонимание как надо давать имена файлу, а как - soname) - и их только подменой линка вручную и удастся побороть - это ж не abi виноват.
     
     
  • 5.74, timur.davletshin (ok), 21:27, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если дочитать переписку, то там есть и другие такие же...
     
     
  • 6.76, пох (?), 22:51, 12/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    "что-то я и не удивлен"

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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