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

"Значительный выпуск криптографической библиотеки OpenSSL 1.1.1"	+/–
Сообщение от opennews (??), 11-Сен-18, 18:56
После двух лет разработки состоялся (https://www.openssl.org/blog/blog/2018/09/11/release111/)  релиз библиотеки OpenSSL 1.1.1 (https://www.openssl.org) с реализацией протоколов SSL/TLS и различных алгоритмов шифрования. Новая ветка включает изменения, нарушающие обратную совместимость на уровне API. Поддержка выпуска OpenSSL 1.1.1 будет осуществляться (https://www.openssl.org/policies/releasestrat.html) в течение пяти лет. Основные новшества (https://www.openssl.org/news/openssl-1.1.1-notes.html) OpenSSL 1.1.1: -  Поддержка TLS 1.3 (https://www.opennet.dev/opennews/art.shtml?num=49126), который представляет собой улучшенную версию протокола TLS и отличается удалением устаревших и ненадёжных криптографических примитивов (MD5, SHA-224) и возможностей (сжатие, повторное согласование, не-AEAD шифры, статический обмен ключами RSA и DH, указание unix-времени в Hello-сообщениях и т.п.), работает только в режиме forward secrecy (компрометации одного из долговременных ключей не позволяет расшифровать перехваченный сеанс), обеспечивает более высокую производительность, поддерживает режим 0-RTT (устраняет задержки при согласовании соединений), поддерживает потоковый шифр ChaCha20 (http://cr.yp.to/chacha.html), алгоритм аутентификации сообщений (MAC) Poly1305 (http://cr.yp.to/mac.html), ключи аутентификации на основе цифровых подписей Ed25519, HKDF (https://en.wikipedia.org/wiki/HKDF) (HMAC-based Extract-and-Expand Key Derivation Function), ключи на основе алгоритмов x25519 (https://en.wikipedia.org/wiki/Curve25519) (RFC 7748 (https://tools.ietf.org/html/rfc7748)) и x448 (RFC 8031 (https://tools.ietf.org/html/rfc8031)); -  Настройки конфигурации перенесены в файл configdata.pm; -  Обеспечена возможность использования в сборочном скрипте Configure  переменных для утилиты make в стиле GNU; -  Новый модуль STORE (OSSL_STORE); -  Определены пространства имён OSSL и OPENSSL, реализованные в виде префиксов; -  Добавлена поддержка формирования ключей RSA  на основе более чем двух случайных простых чисел (multi-prime, RFC 8017 (https://tools.ietf.org/html/rfc8017)); -  Реализованы криптографические хэши SM3 (GB/T 32905-2016) и SM4 (GB/T 32907-2016), стандартизированные для учреждений Китая;   -  Поддержка расширения TLS для согласования максимального размера фрагмента; -  Поддержка алгоритма симметричного блочного шифрования  ARIA (https://ru.wikipedia.org/wiki/ARIA_(%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%8F)); -  Поддержка алгоритма хэширования SHA3; -  Поддержка  хеш-функции SipHash; -  Переписан движок devcrypto; -  Значительная переработка  встроенного генератора псевдослучайных чисел. URL: https://www.mail-archive.com/openssl-announce@openssl.o... Новость: https://www.opennet.dev/opennews/art.shtml?num=49255
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

2. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–1 +/–
Сообщение от Аноним (2), 11-Сен-18, 19:02
А в RHEL даже 1.1.0 не завезли.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–1 +/–
	Сообщение от IRASoldier (?), 11-Сен-18, 19:11
	Комментарии на офсайте по этому поводу: https://access.redhat.com/discussions/3440141
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–11 +/–
	Сообщение от rhel (?), 11-Сен-18, 19:13
	потому что он нахрен не нужен. ну кроме больных, считающих, что чем больше цифирка тем круче шифрование. а вот поломать совместимость с чем-то, что, ну надо же, не использует модных-современных шифров (и вполне надежно защищено другими способами - периметром, внутренней аутентификацией и т д) - мы совершенно не хотим без острой необходимости.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	7. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+3 +/–
	Сообщение от xl32 (ok), 11-Сен-18, 19:48
	TLS 1.3 очень нужен. Смотрю количество скачиваний апача и nginx на codeit.guru для RHEL/CentOS и диву даюсь, что не завозят даже 1.1.0 штатно.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+3 +/–
	Сообщение от Аноним (8), 11-Сен-18, 19:52
	Где логика? В 1.1.0 tls 1.3 нет. Он есть в 1.1.1, который релизнулся буквально сегодня. Зачем тащить в RHEL 1.1.0, если это и новый tls не даст, и совместимость сломает?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	30. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–2 +/–
	Сообщение от xl32 (ok), 11-Сен-18, 21:35
	Очень простой ответ: новые шифры, новые фичи. 1.0.2 же появился в RHEL взамен 1.0.1, появился ALPN.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	61. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Виталик (??), 12-Сен-18, 14:08
	Даже на попеннете нет 1.3, а вы говорите о тырпрайзе.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	10. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–2 +/–
	Сообщение от Kido Katsuragi (?), 11-Сен-18, 19:57
	А можно для нуба кратко объяснить зачем TLS 1.3 нужен? Что он дает админу или конечному потребителю? Я сам сетевик, в глубокие глубины работы http-серверов и https не залезал, дальше чем поставить apache для nextcloud/wordpress с lets encrypt чтобы в браузере открывалось не вникал.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	12. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–2 +/–
	Сообщение от CHERTS (ok), 11-Сен-18, 20:12
	А прочитать первый абзац в статье не можете? >>Поддержка TLS 1.3 (https://www.opennet.dev/opennews/art.shtml?num=49126), который представляет собой улучшенную версию протокола TLS и отличается удалением устаревших и ненадёжных криптографических примитивов (MD5, SHA-224) и возможностей (сжатие, повторное согласование, .....
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	14. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от An (??), 11-Сен-18, 20:27
	режим - forward secrecy
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	36. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+2 +/–
	Сообщение от Ага (?), 11-Сен-18, 22:20
	Perfect forward secrecy уже давно в ходу начиная tls 1.0 и шифрами использующими DH
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	41. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–1 +/–
	Сообщение от Аноним (41), 12-Сен-18, 00:27
	Только теперь это единственный возможный режим. Раньше нужно было прикладывать усилия чтобы поотключать не-pfs шифры, это делали единицыи pfs по факту не было.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	52. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от пох (?), 12-Сен-18, 07:14
	умелец, умудрившийся настроить сервер так, чтобы выбрался не-pfs шифр или кто-то третий заставил сдаунгрейдиться протокол при более-менее нормальном софте у клиента (хотя бы 2016го года выпуска) - прое%#т ваши данные еще миллионом других, гораздо более простых путей, например, они просто будут скачаны всеми желающими через http://site/backup/ (где будет даже индекс. умения потребны примерно одного порядка) а теперь да - "единственно возможное ненужно", и если ты, внезапно, оказался в месте, где pfs наxeр тебе не вcpался, но его там и нет - то слососи тyнцa, что ж ты такой нешифровано-непродвинутый, не будет с тобой хипста-сайт разговаривать. хотя эти котики нахрен, скорее всего, никому не сдались, и шифрование там для гуглялочки.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	26. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–2 +/–
	Сообщение от пох (?), 11-Сен-18, 21:20
	объясняю: вам - низачем. админу локалхоста и конечному потребителю котиков он ничего и не дает. хаксор васья не сможет расшифровать ваших котиков, выливаемых на нёхклауд (на самом деле он этого не сможет по тридцатитрем причинам, причина первая - он не умеет даже подключиться к вашему кабелю, не сломав вам сеть), даже если вы не используете модный мутный шифр chacha. если вы - резидент шпионской сети иностранного государства, только прикидываетесь белым и пушистым админчегом локалхостика - то, теоретически, если вы успели с его территории унести ноги и ректальный криптоанализатор вам не грозит, tls1.3 способен слегка застраховать вас от явных глупостей в конфигурациях серверов, которые понапихал туда проспанный вами внедренный агент (потому что по ошибке это сделать просто невозможно), и сделать кратковременный успех товарищ майора, перехватившего ваши сессионные ключи слишком поздно, достаточно бесполезным для дела. но грамотно настроенный сервер с tls>1.0 в общем-то ничем не хуже, а tls=1.0 - весьма эфемерно хуже. Шанс присесть на бутылочку явно выше, чем шанс взлома товарищ-майором-фсб tls1.0, настроенного на от'сь, а не с заведомо диверсионной целью.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	29. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–2 +/–
	Сообщение от xl32 (ok), 11-Сен-18, 21:34
	Очень просто: новые шифры, новые фичи. 1.0.2 же появился в RHEL взамен 1.0.1, появился ALPN.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	53. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–1 +/–
	Сообщение от пох (?), 12-Сен-18, 07:19
	от этого alpn хотя бы теоретическая польза есть (правда, практическая есть только если alpn у гугля/ставосьми других вонючих cdn с которых альтернативно-одаренный разработчик заставляет тебя грузить всякий мусор, но там нет редхата, там гугль либо последняя убунточка - а с основным сайтом, на который тебя угораздило зайти, видимой глазу пользы не будет) От 111 - никакой вообще.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	21. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–8 +/–
	Сообщение от пох (?), 11-Сен-18, 21:11
	кому нужен? Ушибленным цифирками версий, неспособным понять, что он практически ничего им лично не добавит к безопасТносте, зато очень даже убавит совместимости? > Смотрю количество скачиваний апача и nginx на codeit.guru для RHEL/CentOS озабоченных безопасТностью идиотов с руками из задницы - полным-полно, кто бы в этом сомневался. впрочем, как и методичек, написанных такими же, требующими немедленно скачать самую распоследнюю версию незнамочего. "не завозят" вам потому,что покупатели rhel к таковым не относятся, ну, по крайней мере, в большинстве своем. У них совсем-совсем другие задачи.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	31. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от xl32 (ok), 11-Сен-18, 21:36
	Совместимость? Вы про SSLv2 и SSLv3, я полагаю?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	22. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Аноним (22), 11-Сен-18, 21:12
	При этом им не помешало выпилить некоторые шифры, могли бы это как то через конфиг сделать.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	54. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–2 +/–
	Сообщение от пох (?), 12-Сен-18, 07:23
	через конфиг это должны делать не они, а альтернативно-одаренные авторы софта, использующего библиотеку. Многие, между прочим, и сделали - лет этак десять назад. Но мы ж заботимся о пользователях с куриными мозгами (теперь эта "забота" просочилась и в мозги горе-разработчиков библиотек, которые вообще пользователь видеть не должен) - надо им все небезопасТное запретить, запретить, запретить! Ну а чего вы хотите, разработчики openssl небось тоже давно в гей эреа проживают.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	32. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+2 +/–
	Сообщение от Michael Shigorin (ok), 11-Сен-18, 21:50
	> ну кроме больных, считающих, что чем больше цифирка тем круче шифрование. as in https://fedoraproject.org/wiki/Changes/OpenSSL110?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	55. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Gemorroj (ok), 12-Сен-18, 08:37
	Даунята, которые никогда не обновляются, как раз не обновляются потому что не читают ченжлоги. И считают что раз они нихрена не знают что же поменялось в новой версии, то ничего и не поменялось. Просто проф некомпетентность.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	62. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–5 +/–
	Сообщение от Sw00p aka Jerom (?), 12-Сен-18, 14:15
	>>Даунята, которые никогда не обновляются а смысл обновлять, если зависимый софт при этом не обновился? И собственно качество openssl гавёное, такой софт должен быть стабильным, и не инкрементить номерки версий еженедельно. пс: работает - не трогай!
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	79. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–1 +/–
	Сообщение от Аноним (79), 13-Сен-18, 06:37
	Это всё таки слишком сложно для них. По уму - выдачей предупреждений с последующим исправлением - этим должен заниматься менеджер пакетов, в котором должна быть отдельная функциональность в виде специализированной экспертной системы, которая сама фоново занимается поиском проблемных версий программ, библиотек и конфигов, тестирует безопасность машины. Слишком много всего в сети работает на всяких никсах, чтобы позволить себе не иметь такой важной и нужной вещи.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	80. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Sw00p aka Jerom (?), 13-Сен-18, 22:52
	>>Это всё таки слишком сложно для них. Должно ли быть всё сложно? Я думал, человек стремится к простоте, промолчу про "ад зависимостей", кто-то с места крикнет про автоматизацию, так вот в ответ - автоматизация разве решает сложности? Что есть сложность? - задумайтесь!
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	47. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Аноним (47), 12-Сен-18, 01:10
	> а вот поломать совместимость с чем-то, А что, в редхатах нельзя поставить рядом две разных версии одной библиотеки?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

6. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+1 +/–
Сообщение от Kido Katsuragi (?), 11-Сен-18, 19:16
С каких пор релиз x.y.Z стал "значительным"? На Semantic Versioning совсем уже всем стало наплевать?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Фуррь (ok), 11-Сен-18, 19:56
	Уважаемый, смотрите на changelog, а не на цифирьки, что вы как хипстер, в самом деле.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	11. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+4 +/–
	Сообщение от Kido Katsuragi (?), 11-Сен-18, 19:59
	А "циферьки" тогда зачем? Можно же тогда как хром с лисой каждый релиз мажорную версию менять. SM же и придуман чтобы циферьки были не просто так, а несли в себе смысл.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	13. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–3 +/–
	Сообщение от A.Stahl (ok), 11-Сен-18, 20:18
	За смыслом в "цифирьках" это вам к нумерологам или хотя бы в ближайшую церковь. Единственная логика в номере версии -- чем больше число, тем свежее код. И то не всегда.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	34. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–2 +/–
	Сообщение от ююю (?), 11-Сен-18, 22:03
	> За смыслом в "цифирьках" это вам к нумерологам или хотя бы в ближайшую церковь. И эти люди ещё пытаются что-то там критиковать... Куда катится опеннет. Хотя, понятно куда.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	77. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Аноним (77), 12-Сен-18, 23:55
	Дружок, а тебя не смущает, что ты пробил дно дна опеннета? Ведь твоя критика полностью подпадает под твою же критику.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	16. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–2 +/–
	Сообщение от Аноним (16), 11-Сен-18, 20:46
	Можно как с лисой, можно как не с лисой, кому как нравится. Не у вас же спрашивать как версию называть. А SemVer бесполезен. К прикладному софту он слабо применим, а для библиотек опирается на совместимость API, которой на деле не существует (про это хорошо рассказано в https://www.youtube.com/watch?v=tISy7EJQPzI), и игнорирует совместимость ABI.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	33. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Michael Shigorin (ok), 11-Сен-18, 21:55
	Да ладно, бесполезен.  Тех, кто не читал дрепперовское dsohowto -- всё равно разве что нашим турбинским set versioning'ом на подлёте шмалять, и то кто-то да пролетит...
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	35. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+2 +/–
	Сообщение от ююю (?), 11-Сен-18, 22:12
	> А SemVer бесполезен. К прикладному софту он слабо применим Вот и выросло поколение Гарри Поттеров. Сам ты бесполезен, Анон. Ломаете совместимость - выпускайте мажорную версию. Поддержка ранее выпущенных мажорных "релизов" отдельный вопрос.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	38. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Аноним (38), 11-Сен-18, 23:25
	> Ломаете совместимость - выпускайте мажорную версию. Допустим, я реализую графический редактор и значительно переписал большую часть кода, добавил много новых функций и несколько новых форматов файлов. Должен ли я увеличить минорную версию лишь потому, что совместимость с предыдущей версией сохранена? Допустим, я исправил уязвимость при чтении некоторых типов файлов, в результате чего на некоторые читавшиеся ранее файлы приложение теперь ругается (даже если в них уязвимости нет). Должен ли я увеличить мажорную версию лишь потому, что совместимость пострадала?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	39. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от ююю (?), 11-Сен-18, 23:49
	1. нет 2. нет Это крайние случаи, которых стоит избегать с помощью грамотного планирования разработки.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	43. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–1 +/–
	Сообщение от Аноним (41), 12-Сен-18, 00:33
	Вот и вырасло поколение буратин-теоретиков. Что ж ты не пришёл во все проекты которые когда-нибудь могут сломать совместимость и не распланировал их грамотно чтобы этого не случилось?
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	46. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от ююю (?), 12-Сен-18, 01:09
	> Что ж ты не пришёл во все проекты которые когда-нибудь могут сломать совместимость и не распланировал их грамотно. Анон, при всем уважении, ты задаёшь тупые вопросы. В тех проектах, где я отвечал модель за разработки и версионирование, мне удавалось придерживаться SV без особых проблем. Проектов было много (20+), я этим занимался несколько лет.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	60. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–1 +/–
	Сообщение от Аноним (41), 12-Сен-18, 13:15
	Вопросы я не задаю, это раз. Твой тепличный опыт яйца выеденного не стоит, это два.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	78. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+1 +/–
	Сообщение от Аноним (77), 13-Сен-18, 00:04
	Уважаемый, бесполезно говорить с малолетками на серьезные темы, они же ничего не знают и пытаются играть в  троллей.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	42. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Аноним (41), 12-Сен-18, 00:30
	Ты даже не удосужился пройти по ссылке. А ты пройди, много нового узнаешь. Совместимость - фикция, и для кого-то её может сломать даже незначительнфй багфикс не затрагивающий API.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	63. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от yet another anonymous (?), 12-Сен-18, 15:19
	Таки да, в подавляющем большинстве --- фикция. Характерный пример --- библиотеки происходящие от GNOME-команды.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	45. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от AnonPlus (?), 12-Сен-18, 01:05
	К лисе (не знаю, как к хрому) SM не применим по простой причине - у лисы релиз не зависит от фич или багфиксов, а жёстко привязан к графику. Релиз каждые N недель, то есть, делается срез репозитория, обзывается бетой, неготовые фичи выключаются, отлавливаются баги. Что интересно, хающие лису не вспоминают про ядро Linux, которое точно так же релизиться примерно через равные промежутки времени, второе число в версии просто увеличивается на 1, а первое число отражает ощущение Линуса "ну, вроде уже пора" (поинтересуйтесь переходом 3.x -> 4.x").
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	17. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от бедный буратино (ok), 11-Сен-18, 20:49
	патамучта она бинарно совместима с 1.1.0
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	23. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–1 +/–
	Сообщение от Никонор Бонифатич (?), 11-Сен-18, 21:12
	чтобы "стало плевать", сначала надо семверу следовать. А - тут открытие - не каждое ПО следует семверу.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	64. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от yet another anonymous (?), 12-Сен-18, 15:23
	> чтобы "стало плевать", сначала надо семверу следовать. Ему следовать довольно проблематично. Должного покрытия тестами почти никогда нет, а метод пристального вглядывания --- ненадёжен.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	37. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–1 +/–
	Сообщение от Аноним (38), 11-Сен-18, 23:19
	> На Semantic Versioning совсем уже всем стало наплевать? Всем адекватным - да. Semantic Versioning изначально разрабатывалось для версионирования АПИ. У некоторых, из-за того, что они используют его не по назначению (а например, для версионирования версий софта, для которого оно в большинстве случаев не подходит), это приводит к проблемам, с которыми они отважно борются (можете их багтрекер на гитхабе почитать ради интереса, а не только главную страницу сайта). Другие же, невзирая на моду, просто не пытаются колоть орехи микроскопом.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	40. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+1 +/–
	Сообщение от ююю (?), 11-Сен-18, 23:58
	> (а например, для версионирования версий софта, для которого оно в большинстве случаев не подходит), это приводит к проблемам А можно реальные примеры вашего примера? Желательно со ссылками. А то складывается впечатление, что у кого-то просто знания "матчасти" не хватает. Буду рад открыть для себя что-то новое.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	44. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	–1 +/–
	Сообщение от Аноним (41), 12-Сен-18, 00:35
	Там сверху ссылка на доклад. Не появляйся сдесь пока его целиком не посмотришь, пожалуйста.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	48. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от ююю (?), 12-Сен-18, 01:11
	С докладчиком не согласен. Тратить на тебя время тоже желание пропало.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	58. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Аноним (41), 12-Сен-18, 13:12
	Спасибо что честно признал свою неправоту.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	49. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+3 +/–
	Сообщение от Аноним (38), 12-Сен-18, 01:23
	> А можно реальные примеры вашего примера? Желательно со ссылками. Год-два назад я думал, что СемВер решит все мои проблемы, поэтому решил полазать по их багтрекеру. Многие тикеты содержат интересные обсуждения на тему версий и того, насколько СемВер может быть применим в тех или иных условиях. После прочтения всех открытых на тот момент тикетов сложилось общее впечатление о СемВере, однако искать конкретные цитаты сейчас мне некогда. Если есть желание действительно разобраться в теме, то ОЧЕНЬ советую почитать их багтрекер. Все открытые задачи. Там не так много, за день можно управиться. Из того, что могу сходу озвучить: 1. Нумерация СемВер основана на понятии совместимости, тогда как нумерация софта традиционно отталкивается от понятий функционала и/или объёма выполненных работ. Это ортогональные понятия. В случае СемВер изменение версий имеет следующие значение: - мажорная - изменён/добавлен функционал, пропала совместимость, - минорная - добавлен функционал, сохранена совместимость, - патч - функционал не изменён, сохранена совместимость. В случае софта изменение версий имеет значение (если число компонент версий вообще три): - мажорная - перед обновлением пользователю рекомендуется тщательно протестировать, всё ли работает, как он ожидает (либо значительно поменялся функционал, либо были переписаны крупные куски кода), - минорная - добавлен функционал, можно обновиться, если новый функционал нужен, крупных проблем после обновления не возникнет, так как код глобально не переписывался, - патч - исправлены ошибки, необходимо обновиться, проблем при обновлении не возникнет. Можно притянуть за уши эти две шкалы, если считать "совместимостью" способность пользователя, работавшего со старой версией, быстро начать работать с новой. Но имхо совместимость - это больше технический, формальный термин, и всегда можно чётко сказать, совместима новая версия со старой или нет. А совместимость "функционала" с точки зрения пользователя оценить может быть сложно, это термин больше психологический, неформальный. Но даже в этом случае появится несоответствие, когда незначительное изменение рушит "совместимость". Если изменение в софте, то любой адекватный разработчик не станет менять мажорную версию. Хотя по логике СемВер менять нужно именно её. Мажорная версия в случае СемВер меняется ТОЛЬКО когда ломается совместимость. А в случае версионирования ПО мажорную версию можно менять, например, каждые пять лет просто чтоб продемонстрировать "взрослось" проекта. Плюс с точки зрения софта, если для исправления мелкой ошибки пришлось значительно поменять какой-то интерфейс или workflow, то меняется патч-версия. Тогда как в случае СемВер, по логике, нужно было бы менять старшую цифру из-за несовместимых изменений. 2. СемВер плохо отражает процесс разработки ПО. Например, сортировка пререлизных версий идёт по алфавиту. Нам просто повезло, что согласно алфавиту alpha < beta < pre < rc. Но добавьте сюда ещё какую-нибудь стадию, специфичную для вашего проекта, и очень вероятно, что она не впишется в такой порядок. В СемВер нет пострелизных версий. Вы можете создать 1.0.0-rc.1, но после релиза создать 1.0.0-daily.1 вы не сможете, так как daily будет между beta и pre. Для ежедневных сборок приходится либо использовать 1.0.0+daily.1 (при том, что при сравнении версий метаданные могут игнорироваться), либо нужно угадать, какой будет следующая версия (1.0.1, 1.1.0 или 2.0.0) и дальше делать её пререлизы (1.0.1-daily.1, 1.0.1-daily.2, ...). Если при этом появится функциональное добавление, то после 1.0.1-daily.2 у вас уже будет 1.1.0-daily.1. Это вместо того, чтоб плодить 1.0.0-daily.N а в нужный момент сразу решить, как назвать новую версию. Тот факт, что любой daily заведомо окажется старше любого beta и младше любого pre (официальная позиция СемВер), не позволяет строить схемы с daily-релизами, местно прерываемыми другими релизами. В СемВер нельзя объявить, что daily невозможно сравнивать с beta/pre. При нумерации версий софта бывает удобно использовать только две цифры (1.2) или добавить четвёртую (1.2.0.240, например для обозначения номера билда). СемВер недостаточно гибок, чтобы позволить такое. При создании версии 1.0.0 вы делаете 0.1.0, 0.2.0, 0.3.0... 1.0.0. Но для создания версии 2.0.0 у вас нет такого запаса по числам, приходится изголяться и делать 2.0.0-dev.1.0, 2.0.0-dev.2.0 и т.д. И это описано в самом СемВер, вместо того чтоб запретить всё, начинающееся с нуля, и форсировать схему с 1.0.0-dev.1.0. Некоторые проекты являются "модификацией" основного проекта. Основной выпускает версию 1.2.3, а модификация патчит эту версию и делает 1.2.3.0. После нахождения ошибок в модификации, выпускается 1.2.3.1. После релиза 1.2.4 основного проекта выпускается модификация версии 1.2.4.0. Это, конечно, можно переложить на СемВер, но для автора "модификации" (да и для пользователей) такой способ выглядит более наглядным. Использовать версии типа 1.2.3-modified.1 нельзя, так как это считается пререлизной версией, то есть 1.2.3-modified.1 < 1.2.3. Использовать 1.2.3+modified.1 тоже нельзя, так как инструмент сравнения версий может игнорировать метаданные, так что может получиться 1.2.3+modified.1 = 1.2.3+modified.2. И лично я вообще не понимаю, зачем им дефис. Почему бы не использовать точку: 2.0.0.dev.1.0, всё же понятно. 3. В багтрекере вообще периодически встречаются комментарии, что СемВер предназначен для разного рода АПИ, и ни для чего другого (правда, я не обращал внимания, комментарии ли это мейнтейнеров СемВера или нет). Если версия вашего софта можно рассматривать как АПИ, то СемВер применим. Но если вы, к примеру, провели масштабный рефакторинг, то ни для пользователя, ни с точки зрения совместимости ничего не поменялось. Однако вы в этом случае можете счесть приемлемым увеличить мажорную версию.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	50. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от ююю (?), 12-Сен-18, 02:13
	Огромное спасибо за такой развернутый ответ! Респект. > Если есть желание действительно разобраться в теме, то ОЧЕНЬ советую почитать их > багтрекер. Все открытые задачи. Там не так много, за день можно управиться. ОК, спасибо за наводку. > Из того, что могу сходу озвучить: > 1. Нумерация СемВер основана на понятии совместимости, тогда как нумерация софта традиционно > отталкивается от понятий функционала и/или объёма выполненных работ. Это ортогональные > понятия. .... > Плюс с точки зрения софта, если для исправления мелкой ошибки пришлось значительно > поменять какой-то интерфейс или workflow, то меняется патч-версия. Тогда как в > случае СемВер, по логике, нужно было бы менять старшую цифру из-за > несовместимых изменений. Ну, это можно по ситуации решать, я признаю, что буквально следовать SV очень трудно. С другой стороны, если приходится значительно менять интерфейс - сложно назвать это "мелкой ошибкой". я бы чинил не ломая, что можно (patch-level), остальное добавил в known issues, и новый мажорный релиз выпустил с учетом предыдущих косяков. > 2. СемВер плохо отражает процесс разработки ПО. > Например, сортировка пререлизных версий идёт по алфавиту. Нам просто повезло, что согласно > алфавиту alpha < beta < pre < rc. Но добавьте сюда > ещё какую-нибудь стадию, специфичную для вашего проекта, и очень вероятно, что > она не впишется в такой порядок. Честно говоря, не вижу в этом проблемы. Заказчик получает доступ к папке с релизами, а там вполне можно добиться вменяемой сортировки версий. Сами по себе "alpha < beta < pre < rc", такой себе канон, сильно зависит от внутренней модели разработки, "pre" - уже не помню, когда видел последний раз. >[оверквотинг удален] > 1.2.3, а модификация патчит эту версию и делает 1.2.3.0. После нахождения > ошибок в модификации, выпускается 1.2.3.1. После релиза 1.2.4 основного проекта выпускается > модификация версии 1.2.4.0. Это, конечно, можно переложить на СемВер, но для > автора "модификации" (да и для пользователей) такой способ выглядит более наглядным. > Использовать версии типа 1.2.3-modified.1 нельзя, так как это считается пререлизной версией, > то есть 1.2.3-modified.1 < 1.2.3. Использовать 1.2.3+modified.1 тоже нельзя, так как > инструмент сравнения версий может игнорировать метаданные, так что может получиться 1.2.3+modified.1 > = 1.2.3+modified.2. > И лично я вообще не понимаю, зачем им дефис. Почему бы не > использовать точку: 2.0.0.dev.1.0, всё же понятно. Имхо, все эти цифры, буквы, плюсы, минусы, точки и т.п. знаки препинания уже болше определяются политикой и совокупностью гайдлайнов дистрибутивов, для которых приложение собирается. например версия может быть appname-1.2.RC1-ubuntu+master.build3455.2fbf9281 в ней есть major(1),minor(2),patchlevel(RC1-ubuntu+master.build3455.2fbf9281), при этом patchlevel точно описывает: состояние, под какую ось, из какой ветки взят код, номер билда/хэш коммита/дату билда и т.п. > 3. В багтрекере вообще периодически встречаются комментарии, что СемВер предназначен для > разного рода АПИ, и ни для чего другого (правда, я не > обращал внимания, комментарии ли это мейнтейнеров СемВера или нет). Если версия > вашего софта можно рассматривать как АПИ, то СемВер применим. Но если > вы, к примеру, провели масштабный рефакторинг, то ни для пользователя, ни > с точки зрения совместимости ничего не поменялось. Однако вы в этом > случае можете счесть приемлемым увеличить мажорную версию. имхо, всё что угодно можно рассматривать как АПИ. :) Даже конституцию. ну рефакторинг - отдельная тема, выпускать функционально такой же продукт (но внутренне переработанный!) особого смысла нет, должны быть новые фичи, чтобы пользователь захотел поставить новую версию.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	56. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Онанимус (?), 12-Сен-18, 10:31
	> должны быть новые фичи, чтобы пользователь захотел поставить новую версию. Увеличение скорости работы, снижение потребления ресурсов, пересмотр кода с точки зрения безопасных методик - может считаться новыми фичами (в функционале ничего не поменялось)?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	69. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от your mom (?), 12-Сен-18, 17:08
	Ну, на практике такое встречается когда "проведен глубокий рефакторинг кода, снижено потребление памяти, улучшена стабильность приложения" - единственная фича нового релиза.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	70. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от yet another anonymous (?), 12-Сен-18, 18:17
	> при этом patchlevel точно описывает: состояние, под какую ось, из какой ветки взят код, номер билда/хэш коммита/дату билда и т.п. Во-первых, избыточно (ср.: хеш и ветка; хотя без репозитория, содержащего этот коммит --- бесполезно); во-вторых, недостаточно (ABI, компилятор, etc.); в-третьих, бесполезно (под какую ось,... номер билда, дату билда).
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	75. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от Аноним (75), 12-Сен-18, 22:08
	> С другой стороны, если приходится значительно менять интерфейс - сложно назвать это "мелкой ошибкой" Ситуации разные бывают. Представьте, что приложение работает через веб-сервис, а в том обнаружили проблему безопасности, немного изменили АПИ, и из-за этого пришлось поменять интерфейс приложения. Согласен, что ситуация нечастая, но по СемВер она адекватно не разруливается. Идеальная схема версионирования должна предоставлять удобные варианты для наиболее типичных случаев и быть достаточно гибкой, чтобы позволить реализовать почти любой (а в идеале любой) нетипичный случай. > Заказчик получает доступ к папке с релизами, а там вполне можно добиться вменяемой сортировки версий. Вменяемую сортировку придётся делать самим и, вероятно, она будет несовместима с СемВер. > patchlevel(RC1-ubuntu+master.build3455.2fbf9281) А вот и нет. У вас в одном поле patchlevel сразу несколько величин, влияющих на сравнение и сортировку версий: статус (RC), номер релиза (1 после RC), номер билда (3455). То есть в вашем случае у вас не major.minor.patchlevel, а major.minor.stage.release.build, то есть 5 величин. СемВер позволяет только три. Я, кажется, понимаю, вы хотите сказать, что сама схема major.minor.patchlevel логична, и под неё, в принципе, можно подогнать любую другую с определёнными допущениями. Но суть СемВера в том, что схема именно такая, как они описывают, а не почти такая же. Ваш пример - это уже не СемВер, и библиотеки, заявляющие поддержку СемВер, с вашим примером работать не будут. И люди, "имеющие опыт" работы с СемВер, тоже не поймут, что есть что. И проблема не в дефисах/плюсах/точках. > выпускать функционально такой же продукт (но внутренне переработанный!) особого смысла нет, должны быть новые фичи, чтобы пользователь захотел поставить новую версию. Почему? После 5 лет развития была версия 1.19.6. Автор решил, что добавлять новый функционал лучше в форме плагинов (не с точки зрения пользователя, а с точки зрения реализации и архитектуры приложения), а это будет возможно только после рефакторинга и добавления схемы работы с плагинами. Он переписывает кучу кода, выпускает 2.0.0, и уже на её основе начинает пилить 2.1.0 с новым функционалом в форме плагинов. Пользователям, конечно, нет смысла обновляться до 2.0.0, но автору такой подход может быть проще, чем сразу писать плагины и в качестве 2.0.0 выкладывать версию уже с новым функционалом.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

66. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
Сообщение от timur.davletshin (ok), 12-Сен-18, 16:07
А в debian зарегистрировали баг на тему совместимости ABI — https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908567
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	71. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+1 +/–
	Сообщение от пох (?), 12-Сен-18, 19:26
	это не несовместимость abi, это руки у авторов qt растут из ануса - сперва они требуют от библиотеки поддержки последней возможной в ней версии, вместо последней поддерживаемой собой, или уж не лезть кривыми руками куда не надо вообще, оставив все по-умолчанию, а потом, вдруг "ой, а она нам незнакома, мы не знаем что с этим делать". В abi ничего не изменилось, в api тоже - константа не превратилась вдруг в long double вместо int, функция не поменяла свое поведение.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	72. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от timur.davletshin (ok), 12-Сен-18, 19:56
	> это не несовместимость abi, это руки у авторов qt растут из ануса > - сперва они требуют от библиотеки поддержки последней возможной в ней > версии, вместо последней поддерживаемой собой, или уж не лезть кривыми руками > куда не надо вообще, оставив все по-умолчанию, а потом, вдруг "ой, > а она нам незнакома, мы не знаем что с этим делать". > В abi ничего не изменилось, в api тоже - константа не превратилась > вдруг в long double вместо int, функция не поменяла свое поведение. Я всё это понимаю, но пользователю от этого не легче.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	73. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от пох (?), 12-Сен-18, 21:05
	ну, следующие дятлы просто намертво залинкуются с libssl.so.1.1.0h, не используя при этом ни одной version-specific фичи (довольно, кстати, распространенный вид идиотизма, как и наоборот, непонимание как надо давать имена файлу, а как - soname) - и их только подменой линка вручную и удастся побороть - это ж не abi виноват.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	74. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от timur.davletshin (ok), 12-Сен-18, 21:27
	Если дочитать переписку, то там есть и другие такие же...
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	76. "Значительный выпуск криптографической библиотеки OpenSSL 1.1..."	+/–
	Сообщение от пох (?), 12-Сен-18, 22:51
	"что-то я и не удивлен"
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

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

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