Разработчики проекта OpenBSD представили (http://marc.info/?l=openbsd-tech&m=140510291304119&w=2) первый выпуск переносимой редакции пакета LibreSSL (http://www.libressl.org/), в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. Из особенностей LibreSSL можно отметить ориентацию на качественную поддержку протоколов SSL/TLS с удалением излишней функциональности и проведением значительной чистки (http://opensslrampage.org/) и переработки кодовой базы. При работке LibreSSL также проводится работа по повышению читаемости кода, добавлению дополнительных средств защиты и устранению ошибок.
Переносимая версия LibreSSL пригодна для использования в различных операционных системах и не ограничивается работой в окружении OpenBSD (до сих пор LibreSSL был доступен для тестирования только пользователям OpenBSD). Работа пакета протестирована в Linux, Solaris, OS X и FreeBSD. Интеграция LibreSSL в состав OpenBSD ожидается в ближайшем выпуске 5.6, который намечен на 1 ноября.Среди внесённых изменений:
- Удалена поддержка всех движков шифрования (кроме padlock и aesni) и слабых дополнений для получения энтропии.
- Прекращена поддержка устаревших и малоиспользуемых платформ, в том числе Mac OS, NetWare, OS/2 и VMS, прекращена поддержка big-endian для i386 и amd64 (они всегда little-endian).
- Проведена чистка кода от некоторых компонентов, специфичных для платформы Windows. Например, удалён код OPENSSL_isservice и других функций для учёта особенностей не POSIX-систем.
- Удалён весь код, связанный с поддержкой SSL-расширения heartbeat, ошибка в котором привела к катастрофической (http://www.opennet.me/opennews/art.shtml?num=39544) уязвимости (http://www.opennet.me/opennews/art.shtml?num=39518).
- Прекращено использование дополнительных обёрток для различных потенциально небезопасных функций (snprintf, opendir, функции работы с сокетами и т.п.).
- Вызовы strlcat/strlcpy (http://opensslrampage.org/post/83153080370/re-using-strlcpy-...) замены (http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/cry...) на snprintf (http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/app...), связка malloc+memset заменена (http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl...) на calloc.
- Исправлена серия ошибок распределения памяти (например, в некоторых местах почищен (http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/cry...) двойной вызов free).
- Внесена серия исправлений, связанных с решением проблемы 2038 года.
- Объявлено излишним (http://opensslrampage.org/post/83222773842/writing-your-own-...) и удалено (http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/app...) собственное кэширование результатов DNS-запросов.
- Удалена поддержка bdes;
- Удалены неиспользуемые ssl-утилиты на Perl;
- Удалена поддержка FIPS API, так как навязываемые сертификацией требования противоречат целям свободного проекта;
URL: http://marc.info/?l=openbsd-tech&m=140510291304119&w=2
Новость: http://www.opennet.me/opennews/art.shtml?num=40184
Сказка :)> Удалён весь код, связанный с поддержкой SSL-расширения heartbeat
Убили keep-alive в SSL ? задержки выростут.
> задержки выростут.Правильно, мы за быстрый слив приватных ключей и паролей в интернет! :)
Впрочем, в libressl тоже все странно:
> Удалена поддержка всех движков шифрованияТ.е. оставлены только местные, при том что исходные авторы - редкие долбодятлы?
> Прекращена поддержка устаревших и малоиспользуемых платформ, в том числе Mac OSвот это радует. Малоиспользуемой MacOSX не место с широко используемой массами OpenBSD
Mac OS != Mac OS X
Подозреваю, что под Mac OS прячется 9-ка и ниже. Классика.
> Mac OS != Mac OS X
> Подозреваю, что под Mac OS прячется 9-ка и ниже. Классика.Всё верно.
Главное, вот это порадовало:"Проведена чистка кода от некоторых компонентов, специфичных для платформы Windows. Например, удалён код OPENSSL_isservice и других функций для учёта особенностей не POSIX-систем."
Mac OS X входит в подмножество Mac OS, что у вас с логикой?
Нет, это не логика, это ваши заблуждения.
Более того, нет никакой Mac OS X. Есть просто — OS X.
Именно такое у этой ОС название.
> Mac OS X входит в подмножество Mac OS, что у вас с
> логикой?Это у вас плохо со знаниями. Официально MacOS вообще не существовала, была просто "ОС для Макинтошей".
И общего у MacOS и OS X (как тут правильно заметили) только то, что они предустанавливаются на компьютеры производства Apple.
>> Mac OS X входит в подмножество Mac OS, что у вас с
>> логикой?
> Это у вас плохо со знаниями. Официально MacOS вообще не существовала, была
> просто "ОС для Макинтошей".
> И общего у MacOS и OS X (как тут правильно заметили) только
> то, что они предустанавливаются на компьютеры производства Apple.Не совсем. Были разные названия "OS System 6", к примеру, но официальное все же
Mac OS N
Просвещаем слабых на интеллект: http://en.wikipedia.org/wiki/Mac_OS#Versions
> Просвещаем слабых на интеллект:Это излишне: безошибочно детектируются по слову "Mac OS".
Оригинальный MacOS (тот что не X, а версий от 9 и ниже) можно встретить еще реже.
ассемблерные реализации шифров (AES, хеши) убрали :/
производительность упала на 25-30% примерно в "openssl speed" соответственно-lrt в apps/Makefile забыли
libssl.so.26
libcrypto.so.29
уж лучше бы целились на полную совместимость (drop in replacement), или уже переименовывали библиотеки полностью
> ассемблерные реализации шифров (AES, хеши) убрали :/
> производительность упала на 25-30% примерно в "openssl speed" соответственно
> -lrt в apps/Makefile забыли
> libssl.so.26
> libcrypto.so.29
> уж лучше бы целились на полную совместимость (drop in replacement), или уже
> переименовывали библиотеки полностьюНа drop in они и нацелились; это всего лишь первый публичный релиз, в нём, конечно, куча грабель при сборке будет (например, конфликт с OpenSSH Portable из-за RAND_BYTES). Думаю, за несколько недель большую часть исправят. Вы лучше письмецо на misc@openbsd.org отправьте с описанием встреченных проблем - времени столько же, сколько на OpenNet писать, а пользы всяко больше. ;)
> Вы лучше письмецо на misc@openbsd.org отправьте с описанием встреченных проблем -
> времени столько же, сколько на OpenNet писать, а пользы всяко больше. ;)лучше бы они не частили. :) а то беру снэп от 10 июля, а пакеты - от 8, и больше не пересобирались. ставлю - и ничего не ставится, потому что bad major, ssl.26, а в пакетах ssl.25
еле нашёл эстонский сервер, где снэп от 8 июля.
портирование - портированием, но пользователи openbsd должны быть превыше всего :)
Портировали, портировали да не выпортировали...
>> Вы лучше письмецо на misc@openbsd.org отправьте с описанием встреченных проблем -
>> времени столько же, сколько на OpenNet писать, а пользы всяко больше. ;)
> лучше бы они не частили. :) а то беру снэп от 10
> июля, а пакеты - от 8, и больше не пересобирались. ставлю
> - и ничего не ставится, потому что bad major, ssl.26, а
> в пакетах ssl.25
> еле нашёл эстонский сервер, где снэп от 8 июля.
> портирование - портированием, но пользователи openbsd должны быть превыше всего :)Потому что прямо сейчас идёт большой ежегодный хакатон, количество коммитов зашкаливает. Хотите стабильности - подождите с недельку, когда все разъедутся и новые пакеты подоспеют.
мне надо было что-то "прямо сейчас" поставить, взамен 5.5. хотелось firefox 30 и gnome 3.12, из коих сейчас и пишуа поймать нужный снапшот, в котором ничего не вываливается, в котором есть нужные пакеты, да ещё успеть его скачать, пока не обновится - это вообще большая удача :)
> мне надо было что-то "прямо сейчас" поставить, взамен 5.5. хотелось firefox 30
> и gnome 3.12, из коих сейчас и пишу
> а поймать нужный снапшот, в котором ничего не вываливается, в котором есть
> нужные пакеты, да ещё успеть его скачать, пока не обновится -
> это вообще большая удача :)Есть, кстати, шанс, что ситуация в ближайшем времени может измениться в лучшую сторону. Но для этого нужно ещё как минимум по небольшому кластеру на amd64, i386 и sparc64 (особенно актуальны последние два). Либо на условиях "неограниченное пользование", либо "отправляем железо и спонсируем его обслуживание". Если есть реальная возможность помочь любым из указанных способов - прошу связаться сразу с deraadt@openbsd.org или espie@openbsd.org. :)
> ассемблерные реализации шифров (AES, хеши) убрали :/
> производительность упала на 25-30% примерно в "openssl speed" соответственно
> -lrt в apps/Makefile забыли
> libssl.so.26
> libcrypto.so.29
> уж лучше бы целились на полную совместимость (drop in replacement), или уже
> переименовывали библиотеки полностьюКстати, уже в разработке альтернативный, более высокоуровневый (читай: упрощённый до уровня, удобного для реального использования) интерфейс в виде отдельной libressl. Но эта вкусняшка будет уже чуть позже. :)
> libssl.so.26
> libcrypto.so.29это и есть drop-in замена. для того, что было в openbsd до этого. например, в 5.3 libssl.so.19
просто выдернули из своих исходников, и всё. это, прежде всего, внутренний проект openbsd, и это только первый выпуск, чтобы узнать, какие у порта косяки.
Неподписанный архив, раздаётся по простому HTTP... Будет не слишком-то красиво, если в первый релиз кто-нибудь пристроит ACIDBITCHEZ.
Каждый выбирает грабли по вкусу - кто-то пишет запутанный и неподдерживаемый код, а кто-то пренебрегает банальными мерами безопасности.
> а кто-то пренебрегает банальными мерами безопасностиИспользуя в XXI веке языки программирования с ручным управлением памятью.
> Используя в XXI веке языки программирования с ручным управлением памятью.Посмотрел бы как продвинутые, высокоразвитые, современныет молодые разрабы
будут низколатентный сетевой демон, с оптимизациями на уровне связки драйвера
сетевухи и сетевого стека ядра, писать на каком нибудь Питоне/Бредоне.
> Используя в XXI веке языки программирования с ручным управлением памятью.А в криптографии сборщик мусора и прочая автоматика скорее нагадит. Непредсказуемыми временами изничтожения ключей, задержками зависящими от активности программ, просадкой скорости и прочими прелестями.
И вообще, те кто пишет такой бред - безопасно криптографию не напишут ни на каком языке. Для начала - в самой по себе криптографии вообще памятью особо управлять толком негде. Чистая математика.
> А в криптографии сборщик мусора и прочая автоматика скорее нагадит. Непредсказуемыми временами
> изничтожения ключей, задержками зависящими от активности программ, просадкой скорости
> и прочими прелестями.Бред, сборщик мусора ничего не сделает с памятью объекта, пока он в области
видимости. А привыходе из таковой и в Cи делается free, только руками.> И вообще, те кто пишет такой бред - безопасно криптографию не напишут
> ни на каком языке. Для начала - в самой по себе
> криптографии вообще памятью особо управлять толком негде. Чистая математика.Чистая математика у тех, кто крипто. алгоритмы разрабатывает, и исследует.
У реализаторов, на любом языке, из математики только готовая спека алгоритма,
всё остальное-чистый ЯП, компиляторы и ОС.
>> А в криптографии сборщик мусора и прочая автоматика скорее нагадит. Непредсказуемыми временами
>> изничтожения ключей, задержками зависящими от активности программ, просадкой скорости
>> и прочими прелестями.
> Бред, сборщик мусора ничего не сделает с памятью объекта, пока он в
> области
> видимости. А привыходе из таковой и в Cи делается free, только руками.Угу, и free(), конечно, зануляет освобождаемую память...
А насчёт видимости объекта - напомнить про циклические ссылки?
>> И вообще, те кто пишет такой бред - безопасно криптографию не напишут
>> ни на каком языке. Для начала - в самой по себе
>> криптографии вообще памятью особо управлять толком негде. Чистая математика.
> Чистая математика у тех, кто крипто. алгоритмы разрабатывает, и исследует.
> У реализаторов, на любом языке, из математики только готовая спека алгоритма,
> всё остальное-чистый ЯП, компиляторы и ОС.Короче, не знаете, о чём говорите - лучше помолчите. Это _добрый_ совет.
> Угу, и free(), конечно, зануляет освобождаемую память...
> А насчёт видимости объекта - напомнить про циклические ссылки?Короче, Вы про кривые руки. Сразу так бы и говорил.
> Короче, не знаете, о чём говорите - лучше помолчите. Это _добрый_ совет.
На прошлом месяце просматривал релизации алгоритмов шифрования в linux,
и программные и аппаратные. Математических построений, которые представляют
из себя сам алгоритм в теории, и которые исследуются в задачах исследования
алгоритма, там не видел. Видел описанную на ЯП/С99 или x86_64/asm спецификацию
этих алгоритмов.Ферштейн?
>> Угу, и free(), конечно, зануляет освобождаемую память...
>> А насчёт видимости объекта - напомнить про циклические ссылки?
> Короче, Вы про кривые руки. Сразу так бы и говорил.Вы считаете, что free() работает криво?
>> Короче, не знаете, о чём говорите - лучше помолчите. Это _добрый_ совет.
> На прошлом месяце просматривал релизации алгоритмов шифрования в linux,
> и программные и аппаратные. Математических построений, которые представляют
> из себя сам алгоритм в теории, и которые исследуются в задачах исследования
> алгоритма, там не видел. Видел описанную на ЯП/С99 или x86_64/asm спецификацию
> этих алгоритмов.
> Ферштейн?Вам про Фому, а вы про Ерёму. Частный случай не доказывает общее утверждение. Лечитесь дальше.
> Вы считаете, что free() работает криво?Мы считаем, что free() просто делает free структуре vma_area_struct в ядре,
с возможным высвобождением страниц и всё. Если нужно чтоб страницы была чисты-выпрямляй
руки.> Вам про Фому, а вы про Ерёму. Частный случай не доказывает общее
> утверждение. Лечитесь дальше.Ваш Фома и Ерёма-порождения слабоватого бидлокодерского умишка.
Ещё раз для школяров. Представление крипт. алгоритма в теории-раздел чистой математики.
Реализации крипт. алгоритма в реальной или абстрактной машине-чистый ЯП, ни один из которых
к разделам чистой математики не относится.
> Мы считаем, что free() просто делает free структуре vma_area_struct в ядре,Считать можно что угодно, только инструмент для профессионалов позволяет и нестандартные манипуляции. Если задача например требует затирания памяти при освобождении, на сях можно и кастомный аллокатор под эти требования запилить. А там где автоматическое управление памятью, навязанное сверху - с этим будет большой облом.
> Угу, и free(), конечно, зануляет освобождаемую память...В си, если задаться целью, можно сделать свое управление памятью под кастомные нужды. Как один из вариантов таковых - "secure free(), который затирает память нолями".
А теперь домашнее задание скрипткидизам: попробуйте провернуть этот трюк с моднявыми фигнями, автоматически управляющими памятью...
Нолями нельзя - нужно мусором.
> Нолями нельзя - нужно мусором.Это почему?
>> Нолями нельзя - нужно мусором.
> Это почему?security by obscurity же!
> Бред, сборщик мусора ничего не сделает с памятью объекта, пока он в
> области видимости.Так это то и есть одна из проблем. Даже если мы собираемся остаться в области видимости полгода, ключ может требоваться надежно и предсказуемо изничтожить *сейчас*. Чтобы не болтался в памяти. Мало ли кто и по какому поводу в памяти системы шариться потенциально может. Умный рантайм может в этом начинании неиллюзорно подгадить своим малопредсказуемым менеджментом памяти.
> А привыходе из таковой и в Cи делается free, только руками.
В си операции делаются тогда, когда их посчитали необходимыми и их результат железобетонно предсказуем, если не лажаться. А не тогда, когда раздуплится тормозной неповоротливый рантайм, вообще ни разу не писаный security minded людьми и криптографами.
> Чистая математика у тех, кто крипто. алгоритмы разрабатывает, и исследует.
Сама по себе криптография - чистая математика и есть. Вон, например, tweetnacl - ни единого динамического выделения памяти на всю либу! Можно даже в какой-нить микроконтроллер засунуть, где полностью статическое распределение памяти. Очень интересно, как можно облажаться в управлении памятью, если оного при желании может не быть совсем. Кстати, на сях так можно, по крайней мере. В отличие от переусложненных Бюро Медвежьих Услуг, где тебя пытаются облагодетельствовать волшебными пинками.
> У реализаторов, на любом языке, из математики только готовая спека алгоритма,
> всё остальное-чистый ЯП, компиляторы и ОС.И тем не менее, на си можно писать очень надежный, стабильный и предсказуемый код. Си используется в автомобильной, авиационной и т.п. промышленностях, где важна именно предсказуемость и надежность микропроцессорных систем. Туда бакланов типа вас с сборщиками мусора вообще на пушечный выстрел не подпускают. Потому что фигово, знаешь ли, если Вася въехал в стену, а проц вместо того чтобы подушки выкидывать - мусор собирал...
> Так это то и есть одна из проблем. Даже если мы собираемся
> остаться в области видимости полгода, ключ может требоваться надежно и предсказуемо
> изничтожить *сейчас*. Чтобы не болтался в памяти. Мало ли кто и
> по какому поводу в памяти системы шариться потенциально может. Умный рантайм
> может в этом начинании неиллюзорно подгадить своим малопредсказуемым менеджментом памяти.Var=[] на Притоне, например.
> Сама по себе криптография - чистая математика и есть. Вон, например, tweetnacl
> - ни единого динамического выделения памяти на всю либу! Можно даже
> в какой-нить микроконтроллер засунуть, где полностью статическое распределение памяти.
> Очень интересно, как можно облажаться в управлении памятью, если оного при
> желании может не быть совсем. Кстати, на сях так можно, по
> крайней мере. В отличие от переусложненных Бюро Медвежьих Услуг, где тебя
> пытаются облагодетельствовать волшебными пинками.Дык и мы о том же.
> И тем не менее, на си можно писать очень надежный, стабильный и
> предсказуемый код. Си используется в автомобильной, авиационной и т.п. промышленностях,
> где важна именно предсказуемость и надежность микропроцессорных систем. Туда бакланов
> типа вас с сборщиками мусора вообще на пушечный выстрел не подпускают.
> Потому что фигово, знаешь ли, если Вася въехал в стену, а
> проц вместо того чтобы подушки выкидывать - мусор собирал...Дык.. Вы не перепутали, кому отвечать? Просто в Ваших ответах-всё то, что и утверждалось,
немного по другому представленное.
> Var=[] на Притоне, например.Опять же - чтобы это было предсказуемым, надо очень хорошо знать свойства рантайма своего ЯП. И чем он навороченнее - тем с этим сложнее. А потом что-нибудь как обычно перетрясут и наступит факап. Да и скорость работы бидона по дефолту такова, что для криптографии его будут использовать только отчаянные грызцы кактусов. Которые готовы "за идею" просадить скорость в 20 раз.
> Дык.. Вы не перепутали, кому отвечать?
А вот черт знает.
> Опять же - чтобы это было предсказуемым, надо очень хорошо знать свойства
> рантайма своего ЯП. И чем он навороченнее - тем с этим
> сложнее. А потом что-нибудь как обычно перетрясут и наступит факап. Да
> и скорость работы бидона по дефолту такова, что для криптографии его
> будут использовать только отчаянные грызцы кактусов. Которые готовы "за идею" просадить
> скорость в 20 раз.Опять же, "свойства рантайма"-это придуманные школярами умные словечки.
Есть стандарт языка, который гарантирует строго определённое свойства, создаваемым в памяти
объектамс, в течении времени их жизни. Реализации могут быть какими угодно, но все они
будут соответсвовать стандарту. А где в стандарте может быть прописано то, что
выше определилось как "Своства рантайма, навороченные, которые потрясут нафик,
когда что нибудь, как обычно(сотальной дред пропущен) "?
> объектамс, в течении времени их жизни. Реализации могут быть какими угодно, но
> все они
> будут соответсвовать стандарту. А где в стандарте может быть прописано то, что
> выше определилось как "Своства рантайма, навороченные, которые потрясут нафик,
> когда что нибудь, как обычно(сотальной дред пропущен) "?Да вот прямо в спецификации ВМ, той же Явы. Если бы вы не доказывали методично, что не умеете читать, то получили бы точное место, где прописано, например, что никакой детерминированности выполнения GC нет, и что он может с чистой совестью останавливать работу ВСЕХ остальных тредов для выполнения своей работы. Что, конечно, может обходиться некоторыми костыльными методами, но не суть.
Шрифты комические и доступ к репам по FTP и CVS это шутка такая?
> Шрифты комические и доступ к репам по FTP и CVS это шутка такая?у тебя проблема с ПОЛУЧЕНИЕМ через ftp и cvs?
CVS для нового проекта? В 2014 году? Позор вообще-то.Ну, или начинайте объяснять, почему вы предпочитаете CVS SVN или Git.
> CVS для нового проекта? В 2014 году?в 1996, если не ошибаюсь. :) cvs -D не даст соврать :)
LibreSSL началась в 2014 году, не передергивай.
Утилиты имопрта из CSS в любой живой продукт есть и всегда были.
s/CSS/CVS/
libressl - это часть openbsd. развивается именно в основном дереве openbsd.а на то, что у тебя с этим какие-то проблемы - да нам всё равно. если человек увидел cvs и впал в истерику - то это больной человек, по определению.
Да ёмоё, ты все считаешь, что это я не освоил cvs. Я с ним наработался, последние лет 10 не требовалось и слава богу. А вот разработчики OpenBSD ниасилили SVN -- это факт и позор для них.
> Да ёмоё, ты все считаешь, что это я не освоил cvs. Я
> с ним наработался, последние лет 10 не требовалось и слава богу.
> А вот разработчики OpenBSD ниасилили SVN -- это факт и позор
> для них.я считаю, что ты ничего не понимаешь, и считаешь, что видишь всю картину, а на самом деле не видишь ничего, у тебя всё примитивно огрублённо, и система контроля версий для тебя - это ВАЖНО, это СВЯЩЕННЫЙ ГРААЛЬ. последнее, что меня в жизни волнует - это то, пользуешься ли ты cvs или нет. это у тебя триггер сработал "Я ЗНАЮ КАК ПРАВИЛЬНО И НЕ МОГУ МОЛЧАТЬ!", а до этого момента о твоём существовании я и не подозревал.
Ты бы доверил разработку высокопроизвозительнрй программной системы человеку, который в 2014 году утверждает, что кобол рулит, а всё остальное -- хипстерство и ненужно? Вот и тут так же: дурная окаменевшая VCS, отсутствие цифровых подписей и, может быть, автотестирования.
> Ты бы доверил разработку высокопроизвозительнрй программной системы человеку, который
> в 2014 году утверждает, что кобол рулит, а всё остальное -- хипстерство и ненужно?как бы тебе объяснить, чтобы не обидеть...
в общем, никак не буду объяснять. ситуация изначально неверная... наоборот, чтобы была аналогия, это я должен требовать...
И этот человек распинался выше, что еле нашёл рабочий снепшот топика на каком-то протухшем зеркале? Ну-ну.
> И этот человек распинался выше, что еле нашёл рабочий снепшот топика на каком-то протухшем зеркале? Ну-ну.какое отношение автосборка, которая выполняется каждые 1.5 дня, имеет отношение к этому?
Если коротко: есть релизы стабильной ветки, они должны пройти автотестирование (которое не раз в полтора дня, а после каждого коммита). Есть devel-branch (или много), в которых можно ломать работоспособность, но не релизить, если оно сломано. Приблизительно так это принято сейчас, это нормальная разработка.По твоим словам, подход в LibreSSL другой, одна большая куча с периодическими снепшотами непонятной работоспособности. Проблема не в том, что в OpenBSD используют протухшую VCS, это технические детали. А в том, что общий процесс организации разработки и релиза намекает на то, что 'cvs ci' для этих людей -- верх хай-тека и лучше подходить к разработке они не хотят, игнорируя наработки индустрии чисто потому, что они сами настолько правы и твердолобы.
Я не хочу кого-то оскорблять. Я просто понимаю, что есть культура разработки кода и её отсутствие -- пусть даже в мелочах -- плохой показатель.
> По твоим словам, подход в LibreSSL другой, одна большая куча с периодическими снепшотами непонятной работоспособности.давай, ты сначала узнаешь, что такое "портированная" в рамках openbsd
кстати, тебе слово openssh о чём-нибудь говорит? там ТОЧНО ТАК ЖЕ. как и в tmux, и в openbgpd, и opensmtpd, и ещё в некоторых проектах.
>> По твоим словам, подход в LibreSSL другой, одна большая куча с периодическими снепшотами непонятной работоспособности.
>давай, ты сначала узнаешь, что такое "портированная" в рамках openbsdЯ тебе расказываю про то, как делать, чтобы софт из репы был рабочим, а ты мне: посмотри, как всё правильно в OpenBSD -- и похрен, что там рабочий снепшот LibreSSL (при вышедшем нерабочем релизе) приходтся с бубном искать по протухшим зеркалам. Для нативной системы, ещё не для "портированной". Зато как заморочено: и правильный CVS, и отдельное дерево для portable. Если б оно было заморочено, но работало, у меня бы вопросов не было. Так оно и заморочено, и не работает.
> там ТОЧНО ТАК ЖЕ. как и в tmux
Ага-ага, то-то tmux держит мастер-репу в Git. Не понял свяди между tmux и
>в openbgpd, и opensmtpd
> Ага-ага, то-то tmux держит мастер-репу в Git. Не понял свяди между tmux иЯ не ослышался? Чудо произошло?! Ты сам только что признал, что можно взять кусочек общего cvs, и при этом разрабатывать его в git, не имея никаких страданий по поводу основного дерева в cvs?
Тогда у меня только один вопрос - зачем был твой плач на протяжении всех этих сообщений?
имхо, такой ход мысли более чем оправдан, есть культура и уровень производства в ит. но опенбзд это не энтерпрайз, а академический или какой-то ещё проект, они не ставят своей целью максимальную эффективность. выше пишут, что ассемблерную реализацию aes убрали. я как админ в жизни не буду использовать опенбзд на работе, но обязан признать пользу от того же openssh. да и в силу слабой коммерции, людей у них немного. ты вот и сам готов им помочь только за сто баксов в час. :-) так что позора тут никакого нет, а есть своя логика.
> А вот разработчики OpenBSD ниасилили SVN -- это факт и позор
> для них.Переведите репозиторий OpenBSD на Subversion (он свободно доступен, если вы не в курсе). При этом сведите RCS-ревизии в единые коммиты (иначе зачем вообще нужен SVN?). Убедитесь, что по ходу дела история не побилась (здесь вас будут ждать сюрпризы). Покажите преимущества бинарного хранилища SVN по сравнению с текстовым у CVS. И тогда будет о чём говорить.
А так, ваши указания, что делать другим, равноценны содержимому /dev/null.
$100/час и можете рассчитывать на мою помощь.А уж пока мы в чятике, повторю ещё раз: OpenBSD с их окаменевшим нерелизнутым OpenCVS в 2014 году выглядят идиотами, это не только моё мнение.
В мире где прогрессивным считается переписывание чего-нибудь на JavaScript, выглядеть идиотом - не самый страшный вариант.
Роб, старина - ты прав на все 100500% ... да только толку то?
Я лично просто забил. Пусть жрут.
> идиoтом - не самый страшный вариант.В данном случае это не идиотия а обычный ретардизм в терминальной стадии. И забивание гвоздей микроскопом. А потом как-то так и оказывается что за сервера нечем платить, приходится вымогательствовать.
Им следовало бы использовать Mercurial вместо CVS, как наиболее простую реализацию DVCS, поддерживающую, к тому же, докачку данных при нестабильном соединении (чувствую, что выбор FTP обусловлен именно этой причиной: многие разработчики работают в труднодоступных районах, вдали от цивилизации).
А что сразу не RCS over rsync или вообще рассылку по UUCP?Они тоже докачку умеют, проверены временем и всё такое.
Откуда дровишки про "самую распространённую DVCS", кстати?
> Откуда дровишки про "самую распространённую DVCS", кстати?Ой. Там про "самую простую было". В OpenBSD в base system есть python2 (hg не работает с трёшкой)?
>> Откуда дровишки про "самую распространённую DVCS", кстати?
> Ой. Там про "самую простую было". В OpenBSD в base system есть
> python2 (hg не работает с трёшкой)?нет, нет ни python2, ни python3, и боюсь, за одно предложение этого побьют сильно (иначе я давно бы предложил)
есть perl
проблема в том, что мне НЕ НУЖНА ВСЯ ИСТОРИЯ. у меня 900 мб исходников, несколько сот мегабайт xenocara, и ещё всю историю с 1996 года мне в комплекте? :)
в cvs я могу отдельно хоть каждую веточку дёргать. хоть src/sys, хоть src/aaa/bbb/ccc
> проблема в том, что мне НЕ НУЖНА ВСЯ ИСТОРИЯ. у меня 900
> мб исходников, несколько сот мегабайт xenocara, и ещё всю историю с
> 1996 года мне в комплекте? :)
> в cvs я могу отдельно хоть каждую веточку дёргать. хоть src/sys, хоть
> src/aaa/bbb/cccВ SVN так же по обоим пунктам.
В Git есть work-around (указываешь при clone, сколько истории тебе нужно). А как в hg?
>> проблема в том, что мне НЕ НУЖНА ВСЯ ИСТОРИЯ. у меня 900
>> мб исходников, несколько сот мегабайт xenocara, и ещё всю историю с
>> 1996 года мне в комплекте? :)
>> в cvs я могу отдельно хоть каждую веточку дёргать. хоть src/sys, хоть
>> src/aaa/bbb/ccc
> В SVN так же по обоим пунктам.
> В Git есть work-around (указываешь при clone, сколько истории тебе нужно). А как в hg?Мне вообще не нужен никакой лишний файл. Я могу даже с ftp скачать архив, а дальше через cvs up его обновлять. Это прежде всего средство получения и синхронизации. и мне не нужна никакое изучение workaround, я просто захожу в нужный каталог и пишу cvs get src (или cvs get www... или играюсь с ключом -D, и восхищаюсь, что сайт openbsd вообще не изменился с прошлого века, и что тогда, что сейчас, выглядит адекватно и читаемо).
> скачать архив, а дальше через cvs up его обновлять.Для исходников обновление намного лучше получается у dvcs типа git. К тому же мотаться между ревизиями - быстро. Приехало какое-то гомно - ок, сказали git checkout <чтотамунас> и через несколько секунд у нас все зашибись из версии <чтотамунас>. С нулевым сетевым траффиком и затратами на время состоящими в основном из дискового i/o.
>> скачать архив, а дальше через cvs up его обновлять.
> Для исходников обновление намного лучше получается у dvcs типа git. К тому
> же мотаться между ревизиями - быстро. Приехало какое-то гомно - ок,
> сказали git checkout <чтотамунас> и через несколько секунд у нас все
> зашибись из версии <чтотамунас>. С нулевым сетевым траффиком и затратами на
> время состоящими в основном из дискового i/o.для того, чтобы один раз такое сделать - всё время хранить всю историю всей системы с 1996 года? тем более, как я вообще узнаю, как что прилетело. я использую текущую систему всю, целиком, а если разбираться, где источник проблем - тут уже вообще без разницы, какая система версий.
то есть, это, конечно, круто, что я могу вот так вот ВЖИК, и сделать. Только это мне нафиг не надо. У меня на одном компьютере раздел с openbsd 9 гб, на втором - до вчерашнего дня был 7.5, теперь 15. и исходники системы, портов, ксенокары и веб-сайта у меня всегда при мне.
> для того, чтобы один раз такое сделать - всё время хранить всю
> историю всей системы с 1996 года?Не скажу за HG, а гит это делает столь компактно, что вся история с лохматого ядра 2.6.11 (я даже не помню когда оно вышло) до распоследнего 3.16-rc4 занимает порядка гига в сумме и растет медленно, несколко Мб на релиз. По поводу чего в развернутой иерархии такого калибры, с которой делают что-то осмысленное - основной статьей расхода места на диске как правило является отнюдь не содержимое диры .git. А вот независимо вывалить все ревизии с 2.6.11 до 3.16-rc4 - это да, никакого диска не хватит. Но обычно рабочее дерево всего 1 или как максимум несколько, по этому поводу можно мотаться по 100 версиям отстоящим друг от друга на километр с вполне разумными затратами ресурсов и не перекачивая 100 раз почти все файлы целиком.
Вообще, специалисты по программированию умеют выбирать компактные формы представления и эффективные алгоритмы. Оно хранит только дельту, да еще упакованно. Потому можно хранить 100 ревизий с относительно небольшими затратами места. Не 100х а допустим 2х. Чем-то таким профессионалы от питонистов типа тебя и отличаются.
> тем более, как я вообще узнаю, как что прилетело.
В git есть git log, чтобы посмотреть что и от кого. А если так не понятно откуда гадость прилетела и где замаскировалась - есть bisect. За несколько попыток гадость можно локализовать даже не зная что это было и откуда. Маленькая математическая магия, далеко не новая. Но по прежнему позволяющая красивые фокусы. А вот с CVS/SVN/... такой маневр будет смотреться медленно и печально. И потребует скачать весь интернет 10 раз подряд.
> я использую текущую систему всю, целиком, а если разбираться, где источник
> проблем - тут уже вообще без разницы, какая система версий.Как раз разница может быть *гигантской*. С гитом можно ткнуться в 10 отстоящих за километр ревизий большого проекта (размером с линевый кернель например), не скачивая весь интернет 10 раз. Это будет просто и быстро и основное время уйдет на, собственно, сборку софта и проверку бажности энной ревизии. А за 10 раз баг, живший в неизвестном месте - загонится в угол. Путем отделения половины жилполщади по критерию "баг тут" или "баг не тут". Очень скоро окажется что багу некуда бежать. А вот с CVS/SVN такой маневр проводить... ээээ.... качать 10 раз почти целиком - задолбаешься. Гит то хранит только дельту, локально и компактно.
> то есть, это, конечно, круто, что я могу вот так вот ВЖИК,
Это не просто круто. Это позволяет найти блоху на теле у слона по быстренькому, путем отсекания по половинке площади с блохой.
> и сделать. Только это мне нафиг не надо. У меня на
> одном компьютере раздел с openbsd 9 гб, на втором - до
> вчерашнего дня был 7.5, теперь 15. и исходники системы, портов, ксенокары
> и веб-сайта у меня всегда при мне.Не знаю что надо тебе, но по идее, система контроля версий должна прежде всего эти самые версии контролировать, позволяя ненапряжно шариться по десятку разныз ревизий, независимо от расстояния между ними. А все остальные применения для VCS вообще побочны. То что некоторые путают VCS с файлопомойками - бывает, да. В благодарность это нагибает их рабочие процессы, ибо сложно микроскопом гвозди забивать...
>> скачать архив, а дальше через cvs up его обновлять.
> Для исходников обновление намного лучше получается у dvcs типа git. К тому
> же мотаться между ревизиями - быстро. Приехало какое-то гомно - ок,
> сказали git checkout <чтотамунас> и через несколько секунд у нас все
> зашибись из версии <чтотамунас>. С нулевым сетевым траффиком и затратами на
> время состоящими в основном из дискового i/o.Вот кому так надо, используют cvsync. Многие разработчики OpenBSD в том числе. Сюрприз?
Man cvssync:cvssync is an auxiliary tool issued with cvs-fast-export in order to facilitate moving CVS repositories to version control systems that aren’t chipped out of flint. Of course, you can also use it for backups and other purposes.
Офигенный пример забивания гвоздей микроскопом этот cvssync, чтобы использовать его вместо гита.
А, это не оно. Вот оно:CVSync is a software package for distributing and updating source trees from a master cvs(1) repository on a remote server host. The OpenBSD sources are maintained in a CVS repository on a central development machine in Canada. With CVSync, OpenBSD users can easily keep their own source trees up to date.
CVSync uses the so-called pull model of updating. Under the pull model, each client asks the server for updates, if and when they are wanted. The server waits passively for update requests from its clients. Thus all updates are instigated by the client. The server never sends unsolicited updates. Users must either run the CVSync client manually to get an update, or they must set up a cron(8) job to run it automatically on a regular basis.
Если ты не разработчик, используй хоть ftp, хоть rsync, хоть cvs up, это для тебя удобнее. А VCS тебе вообще не нужен.Но если ты пишешь код (ещё и без постоянного интернета) -- Git/hg удобнее. Люди, игнорирующие это через 10 лет активного существования DVCS (и даже игнорирующие SVN), вероятно, также упорно закрывают глаза на другие идеи, не описанные в книгах 70-х, поэтому я позволяю себе усомниться к компетенции последних.
Ещё раз: я действительно понимаю, почему CVS is heavily outdated, а ты так и не привёл никаких аргументов. Мне не лень написать brew install cvs, чтобы вернуться в восхитительный мир доисторических VCS, просто это указывает на твердолобость разработчиков LibreSSL.
> Но если ты пишешь код (ещё и без постоянного интернета) -- Git/hg
> удобнее.я использую и hg и git. это не мешает мне считать каждого, кто заикнётся про git в openbsd, неадекватом с абсолютной позицией. короче говоря, больным человеком. короче говоря, типичным современным интернет пользователем.
> Люди, игнорирующие это через 10 лет активного существования DVCS (и
> даже игнорирующие SVN), вероятно, также упорно закрывают глаза на другие идеи,
> не описанные в книгах 70-х, поэтому я позволяю себе усомниться к
> компетенции последних.это твоё дело. то, что ты не сломаешь openbsd, меня только порадует.
> Ещё раз: я действительно понимаю, почему CVS is heavily outdated, а ты
> так и не привёл никаких аргументов.зачем? это ты считаешь себя особенным, а я в подобных дискуссиях участвую примерно 997 раз. смысла это не добавляет. зато я смотрю на плоды, и на то, что cvs-ный openbsd с каждым релизом нравится мне всё больше и больше, а git-ный linux - всё меньше и меньше. это для меня главное. то, что кто-то считает, что git может решить все проблемы, пусть и дальше считает - всё равно он ничего не понимает.
> кто заикнётся про git в openbsd, неадекватом с абсолютной позицией. короче
> говоря, больным человеком. короче говоря, типичным современным интернет пользователем.Больные люди - это те кто использует VCS как файлокачалку, вместо превращения в эффективный инструмент разработки, который вывел бы разработку на качественно новый уровень, позволив ненапряжно и быстро рулить по гигантской иерархии по ВСЕМ ее ревизиям.
> Мне не лень написать brew install ...Тфу ты!
Предупреждать же надо что ты ахтунг :-/
> проблема в том, что мне НЕ НУЖНА ВСЯ ИСТОРИЯ. у меня 900
> мб исходников, несколько сот мегабайт xenocara, и ещё всю историю с
> 1996 года мне в комплекте? :)Не скажу за hg, а git можно вытянуть и для только текущей ревизии. Но зачем, если в нечто типа гига данных умещается все ядро линя с как минимум, v2.6.11 и вплоть до 3.16-RC?
> в cvs я могу отдельно хоть каждую веточку дёргать. хоть src/sys, хоть
> src/aaa/bbb/cccТолько скачать вместо версии aaa версию bbb займет дохрена времени, если там сколь-нибудь заметное количество файлов поменялось. Вообще, мотаться по версиям в CVS/SVN посли git может заходеть лишь отчаянный мазохитс. Как человек шарящийся по ревизиям такой мелочи как Linux Kernel это ответственно заявляю.
> Не скажу за hg, а git можно вытянуть и для только текущей
> ревизии. Но зачем, если в нечто типа гига данных умещается все
> ядро линя с как минимум, v2.6.11 и вплоть до 3.16-RC?мне не нужно два гига. как и ядро линя. у меня есть и мелкие носители.. и у других есть мелкие носители. иметь сырцы - это удобно, йоу. а держать всю историю.
>> в cvs я могу отдельно хоть каждую веточку дёргать. хоть src/sys, хоть
>> src/aaa/bbb/ccc
> Только скачать вместо версии aaa версию bbb займет дохрена времени, если там
> сколь-нибудь заметное количество файлов поменялось. Вообще, мотаться по версиям в CVS/SVN
> посли git может заходеть лишь отчаянный мазохитс. Как человек шарящийся по
> ревизиям такой мелочи как Linux Kernel это ответственно заявляю.чё? это не версия, это путь. мне может не требоваться весь src. мне, например, потребовалось скачать только sys от нужной версии, я сделал cvs get src/sys -rВЕТКА, и всё. потом собрал tiny-ядро и завёл новый релиз на pentium 120. красота.
мне не нужно мотаться по версиям. а если и нужно - то только по дате, типа "какая версия веб-сайта или ещё чего-то была на такую-то дату". для этого есть ключ -D.
> мне не нужно два гига. как и ядро линя. у меня есть и мелкие носители..У меня где-то и флоппики завалялись, но, как ты понимаешь, они представляют для меня исключительно музейный интерес.
> и у других есть мелкие носители.
Экономить на своем же собственном удобстве - крайне паскудное начинание, хотя тебе с твоим ником - в самый раз.
> иметь сырцы - это удобно, йоу. а держать всю историю.
А вся история - более информативно. Особенно когда в очередной версии появился какой-то паскудный баг, сразу не понятно где он вылез, но очень уж хочется гада прибить.
> cvs get src/sys -rВЕТКА, и всё. потом собрал tiny-ядро и завёл
> новый релиз на pentium 120. красота.А я завел мой минимальный кернел на MIPS, 400МГц, 16 мег оперативы. А еще размер с полпачки сигарет и питается от одной 18650 банки (в ноуте таких воткнуто от души, 4-6 штук минимум) порядка 5 часов. Куда как больше вставляет чем некромансия с пыльными гробами.
> мне не нужно мотаться по версиям. а если и нужно - то
> только по дате, типа "какая версия веб-сайта или ещё чего-то была
> на такую-то дату". для этого есть ключ -D.А пофигу - у CVS/SVN есть абсолютно фатальный недостаток - они не хранят историю и не оперируют дельта-компрессией в этом процессе и при передаче данных. Это означает что скачка сколь-нибудь разной ревизии будет занимать почти столько же времени как скачка с ноля. А это буллшит.
>> иметь сырцы - это удобно, йоу. а держать всю историю.
> А вся история - более информативно. Особенно когда в очередной версии появился
> какой-то паскудный баг, сразу не понятно где он вылез, но очень
> уж хочется гада прибить.Вот кому это надо, те используют что-то сверх CVS. Тот же cvsync.
>> cvs get src/sys -rВЕТКА, и всё. потом собрал tiny-ядро и завёл
>> новый релиз на pentium 120. красота.
> А я завел мой минимальный кернел на MIPS, 400МГц, 16 мег оперативы.
> А еще размер с полпачки сигарет и питается от одной 18650
> банки (в ноуте таких воткнуто от души, 4-6 штук минимум) порядка
> 5 часов. Куда как больше вставляет чем некромансия с пыльными гробами.То есть выкидываем рабочее железо и покупаем новое со сравнимой производительностью. ОК.
>> мне не нужно мотаться по версиям. а если и нужно - то
>> только по дате, типа "какая версия веб-сайта или ещё чего-то была
>> на такую-то дату". для этого есть ключ -D.
> А пофигу - у CVS/SVN есть абсолютно фатальный недостаток - они не
> хранят историюЕщё раз - cvsync.
> и не оперируют дельта-компрессией в этом процессе
Простите, дядя мальчик, вы - даун?..
> и при передаче данных.
... судя по всему, вопрос риторический.
> Это означает что скачка сколь-нибудь разной ревизии будет занимать
> почти столько же времени как скачка с ноля. А это буллшит.Буллшит - ваши заявления. Не имея понятия о том, как на самом деле устроен и что умеет CVS, вы с пафосом вещаете о том, что все, кто им пользуются - лохи. Неужели самому не противно вариться в собственном желудочном соке?
Да, у CVS есть масса недостатков, он не умеет много вкусностей, которые есть у Mercurial и прочих. Но вы об этом не имеете никакого понятия, иначе бы у вас были аргументы, а не... буллшит.
>чувствую, что выбор FTP обусловлен именно этой причиной: многие разработчики работают в
> труднодоступных районах, вдали от цивилизации.Где можно почитать о том, откуда работают разрабы? Интерсено.
>>чувствую, что выбор FTP обусловлен именно этой причиной: многие разработчики работают в
>> труднодоступных районах, вдали от цивилизации.
> Где можно почитать о том, откуда работают разрабы? Интерсено.Порт geo/openbsd-developers к вашим услугам. Что лично до меня - даже если работаю в Москве, то нередко через мобильник, причём из такого здания, где и 3G не всегда ловится.
> работаю в Москве, то нередко через мобильник, причём из такого здания,
> где и 3G не всегда ловится.А программируете на тетрисе? :)
>> работаю в Москве, то нередко через мобильник, причём из такого здания,
>> где и 3G не всегда ловится.
> А программируете на тетрисе? :)На абаке. :-P
странно, что код не выложен на публичные репы, но это наверное вопрос времени...
> странно, что код не выложен на публичные репы, но это наверное вопрос
> времени...Эм, http://www.openbsd.org/cgi-bin/cvsweb/src/lib/ , далее libcrypto, libssl и - сюрприз! - libressl (новенькая штучка, готовится к выпуску).
Не понял, зачем поддержку Windows убрали...
Видимо, чтобы в выпуске 2.0 триумфально её вернуть.
> Не понял, зачем поддержку Windows убрали...Наверное затем что сильно отличается от *nix-образных и возиться с ней соответственно никто не хочет.
>> Не понял, зачем поддержку Windows убрали...
> Наверное затем что сильно отличается от *nix-образных и возиться с ней соответственно
> никто не хочет.Свист. Использовалась и будет использоваться. Мнение маргиналов рынку до одного места. Да-да, до того самого.
> Свист. Использовалась и будет использоваться. Мнение маргиналов рынку до одного места. Да-да, до того самого.Вот пусть и сами пишут.
Главная задача libressl - это обеспечивать своих пользователей, пользователей openbsd.
> Мнение маргиналов рынку до одного места.Му-ха-ха. Так вот: мнение рынка проекту OpenBSD до одного места! :)
> Да-да, до того самого.
Я слышу треск твоего шаблона даже через интернет :)
> Свист. Использовалась и будет использоваться. Мнение маргиналов рынку до одного места.А разработчикам может быть до того же места на мнение рынка, например. Как хотят так и программят. А оспорить можно в спортлото.
> Не понял, зачем поддержку Windows убрали...OpenSSL же всё также как и раньше работает на Windows? ну и в чём тогда притензии к LibReSSL?
ато вы пишете так будтобы разработчики LibReSSL -- якобы отобрали у OpenSSL функцию Windows :-)..
всё в порядке(!) OpenSSL+Windows --- это два сапога пара :) . пусть это так и останется.
а на Линуксах-и-Бсдях -- будет нормальный LibReSSL! (а лучше -- GnuTLS)
BoringSSL оказался постабильнее (drop in replacement)
а безопаснее кто из них? BoringSSL или LibReSSL?ну или если предположим что качество кода примерно одинаковое, и следовательно, величина описывающая среднюю-вероятность-ошибки-на-1-строчку-кода -- тоже одинаковая.. то у кого строчек-то кода больше?
libressl-2.0.0:1177 text files.
1172 unique files.
356 files ignored.http://cloc.sourceforge.net v 1.60 T=9.21 s (89.2 files/s, 35898.9 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C 668 23293 51532 164696
C/C++ Header 124 5404 10990 32521
Bourne Shell 15 3391 3950 22631
m4 7 979 91 8792
make 8 29 2 2422
-------------------------------------------------------------------------------
SUM: 822 33096 66565 231062
-------------------------------------------------------------------------------boringssl-HEAD:
614 text files.
543 unique files.
60 files ignored.http://cloc.sourceforge.net v 1.60 T=5.96 s (88.6 files/s, 40349.7 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C 324 14440 25986 91648
Perl 49 5817 4916 44670
C/C++ Header 88 5788 9958 24067
Go 14 955 707 5869
Assembly 2 491 0 2407
C++ 6 151 91 1033
CMake 40 240 11 918
Bourne Shell 3 50 46 127
CSS 1 12 0 55
ASP.Net 1 0 0 47
-------------------------------------------------------------------------------
SUM: 528 27944 41715 170841
-------------------------------------------------------------------------------
Заметьте, при том, что codebase BoringSSL меньше, чем у LibreSSL в полтора раза:1. BoringSSL стабильнее, быстрее и фичастее LibreSSL
2. BoringSSL поддерживает Windows (>90% market share)Что-то не так в консерватории у OpenBSD, факт. У гугля лучше.
> Заметьте, при том, что codebase BoringSSL меньше, чем у LibreSSL в полтора
> раза:
> 1. BoringSSL стабильнее, быстрее и фичастее LibreSSL
> 2. BoringSSL поддерживает Windows (>90% market share)
> Что-то не так в консерватории у OpenBSD, факт. У гугля лучше.1. гугле собирается обмениваться кодом с libressl
2. гугле использует libc от openbsd в android.
3. а вы, сударь, зануда
> 1. гугле собирается обмениваться кодом с libressllibressl не собираться принимать код, у них своя атмосфера.
> 2. гугле использует libc от openbsd в android.
старперы openssl будут продолжать городить велосипеды
>> 1. гугле собирается обмениваться кодом с libressl
> libressl не собираться принимать код, у них своя атмосфера.Сказал человек, не участвующий в разработке LibreSSL и OpenBSD
(для справки, я - участвую)
> Заметьте, при том, что codebase BoringSSL меньше, чем у LibreSSL в полтора
> раза:
> 1. BoringSSL стабильнее, быстрее и фичастее LibreSSLПруф? Насчёт стабильнее и быстрее особенно.
> 2. BoringSSL поддерживает Windows (>90% market share)
LibreSSL уже допиливают под cygwin, буквально на глазах.
> Что-то не так в консерватории у OpenBSD, факт. У гугля лучше.
Гугль пилит в первую очередь под Хром, и не так сильно заморачивается на тему "быть drop-in заменой для OpenSSL". Так что эти два проекта сравнивать НЕ КОРРЕКТНО. И, да, обмен кодом между ними уже потихоньку идёт.
> LibreSSL уже допиливают под cygwin, буквально на глазах.Боюсь, большинство виндозных програмеров будет истошно махать факами по этому поводу. Я бы еще понял со скрипом msys/mingw, но cygwin - довольно своеобразная штука...
>> LibreSSL уже допиливают под cygwin, буквально на глазах.
> Боюсь, большинство виндозных програмеров будет истошно махать факами по этому поводу.А ты не бойся, вендузоид.
> Я бы еще понял со скрипом msys/mingw, но cygwin - довольно своеобразная
> штука...Так ведь и вы, вендузоиды, тоже несколько... "своеобразные".
>> LibreSSL уже допиливают под cygwin, буквально на глазах.
> Боюсь, большинство виндозных програмеров будет истошно махать факами по этому поводу. Я
> бы еще понял со скрипом msys/mingw, но cygwin - довольно своеобразная
> штука...Виноват, именно MinGW упоминался, да.
Google ненавидит NSA в отличии от OpenBSD.
> Google ненавидит NSA"Google испытывает ненависть по отношению к NSA" ?
или
"Google подвергается ненависти со стороны NSA" ?
русский язык, такой русский язык.. нифига не ясно без этихвсех уточнений :-)
> ...в отличии от OpenBSD.
и это тоже добавляет ещё кучу вариантов как это сложное предложение можно понимать
Из них - никто.> Our main reasons for ocaml-tls are that OCaml is a modern functional language, which allows concise and declarative descriptions of the complex protocol logic and provides type safety and memory safety to help guard against programming errors. Its functional nature is extensively employed in our code: the core of the protocol is written in purely functional style, without any side effects.
> https://github.com/mirleft/ocaml-tls
пацаны... а сделайте порт для openxcom 1.0. и minetest 0.4.10кстати, ещё у кого-нибудь minetest в openbsd тупит?
> пацаны... а сделайте порт для openxcom 1.0. и minetest 0.4.10
> кстати, ещё у кого-нибудь minetest в openbsd тупит?Напиши bentley@, он специализируется на портировании игр. :)
>> пацаны... а сделайте порт для openxcom 1.0. и minetest 0.4.10
>> кстати, ещё у кого-нибудь minetest в openbsd тупит?
> Напиши bentley@, он специализируется на портировании игр. :)да я по иноземному не умею писать :(
тем более, оно у меня не очень собралось: http://51t.ru/k47nUu
>>> пацаны... а сделайте порт для openxcom 1.0. и minetest 0.4.10
>>> кстати, ещё у кого-нибудь minetest в openbsd тупит?
>> Напиши bentley@, он специализируется на портировании игр. :)
> да я по иноземному не умею писать :(
> тем более, оно у меня не очень собралось: http://51t.ru/k47nUuВ -CURRENT для 5.6 это уже, видимо, не попадёт - подожди падения релиз-лока, тогда можно будет подумать насчёт обновления yaml. На оном полсотни портов только напрямую завязаны, а сейчас между только что закончившимся хакатоном и заморозкой дерева слишком мало времени осталось.
> В -CURRENT для 5.6 это уже, видимо, не попадёт - подожди падения
> релиз-лока, тогда можно будет подумать насчёт обновления yaml.я где-то в рассылке видел какой-то порт, но не знаю, рабочий ли он, автор говорит, что он зависит от предыдущего порта, которого я не нашёл. а потом вообще всё потерял :(
ps. пиши прям туда, там я хоть сразу увижу :) а то тут вспоминал, где это было :)
> Вызовы strlcat/strlcpy (http://opensslrampage.org/post/83153080370/re-using-strlcpy-...) замены (http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/cry...) на snprintf (http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/app...),Суть не в этой замене, а в том, что факт переполнения строки отслеживается.
+ i = snprintf(str, newlen, "%s%s", (t->data >= '5') ? "19" : "20",
+ (char *) t->data);
+ if (i == -1 || i >= newlen) {
+ ASN1_STRING_free(ret);
+ return NULL;
+ }