The OpenNET Project / Index page

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

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"Выпуск LibreSSL 2.5.2"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск LibreSSL 2.5.2"  +/
Сообщение от opennews (??) on 27-Мрт-17, 09:42 
Разработчики проекта OpenBSD представили (http://www.mail-archive.com/announce@openbsd.org/msg001...) выпуск переносимой редакции пакета LibreSSL 2.5.2 (http://www.libressl.org/), в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. Проект LibreSSL ориентирован на качественную поддержку протоколов SSL/TLS с удалением излишней функциональности, добавлением дополнительных средств защиты и проведением значительной чистки и переработки кодовой базы.


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


-  Добавлена новая функция распределения памяти recallocarray() (http://man.openbsd.org/recallocarray), которая теперь используется вместо reallocarray() в некоторых подсистемах, таких как CBB и BUF_MEM_grow. Новая функция отличается тем, что производит очистку содержимого выделяемых блоков памяти, по аналогии с calloc(), а также обнуляет или отдаёт системе (unmap) не распределённые блоки памяти;

-  В список корневых сертификатов добавлен сертификат удостоверяющего центра SECOM Trust Systems;
-  Добавлена возможность использования интерфейса  EVP (https://wiki.openssl.org/index.php/EVP) для хэшей  MD5+SHA1;
-  Налажена обработка добавочного заполнения при обновлении запроса SSLv2 до соединения SSLv3/TLS;

-  Для реализаций протоколов и шифров предоставлена возможность установки конфигурационных объёктов TLS в libtls;

-  Снижена нагрузка на CPU при согласовании TLS-соединения при использовании утилиты nc.


URL: http://www.mail-archive.com/announce@openbsd.org/msg001...
Новость: http://www.opennet.ru/opennews/art.shtml?num=46259

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

Оглавление

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


1. "Выпуск LibreSSL 2.5.2"  –19 +/
Сообщение от Аноним (??) on 27-Мрт-17, 09:42 
Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Выпуск LibreSSL 2.5.2"  –3 +/
Сообщение от Анончик on 27-Мрт-17, 10:07 
> Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.

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

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

3. "Выпуск LibreSSL 2.5.2"  –1 +/
Сообщение от Аноним (??) on 27-Мрт-17, 10:12 
Удивляет даже, что это вообще упоминается в чейнджлоге новости. Каждый раз переизобретают колёса: в glib разве уже нет специальных функций вроде g_slice_alloc0? А тут это преподносится как инновационное супердостижение.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

8. "Выпуск LibreSSL 2.5.2"  –1 +/
Сообщение от 1 (??) on 27-Мрт-17, 11:08 
про "переносимость" не дочитал ?
Где-то есть glibc, а где-то и нет.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

10. "Выпуск LibreSSL 2.5.2"  +1 +/
Сообщение от S.Atahl on 27-Мрт-17, 11:20 
Берешь любой опенсорц-проект на си, заглядываешь в исходники -- нет-нет, да и там найдется своя собственная версия super_calloc. Где ж ваша хваленая стандартизация? И эти люди что-то там говорят про left-pad.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

18. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от Sw00p aka Jerom on 27-Мрт-17, 15:17 
а что в super_calloc не используется функция malloc, calloc, free и тд. ?
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

20. "Выпуск LibreSSL 2.5.2"  +1 +/
Сообщение от Аноним (??) on 27-Мрт-17, 16:25 
> И эти люди что-то там говорят про left-pad.

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

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

32. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 30-Мрт-17, 14:49 
> про "переносимость" не дочитал ?
> Где-то есть glibc, а где-то и нет.

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

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

5. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от Andrey Mitrofanov on 27-Мрт-17, 10:54 
>> Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.
> А у них есть выбор?

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

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

4. "Выпуск LibreSSL 2.5.2"  +9 +/
Сообщение от A.Stahl (ok) on 27-Мрт-17, 10:53 
Шёл уже пятый десяток лет безуспешных попыток создать язык лучше Си...
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

6. "Выпуск LibreSSL 2.5.2"  –2 +/
Сообщение от S.Atahl on 27-Мрт-17, 10:58 
А правда, что у вас там нет исключений, и вам приходится как обезьянам проверять ошибки непосредственно после вызова какой-либо функции?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Выпуск LibreSSL 2.5.2"  +3 +/
Сообщение от A.Stahl (ok) on 27-Мрт-17, 11:00 
Да я и в плюсах не использую исключения -- уж очень у них некрасивый синтаксис на мой вкус.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

11. "Выпуск LibreSSL 2.5.2"  +1 +/
Сообщение от S.Atahl on 27-Мрт-17, 11:26 
> Да я и в плюсах не использую исключения -- уж очень у
> них некрасивый синтаксис на мой вкус.

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


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;


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

14. "Выпуск LibreSSL 2.5.2"  +2 +/
Сообщение от Mihail Zenkov (ok) on 27-Мрт-17, 14:05 
Для 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;

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

15. "Выпуск LibreSSL 2.5.2"  –1 +/
Сообщение от S.Atahl on 27-Мрт-17, 14:18 
А errno что, глобальная переменная? Прямо как в старом добром QBASIC.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от Mihail Zenkov (ok) on 27-Мрт-17, 14:21 
> А errno что, глобальная переменная?

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

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

19. "Выпуск LibreSSL 2.5.2"  +3 +/
Сообщение от Аноним (??) on 27-Мрт-17, 16:21 
Во-первых, ЧИТАБЕЛЬНЫЙ вариант на Си выглядит как описано ниже, а не как у вас с кучей лишних строк, фигурных скобок где только возможно и лишних переменных типа 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();
}

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

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

24. "Выпуск LibreSSL 2.5.2"  +2 +/
Сообщение от Аноним (??) on 27-Мрт-17, 23:59 
> перед вызовом fallback вам ещё нужно какие-то ресурсы освободить

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

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

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

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

25. "Выпуск LibreSSL 2.5.2"  +1 +/
Сообщение от Аноним (??) on 28-Мрт-17, 01:39 
> деструктор закроет "fs" ещё до начала выполнения блока "catch"

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

Проблема в том, что чтобы понять, как в этом случае себя ведёт код, нужно ЗНАТЬ, как работают исключения в конкретном языке (как вы написали, в разных языках есть свои особенности), знать, как РЕАЛИЗОВАН деструктор (вызывает ли он close()) и в каких случаях он вызывается компилятором/средой выполнения. В Си же вся логика локализована в одном месте (в нашей функции) и как оно будет работать можно оттрейсить "глазами".

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

28. "Выпуск LibreSSL 2.5.2"  –1 +/
Сообщение от Crazy Alex (ok) on 28-Мрт-17, 16:20 
теоретически - да. В абсолютном большинстве случаев на это можно забить. А в тех, когда нельзя - приходится кроме этого проверять такую тучу нюансов, что урод получается вообще на любом языке.

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

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

27. "Выпуск LibreSSL 2.5.2"  +1 +/
Сообщение от Пользователь Debian on 28-Мрт-17, 09:40 
RAII хорош, но он решает не все проблемы.

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

  a = b;

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

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

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

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

29. "Выпуск LibreSSL 2.5.2"  –1 +/
Сообщение от Crazy Alex (ok) on 28-Мрт-17, 16:36 
Человек не в курсе, что обработку исключительных ситуаций надо проектировать как часть архитектуры, только и всего. Если что - с квалификацией программиста, особенно тех, кто довольно низкоуровневыми вещами занимается, это обычно не связано. А вот тут - не свезло, судя по всему.

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

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

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

30. "Выпуск LibreSSL 2.5.2"  –1 +/
Сообщение от Mihail Zenkov (ok) on 28-Мрт-17, 20:49 
> Когда у вас миллионы строк выгоднее другое. вот те самые ООП, изоляция,
> проектирование исключительных ситуаций и их обработки, четко формализованные принципы
> "когда что использовать", правила именования и прочее.

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

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

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

31. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от Аноним (??) on 29-Мрт-17, 02:00 
> Самое забавное, что в итоге программы на c++ не меньше по объему кода, а больше. Достаточно вспомнить про qt, boost, ff. Иногда возникает такое чувство, что классы и объекты самостоятельно размножаются :)

А так и есть, на плюсах обертки часто занимают место гораздо больше чем сам код. Как результат - появляются интересные печатные труды на подобие классической монографии "о переливании из пустого в порожнее" Фаулера.

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

21. "Выпуск LibreSSL 2.5.2"  +4 +/
Сообщение от Аноним (??) on 27-Мрт-17, 16:39 
> вам приходится как обезьянам проверять ошибки

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

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

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

36. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от Michael Shigorin email(ok) on 30-Мрт-17, 15:52 
> А правда, что у вас там нет исключений, и вам приходится как
> обезьянам проверять ошибки непосредственно после вызова какой-либо функции?

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

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

13. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от YetAnotherOnanym (ok) on 27-Мрт-17, 13:21 
> Сишники до сих пор копаются в своих alloc/calloc/malloc

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

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

35. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от Michael Shigorin email(ok) on 30-Мрт-17, 15:46 
> Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.

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

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

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

9. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от Аноним (??) on 27-Мрт-17, 11:18 
Что там с nc? Разве оно ещё и SSL умеет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от Mihail Zenkov (ok) on 27-Мрт-17, 14:20 
> Что там с nc? Разве оно ещё и SSL умеет?

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

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

26. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от Аноним (??) on 28-Мрт-17, 02:21 
socat умеет
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

33. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 30-Мрт-17, 14:55 
> Что там с nc? Разве оно ещё и SSL умеет?

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

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

23. "Выпуск LibreSSL 2.5.2"  –1 +/
Сообщение от Ilya Indigo (ok) on 27-Мрт-17, 20:50 
Интересно, почему DistroWatch заклинило на версии 2.4.5 и он её считает последней и не сообщает о свежих версиях?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

34. "Выпуск LibreSSL 2.5.2"  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 30-Мрт-17, 14:56 
> Интересно, почему DistroWatch заклинило на версии 2.4.5 и он её считает последней
> и не сообщает о свежих версиях?

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

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

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

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

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


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