Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
TLS - просто существует
Как ученическая работа на поковырять и посмотреть ваш проект хорош. Даже векторы затронули, что не каждый из тех кто играется с созданием своей криптографии делает.
Но вот как "боевое использование" какие преимущества от такой проприоретаршины? На глаз Я бы не сказал что она будет быстрее классики, я бы даже сказал что наоборот если я правильно понял и вы все end-to-end в RSA пакуете. За безопасность тоже под вопросом, хотя тут я не специалист может и не прав.
У меня сразу вопрос почему производная от SHA256 а не тот же BLAKE3?
Из интереса закопался в исходный код (интересен сам алгоритм) и по состоянию на последний коммит f4228c5 вот список вопросов/фактов
не совсем понятно почему не запаковалось это все в динамические библиотеки (dll/so) раз уж начали делать интеграции, вместо этого неочевидный cli который еше может дрейфовать если продукт будет развиваться
не совсем понял за фишку с "смешанным потоком", я думал там что-то по типу "размазывания шума" что бы сами данные не были видны (очень актуально сейчас), но там классическая классика с сигнатурой+crc
так же вообще не понял за механику хранилища, я думал то такой странный кольцевой буфер для асинхронных ридеров, даже неронку зарядил на анализ, но оказалось что это просто хранилище? Зачем вшитое хранилище в потоковый криптопротокол? И я не увидел никаких ограничений на память при запуске (как параметр) то есть вполне можно убивать удаленные машины просто забив память отсылая пустые данные этим протоколом
подозрительно встречающиеся unsafe, для такой задачи (учитывая что никакой магии с байтами я не заметил) это очень похоже на костыли которые воткнули "чтоб работало" что в разрезе криптопротокола интересно смотрится, особенно если добиться колизии адресов при перезапуске тулзы(где в основном unsafe и юзается)
уязвимость прямо из учебника - берется len из полученного пакета и по этому len сразу резервируется память. Как минимум крашнуть тулзу можно и вызвать потери пакетов, как макс память выделится на всю оперативку и комп зависнет (никаких ограничений в рамках самой тулзы на лимиты памяти нет, напомню)
таки я был не прав и сделано нормально с симетричным на тело и асиметричным на обмен, но как же оно сделано! Ротация ключей сделана на лимите. Я искал другие механизмы начиная от принудительного рукопожатия по требованию и заканчивая сбросом лимита по условиям (размер, частота битости, иное) но такого нет, строго лимит и все.
в продолжение вышеперечисленного - шифрование ничего не гарантирует и ни от чего не защищает. Я выше писал что распознание по сигнатуре+CRC и это не опечатка - используется не префикс и даже не правило чтоб не палится с префиксом, а тупо тело. Незашифрованное хочу заметить тело (перепроверил нейросетью, метаданные гарантировано не шифруются)
Резюмируя - как учебный проект на поиграться очень топово и разнопланово. Все мы таким занимались когда-то в своей жизни если программирование действительно интересно.
Но как реально используемый проект/алгоритм под вопросом потому что я даже не могу придумать где такое можно было бы использовать что бы оно было прямо таки преимуществом и/или в тему.
Я благодарен вам за ответ и за то, что вы нашли время пройтись по коду. Это уже тянет не на комментарий, а на полноценное ревью, и за это правда спасибо. Оценку вроде “ученический проект” я оставлю за скобками: это, что называется, навешивание ярлыков, а не технический аргумент. Увы, в нашей среде такое встречается чаще, чем хотелось бы. Но выбранный вами тон комментария не отменяет того, что часть замечаний полезна и заслуживает отдельного разбора.
Давайте разбираться.
Вначале про контекст - это важно. Во многих местах документации, равно как и в статьях про brec упоминается наиболее подходящий сценарий его использования (по мнению автора) - логирование (логи, трейсы, метрики и вот весь этот зоопарк). Я много работал с DLT, работал с protobuf и flatbuffer, где данные собирались со множества устройств и это были гигобайты данных, которые потом приходилось анализировать и фильтровать. Собственно фильтрация была основной болью. Особенно это актуально для DLT-like протоколов, где можно (но не всегда просто) заглянуть “до” полного парсинга. Под каждый кейс приходилось пилить какой-то “особенный заглядыватель”, а если уж протокол обновился - всё, пиши пропало. Отсюда и основная идея проекта - блоки + полезная нагрузка, где блоки - это “открытый” индекс. То есть проект родился, простите, не как ученический, а как попытка обойти боль )) Причем brec не отменяет тот же DLT, protobuf, flatbuffer и прочих. Brec может быть “индексной” обёрткой - блоки как индекс, а payload может хранить хоть JSON, хоть байты DLT или protobuf.
Этим же контекстом диктовался и дизайн storage, хранящим данные по слотам для быстрого доступа к нужным участкам записей. Хочу записи от 100 000 до 100 042 - вот пожалуйста. Быстро и без магии.
Откуда фигня с шифрованием, если речь о логах? Тут просто. Компании, с которыми приходилось поработать, очень любят класть какую-нибудь гадость в логи. Говоришь им “фу! кака!”, а они всё равно кладут. И логика на самом деле ясна и проста. Во время разработки какой-нибудь приблуды, которая потом будет отвечать за работу приблуды в машине, данных нужно собрать будь здоров и как раз в режиме dev совершенно нормально часть секретиков пихать прямо в логи. У разрабов есть ключ - откроют. Конечно, на проде, когда вафля уже выпущена - такой дичи нет. Но вот во время разработки, когда за ночь легко набегает под терабайт диагностических данных - легко. И шифрование здесь используется как компромисс своего рода, когда разные подрядчики могут работать над массивом данных, но не всегда видеть всё.
Теперь предметно.
За замечание по поводу максимальных размеров - огромное спасибо. Это моё упущение, я об этом не подумал. Честно создал по мотивам два тикета: тыц, тыц. Правда, задача там шире, чем просто default-значение поправить, но буду разбираться. Вы смотрите с перспективы - “как сломать, если захотеть?”, я же честно смотрел с логики прикладного применения в “безопасной” зоне. Это ни в коем случае не отменяет ценности замечания. Тикеты созданы, возьму в работу.
По мотивам замечаний к самой фиче шифрования тоже сделал тикет, чтобы не забыть и подумать.
Про TLS. Это не сюда всё-таки. Это про транспорт. Сравнивать напрямую скорость TLS и
brec cryptне корректно, потому что это разные слои и разные задачи: TLS защищает канал, аbrec cryptзащищает payload внутри самого формата, включая сценарии storage, где TLS уже закончился.Это замечание “шифрование ничего не гарантирует и ни от чего не защищает” я честно не понял. Про то, что шифруется только payload, сказано в статье и документации. Это осознанное решение. Сама библиотека не кладёт в открытые блоки никаких чувствительных данных; блоки содержат только то, что пользователь протокола сам объявил как открытый индекс. Каким образом это убивает защиту самого payload - я не понимаю. Это не отличается от рабочей схемы, где в protobuf-сообщении шифруется отдельное поле, а остальные поля остаются открытыми. Или я, может быть, не понял, в чём вопрос?
Если посмотрите тикеты, я специально для ясности добавил туда пояснения по мотивации - почему было сделано так или иначе. Это тоже очень важно. И в части шифрования мне пришлось пойти на компромиссы ради производительности. Но вот то, что нужно сделать более гибко настраиваемым - тут я полностью согласен. Как и говорил, тикет создан, но пойдёт как улучшение - уязвимости я не вижу.
Почему не BLAKE3? В текущей схеме SHA-256 используется как часть RSA-OAEP-SHA256, то есть как стандартный и широко поддержанный параметр для обёртки сессионного ключа, а не как самостоятельная попытка выбрать “самый быстрый хеш”. О BLAKE3 думал, но это уже скорее отдельный crypto profile / algorithm option, который можно добавить позже по запросу. В идеале было бы здорово это дело настраивать, но так, чтобы не тянуть кучу зависимостей, а именно на этапе генерации определять “кого” и тянуть только его, чтобы не раздувать бинарник.
Насчёт скорости в боевых условиях. Я честно включал фичу шифрования в бенч. Скрывать ничего не пытаюсь. Конечно, шифрование не бесплатно, но и результаты выглядят вполне недурно. И вообще, если вы посмотрите именно на производительность - я там обманывать никого не пытаюсь, а совершенно честно говорю те сценарии, где brec выигрывает и где проигрывает. И если выигрывает, то честно говорю про цену.
Про unsafe. Тут я словил скример от вас ) Проверил… в crypto-core unsafe нет. В генераторе unsafe действительно встречается в zero-copy / referred path и низкоуровневом копировании байт, а в интеграциях - на FFI/JNI границах (об этом ниже). То есть это не часть криптографической схемы как таковой, но место для отдельного аудита, да.
Вы заглянули в интеграции. Спасибо конечно. Но эту часть я пока не готов анонсировать и этого не делал. Эта часть ещё требует доработок и осмысления, там много проблем и нерешённых архитектурных вопросов. Кэширование для Java - вообще черновик, а C# я даже не решил, оставлю ли в проекте в принципе. И да, вы правы… Если в Node и WASM у меня была возможность более внимательно посмотреть, то в части Java и C# - это чистые MVP. Весь фокус всё-таки был на ядре и генераторе. Про CLI в этой части я всё-таки считаю, что вариант вполне рабочий - не вижу проблемы. Мотивация за этим тоже стоит вполне ясная - интеграция разделена на несколько слоёв: слой кодека, когда мы в принципе можем прочитать сообщение, и слой генерации типов под платформу + биндинг (CLI только про этот слой, и он опциональный). Что касается потенциального кошмара в поддержке интеграции, то да - это риск. Но именно для этого все интеграции вынесены в свои крейты, отделены максимально от ядра и живут своей жизнью. Иными словами, апдейтить интеграцию с Node в 98-99 случаях из 100 можно не трогая ядро. Слой клея там есть, но очень тонкий. Но повторюсь - по интеграции есть много нерешённых архитектурных вопросов, о которых я бы пока предпочёл не говорить.
Про “смешанный поток” или “размазывание шума”. Может, я не совсем чётко артикулировал в статье и документации. Доки перепроверил - речи не идёт о том, что brec может собрать своё сообщение по частям. Речь о том, что может найти целое блюдце в мусорном баке. Но найти среди осколков и склеить битое - нет, не сможет. Этого нигде не заявлено и задачи такой не было.
Если что-то упустил - спрашивайте, я с радостью отвечу. Всегда приятно отвечать на умные вопросы от умных людей, но давайте попробуем без ярлыков ;)
Не планировал как то оскорблять или навешивать ярлыки, просто написал как думаю
а теперь по пунктам:
я не владею растом, пробовал много раз, но мне сложного и не очевидного синтаксиса и в Си хватает, потому мог что-то просто криво понять
TLS это не просто транспорт, как и protobuf это не просто gRPC. Если вам нужно безопасно хранить логи клиента то храните, в чистом виде что получили то и храните. При этом куча фишек сразу идет в комплекте причем не только критографических.
За хранение:
Статья написана про протокол, в репе сказано за протокол. Я пытался понять зачем хранение в транспортном протоколе. Обычно если делают модуль то разделяют зоны ответственности, то есть транспорт отдельно, хранение отдельно. Вместе это уже какая-то тулза что состоит из отдельных модулей.
По хранению рекомендую посмотреть на как сделано cockroachdb/pebble дам довольно просто и очевидно, потому как ваше простое хранение по фиксированному массиву спорное решение для вашей же задачи когда надо прокидывать и читать странные логи.
Во-первых хранение не массивами, а фиксированными чанками,что бы оно ровно в памяти лежало и проще читалось на произвольные размеры.
Во-вторых как раз лучше разорвать шифрование транспорта и шифрование хранилища, для того что бы расшифрованное нарезать по чанкам, а чанки жать и уже результат шифровать. Даже если все in-memory то оперативка не бесконечная, а зашифрованное не сожмется так как расшифрованное особенно если это логи которые можно сжать и в х20 если повторов много.
По кривому шифрованию как минимум у вас в отрытых данных длинна и как убить комп подменив всего пару байт в потоке я писал выше. Было бы у вас еще по хешу проверка целостности, а не CRC32 то можно было бы "помолившись забить" но так вектор атаки настолько очевиден, что подсознательно кажется что это приманка (например 16 байт с зашифрованного блока это скрытая хеш-сумма всего пейлоада, что бы детектить мамкиных хакеров еше на этапе анализа инфраструктуры)
За интеграции я потому и написал за подключаемые библиотеки. Вы со своей стороны собрали бинарь, а дальше как с ним будут работать не ваши половые трудности. Если простыми словами, то dll/so это "стариковский WASM для десктопов". Потому как CLI это не сильно безопасно и вообще не кроссплатформенно. Я вот например свои пет-проекты если делаю как "универсальный" CLI то собираю 38 бинарей (linux/amd64, linux/arm64, linux/arm/v7, linux/arm/v6, linux/386, linux/mips, linux/mipsle, linux/mips64, linux/mips64le, linux/ppc64, linux/ppc64le, linux/riscv64, linux/s390x, windows/amd64, windows/arm64, windows/arm/v7, windows/386, macos/amd64, macos/arm64, freebsd/amd64, freebsd/arm64, freebsd/arm/v6, freebsd/arm/v7, freebsd/386, openbsd/amd64, openbsd/arm64, openbsd/arm/v6, openbsd/arm/v7, openbsd/386, netbsd/amd64, netbsd/arm64, netbsd/arm/v6, netbsd/arm/v7, netbsd/386, android/amd64, android/arm64, android/arm/v7, android/386) и это самые популярные и беспроблемные (то есть собирается прямо в actions github) потому как предусмотреть все нереально, а ковыряться со сборкой до бума с ИИ редко бы кто стал.
А за логи я вам писал в другом вашем посте развернуто. Как лучше хранить и агрегировать. По поводу "небезопасных данных" - если сами разрабы, кто писали логи, такие "индусы" то просто сделайте тонкий клиент-обфускатор что будет работать в потоке и все. Все равно нежные данные должны как то помечатся - задетектили, обрезали середину, добавили звездочек и вот уже открыто переданный пароль нечитаем для стороннего чтения. Потому как шифрование это полумеры и вы этим лечите чужие ошибки своими костылями. Но вообще за такое безопасники беседуют без смазки со всеми причастными вплоть до увольнений.
Послушайте, я внимательно прочитал все ваши комментарии. К сожалению, с должным вниманием - только сейчас.
Что могу сказать: спасибо за прогонку репозитария через ИИ и найденное потенциально уязвимое место. Давайте только для читателей оговоримся, что речь именно о потенциальной уязвимости в сценарии недоверенного входного потока, а не о подтверждённом баге. По этому поводу я уже создал тикеты и буду разбираться.
В остальном, простите, это всё больше похоже на поток общих рассуждений вокруг темы. Если читать по диагонали - выглядит внушительно. Если читать внимательно - многие тезисы либо не относятся к статье, либо подменяют постановку задачи, либо спорят с тем, чего я не утверждал, либо вовсе отменяют реальность - это откровенный флуд. И честно это совсем не характеризует вас, как человека действительно в теме.
Поэтому предлагаю так: если у вас есть конкретные технические замечания по brec - на GitHub есть вкладка Issues и кнопка New Issue. Воспроизводимый сценарий, входные данные, ожидаемое/фактическое поведение - и я с радостью разберу.
А вашей продуктивности остаётся только завидовать: на Хабре меньше месяца, а уже больше полутора сотен объёмных комментариев :) Но увы ни одной статьи про ваши "миллион-миллионов бинарей". Я бы с радостью почитал... отправьте ping, как появится.
Удачи!
Я бы сказал что вы слишком серьезно воспринимаете жизнь, но странно такое писать про человека которому комментарии ИИ пишет
В целом сложилось такое впечатление что я вам своими комментариями непоправимую ментальную травму нанес, что очень странно слышать от настолько старого аккаунта (хотя аккаунтами как и кармой свободно торгуют, причем недорого)
Если вы так плохо воспринимаете критику (а ее и не было как таковой), то не публикуйтесь, что бы поберечь свое ментальное здоровье.
Удачи!
я не владею растом, пробовал много раз, но мне сложного и не очевидного синтаксиса и в Си хватает, потому мог что-то просто криво понять
и как же это соотносится с этим?
Из интереса закопался в исходный код (интересен сам алгоритм) и по состоянию на последний коммит f4228c5 вот список вопросов/фактов
вы либо крестик снимите, либо … ну это… что бы факты уверено раздавать
TLS это не просто транспорт, как и protobuf это не просто gRPC. Если вам нужно безопасно хранить логи клиента то храните, в чистом виде что получили то и храните. При этом куча фишек сразу идет в комплекте причем не только критографических.
Вы о чем вообще здесь говорите? Что значит “protobuf это не просто gRPC”? Что “помидор это не просто кетчуп”, “яйцо это не просто майнез”? В чём заключается ваша глубокая мысль?
В статье или в комментариях кто-то спрашивал о том, как хранить логи? В статье вообще есть акценты на хранении данных? Если уж разбираться, то у protobuf-сообщения самого по себе нет универсальной сигнатуры/framing для поиска сообщения в произвольном замусоренном потоке - каждый крутится с этим как может, что не отменяет ценности protobuf. Другое дело, что вы просто булщитите, постоянно пытаясь уйти от топика статьи. Мы с таким же успехом можем обсудить здесь интимные стрижки, они примерно так же соотносятся по смыслу со статьей, как упомянутый gRPC.
Статья написана про протокол, в репе сказано за протокол. Я пытался понять зачем хранение в транспортном протоколе. Обычно если делают модуль то разделяют зоны ответственности, то есть транспорт отдельно, хранение отдельно. Вместе это уже какая-то тулза что состоит из отдельных модулей.
Это просто какой-то набор слов вообще без содержания. “Сама придумала, сама обиделась” ©. В статье речь про фичу в протоколе. В документации прямо говорится, что это конструктор протокола в первую очередь. Storage, reader и прочие части - это инструменты вокруг packet format, а не обязательная часть crypt и не транспортный протокол. В доках и статье прямо говорится: конструктор протокола + набор инструментов, которыми можно пользоваться по необходимости.
По хранению рекомендую посмотреть на как сделано cockroachdb/pebble дам довольно просто и очевидно, потому как ваше простое хранение по фиксированному массиву спорное решение для вашей же задачи когда надо прокидывать и читать странные логи. Во-первых хранение не массивами, а фиксированными чанками, что бы оно ровно в памяти лежало и проще читалось на произвольные размеры.
Откуда читалось? О каком хранилище вы говорите? О Storage из brec, нацеленном на seekable backend? О каких массивах речь? В brec-storage фиксированным является не размер данных, а размер slot: слот хранит длины пакетов и позволяет вычислять offset. Сами пакеты внутри слота переменного размера. Если вы даёте техническую оценку решения - то сопровождайте её кодом и бенчами, отражающими просадку по чтению/записи. Если бенчи делать лень, то надо очень вежливо спрашивать “а не рассматривали ли вы как вариант это и это?”. Именно вежливо, так как именно автор будет тратить своё время на дополнительные бенчи, чтобы вам ответить. Если и это лень, то хотя бы сформулируйте мысль.
Во-вторых как раз лучше разорвать шифрование транспорта и шифрование хранилища, для того что бы расшифрованное нарезать по чанкам, а чанки жать и уже результат шифровать. Даже если все in-memory то оперативка не бесконечная, а зашифрованное не сожмется так как расшифрованное особенно если это логи которые можно сжать и в х20 если повторов много.
Сжатие, транспорт, шифрование всего хранилища, чанки, чанки. Вы статью читали вообще - это обзор конкретной фичи. brec crypt не является storage encryption pipeline и не пытается им быть. Вы вообще о чём? Если вы не поняли сути, то об этом можно спросить (вежливо) автора. В статье прямо говорится, в комментариях раскрывается, что есть сценарии, в которых на условные 100 сообщений приходится 1-2 зашифрованных. Точка. Если бы вы серьёзным ребятам, на серьёзных embedded-проектах, предложили бы шифровать всё ради 1-2% данных - вас не уволили, вас бы пристрелили, молча и хладнокровно. Вы либо очень ограниченно понимаете мир логов, трейсов, метрик и прочего, считая, что это вотчина исключительно Datadog и OpenTelemetry, либо какое-то медоборудование, где потоково шифруется зачастую вообще всё, либо… я хрен знает, если вы отрицаете право существования логов в файлах (отсылка к вашим вчерашним комментариям к моим статьям 5-летней давности). Мир разнообразнее, чем вам кажется.
По кривому шифрованию как минимум у вас в отрытых данных длинна и как убить комп подменив всего пару байт в потоке я писал выше.
То есть да, DoS через length в одном из reader-path возможен (на недоверительном потоке), и это уже вынесено в issues (вас даже за это поблагодарили!). Но назвать это “кривым шифрованием” - это либо непонимание предмета, либо сознательная подмена тезиса. Шифрование здесь не ломается: payload не раскрывается, AEAD не обходится, валидная подмена encrypted body не появляется. Ломается входная валидация длины до аллокации. Это разные классы проблем. Если это ломает шифрование, то будьте добры доказательства на стол, за базар-то надо отвечать, если уж взялись.
Было бы у вас еще по хешу проверка целостности, а не CRC32 то можно было бы “помолившись забить” но так вектор атаки настолько очевиден, что подсознательно кажется что это приманка (например 16 байт с зашифрованного блока это скрытая хеш-сумма всего пейлоада, что бы детектить мамкиных хакеров еше на этапе анализа инфраструктуры)
Ровно то же самое - лишь бы саср#ть. CRC32 в brec не является криптографической защитой и за неё не выдавался. Это быстрая проверка для чтения, чтобы ловить повреждения и рассинхрон потока. Для encrypted payload криптографическую целостность тела даёт не CRC32, а AEAD-тег ChaCha20Poly1305: если подменить ciphertext/tag, расшифровка не пройдёт.
Да, открытые length/header поля до decrypt-этапа остаются возможностю для DoS, если читать недоверенный поток без лимитов. Именно это замечание я принял и по нему создал тикеты. Даже при том, что на руках у меня нет воспроизводимого сценария атаки. Но превращать CRC32 в “кривое шифрование” - это просто смешивать разные уровни проверки. Во-вторых, архитектура brec и концепция контекста позволяет реализовывать свой механизм вне фичи crypt, отвечающий повышенным мерам безопастности, что прямо в статье указано.
За интеграции я потому и написал за подключаемые библиотеки. Вы со своей стороны собрали бинарь, а дальше как с ним будут работать не ваши половые трудности. Если простыми словами, то dll/so это “стариковский WASM для десктопов”. Потому как CLI это не сильно безопасно и вообще не кроссплатформенно. Я вот например свои пет-проекты если делаю как “универсальный” CLI то собираю 38 бинарей (linux/amd64, linux/arm64, linux/arm/v7, linux/arm/v6, linux/386, linux/mips, linux/mipsle, linux/mips64, linux/mips64le, linux/ppc64, linux/ppc64le, linux/riscv64, linux/s390x, windows/amd64, windows/arm64, windows/arm/v7, windows/386, macos/amd64, macos/arm64, freebsd/amd64, freebsd/arm64, freebsd/arm/v6, freebsd/arm/v7, freebsd/386, openbsd/amd64, openbsd/arm64, openbsd/arm/v6, openbsd/arm/v7, openbsd/386, netbsd/amd64, netbsd/arm64, netbsd/arm/v6, netbsd/arm/v7, netbsd/386, android/amd64, android/arm64, android/arm/v7, android/386) и это самые популярные и беспроблемные (то есть собирается прямо в actions github) потому как предусмотреть все нереально, а ковыряться со сборкой до бума с ИИ редко бы кто стал.
Ох сударь, вам бы тут промолчать. Если вы не понимаете, чем отличается компиляция бинарника под разные платформы и архитектуры от биндинга и FFI, то хотя бы попридержите своё мнение. И просто для справки: в мире Cargo вспомогательный CLI/build-time tool - это нормальная практика.
Кстати, что такое "половые трудности"?
А за логи я вам писал в другом вашем посте развернуто. Как лучше хранить и агрегировать. По поводу “небезопасных данных” - если сами разрабы, кто писали логи, такие “индусы” то просто сделайте тонкий клиент-обфускатор что будет работать в потоке и все. Все равно нежные данные должны как то помечатся - задетектили, обрезали середину, добавили звездочек и вот уже открыто переданный пароль нечитаем для стороннего чтения. Потому как шифрование это полумеры и вы этим лечите чужие ошибки своими костылями. Но вообще за такое безопасники беседуют без смазки со всеми причастными вплоть до увольнений.
На всё есть ответ и своё единственно-верное мнение. Кругом индусы, а он умничка наша! Ай да молодец, ай да солнышко! Как же хорошо, что мы вместе не работаем )
ЗЫ: Я правда вам признателен за агрессивный прогон решения через ИИ. Вы действительно вскрыли проблему с длинами на недоверенном потоке данных. Тикеты созданы, правки будут внесены. Те 3 проекта (на стадии MVP), что используют сегодня brec и могут в будущем стать реальными продуктами, будут лучше и безопастнее благодаря именно вам. Я особо это подчёркиваю - благодаря Вам. Спасибо! Но наш диалог мог быть совершенно иным, не смотрели бы вы на людей сверху вниз и не пытались бы за счёт других утверждаться. Хотите купить мою учётку на Хабре? Только вряд ли вам это поможет, потому как уважение не покупается.
да я понял что "не бомбит", все ок.
просто будьте проще и жизнь тоже станет проще
Хе ))) @gerbert_MX Вижу, вы уже не ограничились этой статьёй и пошли по архиву моих публикаций, включая материалы двухлетней давности.
Честно говоря, это уже выглядит не как профессиональная дискуссия, а как желание оставить “экспертное мнение” с явным негативным оттенком везде, где получится. Технические комментарии под старыми статьями я здесь обсуждать не буду: во-первых они весьма спорны и откровенно поверхностны, во-вторых это другая тема, другой контекст и местами вообще другой проект.
По brec я уже отдельно признал полезные замечания и завёл тикеты там, где есть реальная техническая фактура. Если появятся конкретные воспроизводимые проблемы - входные данные, падение, DoS-сценарий, ошибка чтения - с радостью разберу.
Если это что-то личное, напишите в личку - я всегда отвечаю.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Шифрование на уровне протокола