Боюсь РИТЭГ, способный запитать 200-ваттный кипятильник, будет весить несколько тонн.
Как его затащить на тот питерский балкон (и влезет ли) — большой вопрос.
Also, one of the CIA documents leaked by Wikileaks last year gave a clear insight into the techniques used by the agency to gain 'persistence' on Apple Mac devices, including Macs and iPhones, demonstrating their use of EFI/UEFI and firmware malware.
Эта проблема подчеркивает, что следующий код просто не может быть реализован с использованием текущего синтаксического анализатора (вызывает ошибку SyntaxError)
Вот как раз это никогда не было большой проблемой, просто токенайзер для "with" кривой, и простейщий lookahead для скобки как в тех же выражениях (и кортежах) был бы достаточен.
К чему они привязали issue12782 к PEG-based parser мне неведомо, ибо тот lookahead без необходимости backslash-ить существует с версий 2.5 или 2.6 если мне не изменяет память.
Сравните:
-with (open("a_really_long_foo") as foo,
- open("a_really_long_bar") as bar):
+if (open("a_really_long_foo") == foo,
+ open("a_really_long_bar") == bar):
pass
Т.е. алгоритм простой и в случае with и простейшим lookahead (открытая скобка) должен включаться "режим" auto-escape для NL, пока не найдена парная закрывающая скобка, точно также как это уже делается в доброй сотне других случаев.
Почему надо было ждать 3.9 чтобы это пофиксить я кроме как ленью долгоиграющей стратегией или идеей фикс "пересадить всех на новые версии" объяснить не могу.
Здесь оно и не сильно надо как бы (многострочный with можно тупо пробэкслэшить), но проблема в том, что они вообщем часто забывают, что многие системы либо еще очень долго, либо совсем не обновятся до 3.9… Т.е. абсолютно всё (даже подобные простейшие вещи) можно использовать только в проектах под >= 3.9.
Лучше что-нибудь показывающее еще и уровень сигнала (типа Wifi Analyzer), потому что когда такой зоопарк как ситуация 4, анализ для выбора лучшего канала совсем не тривиален (и utilization и т.п. сильно зависит от времени/нагрузки)...
если не можете избежать пересечения каналов — ставьте точки доступа на один канал!
Я бы добавил — не просто на один, а на один канал с ближайшей точкой с самым мощным уровнем сигнала (многие интуитивно делают наоборот).
Потому что в таком случае канальные протоколы типа Distributed Coordination Function (DCF) могут помочь лучше, особенно в современных железках (когда EDCF и HCF).
Ну у меня несколько "обратная" статистика… Да, офисы не всегда корректно импортируют сложные html, но зато они заточены под печать и работу с докуменами, а браузерные движки (особливо старые, например как в wkhtmltopdf) не всегда хорошо отображают то для печати (или экспорта в pdf), игнорят страничную разметку или стили, и т.д.
В любом случае проще поправить стиль или html, чем прыгать с бубном вокруг wkhtmltopdf, причем держа в уме что танцы вероятно повторятся с выкатом следующей версии.
Тут даже так — оставим за скобкой качество (слово "лучше" все-таки такая абстракция)…
И посмотрим на словосочетание "в среднем" (из "женщины в среднем кодят лучше мужчин")… (да простят меня дамы, но...) У меня стойкое "низя" (здесь картинка с Боромиром) выработалось на такую вот статистику — что-то начиная от качества выборки (откуда это набрали), через как это "среднее" брали-считали, и заканчивая парадоксом Симпсона/Юла и подобными вкусностями.
(снова дико звиняюсь, но...) Из собственного же (почти тридцатилетнего) опыта общения с противоположным полом по работе и OSS (из попадающего под слово "кодят" исключительно) могу сказать что в моем "среднем" — все с точностью наоборот.
И чем ранг выше, тем разница заметнее, т.е. например в группе senior devs она (разница) начинает cильно коробить. Хотя и не без исключений (но очень редких).
Заставить (lib)webkit(gtk) печатать (в ps file) или экспортировать в pdf, безо всяких wkhtmltopdf, дело не абы какое сложное (сишный файлик со страницей кода)… Но зачем?
Когда есть куча способов прямо "иcкоропки", хоть тем же libre- или open-office:
Вы немного не поняли, оно не совсем про безопасность в прямом смысле…
Intel CSME используется как аппаратная база для DRM и прочих «копирастных» инструментов.
Если цель — «избавиться» от этого, например выковырять ключи и/или цифровой контент, добавить эксплойт, чтобы снять блокировку чего-либо и т.д., то «балалайку» вполне можно и воткнуть :)
Бывает… У меня всегда были кастомные прошивки (сперва CM, потом LinOS), за исключением мелочей — полет нормальный.
А потом пришел белый пушной зверёк PSD2 (я в Европах), который обязует банки вводить dual-factor для входа в онлайн-банк, подтверждения переводов и платежей VISA, а TAN-генератор, созданный банком для этого дела, видит кастомную прошивку и говорит «никак низя» (CTS incompatible)!.. Причем они там очень сильно озадачились её найти, ибо нередко никакими способами, типа подмены kernel на кастомный, скрывающий прошивку, выпиливанием кастомных IDs, прятками через Magisk Hide и т.п., не удается скрыть ее присутствие от вредной программы.
Причем нонсенс состоит в том что часто, чтобы пройти тот safety check, нужно сделать много движений делающий смартфон менее «safe»…
Вот так «мудрые» депутаты Европарламента (ну или чрезмерно усердные разрабы софта для банков) за нас решили, что является «секьюрной» ОСью а что нет.
В «основном цикле» проверяется число 24K-1.
Это число имеет последовательность, в которой допустим до 280 подъемов и спусков, и при этом «бегает» по числам в интервале (22K..24.5K) пока в конце не достигнет уже проверенную группу до 260 или (ожидаемо) гарантированный спуск на каком-то 2N.
При том что хранить все «проверенные» числа вы не хотите, единственная возможность это отсекать интервал (22K..24K-2), последовательно перебирая числа в «основном цикле».
Кроме того если вы посмотрите эту ветку комментариев выше, то возможно заметите что речь тут идет про какое-то «приснившееся» число (т.е. «случайное», для которого числа и менее его могут быть еще не «проверены»).
Вопрос: которое «множество» считать «проверенным», откуда у вас тут «сотня» когда там много-много порядков больше, а главное когда (на каком спуске/подъеме) запускать и главное останавливать того зайца Флойда?
Ну и напомню, что число может забираться сильно вверх, а диапазон (24K..24,5K) у вас не проверен по умолчанию, т.е. вопрос №2: почему вы исключаете что тот «теоретический» замкнутый цикл (aka periodic orbit) не находится где-то в этой области?
А черепахозайцем (т.е. сознательно увеличивая количество вычислений в два раза), да на длинной арифметике будет не выгодно совсем. Даже если проверку делать только при двойном спуске, т.е. когда одна итерация по условию когда x из нижеследующего после второго деления гарантированно меньше предыдущего x: x = 3*x+1 / 2; while not (x & 1) { x = x2 / 2; compare(xhare, xtort) }; repeat
Т.е. только на гарантированном спуске (3*xi+1 / 4 < xi).
Floyd уместен когда сравниваются «готовые» элементы списка, а не когда они будут вычисляться на каждой итерации (т.е. не там где операция вычисления станет дороже операции сравнения).
Кроме того, пока что нет даже подозрения, что какое-то число «влетает» в бесконечный цикл — он пока у всех всегда заканчивался ожидаемо 2n (что есть начало спуска до 1) за какое-то (да иногда долгое, иногда очень, но) конечное время.
Вы работу то хоть смотрели? Там черным по белому «almost all positive
integers do not lie in a periodic Collatz orbit».
А теперь забудем слово «почти» и всякие вероятностные «logarithmic density» и т.д.
Если (невероятно, но вдруг) какая-то замкнутая последовательность и существует, то минимальная длинна такой цепочки (цикла) будет не сильно отличатся от среднего числа итераций до первого спуска, что практически то же AVG значение до первой найденой степени двух (без учета вырожденных случаев, ака начинаем сразу с 2n).
А это даже для «небольших» чисел (21000, 22000, 24000, ..., 210000) очень длинные цепочки (1K, 10K, 20K, ..., 60K) и рост там очевиден.
Предположите, умозрительно, что такое число, замыкающееся в цикл после сравнительно невеликого числа итераций существует.
Предпологать не надо. Надо анализировать (ну или читать что Tao, Korec и др. про то уже написали).
Васяо решил пособить Тао и наугад проверяет числа в районе Гуголплекса.
Поперхнулся. What?!
Вы хоть раз пробовали умножить что-то в районе Гуголплекса (а это на минуточку 1010100, т.е. число с гугол нулями) хоть даже на 3?
Что-то мне говорит что на это не хватит памяти не то что у вас… Смею предположить, что ее врядли хватит у всех компьютеров человечества и всей известной вселенной, даже если размер бита будет равен размеру атома.
(в видимой части Вселенной порядка 1080 атомов, чтобы записать 1 Гуголплекс вам же нужно порядка 3.3*1099 бит).
Я надеюсь стало чуть понятней почему по моему скромному мнению слово «достаточно» тут не совсем подходит.
Если у вас есть единственный замкнутый цикл 1 -> 4 -> 2 -> 1 в самом начале (внезапно потому что тут есть «магическое» число 1, то это совсем не означает, что какая-то другая последовательность тоже замкнется.
Посмотрите на картинки типа «Iteration (stopping) time for inputs» или веер (треугольник) распределения…
Т.е. расти оно будет всегда (бесконечно или нет, не доказано).
Но что оно замкнется — это нонсенс. Что-то из оперы «А пацаны то не знали».
Только вот ни «начальное» число, ни собственно «некоторое количество итераций» (т.е. расстояние от начального числа, до превращение его в «самое себя») не известны.
Вывод — на каждой итерации снизу вверх запоминать, а сверху вниз сравнивать.
Что в худшем случае выливается в сравнивать всех со всеми.
Повторюсь, памяти хватит?
А магию типа «приснилось число» и бац на 3-й итераций оно снова «тоже самое» оставьте для пикабу, плз.
Т.е. построить lookup таблицу (граф, radix-/patricia-trie, whatever) для бесконечного множества огромных чисел и/или итераций (чтобы собственно найти «самое себя»)?
А памяти хватит? :)
Дело в том что опровергнуть как раз и не получится, т.к. для этого нужно продолжать цикл бесконечно (просто потому что и числа в неравенстве fi(x) != 2n могут расти бесконечно)…
Умолчим про то, что уже какая-нибудь растущая итерация на числах близких к каким то 10108 (что все-еще меньше Гуголплекса, но уже много раз больше чем Гугол), не говоря уже про то чтобы подобраться к следующей границе 2n+1 (если даже 2n не полностью «покрыта»), уже тупо не хватит всех вычислительных ресурсов земли.
>>> fci(7)
reached 16 == 2**4 after 12 iter(s), max: 52
>>> fci(27)
reached 16 == 2**4 after 107 iter(s), max: 9232
>>> fci(2**32-1)
reached 16 == 2**4 after 447 iter(s), max: 3706040377703680
>>> fci(2**64-1)
reached 16 == 2**4 after 859 iter(s), max: 6867367640585024969315698178560
>>> fci(2**64+1)
reached 16 == 2**4 after 479 iter(s), max: 55340232221128654852
>>> fci(2**(10**4)-1)
reached 16 == 2**4 after 134400 iter(s), max: 3e4771 (тут как бы 4,5 тысячи нулей)
>>> fci(2**(10**5)-1)
reached 16 == 2**4 after 1344922 iter(s), max: 2e47712 (тут как бы 45 тысяч нулей)
Особенно предлагаю обратить внимание на последние два результата. 2**(10**8)-1 в один поток, да на питоне (да хоть и на C с самой быстрой «длинной» математикой, оптимизированной под алгоритм), можно даже не пробовать…
И я вас уверяю, это всё еще будет не бесконечный цикл. :)
int
string_interpret_escape(const uschar **pp)
{
const uschar *p = *pp;
int ch = *(++p);
+ if (ch == '\0') return **pp;
...
*pp = p; /* fail был здесь - возвращаем ptr на следующий (за границей NTS) байт. */
return ch;
}
Т.е. ранее (до фикса) возвращенный указатель в *pp "тупо" указывал на следующий после последнего '\\' символ (за '\0') в буфере и рутина вызывающая string_interpret_escape при проверке внутри циклов типа while (*p) {...} продолжала исполнение уже за границей строки пока не ловила следующий '\0' или собственно BO.
Учитывая что string_interpret_escape пользуется почем зря (от фильтров до string expansion) мне вот совсем непонятно почему exim разрабы ограничились "BO с возможным RCE на SNI-data в процессе TLS-nego"… когда оно вот прямо само напрашивается.
И если вернуть или выдернуть что-то дельное на стадии TLS-negotiation таким образом действительно вряд ли получится, то например сценарии вида "отправить в bounce атакующему кусок памяти exim" и подобные фишки выглядят вполне себе ничего… а развернуться в exim даже при дефолтных/стандартных конфигах есть где.
Я не большой любитель теорий заговора, но как-то оно не очень выглядит...
Да не… Дело не в руках — там оно чуть не всё такое.
Простейшие вещи нужно иногда через одно место делать… Вот например чтобы отловить "неправильные" Bounce и почту от всяких backscatter и ко (без BATV, ибо не надо) вместо пары простейших правил в системном фильтре чтобы например режектнуть их на входе (без того чтобы самому стать спамером отправляя bounce не туда куда надо), нужно делать кучу ненужных телодвижений.
ибо вдруг по какой-то одному exim известной причине оно позаменяет from@example.com и envelope from и ко из сообщения на root@localhost(wtf) ну и вся проверка дальше коту под хвост...
А поиск в известных поисковиках по howto "exim" "что-то чуть более сложнее чем ..." (как в прочем и для многих популярных продуктов) нередко тонет в бестолковой массе нерелевантных ответов на форумах/SO/SE и т.п. — т.е. найти то что действительно нужное практически нереально.
Документация же (довольно большая кстати) или вики у exim местами откровенно хромают.
Инфы-то вроде много, но как сделать "правильно" что-то конкретное (чуть сложнее чем хеловорлды) — можно искать часами, потому что вот этот параметр конфликтует с вот этим вот (а найти это удается чуть ли не в исходниках).
Хотя с появлением wiki на github стало полегче, да…
Осталось им еще там issues включить (чтобы можно было нормальный баг-трэкер юзать).
Боюсь РИТЭГ, способный запитать 200-ваттный кипятильник, будет весить несколько тонн.
Как его затащить на тот питерский балкон (и влезет ли) — большой вопрос.
Я стесняюсь спросить, а что вы подразумеваете под "мешает использовать"?
Вы возможно удивитесь, но таки да — "злые горничные" не особенно и нужны…
Ну например — Cybersecurity Researchers Spotted First-Ever UEFI Rootkit in the Wild.
Ну и про First-Ever можно тоже поспорить (хотя, то только про "обнаружили") — цитата оттуда же:
Вот как раз это никогда не было большой проблемой, просто токенайзер для "with" кривой, и простейщий lookahead для скобки как в тех же выражениях (и кортежах) был бы достаточен.
К чему они привязали issue12782 к PEG-based parser мне неведомо, ибо тот lookahead без необходимости backslash-ить существует с версий 2.5 или 2.6 если мне не изменяет память.
Сравните:
Т.е. алгоритм простой и в случае
withи простейшим lookahead (открытая скобка) должен включаться "режим" auto-escape для NL, пока не найдена парная закрывающая скобка, точно также как это уже делается в доброй сотне других случаев.Почему надо было ждать 3.9 чтобы это пофиксить я кроме как
леньюдолгоиграющей стратегией или идеей фикс "пересадить всех на новые версии" объяснить не могу.Здесь оно и не сильно надо как бы (многострочный with можно тупо пробэкслэшить), но проблема в том, что они вообщем часто забывают, что многие системы либо еще очень долго, либо совсем не обновятся до 3.9… Т.е. абсолютно всё (даже подобные простейшие вещи) можно использовать только в проектах под >= 3.9.
Лучше что-нибудь показывающее еще и уровень сигнала (типа Wifi Analyzer), потому что когда такой зоопарк как ситуация 4, анализ для выбора лучшего канала совсем не тривиален (и utilization и т.п. сильно зависит от времени/нагрузки)...
Я бы добавил — не просто на один, а на один канал с ближайшей точкой с самым мощным уровнем сигнала (многие интуитивно делают наоборот).
Потому что в таком случае канальные протоколы типа Distributed Coordination Function (DCF) могут помочь лучше, особенно в современных железках (когда EDCF и HCF).
Ну у меня несколько "обратная" статистика… Да, офисы не всегда корректно импортируют сложные html, но зато они заточены под печать и работу с докуменами, а браузерные движки (особливо старые, например как в wkhtmltopdf) не всегда хорошо отображают то для печати (или экспорта в pdf), игнорят страничную разметку или стили, и т.д.
В любом случае проще поправить стиль или html, чем прыгать с бубном вокруг wkhtmltopdf, причем держа в уме что танцы вероятно повторятся с выкатом следующей версии.
Тут даже так — оставим за скобкой качество (слово "лучше" все-таки такая абстракция)…
И посмотрим на словосочетание "в среднем" (из "женщины в среднем кодят лучше мужчин")…
(да простят меня дамы, но...)У меня стойкое "низя" (здесь картинка с Боромиром) выработалось на такую вот статистику — что-то начиная от качества выборки (откуда это набрали), через как это "среднее" брали-считали, и заканчивая парадоксом Симпсона/Юла и подобными вкусностями.(снова дико звиняюсь, но...)Из собственного же (почти тридцатилетнего) опыта общения с противоположным полом по работе и OSS (из попадающего под слово "кодят" исключительно) могу сказать что в моем "среднем" — все с точностью наоборот.И чем ранг выше, тем разница заметнее, т.е. например в группе senior devs она (разница) начинает cильно коробить. Хотя и не без исключений (но очень редких).
Заставить (lib)webkit(gtk) печатать (в ps file) или экспортировать в pdf, безо всяких wkhtmltopdf, дело не абы какое сложное (сишный файлик со страницей кода)… Но зачем?
Когда есть куча способов прямо "иcкоропки", хоть тем же libre- или open-office:
Ну уж а модулей для всяких скриптовых чуть ли не десятки понаписаны, ну например WeasyPrint для python и тому подобные.
Intel CSME используется как аппаратная база для DRM и прочих «копирастных» инструментов.
Если цель — «избавиться» от этого, например выковырять ключи и/или цифровой контент, добавить эксплойт, чтобы снять блокировку чего-либо и т.д., то «балалайку» вполне можно и воткнуть :)
Примерно до 1GB/h для «стандартного» разрешения, от 3GB/h для HD до 7GB/h для Ultra.
А потом пришел
белый пушной зверёкPSD2 (я в Европах), который обязует банки вводить dual-factor для входа в онлайн-банк, подтверждения переводов и платежей VISA, а TAN-генератор, созданный банком для этого дела, видит кастомную прошивку и говорит «никак низя» (CTS incompatible)!.. Причем они там очень сильно озадачились её найти, ибо нередко никакими способами, типа подмены kernel на кастомный, скрывающий прошивку, выпиливанием кастомных IDs, прятками через Magisk Hide и т.п., не удается скрыть ее присутствие от вредной программы.Причем нонсенс состоит в том что часто, чтобы пройти тот safety check, нужно сделать много движений делающий смартфон менее «safe»…
Вот так «мудрые» депутаты Европарламента (ну или чрезмерно усердные разрабы софта для банков) за нас решили, что является «секьюрной» ОСью а что нет.
Это число имеет последовательность, в которой допустим до 280 подъемов и спусков, и при этом «бегает» по числам в интервале (22K..24.5K) пока в конце не достигнет уже проверенную группу до 260 или (ожидаемо) гарантированный спуск на каком-то 2N.
При том что хранить все «проверенные» числа вы не хотите, единственная возможность это отсекать интервал (22K..24K-2), последовательно перебирая числа в «основном цикле».
Кроме того если вы посмотрите эту ветку комментариев выше, то возможно заметите что речь тут идет про какое-то «приснившееся» число (т.е. «случайное», для которого числа и менее его могут быть еще не «проверены»).
Вопрос: которое «множество» считать «проверенным», откуда у вас тут «сотня» когда там много-много порядков больше, а главное когда (на каком спуске/подъеме) запускать и главное останавливать того зайца Флойда?
Ну и напомню, что число может забираться сильно вверх, а диапазон (24K..24,5K) у вас не проверен по умолчанию, т.е. вопрос №2: почему вы исключаете что тот «теоретический» замкнутый цикл (aka periodic orbit) не находится где-то в этой области?
x = 3*x+1 / 2; while not (x & 1) { x = x2 / 2; compare(xhare, xtort) }; repeatТ.е. только на гарантированном спуске
(3*xi+1 / 4 < xi).Floyd уместен когда сравниваются «готовые» элементы списка, а не когда они будут вычисляться на каждой итерации (т.е. не там где операция вычисления станет дороже операции сравнения).
Кроме того, пока что нет даже подозрения, что какое-то число «влетает» в бесконечный цикл — он пока у всех всегда заканчивался ожидаемо 2n (что есть начало спуска до 1) за какое-то (да иногда долгое, иногда очень, но) конечное время.
integers do not lie in a periodic Collatz orbit».
А теперь забудем слово «почти» и всякие вероятностные «logarithmic density» и т.д.
Если (невероятно, но вдруг) какая-то замкнутая последовательность и существует, то минимальная длинна такой цепочки (цикла) будет не сильно отличатся от среднего числа итераций до первого спуска, что практически то же AVG значение до первой найденой степени двух (без учета вырожденных случаев, ака начинаем сразу с 2n).
А это даже для «небольших» чисел (21000, 22000, 24000, ..., 210000) очень длинные цепочки (1K, 10K, 20K, ..., 60K) и рост там очевиден.
Предпологать не надо. Надо анализировать (ну или читать что Tao, Korec и др. про то уже написали).
Поперхнулся. What?!
Вы хоть раз пробовали умножить что-то в районе Гуголплекса (а это на минуточку 1010100, т.е. число с гугол нулями) хоть даже на 3?
Что-то мне говорит что на это не хватит памяти не то что у вас… Смею предположить, что ее врядли хватит у всех компьютеров человечества и всей известной вселенной, даже если размер бита будет равен размеру атома.
(в видимой части Вселенной порядка 1080 атомов, чтобы записать 1 Гуголплекс вам же нужно порядка 3.3*1099 бит).
Я надеюсь стало чуть понятней почему по моему скромному мнению слово «достаточно» тут не совсем подходит.
1 -> 4 -> 2 -> 1в самом начале (внезапно потому что тут есть «магическое» число1, то это совсем не означает, что какая-то другая последовательность тоже замкнется.Посмотрите на картинки типа «Iteration (stopping) time for inputs» или веер (треугольник) распределения…
Т.е. расти оно будет всегда (бесконечно или нет, не доказано).
Но что оно замкнется — это нонсенс. Что-то из оперы «А пацаны то не знали».
Так понятнее?
Вывод — на каждой итерации снизу вверх запоминать, а сверху вниз сравнивать.
Что в худшем случае выливается в сравнивать всех со всеми.
Повторюсь, памяти хватит?
А магию типа «приснилось число» и бац на 3-й итераций оно снова «тоже самое» оставьте для пикабу, плз.
Т.е. построить lookup таблицу (граф, radix-/patricia-trie, whatever) для бесконечного множества огромных чисел и/или итераций (чтобы собственно найти «самое себя»)?
А памяти хватит? :)
fi(x) != 2nмогут расти бесконечно)…Умолчим про то, что уже какая-нибудь растущая итерация на числах близких к каким то 10108 (что все-еще меньше Гуголплекса, но уже много раз больше чем Гугол), не говоря уже про то чтобы подобраться к следующей границе 2n+1 (если даже 2n не полностью «покрыта»), уже тупо не хватит всех вычислительных ресурсов земли.
Чтобы было представление о чем это вообще — вот тут на коленке «собранный» простейший вычислитель-итератор на питоне, а вот простые примеры:
Особенно предлагаю обратить внимание на последние два результата.
2**(10**8)-1в один поток, да на питоне (да хоть и на C с самой быстрой «длинной» математикой, оптимизированной под алгоритм), можно даже не пробовать…И я вас уверяю, это всё еще будет не бесконечный цикл. :)
Хмм…
А баг конечно эпичный:
Т.е. ранее (до фикса) возвращенный указатель в
*pp"тупо" указывал на следующий после последнего'\\'символ (за'\0') в буфере и рутина вызывающаяstring_interpret_escapeпри проверке внутри циклов типаwhile (*p) {...}продолжала исполнение уже за границей строки пока не ловила следующий'\0'или собственно BO.Учитывая что
string_interpret_escapeпользуется почем зря (от фильтров до string expansion) мне вот совсем непонятно почему exim разрабы ограничились "BO с возможным RCE на SNI-data в процессе TLS-nego"… когда оно вот прямо само напрашивается.И если вернуть или выдернуть что-то дельное на стадии TLS-negotiation таким образом действительно вряд ли получится, то например сценарии вида "отправить в bounce атакующему кусок памяти exim" и подобные фишки выглядят вполне себе ничего… а развернуться в exim даже при дефолтных/стандартных конфигах есть где.
Я не большой любитель теорий заговора, но как-то оно не очень выглядит...
Да не… Дело не в руках — там оно чуть не всё такое.
Простейшие вещи нужно иногда через одно место делать… Вот например чтобы отловить "неправильные" Bounce и почту от всяких backscatter и ко (без BATV, ибо не надо) вместо пары простейших правил в системном фильтре чтобы например режектнуть их на входе (без того чтобы самому стать спамером отправляя bounce не туда куда надо), нужно делать кучу ненужных телодвижений.
И главное потом еще и дебажить его на живую, потому что внезапно чтобы протестировать от рута (ибо только так всё, включая системные фильтры и т.д., можно проверить), т.е. "нельзя просто взять и сделать"© что-нибудь вида:
ибо вдруг по какой-то одному exim известной причине оно позаменяет
from@example.comи envelope from и ко из сообщения наroot@localhost(wtf)ну и вся проверка дальше коту под хвост...А поиск в известных поисковиках по howto "exim" "что-то чуть более сложнее чем ..." (как в прочем и для многих популярных продуктов) нередко тонет в бестолковой массе нерелевантных ответов на форумах/SO/SE и т.п. — т.е. найти то что действительно нужное практически нереально.
Документация же (довольно большая кстати) или вики у exim местами откровенно хромают.
Инфы-то вроде много, но как сделать "правильно" что-то конкретное (чуть сложнее чем хеловорлды) — можно искать часами, потому что вот этот параметр конфликтует с вот этим вот (а найти это удается чуть ли не в исходниках).
Хотя с появлением wiki на github стало полегче, да…
Осталось им еще там issues включить (чтобы можно было нормальный баг-трэкер юзать).