The OpenNET Project / Index page

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

27.03.2017 09:15  Выпуск LibreSSL 2.5.2

Разработчики проекта 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
Тип: Программы
Ключевые слова: libressl, crypt
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | 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 +/
    Удивляет даже, что это вообще упоминается в чейнджлоге новости Каждый раз переи... весь текст скрыт [показать]
     
     
  • 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 +/
    > Да я и в плюсах не использую исключения -- уж очень у
    > них некрасивый синтаксис на мой вкус.

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

    [code]
    try {
      return unsafe_op1(unsafe_op2(unsafe_op3()));
    } catch (e) {
      return fallback();
    }
    [/code]

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

    [code]
    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;
    [/code]

     
     
  • 6.14, Mihail Zenkov (ok), 14:05, 27/03/2017 [^] [ответить]    [к модератору]  
  • +2 +/
    Для C скорее будет:
    [code]
    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;
    [/code]

    или

    [code]
    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;
    [/code]


    Обычно приходится видеть что-то типа:
    [code]
    try {
        int* array= new int[1000];
    }
    catch (exception& e) {
        cout << "Standard exception: " << e.what() << endl;
        return(-1);
    }
    return 0;
    [/code]

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

     
     
  • 7.15, S.Atahl (?), 14:18, 27/03/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    А errno что, глобальная переменная? Прямо как в старом добром QBASIC.
     
     
  • 8.17, Mihail Zenkov (ok), 14:21, 27/03/2017 [^] [ответить]    [к модератору]  
  • +/
    > А errno что, глобальная переменная?

    https://en.wikipedia.org/wiki/Errno.h

     
  • 6.19, Аноним (-), 16:21, 27/03/2017 [^] [ответить]     [к модератору]  
  • +3 +/
    Во-первых, ЧИТАБЕЛЬНЫЙ вариант на Си выглядит как описано ниже, а не как у вас с... весь текст скрыт [показать]
     
     
  • 7.24, Аноним (-), 23:59, 27/03/2017 [^] [ответить]     [к модератору]  
  • +2 +/
    В C , при всех его недостатках, эта проблема легко решается деструкторами RAII... весь текст скрыт [показать]
     
     
  • 8.25, Аноним (-), 01:39, 28/03/2017 [^] [ответить]     [к модератору]  
  • +1 +/
    Главное, не забыть в деструкторе проверить uncaught_exception на случай, если ... весь текст скрыт [показать]
     
     
  • 9.28, Crazy Alex (ok), 16:20, 28/03/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    теоретически - да. В абсолютном большинстве случаев на это можно забить. А в тех, когда нельзя - приходится кроме этого проверять такую тучу нюансов, что урод получается вообще на любом языке.

    Последние три года я пишу практичсеки только на сях довольно крупную штуку, и уже никких матов нет на отсутствие исключений. Что самое смешное - в go хоть они и есть, но ошибки обрабатываются таким же уродским сопосбом, что и в сях.

     
  • 8.27, Пользователь Debian (?), 09:40, 28/03/2017 [^] [ответить]    [к модератору]  
  • +1 +/
    RAII хорош, но он решает не все проблемы.

    Грубо говоря, в языке с исключениями (и особенно — в C++ с его контекстно-зависимой
    грамматикой, когда конкретный код, который будет вызван в высказывании

      a = b;

    зависит от типа a, от того, инициализирована ли эта переменная, а также от типа b),
    и потому просто читая код, человеку невозможно понять, в какой именно точке он может взорваться.  Проще говоря, в программе на C++ это почти любой сивмол в исходном коде.

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

    Вот тут <http://250bpm.com/blog:4> это всё изложено предельно доступно.

     
     
  • 9.29, Crazy Alex (ok), 16:36, 28/03/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    Человек не в курсе, что обработку исключительных ситуаций надо проектировать как часть архитектуры, только и всего. Если что - с квалификацией программиста, особенно тех, кто довольно низкоуровневыми вещами занимается, это обычно не связано. А вот тут - не свезло, судя по всему.

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

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

     
     
  • 10.30, Mihail Zenkov (ok), 20:49, 28/03/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    > Когда у вас миллионы строк выгоднее другое. вот те самые ООП, изоляция,
    > проектирование исключительных ситуаций и их обработки, четко формализованные принципы
    > "когда что использовать", правила именования и прочее.

    Самое забавное, что в итоге программы на c++ не меньше по объему кода, а больше. Достаточно вспомнить про qt, boost, ff. Иногда возникает такое чувство, что классы и объекты самостоятельно размножаются :)

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

     
     
  • 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:
    Заголовок:
    Текст:


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