Разработчики проекта OpenBSD представили выпуск переносимой редакции пакета LibreSSL 3.9.0, в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. Проект LibreSSL ориентирован на качественную поддержку протоколов SSL/TLS с удалением излишней функциональности, добавлением дополнительных средств защиты и проведением значительной чистки и переработки кодовой базы. Выпуск LibreSSL 3.9.0 рассматривается как экспериментальный, в котором развиваются возможности, которые войдут в состав OpenBSD 7.5...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60765
> Прекращена поддержка алгоритмов GOST и STREEBOGПорвались, жаль
> Порвались, жальПочему сразу порвались?
Зачем им вообще поддерживать ненужный им мусор? Тем более в котором они не сильно и разбираются.
Чтобы были закладки_от_майора?
Чтобы я тоже мог пользоваться ихним продуктом!А они... гады...
Согласен, закладки должны быть только от правильных хозяев, иначе и рукопожатым можно перестать быть.
Обычному локалхостовому линуксоиду эта самая рукопожатность не сильно-то и нужна ни с какой стороны. Но вреда от отечественного майора ему может прилелеть гораздо больше.
>мусорВот так местный иксперд назвал мусором чью-то работу. Видать сам сделал нечто более полезное.
> Вот так местный иксперд назвал мусором чью-то работу.Извини, но если чью-то работы выкинули на мороз из-за качества, то таки да - это мусор:
> The current implementation is low quality and got in the way, especially in libssl.
> While we would be open for GOST support, it needs to be significantly better than
> what we have had and it also needs a maintainer.И да, это не я оценил, а разрабы LibreSSL
>Извини, но если чью-то работы выкинули на мороз из-за качества, то таки да - это мусор:Нет. Просто не хватило желания или ресурсов на поддержку.
>И да, это не я оценил, а разрабы LibreSSL
Опять балаболишь. Это ТВОЯ ЛИЧНАЯ бесполезная оценка.
>>Извини, но если чью-то работы выкинули на мороз из-за качества, то таки да - это мусор:
> Нет. Просто не хватило желания или ресурсов на поддержку.Вот она, суть картонного героизма. Ему и реализация от Джона До из АНБ вполне годится. Нахаляву и уксус сладок, как говорится.
Картонный героизм — это закрыть возможность отвечать на свои выcepы, и отвечать самому.Уж коли отключил возможность комментировать твой бред, то будь мужиком — не пиши мне сам.
Забыл, что для тебя надо писать предельно доходчиво: если ты соберёшь LibreSSL и продашь как СКЗИ, то тебя гарантированно отправят познакомиться с теми хакирами, кто "ломает" кредитки доверчивых бабушек. Боюсь, те тебя за язык определят уровнем пониже.
Они тебе чем-то обязаны?
а где, понимаешь, российская реализация SSL, чтобы с ними?
где ipsec с ними в астре и/или альте? где openvpn, wireguard?
ну и https чтоб в каждом броузере?
чтобы легко выполнять требования ФСБ?
Ipsec, openvpn и wireguard в одном флаконе с ГОСТ'ом, русскими шашками и лаборантками, существует и называется "ViPNet".
Купишь - будет тебе и в Астре, и в Альте.
>а где, понимаешь, российская реализация SSL, чтобы с ними?
Не жаль.In 2015 Biryukov, Perrin and Udovenko reverse engineered the unpublished S-box generation structure (which was earlier claimed to be generated randomly) and concluded that the underlying components are cryptographically weak.[13]
И немного подробнее, на русском:На конференции Crypto-2015 Алекс Бирюков, Лео Перрин и Алексей Удовенко представили доклад, в котором говорится о том, что значения S-блока шифра «Кузнечик» и хеш-функции Стрибог не являются (псевдо)случайными числами, а сгенерированы на основе скрытого алгоритма, который докладчикам удалось восстановить методами обратного проектирования[12][13].
29 января 2019 года была опубликовано исследование «Partitions in the S-Box of Streebog and Kuznyechik»[14], которое опровергает заявление авторов о случайном выборе параметров таблиц замен в алгоритмах Стрибог и Кузнечик[15].
https://ru.wikipedia.org/wiki/Стрибог_(хеш-функция)
На мой взгляд, достаточно хорошим аргументом является то, что у этой крипты много "идейных" ненавистников, но пока только раз за разом обнаруживаются уязвимости в насаждаемых СГА стандартах. Если проблемы алгоритмов и в самом деле такие значительные, как утверждается, хотелось бы увидеть обоснованные подтверждения и какие бы то ни было результаты. А вот в низкое качество реализаций я легко верю, нет культуры.
> А вот в низкое качество реализаций я легко верю, нет культуры.Что же делать с культурой? Математик, по совместительству умеющий кодить, публикует эталонную реализацию, к которой основное требование - изложить на понятном для программистов языке. Каждый может её посмотреть, а не просто верить.
Вот, например:
#if defined(__i386) || defined(__i386__) || defined(__x86_64) || defined(__x86_64__)
# define c2l(c,l) ((l)=*((const unsigned int *)(c)), (c)+=4)
# define l2c(l,c) (*((unsigned int *)(c))=(l), (c)+=4)
#elseКак видно, даже обошлось без злой шутки с bswap, которую программисты слепо накопировали из референса AES в свои оптимизированные варианты.
Но здесь и своих вариантов не было, программисты копировали всё сплошным текстом, а потом чему-то удивляются.
Не.
Всратый математик головного мозга, у всех крипто стандартов РФ проблема с тем что их пишут чокнутые математики для чокнутых математиков.
Людям у которых математика не родной единственный язык общения (считай программерам-имплементаторам) ихняя писанина не понятна от слова совсем.И кодить они тоже не умеют, только формулы на бумажке писать.
> Как видно, даже обошлось без злой шутки с bswapЭто не про bswap, это htonl(), ntohl().
Из описания выше следует, что всратый в этой истории имеет Вы, Иван83.
Я пограмист самоучка.
У меня не было проблем с имплементацией иностранных крипто алгоритмов, и даже ECDSA я умудрился реализовать на С с нуля, те математику длинных чисел, математику для элиптических кривых и уже поверх этого сам ECDSA.Но описание алгоримтмов российской крипты - это сектансткий математический язык, на котором выпускники полутора кафедр криптографии пишут для себя и друг для друга. У них закрытый клуб для своих, они в этом варятся всю жизнь.
И как показывает практика ничего хорошего родить не могут.
- ассиметричная крипта в РФ всегда была не своя, RSA а теперь ECDSA со своими параметрами, тут претензий нет, как и вклада
- симметричная - древний гост89, у которого было непонятное описание, 100500 разных параметров и который под конец переименовали в магму оставив только один набор параметров и заодно зачем то зарвенув порядок следования байтов.
Про ихний новый алгоримт (кузнечик) уже писали - они там какие то подозрительные SBox нафигачили, говорили что рандомные но явно нет.
- хэш (стрибог) - огромный стыд! взяли израильскую хайфу, не правильно посмотрели на картинку и накосячили с реализацией так что из 512 бит она стала ~260. И это так и оставили в стандартах.
Ну в принципе он пересказал слова автора EnRUPT, только тот их писал про западную школу.
>> Как видно, даже обошлось без злой шутки с bswap
> Это не про bswap, это htonl(), ntohl().Не вижу никаких htonl() или ntohl() в FIPS 197. Вижу какой-то язык от математиков для математиков:
01: procedure CIPHER(in, Nr, w)
02: state ← in
03: state ← ADD_ROUND K EY(state, w[0..3])
04: for round from 1 to Nr − 1 do
05: state ← SUB_BYTES(state)
06: state ← SHIFT_ROWS(state)
07: state ← MIX_COLUMNS(state)
08: state ← ADD_ROUND_KEY(state, w[4 ∗ round..4 ∗ round + 3])
09: end for
10: state ← SUB_BYTES(state)
11: state ← SHIFT_ROWS(state)
12: state ← ADD_ROUND_KEY(state, w[4 ∗ Nr..4 ∗ Nr + 3])
13: return state
14: end procedureЗато bswap видел в товарных количествах, поскольку htonl() почему-то объявлена без inline и хотевшим быстрых вычислений приходилось кодить на ассемблере. Кто-то догадывался заменить bswap более быстрой на то время последовательностью команд, кто-то нет. А вот уйти вообще от необходимости менять порядок байт в двойном слове - это не типичная для программистов задача вроде длинной арифметики с учётом флага переноса, а требующая хотя бы приблизительного понимания, чем отличаются поля Галуа от Елисейских - не удивительно, что не догадывались. Зато если бы программистам дали reference implementation - наверняка некоторые точно так же тыкали бы в неё пальчиком и ухохатывались.
Порядок следования байт - это машино зависимое.
Одно дело юзать bswap() там где нужно по алгоритму миксовать байты и другое дело htonl()/ntohl() которые используются для конвертации данных на входе/выходе, и на архитектурах отличных по big-endian от х64 они могут вообще отбрасыватся при компиляции потому что перестановки не требуется.
Rijndael описан в расчёте на BigEndian. Поскольку оперирует 32-х разрядными значениями, программистам приходится менять порядок байт при чтении-записи памяти на LitteEndian. Эта операция достаточно дорогая. Однако, существует другой алгоритм, дающий тот же побочный эффект, но не требующий смены порядка байт на LitteEndian. Такой алгоритм, реализованный на С++, обгоняет оптимизированные ассемблерные реализации. Практика показала, что программисты в большинстве своём не могут создать такой алгоритм.
Да, только роботы его могут создать!
Слава роботам!
Это шутка? И над чем смеяться? Когда программисты тыкают пальчиком в математиков, но при этом не могут проделать очевидные для математиков преобразования, мне почему-то грустно.
Потому что пограмисты програмировают для компуктера и оно работает, а математики должны написать для пограмистов понятное и тут как раз фейл.А касательно оптимизаций - там see и simd версии уже есть, пофиг на такую мелочёвку.
Кроме того я не умерен что нынче компилятор сам такое не преобразует автоматом.
> Потому что пограмисты програмировают для компуктера и оно работает, а математики должны
> написать для пограмистов понятное и тут как раз фейл.Для меня математики вполне понятно написали.
> А касательно оптимизаций - там see и simd версии уже есть, пофиг
> на такую мелочёвку.Угу, когда программисты не справились, на помощь пришли инженеры из Intel и AMD.
> Кроме того я не умерен что нынче компилятор сам такое не преобразует
> автоматом.Я уверен, что и завтра не сможет.
> Если проблемы алгоритмов и в самом деле такие значительные, как утверждается, хотелось бы увидеть обоснованные подтверждения и какие бы то ни было результаты.Товарищ майор, там по ссылке выше уже всё объяснили и обосновали. Доверять алгоритмам, разработанным при участии спецслужб какой-либо страны категорически нельзя.
А других алгоритмов практически и нет, либо вы плохо искали связь.
Задача прикто либы - быть криптолибой, те сборником разных крипто алгоритмов, не важно нравятся они кому то или нет, соотвествуют требованиям или нет.
Чтобы вы понимали там до сих пор везде начиная с md2 и 3des всё есть.Вот это фанбойство: "давайте оставим полтора алгоритма самых лучших в мире" - это архи тупо.
Ну оставляйте вы их где то в дефолтах TLS, но удалять имплементации самих алгоритмов просто нельзя.
> Чтобы вы понимали там до сих пор везде начиная с md2 и 3des всё есть.тебе уже удалось хотя бы в лабораторных условиях расшифровать 3des?
А вот single-des и dss auth - уже лет пять как нету в принципе (в openssl можно, помучавшись, включить, хотя уже и не факт что соберется), как и много чего другого.
Не то чтобы от чего помогло, конечно, но во всяком случае освободило разработчиков от необходимости исправлять баги еще и в таком коде (а их там вполне могло быть).
> но удалять имплементации самих алгоритмов просто нельзя.
тебя спросить забыли, какая жалость.
Что там исправлять!?
Открываешь RFC с эталонной реализацией md5 на Си из 199х годов от Ривеста, копипастишь это в .c .h файлы и оно до сих пор собирается и работает.
Но может быть компелятор тебя немного обругает и потребуются косметические правки.Да у меня своих реализаций крипты полно, ничего им не делается за годы лежания на диске, как работали так и работают.
Моя позиция как у авторов bounce caste крипто либы - все алгоритмы собрать в одном месте и сделать удобными к использованию.
Потому что БИБЛИОТЕКА это собрание, чем больше всего - тем лучше.
То что вы на практике 95% использовать не будете потому что оно слабое/устарвшее/тп - дело ваше, я не прошу DSS, md2, des юзать, только чтобы алгоритмы были доступны в либе.
Меня больше заботит чтобы как со старыми форматами - всегда было чем обработать любой давности любой файл.
> Но может быть компелятор тебя немного обругает и потребуются косметические правки.А может не обругает, и будет опять - "fixed RCE bug which standed for 20+ years".
Если ты не знал или забыл - вся идея libreфорка была именно в том чтобы выбросить тонны уже неактуального (или во всяком случае - неактуального для применения в openbsd в качестве штатного механизма) кода и тем избавиться от вызванных им ошибок и уязвимостей, сократив кодовую базу до обозримой. Не получилось, но они - пытались. А задача сделать мегауниверсальный набор всех возможных алгоритмов - не ставилась вообще.
> Меня больше заботит чтобы как со старыми форматами - всегда было чем обработать любой давности
> любой файл.или файл внезапно - сам тебе что-нибудь "обработает". С файлами слишком большой давности - или нарочно подброшенными - это бывает.
Теперь же это идея сделать невозможным использование в "несвободных"®™ странах. Или всегда была?
> Или всегда была?Да и сейчас ее нет.
Там же написали:
"While we would be open for GOST support, it needs to be significantly better than what we have had and it also needs a maintainer."
Т.е. у них даже ментейнера нет.Эти алгоритмы нужны где-то за пределами этой страны?
Нет.А кто из местных решится мейнтейнить криптографию для зарубежного НКО без опасений набутыливания?
Скорее всего никто.А если найдется, то можно ли ему будет доверять?
Тоже нет, на него будут влиять местные спецы.Т.е. у тебя есть некачественный код без ментейнера.
Который ты и основные разрабы не используют.
Ну и нафига это счастье libssl'цам?Но конечно проще всего все списать "Кругом враги!!111"
Скулёж для нищих разумом.Не нужен ни меинтейнер ни доверие.
Достаточно прогнать тест и убедится что оно выдаёт то что должно.
Тестовые векторы даже ущербные математики-криптографы РФ сообразили что надо писать.
Они взялись не выбрасывать алгоритмы а переписать код с учётом современных принципов, типа там strlen() и всякий подобный мусор выкинуть и почистить всякое другое непотребство.RCE в крипто алгоритмах - это надо постаратся очень сильно.
Максимум можно не очень красиво обрабатывать поддинг base64 и где то там падать.
Напоминаю - за двадцать лет в ssh1 нашлась ОДНА ошибка в strlen. НЕ эксплуатируемая, поскольку off-by-one обычно крайне сложно как-то применить. (да, считали вручную и после редактирования строчки на единичку сбились)А несколько remote root - это вот умельцы из прожекта. Щас-то вот они точно тебе почистят.
> RCE в крипто алгоритмах - это надо постаратся очень сильно.
rce там как обычно будет не в алгоритме (он если и будет - в openssl) а на стадии разбора параметров.
Я в них верю, они смогут.
Охх.
Дело в том, что я работал с оригинальным кодом от ssh конторы, код там тот ещё.
Подозреваю что все эти конюшни не дочистили до сих пор, как минимум пару лет назад я развлекался с кнвертацией закрытого ключа в ssh2 формате и ssh-keygen банально падал.
> Подозреваю что все эти конюшни не дочистили до сих пор, как минимум
> пару лет назад я развлекался с кнвертацией закрытого ключа в ssh2
> формате и ssh-keygen банально падал.это вот - целиком и полностью код опенбсдшников.
Нет, читайте копирайты в исходниках.
> Нет, читайте копирайты в исходниках.те исходники от которых копирайты - все еще доступны в оригинале. Нет там фичи преобразования ключей.
> Задача прикто либы - быть криптолибой, те сборником разных крипто алгоритмов, не
> важно нравятся они кому то или нет, соотвествуют требованиям или нет.Т.е если криптоалгоритм созданн с уязвимостями (или бекдорами), то нужно его радостно жавать пользователю?
Тут же не получится выкинуть на экран предупреждение "алгоритм написан в шарашке по заказу кровавой гебни".> Вот это фанбойство: "давайте оставим полтора алгоритма самых лучших в мире" - это архи тупо.
> Ну оставляйте вы их где то в дефолтах TLS, но удалять имплементации самих алгоритмов просто нельзя.Их либа, что хотят то и делают.
Можешь форкнуть и пихать туда все что душа пожелает.
Это примерно как из публичной библиотеки выкидывать книжки которые тебе не нравятся или устарели.И чтобы вы понимали, некоторые алгоритмы прибиты на гвозди к актуальному софту и не смотря ни на что они будут продолжать использоватся.
> из публичной библиотеки выкидывать книжки которые тебе не нравятся или устарелиНу во-первых такое уже было и не раз. И у нас, и в европах и в штатах.
Вон сочинения самого известного австрийского художника выкинули почти отовсюду и никто не умер.Во-вторых сфигали эта библиотека 'публичная'?
Они что финансируются государством?
Ты можешь посмотреть на их сайт. Сомневаюсь что они вообще какие-то деньги получают)
Так что имеют полное право прееставлять кровати как хотят.> И чтобы вы понимали, некоторые алгоритмы прибиты на гвозди к актуальному софту и не смотря ни на что они будут продолжать использоватся.
А это уже не проблемы разработчиков либы.
Вам что-то не нравится? можете скачать BoringSSL/GnuTLS/MatrixSSL/OpenSSL тысячи их!
Тео живёт на пожертвования проекту.
Даже одного этого достаточно чтобы принать его публичной библиотекой, а то что туда несут код все кому не лень только усиливает позицию публичности.Вот у меня на гитхубе моя liblcb - это пока моё личное, что хочу то и ворочу там, ибо пишу один и за свой счёт.
> Даже одного этого достаточно чтобы принать его публичной библиотекойУ вас какое-то особое понимание публичности.
> LibreSSL is supported financially by the OpenBSD Foundation and the OpenBSD Project.
Первая Canada Not-For-Profit Corporations, вторая "volunteer-driven software group funded by donations".
Ни одно, ни другое не значит что они должны выполнять чьи-то хотелки. Тем более в контексте "публичности".
Все что они обязаны делать - прописано в их уставе openbsdfoundation.org/foundation/bylaws.html
Если что-то не нравится или переставайте донатить, или подавайте в суд.> а то что туда несут код все кому не лень только усиливает позицию публичности.
Абсолютно нет. Люди коммитят по конкретной лицензией.
На этом всё. Не нравится - иди форкай, код свободный.> Вот у меня на гитхубе моя liblcb - это пока моё личное, что хочу то и ворочу там, ибо пишу один и за свой счёт.
Так и они что хотят то и воротят.
Вы пытаетесь так сильно натянуть сову на глобус, что она скоро треснет.
> Вот у меня на гитхубе моя liblcb#define SHA1_Ch(__x, __y, __z) (((__x) & (__y)) | ((~(__x)) & (__z)))
#define SHA1_Maj(__x, __y, __z) (((__x) & (__y)) | ((__x) & (__z)) | ((__y) & (__z)))SHA1_Ch упрощается первой строкой, а SHA1_Maj - третьей.
static inline uint32_t f(unsigned const t, uint32_t b,
uint32_t c, uint32_t d)
{
return t < 20 ? (c ^ d) & b ^ d // b & c | ~b & d
: t < 40 ? b ^ c ^ d
: t < 60 ? (c | d) & b | c & d //b & c | b & d | c & d
:/* < 80 */ b ^ c ^ d;
}
Про такие фокусы советую «Алгоритмические трюки для программистов» Генри Уоррен, мл.
Вы добавили ветвления, нафиг не нужны такие упрощения.
Я не публикую код, если не проверял, потому не стал вытаскивать ветки и писать макросы. Надеялся, что и так будет понятно, что получится что-то вроде этого (скобочки не пишу)#define SHA1_Ch(__x, __y, __z) (((__x) & (__y)) | ((~(__x)) & (__z)))
#define SHA1_Ch(b, c, d) ((c ^ d) & b ^ d)
Тут на одну операцию меньше.
Что касается ветвлений, то при инлайне они вряд ли будут, это компиляторы и 20 лет назад разруливали.
Я когда то этим развлекался и бенчил, по тем временам оставил лучший результат.
Сейчас там или SSE/AVX или сразу нужный SIMD который делает внутри всю магию.
> Я когда то этим развлекался и бенчил, по тем временам оставил лучший
> результат.Потому что упрощённый вариант в сравнении не участвовал.
А вообще я это привёл не как заявку на быстрейший вариант, а как пример оптимизаций очевидных, но не для всех. Ну и книжку всё же советую полистать. Оригинальное её название Hacker's Delight.
https://github.com/rozhuk-im/liblcb/blob/f254da703bb01bf089c...
Вот что было, может что то ещё.Это всё низовые оптимизации, я когда ECDSA оптимизировал то там сильно роялит алгоритмическая оптимизация, так сказать сверху-середины.
> Это всё низовые оптимизацииВ математике это называется - упростить выражение. И некоторые такое пишут на автомате, просто потому, что иначе не могут.
> Т.е если криптоалгоритм созданн с уязвимостями (или бекдорами), то нужно его радостно жавать пользователю?С одной стороны таки да, пусть пользователь сам там с этим всем. Другое дело, что это условный ты пишешь либу и тебе претит, то как разраб, ты можешь выкинуть на мороз это. А пользователь, в случае опенсурса, пусть сам, ручками.
Зачем сборник?
1 алгоритм = 1 либа.
> Порвались, жальАноны на опеннете.
Бтв, вот реально тот случай, когда уж кому- кому, а джонам из оттуда стоит задать вопрос, зачем они это вообще имплементируют?
Лучше бы сделали включение опциональным при сборке:./configure --with-gost
Теперь нам придется самим этот патч для поддержки GOST и STREEBOG пилить.
> развиваются возможности, которые войдут в состав OpenBSD 7.5.Ваў, курто!
> Одновременно сформирован стабильный выпуск LibreSSL 3.8.3, в котором исправлено несколько специфичных для Windows ошибокА... Ну тогда понятно.
Уже пару лет как опенбзд принципиально не ставится в дуалбуте с линуксом(когда-то получалось). А если ей таки выделить отдельный комп, то тормозить будет люто, слайдшоу на экране, и периодическое выпадение пакетов.
Причиной удаления GOST и STREEBOG указано низкое качество кода, мешающее развитию остальной части библиотеки.Unhook and remove GOST and STREEBOG
This stops compiling the GOST source. The current implementation is low
quality and got in the way, especially in libssl. While we would be open
for GOST support, it needs to be significantly better than what we have
had and it also needs a maintainer.Add OPENSSL_NO_GOST to opensslfeatures and stop installing gost.h.
Some code wrapped in #ifndef OPENSSL_NO_GOST will be removed later.
в научной роте писали что ли?
А ты остроумен. Так заявить, что не смог найти код и авторов, это надо суметь.
> also needs a maintainerвот вам и "оберточные опсосы (опенсурсники)".
Да. Совершенно для всех внезапно, им дали эталон: A reference implementation of the Russian GOST crypto algorithms for OpenSSL
Там кода то не более 5к строк, причесать такое можно было за один вечер.
Причеши.
А мне уже не надо.
Стоит уточнить, что это камень не в сторону автора (он и так опубликовал код, на продаже которого его работодатель зарабатывает), а в сторону местного так называемого Сообщества.
Пришлось свалить с libressl во фре, ибо задолбало бегать по багтрекерам после каждого обновления и то тягать патчи в порты то самому писать патчи чтобы оно собиралось с очередным софтом.Очень жаль, ибо libressl мне нравится больше.
На что свалить?
Во фре самое безпроблемное - сидеть на дефолте.
Дефолт:
- это 1х для 13
- 3.0.3 для 14, то что там прямо в базе.
Но для 13 уже имеет смысл переехать на 3.0.3 из портов, ибо раз оно в 14 то и софт поддерживается.https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273961 - эта импотентность меня в конец достала: 1+ месяц ничего не делать.
В самый раз шутить: "сколько фрибсдешников надо чтобы закоммитить готовый патч от пользователя? - 15 человек явно не достаточно!".
А просто патчи для libressl - так несколько у меня висит уже 1+год.
> В самый раз шутить: "сколько фрибсдешников надо чтобы закоммитить готовый патч от
> пользователя? - 15 человек явно не достаточно!".Ровно ноль. Тогда можно воспользоваться шансом и захватить порт.
(а, это для просто-патчей, в портах. В твоем том случае шансов ноль в любом раскладе - "а вот не нравишься ты мне мужык".)> А просто патчи для libressl - так несколько у меня висит уже
> 1+год.maintainer timeout/takeover - не?
Дело в том, что это не мне нужны эти патчи, они нужны все кроме меня, у меня лично они в гите лежат и автоматом накладываются при ребейзе во время пулл.
тогда каждый раз сам и будешь править когда реджектнется в очередной раз из-за замены в комментарии color на colour.
А если зохаваешь порт - то уже другие пусть страдают.
зачем ты бегал по багтрекерам?