The OpenNET Project / Index page

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

Выпуск LibreSSL 2.5.2

27.03.2017 09:15

Разработчики проекта OpenBSD представили выпуск переносимой редакции пакета LibreSSL 2.5.2, в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. Проект LibreSSL ориентирован на качественную поддержку протоколов SSL/TLS с удалением излишней функциональности, добавлением дополнительных средств защиты и проведением значительной чистки и переработки кодовой базы.

Особенности LibreSSL 2.5.2:

  • Добавлена новая функция распределения памяти recallocarray(), которая теперь используется вместо reallocarray() в некоторых подсистемах, таких как CBB и BUF_MEM_grow. Новая функция отличается тем, что производит очистку содержимого выделяемых блоков памяти, по аналогии с calloc(), а также обнуляет или отдаёт системе (unmap) не распределённые блоки памяти;
  • В список корневых сертификатов добавлен сертификат удостоверяющего центра SECOM Trust Systems;
  • Добавлена возможность использования интерфейса EVP для хэшей MD5+SHA1;
  • Налажена обработка добавочного заполнения при обновлении запроса SSLv2 до соединения SSLv3/TLS;
  • Для реализаций протоколов и шифров предоставлена возможность установки конфигурационных объёктов TLS в libtls;
  • Снижена нагрузка на CPU при согласовании TLS-соединения при использовании утилиты nc.


  1. Главная ссылка к новости (http://www.mail-archive.com/an...)
  2. OpenNews: Новые выпуски LibreSSL 2.5.1, 2.4.5 и 2.3.10
  3. OpenNews: Обновление LibreSSL 2.3.9/2.4.4 и GnuTLS 3.5.6 с устранением DoS-уязвимости
  4. OpenNews: Выпуск LibreSSL 2.5.0
  5. OpenNews: DragonFly BSD перешел на LibreSSL по умолчанию
  6. OpenNews: Выпуск LibreSSL 2.4.0
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/46259-libressl
Ключевые слова: libressl, crypt
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (34) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 09:42, 27/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –19 +/
    Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.
     
     
  • 2.2, Анончик (?), 10:07, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.

    А у них есть выбор?

     
     
  • 3.3, Аноним (-), 10:12, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Удивляет даже, что это вообще упоминается в чейнджлоге новости. Каждый раз переизобретают колёса: в glib разве уже нет специальных функций вроде g_slice_alloc0? А тут это преподносится как инновационное супердостижение.
     
     
  • 4.8, 1 (??), 11:08, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    про "переносимость" не дочитал ?
    Где-то есть glibc, а где-то и нет.
     
     
  • 5.10, S.Atahl (?), 11:20, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Берешь любой опенсорц-проект на си, заглядываешь в исходники -- нет-нет, да и там найдется своя собственная версия super_calloc. Где ж ваша хваленая стандартизация? И эти люди что-то там говорят про left-pad.
     
     
  • 6.18, Sw00p aka Jerom (?), 15:17, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    а что в super_calloc не используется функция malloc, calloc, free и тд. ?
     
  • 6.20, Аноним (-), 16:25, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И эти люди что-то там говорят про left-pad.

    Как будто мы этот super_calloc при каждой компиляции с левого сервака качаем.

     
  • 5.32, PereresusNeVlezaetBuggy (ok), 14:49, 30/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > про "переносимость" не дочитал ?
    > Где-то есть glibc, а где-то и нет.

    Эм. glibc и glib — как бы разные вещи. Впрочем, обе по-любому не подходят из-за их лицензий...

     
  • 3.5, Andrey Mitrofanov (?), 10:54, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.
    > А у них есть выбор?

    Конечно! Десятое правло https://packages.debian.org/source/sid/libgc Гринспена -- решает. </и почту читать>

     
  • 2.4, A.Stahl (ok), 10:53, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Шёл уже пятый десяток лет безуспешных попыток создать язык лучше Си...
     
     
  • 3.6, S.Atahl (?), 10:58, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А правда, что у вас там нет исключений, и вам приходится как обезьянам проверять ошибки непосредственно после вызова какой-либо функции?
     
     
  • 4.7, A.Stahl (ok), 11:00, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да я и в плюсах не использую исключения -- уж очень у них некрасивый синтаксис на мой вкус.
     
     
  • 5.11, S.Atahl (?), 11:26, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да я и в плюсах не использую исключения -- уж очень у
    > них некрасивый синтаксис на мой вкус.

    В нормальных языках:




    try {
      return unsafe_op1(unsafe_op2(unsafe_op3()));
    } catch (e) {
      return fallback();
    }


    В няшной сишке (в режиме "никакого некрасивого синтаксиса"):




    int result3;
    int error3 = unsafe_op3(&result3);

    if (error3) {
      return fallback();
    }

    int result2;
    int error2 = unsafe_op2(result3, &result2);

    if (error2) {
      return fallback();
    }

    int result1;
    int error1 = unsafe_op1(result2, &result1);

    if (error1) {
      return fallback();
    }

    return result1;



     
     
  • 6.14, Mihail Zenkov (ok), 14:05, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Для C скорее будет:



    int result;

    result = unsafe_op3();
    if (errno)
      return fallback();

    result = unsafe_op2(result);
    if (errno)
      return fallback();

    result = unsafe_op1(result);
    if (errno)
      return fallback();

    return result;


    или




    int result;

    unsafe_op3(&result);
    if (errno)
      return fallback();

    unsafe_op2(&result);
    if (errno)
      return fallback();

    unsafe_op1(&result);
    if (errno)
      return fallback();

    return result;



    Обычно приходится видеть что-то типа:



    try {
        int* array= new int[1000];
    }
    catch (exception& e) {
        cout << "Standard exception: " << e.what() << endl;
        return(-1);
    }
    return 0;





    int* array = malloc(1000 * sizeof(int));
    if (!array) {
        printf("malloc failed\n");
        return(-1);
    }
    return 0;



     
     
  • 7.15, S.Atahl (?), 14:18, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А errno что, глобальная переменная? Прямо как в старом добром QBASIC.
     
     
  • 8.17, Mihail Zenkov (ok), 14:21, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    https en wikipedia org wiki Errno h ... текст свёрнут, показать
     
  • 6.19, Аноним (-), 16:21, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Во-первых, ЧИТАБЕЛЬНЫЙ вариант на Си выглядит как описано ниже, а не как у вас с кучей лишних строк, фигурных скобок где только возможно и лишних переменных типа error1:



    int r1, r2, r3;

    if (!unsafe_op3(&r3))
      goto fallback;

    if (!unsafe_op2(&r2, r3))
      goto fallback;

    if (!unsafe_op1(&r1, r2))
      goto fallback;

      return r1;

    fallback:
      return fallback();


    Во-вторых, сказки не надо рассказывать, какие хорошие эти исключения. В этих ваших C++/Java/Python всё построено на объектах, и во-первых у вас в коде появится вызов конструктора для ваших unsafe_ (а в особо клинических случаях ещё и деструктор ручками вызывать придётся в каких-нибудь finally, при этом следя, чтобы вызывать деструкторы только для переменных, которые были инициализированы успешно), во-вторых если вы получаете исключение, то перед вызовом fallback вам ещё нужно какие-то ресурсы освободить.

    Из-за всех этих сложностей 99% ошибок обрабатываются методом "пробрасываем исключение до main(), а там выводим стектрейс в лог и завершаем программу". К чести исключений скажу, что 99% ошибок и невозможно обработать в коде, и вывести ошибку в лог и завершиться - единственный возможный вариант, и механизм исключений оптимизирован именно для этих случаев.

    Но в половине, если не больше, реальных приложений, использующих исключения, происходит что-то типа




    try
    {
      file_stream fs;
      fs.open();
      fs.write();
      fs.read();
      fs.write();
      fs.read();
      fs.close();
    }
    catch (e)
    {
      // что будет если fs не был закрыт? да не может такого быть, я же написал fs.close() выше
      return fallback();
    }


    Не верите мне - почитайте Спольски.

     
     
  • 7.24, Аноним (-), 23:59, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > перед вызовом fallback вам ещё нужно какие-то ресурсы освободить

    В C++, при всех его недостатках, эта проблема легко решается деструкторами (RAII и всё такое), вызов которых только для инициализированных объектов в порядке, обратном порядку их создания, обеспечивается компилятором. И не надо никаких жабских try-with-resources, питоновских "with", шарповских "using" и прочих подобных костылей, призванных компенсировать неопределённость/непредсказуемость момента и порядка уничтожения объектов.

    > что будет если fs не был закрыт?

    Если автор класса "file_stream" не совсем дурак, то деструктор закроет "fs" ещё до начала выполнения блока "catch" из-за выхода объекта из его области видимости. К.О.

     
     
  • 8.25, Аноним (-), 01:39, 28/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Главное, не забыть в деструкторе проверить uncaught_exception на случай, если ... текст свёрнут, показать
     
     
  • 9.28, Crazy Alex (ok), 16:20, 28/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    теоретически - да В абсолютном большинстве случаев на это можно забить А в тех... текст свёрнут, показать
     
  • 8.27, Пользователь Debian (?), 09:40, 28/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    RAII хорош, но он решает не все проблемы Грубо говоря, в языке с исключениями ... текст свёрнут, показать
     
     
  • 9.29, Crazy Alex (ok), 16:36, 28/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Человек не в курсе, что обработку исключительных ситуаций надо проектировать как... текст свёрнут, показать
     
     
  • 10.30, Mihail Zenkov (ok), 20:49, 28/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Самое забавное, что в итоге программы на c не меньше по объему кода, а больше ... текст свёрнут, показать
     
     
  • 11.31, Аноним (-), 02:00, 29/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А так и есть, на плюсах обертки часто занимают место гораздо больше чем сам код ... текст свёрнут, показать
     
  • 4.21, Аноним (-), 16:39, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > вам приходится как обезьянам проверять ошибки

    Проверка ошибок - это вообще обезьянья работа. Но хипстерам не понять, за них ошибки пользователи ищут.

    А ещё мы как обезьяны их обрабатываем - и не всегда завершением работы с выводом в лог стектрейса.

     
  • 4.36, Michael Shigorin (ok), 15:52, 30/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А правда, что у вас там нет исключений, и вам приходится как
    > обезьянам проверять ошибки непосредственно после вызова какой-либо функции?

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

     
  • 2.13, YetAnotherOnanym (ok), 13:21, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Сишники до сих пор копаются в своих alloc/calloc/malloc

    Видишь alloc/calloc/malloc в компиляторе/интерпретаторе/виртмашине своего любимого языка? - Нет... - А они там есть!

     
  • 2.35, Michael Shigorin (ok), 15:46, 30/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.

    Хозяйке на заметку: с этого же адреса будто по методичке "критиковали" (бездарно притом) ODF и адвокасили MSO, ну и баловались вещанием как бы в несколько ников хором.

    Призовая ссылка: http://wiki.opennet.ru/MSSP

     

  • 1.9, Аноним (-), 11:18, 27/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что там с nc? Разве оно ещё и SSL умеет?
     
     
  • 2.16, Mihail Zenkov (ok), 14:20, 27/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Что там с nc? Разве оно ещё и SSL умеет?

    Сам не умеет, но может использоваться совместно с openssl:
    https://en.wikipedia.org/wiki/Netcat#Proxying

     
  • 2.26, Аноним (-), 02:21, 28/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    socat умеет
     
  • 2.33, PereresusNeVlezaetBuggy (ok), 14:55, 30/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Что там с nc? Разве оно ещё и SSL умеет?

    В OpenBSD умеет. И он же поставляется в комплекте с LibreSSL.

     

  • 1.23, Ilya Indigo (ok), 20:50, 27/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Интересно, почему DistroWatch заклинило на версии 2.4.5 и он её считает последней и не сообщает о свежих версиях?
     
     
  • 2.34, PereresusNeVlezaetBuggy (ok), 14:56, 30/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, почему DistroWatch заклинило на версии 2.4.5 и он её считает последней
    > и не сообщает о свежих версиях?

    Потому что ему никто не помог, очевидно.

    DistroWatch вообще не слишком точная площадка, но многие пользуются за неимением лучшего...

     

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



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

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