Компания Cloudflare опубликовала разбор одного из крупнейших инцидентов в своей инфраструктуре, из-за которого вчера большая часть сети доставки контента оказалась неработоспособной на протяжении более 3 часов. Сбой произошёл после изменения в структуре БД, размещённой в хранилище ClickHouse, после которого файл с параметрами для системы противодействия ботам в два раза увеличился в размере. В БД были образованы дублирующиеся таблицы, при том, что SQL-запрос для формирования файла просто выводил все данные из всех таблиц по ключу, без отсеивания дубликатов...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64282
Как защищать свои сайты и доменьчики от ботов без клауды и подобных?
Как минимум самохостинг go-away или anubis
Из-за anubis много раз не мог попасть на lore.kernel.org, в Firefox зависал или не догружался скрипт. Только недавно починили.
4 месяца cloudflare не может починить прохождение капчи в любых версиях Firefox для Linux > 141 версии. Бесконечно обновляет свою капчу
Это винится сменой айпи на американский.
Для прохождения капчи cloudflare надо переехать в США? Зачем такой костыль нужен и кому.
Как вариант. Достаточно пропустить трафик через посредника. Это такая фишка у cloudflare.
Юзеры просто закроют вкладку с очередным васянским сайтиком за cloudflare
нет никаких проблем с их капчей, всегда сижу на последних версиях firefox
Ага, а лично я намного чаще не мог подключиться к сайтам как раз из-за Cloudflare, чем из-за Anubis. Из под Tor'а вообще вкуснотища, бесконечные капчи.
Главное - главное что СВОБОДНО не мог попасть. Гордо и независимо!
У меня подобное началось после того как роскомпозор один из бакетов Amazon хлопнул. Я даже на git.kernel.org или gitlab.freedesktop.org попасть не мог. Сейчас вроде пускает, но как-то через задницу, например на gitlab.freedesktop.org не грузятся аватарки, а сами страницы хоть и загружаются, но индикатор загрузки не пропадает, те что-то постоянно пытается подгрузиться, но не может...
У меня как-то куча хостинг провайдеров из Европы было заблочено. Звонок оператору решил проблему. Без понятия что конкретно они сделали, но проговорились, что меня не пускал ТСПУ вне их сети.
dpi воткни, сверху варп - всё, кроме госуслуг, работает как надо
Там Firefox ESR что-ли?Поставь хром.
Без ВКЛ JS вообще не пускает этот ваш нубас.
> Как минимум самохостинг go-away или anubisСамохостинг это хорошо, однако они спасут только от L7 атак, когда корявый (других не бывает) PHP код по 20 SQL запросов шлёт в ответ на запрос от юзера
И то не факт, в случае если сайт изначально полумёртвый под нагрузкой из 10 юзеров, однако тут даже cloudflare мало поможет
А от L4, от которого защита тебе потребуется сильнее, самохостинг тебя не спасёт, и надо уже иметь сеть которая способна удар принять и трафик отфильтровать до твоей машины
Однако с этим способны справляться уже все облака, и можно спрятать дедики за реверс-прокси на облаках потенциально того же самого провайдера
> Однако с этим способны справляться уже все облака, и можно спрятать дедики за реверс-прокси на облаках потенциально того же самого провайдераи лежать, когда что-то лежит у них, что бывает чаще
> и лежать, когда что-то лежит у них, что бывает чащеНе исполняют обязанности по SLA - требуй возмещения средств
Ну и дедики тоже не бессмертные, даже более смертные чем большинство облаков если свои механизмы high availability не сделаешь поверх
там в соседней ветке пишут, что SLA у них - "моя хата с краю"
Дружище, бесполезно объяснять верующему в доброго дядю.
> дедики за реверс-прокси на облаках потенциально того же самого провайдераИ после первого же дудоса провайдер попросит тебя на выход
>> дедики за реверс-прокси на облаках потенциально того же самого провайдера
> И после первого же дудоса провайдер попросит тебя на выходКак раз таки у облаков провайдер почти всегда берёт на себя решение проблем с атаками, в отличии от дедиков
В худшем случае счёт тебе побольше выставит
у любого серьезного DC есть решения на случай DDoS а не только у облаков
> у любого серьезного DC есть решения на случай DDoS а не только
> у облаковРешения есть, вопрос как они используются
У многих провайдеров политика такая, что в случае атаки виноват ты, и значит что при атаке твой сервер могут просто отключить
Такая защита не бесплатная
Volumetric attacks Up to 5Gbps*
Protocol-based attacks Up to 2.5 million ppsFREE
*We rate-limit well-known attacks before they reach our scrubbing centers. Actual figures are much higher.
Ну вот пример бесплатного, свыше уже за деньги...
> are much higher.
> Ну вот пример бесплатного, свыше уже за деньги...Как проверил на своей ж...е Креббс которому "anna senpai" налил от души - при первом намеке на проблемы клаудспайвар с удовольствием посылает кастомера нахрен с аргументом "что-то от вас нагрузки дофига, идите-ка вы на мороз".
> Protocol-based attacks Up to 2.5 million ppsЭто точно дедики? Обычно у дедиков такого нет, потому что ресурсы на поддержания таких фильтров немного противоречат цели избавиться от оверхеда на всё подряд
Ну и 5гбит маловато на самом деле, дедики с гигабитом стоят копейки, с 10гбитами чуть дороже и обычно требуют дрочки с KYC, а тут говорится про всего 5 штук
>> Protocol-based attacks Up to 2.5 million pps
> Это точно дедики? Обычно у дедиков такого нет, потому что ресурсы на
> поддержания таких фильтров немного противоречат цели избавиться от оверхеда на всё
> подряд
> Ну и 5гбит маловато на самом деле, дедики с гигабитом стоят копейки,
> с 10гбитами чуть дороже и обычно требуют дрочки с KYC, а
> тут говорится про всего 5 штукда это дедики, и это только то что доходит до твоего IP, а так они еще и свою сетку защищают до 1.2 терабита, и режут все что совпадает с паттернама ддоса
дедикейтед это голое твое железо, но не голый ДЦ
DC - это сеть + резервное питание + охрана, так было всегда
> DC - это сеть + резервное питание + охрана, так было всегдаВот только обычно сеть там это просто aruba/другое простое железо, потому что это всё что тебе надо для машин внутреннего пользования (не торчащее в интернет для кого попало, не для сайтиков), а что-то с фильтрацией L7 на всех клиентов не напасёшься, и потому оно идёт отдельной опцией, либо не идёт вовсе у всех провайдеров что я знаю
>> DC - это сеть + резервное питание + охрана, так было всегда
> Вот только обычно сеть там это просто aruba/другое простое железо, потому что
> это всё что тебе надо для машин внутреннего пользования (не торчащее
> в интернет для кого попало, не для сайтиков), а что-то с
> фильтрацией L7 на всех клиентов не напасёшься, и потому оно идёт
> отдельной опцией, либо не идёт вовсе у всех провайдеров что я
> знаюL7 за деньги, это же логично WAF занимает свою нишу, выше речь про атаки L3 L4
и вообще считаю что L7 должен сам сервер держать или балансер перед ними
а то накупят облаков а потом плачут от ежемесячных счетов
Грамотно настроенный WAF и рейт лимиты помогают, но довольно геморно это все отлаживать. Из коробочных решений BunkerWeb для себя нашёл, почти что CF у себя дома. Но в будущем хотелось бы этот комбайн на что-то модульное сменить.
ddos guard
Это не про них молва ходит, что успешно сотрудничают как с российскими силовиками, так и с различным криминалом?
Клаудтвари сами же этих ботов и запускают.
> Как защищать свои сайты и доменьчики от ботов без клауды и подобных?смотря насколько ты кому-то наступил на хвост.
от потока просто мусора на 10-30 мегабит с безумных утюгов и холодильников - никак ты не защитишься. Еще и твой провайдер запросто может найти ннну очень уважительную причину разорвать с тобой договор (ему проще потерять деньги чем всех своих клиентов вообще - потому что его внешний канал полностью лежит из-за тебя).
(впрочем, клаудшмразь тоже за такое выкатит тебе недетский ценник. Ну, у какого-нибудь бредкома или ситибанка бабла хватит.)
От просто случайных набигателей из инторнетов - просто запасом мощности ну и наличием хоть какого-то представления о том как выглядит твой нормальный траффик и откуда он в основном берется.
>> Как защищать свои сайты и доменьчики от ботов без клауды и подобных?
> смотря насколько ты кому-то наступил на хвост.
> от потока просто мусора на 10-30 мегабит с безумных утюгов и холодильников - никак ты не защитишься.10-30 мбит -- это вообще не проблема, этим мелким паразитным траффиком можно в целом пренебречь. Главное, чего нужно добиваться при защите:
1) недопущение перегрузки кластера обработкой паразитных запросов
2) недопущение повышенных расходов за отдаваемый по паразитным запросам траффик (там могут быть циферки огого)
Общий паттерн защиты такой:1) На балансере -- резать по ip: в ингрессах выделить по правилу на каждый локейшен, и каждому задать rate limit. Можно разбить весь траффик на несколько ингрессов, сгруппировав таким образом локейшены.
2) Раз в месяц нужно анализировать логи балансера и проверять реальную утилизацию локейшенов для пересмотра валидности rate limit-ов. Не забыть сконфигурировать балансер отдавать http-429 для отлупов при превышении лимита, кстати. По умолчанию у того же nginx-а отдаётся http-503. Обязательно поставить алёрты на скачки http-429 в ответах.
3) Далее, если ваше приложение поддерживает авторизацию, то для всего кроме самой авторизации -- ставить rate limit по userid. Реализовывать на уровне приложения.
Реализуете это вкупе с #155, и в целом Cloudflare вам не нужен. Можете конечно дополнительно какой-нибудь anti-ddos или WAF бахнуть. Если не бахнули -- не страшно: на первых парах, если у вас реализовано всё по спискам выше, вы с высокими шансами сможете защититься и подручными средствами, побанив зловредов вручную. Да, будет больно, но не смертельно -- скорее всего даже без даунтайма пройдёт.
> 10-30 мбит -- это вообще не проблемасделают 30 гигабит - снова будет не проблема? Умные утюги разгоняются и до терабитов.
Причем васяну-то это вообще ничего не стоит. В отличие от тебя, где в договоре мелким шрифтиком что-то там на тему не превышения входящего...
> На балансере -- резать по ip
клиенты ненужны!
> Раз в месяц нужно анализировать логи балансера
уже смешно
> Далее, если ваше приложение поддерживает авторизацию, то для всего кроме самой
> авторизации -- ставить rate limit по useridтам где ты можешь проверить userid - уже поздно ставить рейтлимиты. Первой лопается проверялка.
> Реализуете это вкупе с #155, и в целом Cloudflare вам не нужен
он в целом вообще был ненужен если его можно заменить вот этим.
> Можете конечно дополнительно какой-нибудь anti-ddos или WAF бахнуть.
половину пользователей уже перебанил по ойпи - вторую похоронит васянский антиддыдос.
Ну правильно, чего ждать от специалиста забанившего ответы от юзера которому он отвечает...У них все так работает.
А на деле со стороны дерьмохостера которому с тобой "повезло" это выглядит так - "ой", и входной канал лежит. Начинаешь (с большим трудом ибо канал - лежит) разбираться за что ж и откуда - обычно с помощью апстрима, иногда не ближайшего - находишь клиента. Блэклистишь у апстрима его айпишник. Если повезло и его днс у тебя - блокируешь ему доступ и меняешь все адреса на 127.0.0.1, апстрим будет благодарен.
Ждешь пока позвонит. Узнаешь что вчера в два ночи он где-то в чятике послал подальше какого-то онанима (и грех бы такого пры...ра не послать-то). Говоришь что за деньгами взад может подходить в кассу в рабочее время.
>> 10-30 мбит -- это вообще не проблема
> сделают 30 гигабит - снова будет не проблема?А тебя и Cloudflare от такого не защитит, потому что не может быть 100%-ых правил как отличить паразитный траффик с тысяч утюгов от легитимного траффика. Это один фиг придётся резать на уровне региональных балансеров с учётом специфики приложения.
>> На балансере -- резать по ip
> клиенты ненужны!А без резки по ip им даже ddos не нужен, чтобы тебя положить. Выделят отдельный эндпоинт и с одного хоста его успешно закидают.
>> Раз в месяц нужно анализировать логи балансера
> уже смешноУ вариантов получше -- высокая стоимость.
>> Далее, если ваше приложение поддерживает авторизацию, то для всего кроме самой
>> авторизации -- ставить rate limit по userid
> там где ты можешь проверить userid - уже поздно ставить рейтлимиты. Первой
> лопается проверялка.При ddos-е, который работает ради дауна твоего сервиса -- да, поздно. Это для ботов, создающих большой паразитный траффик, выкачивая у тебя всякое. Позволяет избежать повышенных расходов.
> А на деле
А на деле, дорогой пох, я занимаюсь проектированием таких систем далеко не первый год, и мои клиенты пережили далеко не одну атаку.
> А тебя и Cloudflare от такого не защититпохоже ты совсем не сталкивался с реальными атаками...
клаудфларя защитит тебя от банального отвала канала по причине ой он весь кончился (а утюги - нет). Дорого. Хреново. Но сможет.
Канал такой ширины чтоб не кончался - сам себе не купишь. А у нее - есть.
> А на деле, дорогой пох, я занимаюсь проектированием таких систем далеко не первый год, и
> мои клиенты пережили далеко не одну атаку.это не атаки. Это васян из соседнего подъезда пальчиком тебя потрогал (судя по проблемам решаемым на уровне "фильтрации по userid".) Насколько ж все хреново у твоих клиентов, что для них это проблема, требующая платных опеннетчиков содержать...
Причем они видимо совсем никому не нужны, раз другие проблемы тебя не беспокоят.
Когда вдруг понадобятся - вариантов кроме бегом бежать к какому-нибудь куратору или дырдосгварду просто не будет. (поскольку для клаудшмары цветом паспорта явно не вышел)
Хорошо, пох. Видимо, ты -- мастер, а я -- увы, нет. Давай же ты покажешь мастер-класс и докажешь это раз и навсегда.А то я вот предлагал сценарий, который (исключительно по моему скромному мнению) будет экономически целесообразен для большинства. Но давай мы рассмотрим сценарий посложнее, для действительно большого и важного клиента, которому нужна высокая отказоустойчивость, и для которого очень вероятны ddos-атаки с крайне высокими bps.
Вот тебе вводные.
Есть распределённая api-шка, 5 каналов на 10 gbps. Её средняя нагрузка 90k rps. По результатам стресс-тестирования способна спокойно держать ~200k rps, линейно деградирует по времени ответа на 100% при повышении примерно до 350-400k rps, после -- летит экспоненциально.
Есть 5 региональных прокси на базе haproxy c ssl-терминацией. Естественно есть ограничения по req и conn. Естественно со stick-tables. Каждый способен держать 400k rps / 2000k pps / 10 gbps.
По метрикам хапрокси + по результатам анализа логов выставлены разумные лимиты rps:
- per ip 40 (но с кратным увеличением, например, для РК: кто знает почему -- молодец)
- per location 20 (для избранных эндпоинтов в силу специфики приложения -- может быть побольше)
- per auth header 20 (если пользователь категоризирован как бот -- снижает до 1 и ниже; категоризация через внешний WAF-контроллер, правила настраиваемые: учитывают принадлежность к сетям VPS-провайдеров, списки известных публичных проксей, выставляют пользователю категорию за 5 минут анализа его запросов, анализируют статистику за сутки)Сетевые sysctl для машин с региональными хапрокси писать, пожалуй, не стану. Уязвимости со стороны бизнес-логики приложения -- исключаем из рассмотрения. Рассматриваем только инфраструктуру. Отметим дополнительно, что все цифры приблизительные, пример чисто гипотетический, связь с конкретными компаниями искать не надо, а если вдруг найдена -- это случайность и ваши личные домыслы.
Итого. Пожалуйста, рассчитай мне стоимость ddos-атаки, которая гарантировано положит моего клиента, и дай характеристики ботнета атакующего, который способен это сделать.
> Видимо, ты -- мастер, а я -- увы, нет.я, скажем так, довольно долго работал в области, где канал, конечно, большой, но одному клиенту его не отдадут. И именно там обычно мелко-плавают большинство реальных бизнесов.
> будет экономически целесообразен для большинства.
> Есть распределённая api-шка, 5 каналов на 10 gbps.крута. Только вот у "большинства" ничего подобного - нет.
(в лучшем случае у них парочка "10gbps при условии заполнения на 4% в среднем за месяц с допустимым пиком в 20% не более тридцати секунд" и еще один резервный подохлее)
> Уязвимости со стороны бизнес-логики приложения -- исключаем из рассмотрения.
и, кстати, зря, в них-то целевая атака на такого и будет долбать (в смысле не в обычном смысле "уязвимости", а в обнаруженные очень медленные запросы, их у условного э...личного домысла обычно - есть, и легко находятся). Но это если кто-то согласится потратиться на целевую атаку.
Поэтому меня и изумила идея смотреть логи "раз в месяц".
> я, скажем так, довольно долго работал в области, где канал, конечно, большой,
> но одному клиенту его не отдадут. И именно там обычно мелко-плавают
> большинство реальных бизнесов.Ну я примерно представляю, о чём ты. Да только знаешь, большинству этих мелко-плавательных реальных бизнесов -- вот нафиг ни WAF, ни anti-ddos, ничего не нужно. Они с подобными атаками никогда не столкнутся именно потому, что мелко плавают. Ибо если солдаты сапоги вместо куры варят, о какой войне с соседом может идти речь.
> крута. Только вот у "большинства" ничего подобного - нет.
Честно говоря, я ничего не знаю про "большинство". За годы работы в этой сфере образовались, скажем так, надёжные контакты. Я работаю преимущественно с ними.
>> Уязвимости со стороны бизнес-логики приложения -- исключаем из рассмотрения.
> и, кстати, зря, в них-то целевая атака на такого и будет долбатьНу что значит зря, мы же вроде про инфру в целом говорили. В случае целевой -- тут уже начинается сфера умных ботов, имитирующих поведение пользователя. И это, между прочим, тот самый случай, когда WAF с категоризатором пользователей по поведению -- это то, что вне CF имеет шанс сработать лучше (лучше отловит медленных ботов (тех же утюгов, между прочим), учтёт бизнес-логику приложения, даст меньший процент false positives, итд).
> Поэтому меня и изумила идея смотреть логи "раз в месяц".
Практика показывает, что категоризатор требует тюнинга вот примерно как раз с такой частотой. Это происходит потому, что сервис не стоит на месте, а развивается. Добавляется новый функционал, появляются новые паттерны поведения пользователей. Они выпадают в отдельную категорию под условным названием "хрен его знает", и это смазывает картину, ухудшая работу WAF.
--
Короче, раз ты стоимость ddos-атаки считать не собираешься (а оно и правильно, там цифры будут добрые), давай я подытожу мысль следующим:
- в современном мире лучший по соотношению цена-качество подход -- это ставить вперёд бесплатный CF, а за ним уже -- собственные балансеры с дополнительным WAF; CF даёт бесплатный ddos protection и принимает на себя первый удар. (А если CF лежит -- плевать: если вместе с тобой лежит весь Веб в мире, репутацию ты не теряешь).
- если по каким-то причинам нет возможности воспользоваться CF (ну вот бывает у нас такое), можно в целом сделать собственные региональные прокси; вкупе дополнительным собственным WAF это уже более-менее надёжно: даст достаточно рычажков для того, чтобы адаптивно выявлять и резать ботов.
- если бизнес ещё и не особо крупный, то можно также забить и на региональные прокси, и даже, не побоюсь этого сказать, на WAF: rps limit-ы по ip, по эндпоинтам и по userid / auth header -- в целом защитят от нецелевого флуда, отсекут большую часть паразитов и помогут сэкономить денег на egress-траффике; а большего там и не нужно.
> Да только знаешь, большинству этих
> мелко-плавательных реальных бизнесов -- вот нафиг ни WAF, ни anti-ddos, ничего
> не нужно. Они с подобными атаками никогда не столкнутся именно потому,
> что мелко плавают. Ибо если солдаты сапоги вместо куры варят, о
> какой войне с соседом может идти речь.Так. Я решил забрать назад конкретно этот тезис.
Стал давеча свидетелем, как ддосили на редкость мелкий бизнес.Теперь моя метафора будет такая:
У папуасов за душой нифига, но воевать между племенами умудряются.Не разумно нифига, но тем не менее факт: порой люди не так-то и умны.
У меня остался только один вопрос. Извинения принесены будут?
> Как защищать свои сайты и доменьчики от ботов без клауды и подобных?Да как бы Cloudflare устроен не особо сложно.
Просто заказываешь в ряде регионов по паре машинок для приземления регионального траффика и переотправки на реальный api-сервер. На машинках настраиваешь haproxy для TCP-forward. Перед haproxy не обязательно, но желательно -- внешний балансер от провайдера. Терминировать там SSL не надо. Региональные DNS прописываешь смотреть каждому на балансер. Вот тебе и Cloudflare.
Опционально: добавляешь WAF и antiddos. Из плюсов -- ты будешь понимать, как именно они работают, и контролировать ложно-положительные срабатывания.
да счас, кто тебя досить будет по dns? тебя будут напрямую долбить по айпишнику, либо одного регионального узла, либо конкретно API endpoint, если знают его адрес
> да счас, кто тебя досить будет по dns?удивительная адекватность =)
> да счас, кто тебя досить будет по dns?а почему нет? Умные утюги отлично умеют в ресолвинг.
> по айпишнику, либо одного регионального узла, либо конкретно API endpoint, если
тогда эта поделка сдохнет и может даже выпадет из round robin, повезло. Только вот вряд ли кто будет такой фигней маяться. Апи эндпоинт тоже будет по имени, чего возиться-то лишнего.
> да счас, кто тебя досить будет по dns? тебя будут напрямую долбить
> по айпишнику, либо одного регионального узла, либо конкретно API endpoint, если
> знают его адресНу так делаешь DNS шустро обновляемым. Вешаешь endpoint на другой айпи, обновляешь DNS. Атакующий жестко флудит ... какой-то уже бесполезный хлам? Хотя конечно он может плотно окарауливать ваши хосты и мониторить все это. Но это видите ли подгружает и атакующего тоже, что дороже и неудобнее! :D
Погодите-ка сэр, у атакающего всегда будет полный список узлов и он всегда сможет принять решение, что флудить, очевидно же, что региональные узлы c DNS не спасасут от терминации вредного трафика, это все для балансировки легитимного.
точно так же как и с ним: перед сервером ставится балансировщик нагрузки/кеширующий прокси которые скрывают настоящий айпи серверрв.если провайдер позволяет -- к одному айпи можно подключить несколько балансировщиков. если не позволяет -- можно в днс прописать несколько айпи.
> точно так же как и с ним: перед сервером ставится балансировщик нагрузки/кеширующий
> прокси которые скрывают настоящий айпи серверрв.и что такого волшебного в твоем настоящем ойпи?
Просто первым ляжет твой наколеночный балансировщик.
Покупайте защщиты от клаудшмары, с вашими талантами самое оно.
>Как защищать свои сайты и доменьчики от ботов без клауды и подобных?А что сейчас все ещё выгодно иметь сайты? Раньше на рекламе от Гугла могли зарабатывать, но сейчас остался только его местный конкурент, который как говорят платит копейки и сайты держать не выгодно. А платить за хостинг и за не деловые домены ради хобби за свой счёт та себе удовольствие. Хотелось бы узнать мнение того, кто этим занимается.
>>Как защищать свои сайты и доменьчики от ботов без клауды и подобных?
> А что сейчас все ещё выгодно иметь сайты?ЦБ РФ смотрит на тебя... прищурившись.
> Гугла могли зарабатывать, но сейчас остался только его местный конкурент, который
> как говорят платит копейки и сайты держать не выгодно. А платитьсайты без прона и ставочек - держать уже лет десять невыгодно, если не больше.
Большинство из нас, не поверишь, занимается сайтами не ради заработков на помойной рекламе.
Опять во всём Rust виноват
А было бы на си - данные спокойно записались бы за пределами выделенного буфера, переписали несколько случайных структур, и все были бы счастливы
А мы не знаем что было бы, если было бы на Си. Но знаем что уже было, когда было (и до сих пор есть, а значит будет еще) на расте
>А мы не знаем что было бы, если было бы на СиА смешно и тонко ты над сишниками подшутил с их undefined behavior.
Вот CVE про выходы за пределы бывают, про использование освобождённой бывают, а вот про undefined behavior никогда не видел.
> Вот CVE про выходы за пределы бывают, про использование освобождённой бывают, а вот про undefined behavior никогда не видел.И первое, и второе - UB.
Издалека видно, что вы - сишник.
Неопределенное для других. Проблема в "обговоренности". Машинные инструкции вполне определённо себя ведут. А вот что такое тип Result в меняющемся языке, и как вырвать unwrap() в уже написанном коде?
> Неопределенное для других. Проблема в "обговоренности".У вас "особая" терминология?
> Машинные инструкции вполне определённо себя ведут.
Может да, может нет - какая разница? Мы говорим об UB в контексте высокоуровневого языка (например, Си).
> А вот что такое тип Result в меняющемся языке, и как вырвать unwrap() в уже написанном коде?
Какая‑то шизофазия.
Ну так большая часть проблем с памятью происходит из-за undefined behavior
Почему undefined behavior в Си так беспокоит растистов? Занимались бы своим огородом, там дел невпроворот, еще ничего толком не переписано а уже баги вылазят. То в sudo-rs, то в tar, а тут вообще полинтернета отдохнуть отправили в оффлайн.
Не растист, но в целом не могу понять, какого вообще в языке существует undefined behavior. По-моему если у тебя есть язык - в нём надо чтобы всё behavior было defined. Иначе это какая-то недоделка
Даже в математике есть UB :-DНапример 0/0.
> Даже в математике есть UB :-D
> Например 0/0.В математике в отличие от языков программирования нет behavior. 0/0 - это просто бессмысленное выражение, потому что функция / не определена, когда оба аргумента ноль. Тут не может произойти "что угодно", тут просто нет ничего, набор знаков.
В Си же - именно behavior, literally "может произойти что угодно". Вот такое куда страшнее, и должно отсекаться компилятором как можно строже
>> Даже в математике есть UB :-D
>> Например 0/0.
> В математике в отличие от языков программирования нет behavior. 0/0 - это
> просто бессмысленное выражение, потому что функция / не определена, когда оба
> аргумента ноль. Тут не может произойти "что угодно", тут просто нет
> ничего, набор знаков.
> В Си же - именно behavior, literally "может произойти что угодно". Вот
> такое куда страшнее, и должно отсекаться компилятором как можно строжеРассчитывать на то, что компилятор решит волшебным образом проблемы, бред сивой кобылы.
> Рассчитывать на то, что компилятор решит волшебным образом проблемы, бред сивой кобылы.Он должен запрещать как можно больше проблемных ситуаций и как можно меньше отдавать на откуп вниманию пользователя. В чём смысл инструмента, не помогающего в и без того тяжелой работе?
А мы знаем что уже было на c/c++ и почему cf пошли это все переписывать
Ой какая хорошая ссылка, сохранил.
Почему вы приписываете это языку программирования, а не конкретным программистам, написавшем код?
Потому что это прямой конкурент Раста.
Что страшнее - утечка непонятных данных или невозможность позвонить по номеру экстренных служб? Австралийцы смотрят на тебя, как на ... .
> Австралийцы смотрят на тебя, как на ... .Естественный отбор :)
Обновление безопасности было, но чувак его не поставил.
Печалька.
> А мы знаем что уже было на c/c++ и почему cf пошли
> это все переписывать
> https://en.wikipedia.org/wiki/Cloudbleed"Долбаные растеры непоколебимо и фанатично верят в то, что добрый компилятор, <s>ниспосланный им высшими силами</s>, выловит за них все их ошибки, и, как следствие, пишут как попало. Про сишников можно говорить что угодно, но несомненно одно: там если чуток расслабишься, тут же получишь отстрел собственной ноги, так что там никто и не расслабляется. И это правильно."
> переписали несколько случайных структур...запороли бы данные, получили бы неконсистентное состояние, выполнили бы случайный код...
А может все было бы хорошо. Но для того чтобы это узнать, нужно чтобы код был написан на сишке. Вот когда на си перепишут, тогда и поговорим.
на сервисе fl (который до раст) наблюдалась деградация работоспособности, так что какое то время сервису все ещё было бы плохо, но было бы не так заметно, я полагаю
А было бы на Си, проверили бы три раза на тестовом стенде, прежде чем пихать с пылу с жару на боевой сервер. А тут свято уверовали в безопасную безопасность и безопасно без тестирования на несколько часов опRustоволосились.
> А было бы на Си, проверили бы три раза на тестовом стенде... и все равно бы вышли за пределы буфера)))
Хотя глядя как в ядро мерджат сишных код в обход всех ревью, что-то не верится в "проверили бы три раза".
Никогда не понимал: когда проблема выхода за г границы так будоражит - лучше к психиатру обратиться, потому что проблема не в возможности, а в том, что малограмотные люди пишут код, который Вы используете.
Далее если сегодня эти люди такого не допустят, то раньше или в спешке - вполне могут!
+1. Чем больше ржа-апологеты кричат о безопасности, тем больше народ думает, что вообще думать не надо - просто жонглируй указателями.
> А было бы на Си, проверили бы три раза на тестовом стенде, прежде чем пихать с пылу с жару на боевой серверДа что ты говоришь!
Так эта ошибка кодогенерации Ragel, причем тут Си. Разрабы об этом писали в отчете.
blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/For the avoidance of doubt: the bug is not in Ragel itself.
It is in Cloudflare's use of Ragel. This is our bug and not the fault of Ragel.The root cause of the bug was that reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer. This is known as a buffer overrun. Had the check been done using >= instead of == jumping over the buffer end would have been caught. The equality check is generated automatically by Ragel and was not part of the code that we wrote.
> Разрабы об этом писали в отчете.
Проблема в том, что невалидный код скомпилился, потом вылез за пределы буфера и пользовательские данные утекли. А не напр. запаниковал при попытке.
Тогда бы проблему нашли через полдня как тут, а не через пять месяцев утечки.
Если помнить, что на Си написаны миллиарды строк кода, то такие случаи находятся в районе статистической погрешности.
> Если помнить, что на Си написаны миллиарды строк кода, то такие случаи находятся в районе статистической погрешности.Откуда же тогда все эти CVE лезут? Да в принципе много и не надо. Сишочка и плюсы настолько мощные языки, что и одного раза будет достаточно. Как, еапример, было конкретно у Cloudflare:
https://en.wikipedia.org/wiki/Cloudbleed
Всего то делов: из-за переполнения буфера личные данные тихонечко слились примерно 18,000,000 раз, прежде чем проблему заметили.
...после чего ребята пошли переписывать свою инфраструктуру еа Расте.
... и в итоге уронили почти весь интернет на несколько часов (!). Хорошее начало, а что еще будет впереди с такими переписывальщиками.
уронили не из-за rust, а потому что в прод закинули то что не надо было.
> Откуда же тогда все эти CVE лезут?Из "миллиардов строк написанного кода". У Rust написанных строк много меньше. Что ждет человечество с кодом Rust и неопределенностью Result, unwrap(). Гдобальный panic!() по любому чиху.
> А было бы на си"вместо корректной обработки"
"использованием в коде на языке Rust метода unwrap() с типом Result."
"Обычно unwrap() применяется в процессе отладки"Попробуйте связать это. Программисты rust "схалтурили" вместо обработки ошибки. В Си такие перекладывания на отладочную функцию не проходит. Почему Вы оскорбляете незнакомых Вам людей, тем что они не смогли бы грамотно обработать ошибку?
Потому что на практике в среднем коде на Си ошибки не обрабатывают никак, ни грамотно, ни неграмотно. Сложно это, язык бедный.
Ну да, а кто ж ещё?! Не Раст ли бегает и на каждом углу кричит "пешыте на расте у нас нет проблем с памятью"? А зачем нам вообще нужен раст?!! Ну вот так чисто по-программерски ответь. В С++ всё есть, от безопасной памяти до крутого ООП и ТЫСЯЧ полезных библиотек. Накой ляд тут ржа??
> В С++ всё есть, от безопасной памятиНет там безопасной памяти.
В какой большой плюсовый проект не ткни - везде дыры из-за памяти.
Лиса и хром каждый релиз фиксят по десятку-двум проблем, хотя обмазаны умными указателями и всякими мираклПТР, тестами, фаззингом и еще кучей всего....
В Chrome 139 устранены 12 уязвимостей.
В Chrome 140 устранены 6 уязвимостей.
В Chrome 141 устранена 21 уязвимость.
В Chrome 142 устранены 20 уязвимостей....
в Firefox 143 устранено 16 уязвимостей. 8 уязвимостей вызваны проблемами работы с памятью, такими как переполнения буферов и обращение к уже освобождённым областям памяти.
в Firefox 144 устранено 24 уязвимости. 16 уязвимостей вызваны проблемами работы с памятью.
в Firefox 145 устранено 19 уязвимостей. 10 уязвимостей вызваны проблемами работы с памятью.Но не помогает, видать ̶ ̶м̶е̶с̶т̶о̶ ̶п̶р̶о̶к̶л̶я̶т̶о̶е̶ первородный грех наследника дыpяxи.
> убогого ООП
поправил, не благодари
хотя уверен, что сейчас набегут уточки, которые кроме такого ооп ничего не знают)))
> Нет там безопасной памяти.зато есть безопасная работа с памятью
Я понимаю, что ирония. Но словесный понос удержать не могу.unwrap() -- это буквально "в случае любой проблемы совершать роскомнадзор". Полезно для отладки и прототипирования, оч вредно в проде, особенно проде с триллионами запросов в день.
да народ сразу в шутки даже тупо пропустив этот абзац
Как водится, всем хочется расстрелять гонца ☺, который принёс стектрейс. А ошибка была в SQL.
sql сильно изменился за лето…
ошибки было две и в sql не самая интересная
В новости же ясно сказано что ошибка была и в обработчике на Rust:"Проблема оказалась в том, что вместо корректной обработки превышения лимита и продолжения использования прошлой версии файла с информированием системы мониторинга о внештатной ситуации, в обработчике срабатывало аварийное завершение, которое блокировало дальнейший проброс трафика. Ошибка была вызвана использованием в коде на языке Rust метода unwrap() с типом Result."
Нет, не ясно. Если бы ошибка была обработана правильно (то есть преобразована в Result::Err и возвращена), то улучшилась бы диагностика при падении этого сервиса. Само же падение никуда бы не делось.
> Само же падение никуда бы не делось.т.е. сейчас мы можем ожидать новых падений в случайный момент времени? Откуда гарантии, что впредь этот файл всегда будет валидным?
При чем тут Раст, там в таблице просто надо было сделать столбец уникальным, ну или в запросе DISTINCT прописать, хотя бы.
Вот такого от раста я не ожидал!
Да ничего страшного с растом. Там выше говорят, что на самом деле это сишники опять облажались потому, что если бы это было бы на С, то был бы вообще кошмар. Так-что всё хорошо.
Там выше привели ссылку на Cloudbleed - пример того, как это было на С. Прокся 5 месяцев (!) раздавала приватные данные направо и налево. Но для дыряшки это не кошмар, а так, обыденность.
А вот разработчики пишут, что проблема была не в Си: "This indicated that we were not using Ragel correctly." Ragel оказался слишком сложным инструментом для вайбкодеров. Впрочем, как мы видим, Раст им тоже не помог.
>Раст им тоже не помог.Проблема высоко-абстрактных языков - и программистов - в том, что они отрываются от материи. Абстрактно применяют абстракцию в конкретных ситуациях полагаясь на могущество инструмента.
проблемы растсеров - тотальная надежда на чеков борера.
Скорее всего для unwrap() добавят вывод компилятором предупреждения, что по идее и должно было быть сделано изначально.
unwrap() это разворачивание обертки и обработка ошибок в процессе разворачивания по умолчанию языка. Что надо писать перед вызовом panic!()? Что программист халтурщик?
> Скорее всего для unwrap() добавят вывод компилятором предупреждения, что по идее и
> должно было быть сделано изначально.Не добавят. В некоторых случаях использование unwrap() вполне валидное поведение. В этом репозитории должен был быть включен линтер, который бы фейлился, если бы использовалась эта функция (а также например panic и другие).
Кода на си становится все меньше...
Новости про ошибки в расте появляются все чаще...Случайность? Не думаю.
кода на си не становится меньше, когда на расте не становится больше
> Новости про ошибки в расте появляются все чаще... кода на расте не становится большеЭто получается, плотность ошибок на расте увеличилась? Что не так с программистами на расте?
> Что не так с программистами на расте?это не программисты
вопросы твои непонятны
изначально было понятно, что растсеры не программисты.
Кода на Расте становится больше дублирующего сишный.
Нет, не случайность. На расте стали больше писать в прод, и не какие-то никому неизвестные васяны, а крупные коропорации. То есть ровно по той же причине, по которой мы так часто слышим об ошибках в сишном коде.
Знаешь, как работают разработчики из корпорации? Им ставят задачу, они делают как могут по быстрому, если сроки поджимают, они пропускают мимо глаз некоторые моменты и допускают ошибки. Ну и повсеместно юзают AI и не проверяют до конца эти выбросы от LLM. И всё это из-за "эффективных" манагеров чаще всего.
А среднестатистический опытный васян пишет с энтузиазмом и ему не ставят такие рамки, он пишет себе в кайф. И код чаще получается качественнее, чем у корпоратов. Есть много примеров открытых проектов от авторов, которые не состоят в корпорации, а делали это в своё удовольствие и удобное для себя время и сроки.
> Ошибка была вызвана использованием в коде на языке Rust метода unwrap() с типом Result.А ведь даже тут растофилы хвасталась, что вон в Клаудфларе кучу кода пишут на расте, а они 10000% интернета фильтруют
Ну вот и отфильтровали. Ну не 10000 но процентов 50 таки опа, чтотапаламалася и отфильтровалася от посетителей. И пол-дня не были в состоянии раздуплиться и починить (потому что поназаменяли админов девляпсами)Зато на хрусте!
Лучше было бы как здесь, да? https://en.wikipedia.org/wiki/Cloudbleed
Да, лучше. Белкам истеричкам которые гоняют через клаудшмару пароли и данные кредиток ничего уже не поможет, а от страшной и ужасной утечки анонимных айдишек васян-сайта никто не умрет.
(отдельно прикольно что когда использовали ниправильныйниправильный нинатом йезыке nginx - ничего не утекало, в отличие от пы0мерзкой подделки которую принесли альтернативно-одаренные)
А вот васянов копеешный бизнес - умрет, пролежав пол-дня. Если ему не повезло с конкурентами и те нормальных админов наняли - так что не легли вместе с клаудшмарой и перехватили все васяновы заказы.
Uber это белки-истерички? Обожаю аналитику от опеннета.
Я бы сказал что такое это, да модератор не позволит.
>> Лучше было бы как здесь, да? https://en.wikipedia.org/wiki/Cloudbleed
> Да, лучше. Белкам истеричкам которые гоняют через клаудшмару пароли и данные кредиток ничего уже не поможет, а от страшной и ужасной утечки анонимных айдишек васян-сайта никто не умрет.Качественный копиум. Обожаю, когда ты начинаешь нести дикую чушь лишь ради того, чтобы твои нелепые теории не рассыпались.
>> https://en.wikipedia.org/wiki/Cloudbleed
> отдельно прикольно что когда использовали ниправильныйниправильный нинатом йезыке nginx - ничего не утекалоCloudbleed был БУКВАЛЬНО во времена использования Ngnix. Здесь подробности, если осилишь инглиш:
https://web.archive.org/web/20170223233000/https://blog.clou.../
> Cloudbleed был БУКВАЛЬНО во времена использования Ngnix. Здесь подробности, если осилишь
> инглиш:ВНЕЗАПНО, проблема стала серьезной когда они попытались впихнуть между нжинксом еще одну свою косорукую поделку.
It turned out that the underlying bug that caused the memory leak had been present in our Ragel-based parser for many years but no memory was leaked because of the way the internal NGINX buffers were used.
Но им захотелось поулучшайкать. Но язык был не тот. Вот теперь - тот. Поэтому все безопастненько упало и пол-дня не знали как поднимать.
> Но им захотелось поулучшайкать. Но язык был не тот. Вот теперь -
> тот. Поэтому все безопастненько упало и пол-дня не знали как поднимать.Ну так не сравнивай буй с пальцем)
Пол дня упал интернет и "почти полгода у нас утекали данные".Твои куракеки на уровне горцев или колхозанов, которые не пристегиваются, по причине "но если с моста в реку упедешь, то не поможет! у меня барат свата троюродной тети так утонул".
> Пол дня упал интернетклиент ушел к кому-то кто не пользовался стремным сервисом - и вероятно назад не вернется. А у тебя вон счет от клаудмары неоплаченный за услугу.
> "почти полгода у нас утекали данные".
но так никуда и не притекли. Ущерб для клиента и для бизнеса отсутствует. Хотя для него и повода могло бы не возникнуть, если бы эти альтернативно-одаренные не полезли улучшать то что работало.
Визг белок-истеричек никому кроме их самих неинтересен.
Хосспаде. Смиритесь с тем, что всё, что вы кладёте в или гоняете через клауд - априори нужно считать утекшим. By design. Потому что что происходит в клауде, и какой васян там обосновался на транзите - вы не знаете.Ещё хуже, если вы их клаудный туннель открыли в свою сеть. Думаю, понимание того, что сторонний туннель может смотреть и подделывать запросы - не rocket science.
> пароли и данные кредиток [...] утечки анонимных айдишек васян-сайта никто не умрет
> А вот васянов копеешный бизнес - умрет, пролежав пол-дняОт 3 часов простоя копеешный бизнес умрет, а от тихой утечки его кредиток и админки клаудфлари - не умрет? Да ты мастер логики, я смотрю!
>> пароли и данные кредиток [...] утечки анонимных айдишек васян-сайта никто не умрет
>> А вот васянов копеешный бизнес - умрет, пролежав пол-дня
> От 3 часов простоя копеешный бизнес умрет, а от тихой утечки его
> кредиток и админки клаудфлари - не умрет? Да ты мастер логики,не умрет, потому что ни одна кредитка на самом деле и не утекла.
(и если ты настолько л-х что вместо размещения виджета платежной системы САМ собрался обрабатывать кредитки через клаудшмарь (т.е. с полной засветкой всех данных третьему лицу) - такого бизнеса лучше чтоб и не было)
Эти гении веб-технологий промто видимо даже и не в курсе, что Cloudflare работает только за счёт MITM их TLS соединения. Хранить секреты и особенно ПД на сайте за CF - это верх разумизма.
> Эти гении веб-технологий промто видимо даже и не в курсе, что Cloudflare
> работает только за счёт MITM их TLS соединения. Хранить секреты ине только, но в том числе (и отказываться от этой золотой жилы, разумеется, не собирается).
> особенно ПД на сайте за CF - это верх разумизма.
да кому твои пд сдались, ты не сын писькова. Да и те сперли куда более простым способом. (опять клаудшмара не уиноатая)
Тут в другом вопрос - что если ты в любой точке мира (даже в Б-гом проклятой) вздумаешь САМ обрабатывать платежи вместо договора с проверенным обработчиком (который ТОЧНО не за митм прокси) - тебя ждет мир удивительных приключений с pci-dss compliance, а потом... потом банк все равно попросит тебя пойти куда-нибудь подальше даже если ты совершенно правильно кланялся и приседал. Потому что нафиг ты ему такой не упал.
Там ещё неизвестно, что конкретно будет. Тот же клаудфлаер вполне-себе исполняет санкции
Т.е по решению хз кого хз откуда, в другой стране может отрубиться доступ к местному ресурсу для жителей самой же страны тупо потому что трафик к нему шёл через вышеобозначенное
Это не говоря пря всякие мутные фильтрации по адресам( вплоть до ограничений доступа пользователям потому что адресом не вышли как сетевым, так и конкретным географическим регионом, к которому он относится )
> ничего не утекалоДеньги утекали на оборудование, тормозной nginx не вывозил байты между сокетами перекладывать, уж бог знает почему, писали-то его, пожалуй, самые гениальные сишники, которых рождала эта земля.
Потому что байты между сокетами в таком объёме надо в асиках перекладывать, а не в софте. Но это клаудфлара, ей можно.
То, что один дypaк выбрал ржу, ещё ничего не говорит о применимости языка. "Начальник-дe6uл" - это уже практически устойчивая связка слов, а теперь прикиньте - он принимает решение "Завтра все пишем на рже!". !!!!!
> То, что один дypaк выбрал ржу, ещё ничего не говорит о применимости
> языка. "Начальник-дe6uл" - это уже практически устойчивая связка слов, а теперь
> прикиньте - он принимает решение "Завтра все пишем на рже!". !!!!!а завтра пишем на аде - не принимает.
Поэтому, увы, говорит. Видишь раст - вероятнее всего начальники - это вот самое. А с ada еще могут быть варианты.
> Обычно unwrap() применяется в процессе отладки или при написании тестового кода и не рекомендован для использования в рабочих проектах.Угу. Что-то как ни откроешь код на расте, то там "ехал unwrap() через unwrap()". Получается это все не настоящие си^Wрастоманы пишут?
Отлично!
Благодаря unwrap() получился DoS, а не выполнение стороннего кода, как в соседней новости, и взлом серваков! Всего 3 часа отсутствия инета, ошибка найдена и исправлена.Так держать клаудфаря! Главное - безопасноть :)
> Всего 3 часа отсутствия инета, ошибка найдена и исправлена.
> Так держать клаудфаря! Главное - безопасноть :)Если нет сети, то нельзя выполнить удаленную уязвимость (smartblackguy.jpg)
Если нет сети, то нельзя получить данные, нельзя продолжить телеоперацию (да, уже есть удалённые хирурги), авиадиспетчеры останутся без компов...
Зато на Расте! Как тут один по ехавший пишет, "подумаешь немного без интернета посидели" ))
Какие к черту авиадиспетчеры и телехирурги через клаудфларь и публичные веб-сервисы? Не неси бред.В этом типичном факапе есть сочетание нескольких разных косяков организационно-технического характера (как чаще всего и бывает в любой сфере -- неудачное и непредвиденное сочетание разных небольших и некритичных по отдельности факторов внезапно приводит к крупной проблеме), но нет ни одной проблемы в самом Расте, как инструменте. Раст сделал то, что и должен был сделать согласно [недоделанному] исходнику -- прервал выполнение функции с кривыми данными без нарушения целостности памяти и данных.
В итоге виноваты менеджеры CF: ошиблись/схалтурили их кодеры и девопсы/админы нижнего уровня (обычный рабочий момент), схалтурили ревьюверы/сеньор-админы и пропустили лажу дальше (уже хуже, но еще терпимо), выкатили изменения глобального конфига критического сервиса сразу в прод вообще без тестирования в изолированной лабе (эпик-фейл важнейшего бизнес-процесса!), причем даже без ограниченного постепенного (напр., по регионам или часовым поясам) деплоя изменений на весь мир (еще один огромный косяк в бизнес-процессе!). При грамотной архитектуре критической системы и организации бизнес-процессов ее поддержки ни одна грубая ошибка в коде или конфиге не должна доходить до прода, а уж тем более, приводить ее к состоянию тотального DOS.
> нельзя продолжить телеоперацию (да, уже есть удалённые хирурги)Кусок растокода не был рассчитан на возникновение ошибки загрузки данных - "виноват растокод!"
"Удалённый хирург" не был рассчитан на возникновение ошибки соединения - "виноваты все кроме удалённого хирурга!"
Я сам сишник и раст не люблю, но конкретно в этой новости растофаны всё сделали правильно. Не можешь/не хочешь обработать ошибку - падай, пусть ошибка себя проявит.
халтурить при обработке ошибок и на все вызывать панику, это пример растофилии и как говорят растофилы, если язык позволяет значит, то это проблема языка.
> Если нет сети, то нельзя получить данные, нельзя продолжить телеоперацию (да, уже
> есть удалённые хирурги), авиадиспетчеры останутся без компов...Чуваков которые устраивают телеоперацию через колоудфларь (по сути МИТМ) нужно отправлять мести улицы.
Для таких сервисов нужны совершенно другие требования: надеджнось, резервирование.
"всего 3 часа"?!?! Да у нас начальник вые6 бы тебя уже через 10 минут неисправленной ошибки!!! И это чисто корпоративный сервачок, но котором, подумаешь - держится весь бизнес! А тут пол-тырнета завязано на этих тупых облаках и на те - на 3 часа ты просто в ауте и миллионные убытки!А ещё кричали "бегите к нам в облака, у нас 200% устойчивость, кластеры, виртуальные машины!". А чего стоит виртуальная машина, если ею управляет 06е3ьяна?!?!
А бизнес клаушдшмрази держится не на сервачках, а на FUD пропаганде.
Дай угадаю - НОЛЬ клиентов додумались с них свалить после этого инцидента.Хотя нет ровно никаких признаков что следующего точно такого же не будет.
Что такое FUD пропаганда?
Челове́к разу́мный (лат. Homo sapiens[К 1]), также нередко просто челове́к[К 2] — самый многочисленный и широко распространённый вид приматов. Принадлежит роду Люди (Homo) семейства гоминид надсемейства человекообразные обезьяны подотряда Обезьяны (лат. Haplorhini). Среди других животных выделяется постоянным прямохождением[К 3]
https://cdn.ruwiki.ru/commonswiki/files/8/85/Primates_Divers...
> у нас начальник вые6 бы тебяТяжко тебе наверное работать! Ты ж по личному опыту пишешь?
Хорошо что я не работаю с такими отбросами)> А тут пол-тырнета завязано на этих тупых облаках и на те - на 3 часа ты просто в ауте и миллионные убытки!
Где-то сэкономил (на своих серваках), где-то потерял.
Для многих даже 3 часа в год это приемлемо.> А ещё кричали "бегите к нам в облака, у нас 200% устойчивость, кластеры, виртуальные машины!".
Да.
Когда был подобный факап до вчера?
> Когда был подобный факап до вчера?За последние несколько месяцев глобально шатало gcp и aws.
Их в принципе постоянно шатает, просто в отдельных регионах
У вас на работе реально руководство подвергает сексуальному насилию за ошибки? Я так понимаю, вам это по нраву, иначе не могу себе представить зачем в таком месте работать.
не отлично 3 часа слишком долго искали потому что unwrap никуда не логируется и в панике никакого сообщения. было бы логирование поймали бы раньше. было бы запрет на паники было бы вообще замечательно
> 3 часа слишком долго искали потому чтосмотрели не туда.
"we initially wrongly suspected the symptoms we were seeing were caused by a hyper-scale DDoS attack"Да и 3 часа это на всё. Ты не можешь вот так просто откатить что-то, потому что на это нужно время.
В 11:05 они залили бажный конфиг. В 13:37 они уже ролбечили его.
> unwrap никуда не логируется и в панике никакого сообщения
Вообще-то логируется. Они даже в бложике строку скинули:
"thread fl2_worker_thread panicked: called Result::unwrap() on an Err value"
> Ты не можешь вот так просто откатить что-то, потому что на это нужно время.Потому что для этого нужна сеть, а у тебя ИИ не работает из-за краха сети.
> смотрели не туда."we initially wrongly suspected the symptoms we were seeing were caused by a hyper-scale DDoS attack"
у них метрик нет что-ли? по которым должно быть видно есть ддос или нет
и на падение процесса должен алерт быть
они выкатку мониторят вообще?
Типичный раст, постоянные падения это его коронная фишка. Низкая культура разработки, что поделать.
> постоянные падения это его коронная фишкаВообще-то падения стали мемом плазмы, которая совсем не на расте.
"Низкая культура разработки, что поделать" (с)
У меня до сих пор падает каждый день, файловые дескрипторы кончаются. Исправлять, конечно, не спешат, как explicit sync добавили -- это сплошной треш каждый день, и если с иксами просто перезапускалось, то с вейландом падает и всё. Но это у меня systemd нет, перезапустить, видимо. Видишь, тут ничего не поделать. А вот с падениями ripgrep ты вполне можешь что-то сделать.
Так увеличь лимиты, если дескрипторов не хватает.
> Так увеличь лимиты, если дескрипторов не хватает.Они всё равно кончаются. Ну и это утечки. Иногда кликаешь плазму и появляется сообщение о невозможности открыть файл, следом она тут же падает.
Так там плюсы, а не чистый Си.
Там намеренно все плазмоиды, в т.ч. и сторонние, исполняют в одном адресном пространстве. Вот отсюда и возможны падения.
> постоянные падения это его коронная фишкаМожно хоть на Си такое-же написать. Понятно-же, что unwrap() - это, если проводить аналогии, дальнейшее развитие идеи assert-а. Буквами по белому написано, что НЕ надо его использовать в production-коде. Но, как всегда, имеем вот это вот всё и виноват, конечно-же, Rust.
> Но, как всегда, имеем вот это вот всё и виноват, конечно-же, Rust.какие-то неправильные программисты на расте
> какие-то неправильные программисты на растеУ них обычно виноват кто угодно, кроме них самих, ведь им дали такой инструмент.
> дальнейшее развитие идеи assert-а.Если это было бы так, то код бы работал в проде, т.к. ассерт для дебага.
> Буквами по белому написано, что НЕ надо его использовать в production-коде. Но, как всегда, имеем вот это вот всё и виноват, конечно-же, Rust.
Если так рассуждать, то буквами по белому написаны ub, но как всегда имеем вот это вот всё и виноват, конечно-же, Си.
> Если так рассуждать, то буквами по белому написаны ub,Гениально! То есть, чтобы в сишочном коде не было UB, мне достаточно просто не добвалять UB? 😂
ты путаешь UB и Бабайку
Ээ... Ну, как бы да? Причём конкретно тебе делать ничего не надо, компилятор в тебя дофигищей warning бахнет, если ты прямо в коде будешь писать дичь типа a = b[++i] + b[++i]. Если ты боишься разыменования нулевых указателей, то специально для тебя есть такая крутая штука - операционная система, она тебе segfault сделает и будет даже безопаснее, чем unwrap на расте, потому что процесс умер.
> Буквами по белому написано, что НЕ надо его использовать в production-коде.А какие средства язычок предлагает, чтобы unwrap (и ещё сотни паникующих методов) не использовали в production-коде? Может, хотя бы, warning при компиляции выводит?
#![deny(
clippy::unwrap_used,
clippy::expect_used,
clippy::panic
)]
> #![deny(
> clippy::unwrap_used,
> clippy::expect_used,
> clippy::panic
> )]Как обычно интуитивно все. Какое-то clippy образовалось. Хоть не скрепыш из офиса, и на том спасибо. Или это его так и звали? :)
То, что тебе что-то не понятно, не делает это плохим.
Эксперты, сэр!
> #![deny(
> clippy::unwrap_used,
> clippy::expect_used,
> clippy::panic
> )]Ой, что у нас тут? Стат. анализатор? Как же так: компилятор не ловит, надо еще стат. анализатор заводить? Вот сишников за такое ругают... Но тут другое, ведь так?
"Нужно просто правильно писать программы" (c) сишники, ой, то есть фанбои раста
Разумеется раст и есть виноват. Из названия unwrap не очевидно его поведение. Это и есть основная проблема.
В том же jQuery, в C# Task Unwrap имеет поведение, более или менее отражающее название, а именно разворачивает, действие обратное оборачиванию.
Тут же имеем не пойми что. Да, можно в документации написать. Но люди не помнят наизусть документацию. В книжках по C тоже всё описано, но всегда есть неожиданное поведение или недокументированное поведение.
Любой разработчик на Rust, писавший на нём программы больше одного дня, прекрасно знает, что такое unwrap и какое у него поведение.
> Любой разработчик на Rust, писавший на нём программы больше одного дня, прекрасно знает, что такое unwrap и какое у него поведение.Судя по новости - не любой.
> Судя по новости - не любой.В новости нет фактов, говорящих о том, что это было сделано с непониманием последствий.
А кто написал такое про unwrap? Видимо автор статьи, в блоге Клаудфлары не увидел такого текста.Вполне себе нормально использовать unwrap в Rust-программе в тех местах, где экономически выгоднее завершить приложение, чем делать сложную обработку ошибки. Большая часть юзерских приложений именно так и пишется - приложение падает из-за любой неожиданной ошибки (если есть проверка на ошибку). Дальше пускай юзер разбирается. В общем случае он просто запустит приложение заново. И тем более мало кто в сегменте юзерского софта занимается детальной обработкой ошибок нехватки памяти. Самый лучший способ освободить память - завершить работу приложения.
Конечно, в данном случае, использовать unwrap не стоило, т.к. слишком много тех юзеров, которым придётся разбираться со всем этим. Слишком большая ответственность на этом сервисе.
Но уже хорошо, что в коде хотя бы был этот unwrap. На другом языке программист мог бы вообще забить на проверку наличия ошибки. А тут компилятор заставил хотя бы unwrap вызывать, для простейшей проверки.
> А кто написал такое про unwrap?ну какие-то перцы из rust-lang тоже считают, что надо использовать способы получше https://github.com/rust-lang/rust-clippy/blob/24e16f992c2dda...
> где экономически выгоднее завершить приложение, чем делать сложную обработку ошибки.
и потерять пользовательские данные тоже можно, если это экономически выгодно. Так что ли? "юзерские" приложения бывают разные
> Дальше пускай юзер разбирается. В общем случае он просто запустит приложение заново
или пойдет искать другое, которое не вылетает
> И тем более мало кто в сегменте юзерского софта занимается детальной обработкой ошибок нехватки памяти
а к чему тут нехватка памяти, которой не было?
> Самый лучший способ освободить память - завершить работу приложения.
а сколько оно отдаст? Ну в плане системе станет сильно легче от дополнительных пары мегабайт, если всю память сожрало что-то другое?
> и потерять пользовательские данные тоже можно, если это экономически выгодно. Так что ли?Абсолютно верно. Коммерческие сервисы в интернете предоставляются для извлечения коммерческой выгоды, в рамках законов о коммерции. Любая коммерческая деятельность связана с рисками для обеих сторон. Если ты вступаешь в сделку не до конца осознавая всех рисков, проблема в тебе.
и много у коммерческого сервиса будет пользователей после такого? Что это за сервис такой, что не исправлять ошибку из-за которой теряются данные клиентов им более выгодно, чем делать свою работу и получать от клиентов деньги?
Например, абсолютно любой ISP постоянно теряет клиентские данные. Сети по своему дизайну теряют пакеты по множеству разных технологических причин, и дропают намеренно по экономическим причинам. Ситуацию можно значительно улучшить, но цена тебе не понравится. И тем не менее, провайдеры существуют и зарабатывают деньги.
Я так думаю, что Ржу именно для этого изобрели - какой-то кагтавый начальничек решил "сэкономить" и вместо проф.программистов на С++ решил нанять uндycятины "десяток за рупь". А чтобы качество не страдало, решил обложить их борров-чекерами. :))) (можно подумать, все ошибки программы только и состоят, что из указателей!)
Примерно так всё и было. Но проф программисты тоже оценили рюшечки раста, только вот писать и отлаживать код на нём сложнее, чем код плюсов. Ну, минимизирован целый 1 класс ошибок зато, управленцы в восторге.
Это абсолютная неправда
> Это абсолютная неправдаТвоя правда, минимизирован только в коде на раст.
> Низкая культура разработки, что поделать.ну так на нём пишут только веб-синьоры. я что-то плохо себе представляю настоящего программиста, который променяет ЯП на маркетинговый мусор
А настоящие Си-эксперты сразу допускают Cloudbleed, чего мелочиться то.
А ты не заметил, что те, кто допустил ошибку в сабже и те, кто допустил Cloudbleed - это одни и те же люди? Ну или как минимум нанятые в одну и ту же компанию. Т.е. пытаясь уколоть сишников, ты по сути просто признаешь что после перехода этих сишников на безопасный раст - они снова обоср^W облажались.
> пытаясь уколоть сишников, ты по сути просто признаешь что после перехода этих сишников на безопасный раст - они снова обоср^W облажались.Но у них больше не сливаются приватные данные из-за порчи памяти. В этом вся суть.
Приватных данных там и не должно было быть. Но да, если интернет вообще не работает, то они и не сольются, верно подммечено.
> Приватных данных там и не должно было быть.Интересно, почему ты пишешь что не должно быть, а инженеры клаудфари считают что могли быть?
> Но да, если интернет вообще не работает, то они и не сольются, верно подммечено.
Отсутствие инета замечают крайне быстро. И чинят тоже очень быстро.
А тихую дыpeнь могут и через год заметить.
> Т.е. пытаясь уколоть сишников, ты по сути просто признаешь что после
> перехода этих сишников на безопасный раст - они снова обоср^W облажались.Так мы и не отрицаем что они обоcрaлись!
Люди особо не поменялись, а других "правильных" разработчиков нет))Просто разница в последствиях:
- когда используешь современные технологии - инет ложится на несколько часов (пусть даже на один день) и потом восстанавливается.
- когда используешь дыpявое поделие из 80х - то пользовательские данные НЕЗАМЕТНО утекают (по словам той же Клаудфари, если вы ей верите) с September 22, 2016 до February 23, 2017. Сколько месяцев утечки сами посчитаете или помочь?))
> когда используешь дыpявое поделие из 80х - то пользовательские данные НЕЗАМЕТНО утекают (по словам той же Клаудфари, если вы ей верите) с September 22, 2016 до February 23, 2017. Сколько месяцев утечки сами посчитаете или помочь?))Настолько незаметно, что реальной утечки не было. Был лишь возможность.
Спасибо спецу из... Google. А если бы он не заметил, сколько бы успело утечь за эти годы?
> Настолько незаметно, что реальной утечки не было.Реальная утечка была, про это сама клаудфаря пишет
The bug was serious because the leaked memory could contain private information and because it had been cached by search engines.
blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/То что этим никто не воспользовался в открытую - не показатель отсутствия утечки))
Некому Торвальдсу (у него ещё ядро своё поговаривают) раст нравится. Что он про C++ думает широко известно, так что точно дело не в маркетинге.
Непонятно как возникла и расползалась этот tablespase
Об этом почему-то замалчивают. Ещё где-то ошибки есть, ну не руками же в терминале долбили sql команды сразу в прод, нет ведь?
> Об этом почему-то замалчивают. Ещё где-то ошибки есть, ну не руками же
> в терминале долбили sql команды сразу в прод, нет ведь?ну конечно ж не руками. Кто вообще этих рукастых на прод пустит-то.
Пайплайн континьюус дизинтеграции тщательно отработал.
если у вас в компании завелись растсеры... Выгодно поможем от них избавиться! (Мозила)
> Сбой произошёл после изменения в структуре БД, размещённой в хранилище
> ClickHouse, после которого файл с параметрами для системы
> противодействия ботам в два раза увеличился в размере.Мда... Они не тестируют миграцию БД перед выкаткой на прод?
Изменения в структуре БД это не два байта отослать, тут нужно быть аккуратным.
> тут нужно быть аккуратным.Ой, хоспади... Там раст везде он всё проверит сам и по рукам надаёт если делаешь что-то не так, не надо больше думать... да не о чем не надо больше думать. Да, даже во время миграции БД
"Краш тест защитной пленки на iPhone 4.mp4"
Офигеть, Cloudflare использует ClickHouse от Яндекса.
Это уже давно не Яндекс. И от Яндекса они сами открещиваются.
> И от Яндекса они сами открещиваются.Мы тебе поверим на слово, да, конечно. Или нет?
Просто зайди в репу. Половина комитов на сегодня упоминают наименование процессора Эльбрус
Штирлиц никогда не был так близок к провалу
ага, и браузер Vivaldi это не яндекс-браузер, слышали
>открещиваются.Типично: Затраты общие - прибыль частная.
"Оно должно само"... Да?
> "Оно должно само"... Да?Вообще-то да. И оно это сделало.
Память не испортили, за пределы буфера не вышли, сторонний код не исполнили.
Софтину в некорректном стейте грохнули. Данные не пострадали.Все как и ожидалось.
> Все как и ожидалось.могу поспорить, что клиентами не ожидалось 3 часа простоя из-за использования unwrap, который "не рекомендован для использования в рабочих проектах". Нужен анврап-чекер, который будет заставлять переписывать без анврапов
https://rust-lang.github.io/rust-clippy/stable/index.html#ex...
https://rust-lang.github.io/rust-clippy/stable/index.html#un...
и при чем тут линтер? боров-чекер неотключаемая фича компилятора, если бы его можно было отключать, то он был бы отключен в каждом первом проекте. Анврап-чекер тоже должен стать неотключаемым> for a lot of quick-and-dirty code, unwrap is a good choice, which is why this lint is Allow by default.
они даже по умолчанию считают, что ты пишешь "a lot of quick-and-dirty code", а не что-то рабочее
> они даже по умолчанию считают, что ты пишешь "a lot of quick-and-dirty
> code", а не что-то рабочееказалось бы, и в чем неправы-то?!
Ожидалось.... 3 часа простоя?!?! Походу, ты мало относишься к ИТ.Если сайт упал, мгновенно должны поднять по тревоге всех сисадминов, откатиться на рабочую версию и начинать расследование. А в клаудфларе, походу, uндycятuна за доширак работает - пока проснулись, про-д-рис-тались, едва нашли проблему, а потом, спустя сутки, нашли и "виновника торжества" - unwrap. В ПРОДАКШЕН КОДЕ. :D Всё, что вы хотели знать о квалификации cloudflare team.
откатить продакшн код на такой системе как у cf может наоборот навредить (нестабильные состояния), поэтому они сначала расследуют, потом что то делают
> поэтому они сначала расследуют, потом что то делаютДля чела айтишечка ограничена серваком и злым начальником, не требуй от него многого)))
> Если сайт упал, мгновенно должны поднять по тревоге всех сисадминов, откатиться нанет там админов. там девляпсы и констант дизинтегрейшн
> рабочую версию и начинать расследование. А в клаудфларе, походу, uндycятuна за
а невозможно откатить базу на "рабочую версию" (по этой же причине невозможно и откатить код - он уже под новую базу заточен)
А быстро найти ошибку тоже невозможно - йезычок же ж безопастный. И в логах миллион бесполезного мусора (как в нынешней разработке принято), среди которого вот за три часа зоркий глаз наконец-то разглядел "unwrap".
> спустя сутки, нашли и "виновника торжества" - unwrap. В ПРОДАКШЕН КОДЕ.
а никакого другого у клаудшмары и нет. Ну то есть стенд наверняка есть, но там базка была маленькая и на ней все помещалось.
> :D Всё, что вы хотели знать о квалификации cloudflare team.
это не про квалификацию, это про организацию работы. Оно сейчас так примерно везде кроме может быть некоторых крупных банков и страховых. Но и это неточно.
> в логах миллион бесполезного мусора (как в нынешней разработке принято)Наслаждайтесь вашими контейнерами.
В 2010 я просто заходил на сервер по ссш и смотрел, что там у меня упало, сразу же подправлял, если мог, или добавлял больше отладочной инфы. И только когда удостоверился, что проблема решена, вносил ту же правку у себя и коммитил.
Сейчас же у нас оркестрация, разделение ответственности и всякое такое. Доступа на прод нет. Доступ к логам - только через десяток впн и монструозную полурабочую графану. Ясен пень, что чтобы хоть как-то решать проблемы на проде, я буду логировать чуть ли не каждую строку кода. И то иногда система падает, не успевая залогировать причину падения, и у девопса, поддерживающего это всё чудо, приходится просить дамп консоли на момент падения.
Для протокола: 80% проблем прода вызвано не моим кодом, а криворукими сотрудниками клиента, меняющими настройки методом тыка, и внешними сервисами, предоставляемые протоколы интеграции которых задокументированв по принципу "вот вам пример жсона, дальше сами".
> В 2010 я просто заходил на сервер по ссш и смотрел, что там у меня упало, сразу же подправлял, если мог, или добавлял больше отладочной инфы. И только когда удостоверился, что проблема решена, вносил ту же правку у себя и коммитил.Дорогой, это и в 2010м было плохой практикой так-то. =)
Да и мир вообще-то с тех пор посложнее стал. В 2010м большинство были готовы закрыть глаза на небольшой даунтайм. Сейчас же всем подавай SLA чисто из девяток. А чтобы этого добиться, таки да, нужны и оркестрация, и разделение ответственности, и доступов, и централизованные логи, и много чего ещё.
> Доступ к логам - только через десяток впн и монструозную полурабочую графану.
Ну это у вас кстати девопсы плохие. Звучит как "плохо организованный доступ к логам". Это надо исправлять.
> И то иногда система падает, не успевая залогировать причину падения, и у девопса, поддерживающего это всё чудо, приходится просить дамп консоли на момент падения.
А это уже звучит как "плохо организованный сбор логов". Расскажите своим девопсам про то, что сервис не должен сам в loki писать. Вместо этого он должен писать в stdout/stderr, которые в свою очередь должны вычитываться promtail-ом. Дамп полетит при крахе в консоль, его вычитает внешний инструмент, всё будет в loki.
Ну или нормальных девопсов наймите, если у этих лапки.
Погоди! ты выше писал, что начальник тебя е6ать будет.
Это будет до "начинать расследование" или после?ps кажется у тебя максимальный опыт это заправка картриджей в бухгалтерии)
> Память не испортили, за пределы буфера не вышли, сторонний код не исполнили.и не будь клаудшмразь монополистом с договором вида "мы вам ничего и не обещали" - кто-то сейчас суматошно искал бы новую работу.
Выясняется что клиенты, кто бы мог подумать и было ли чем, хотели от них вовсе не "за пределы буфера не вышли".
там разве нет неустоек? или как это правильно называется
ну что ты, что ты - юристам клаудшмара нормально платит, это тебе не одноразовые девляпсы.Там сплошной as is и best effort.
в лучшем случае в зависимости от плана какое-то время будешь получать сервис бесплатно, как это соотносится с твоими потерями (если были) — это не их проблемы
> и не будь клаудшмразь монополистом с договором вида "мы вам ничего и не обещали" - кто-то сейчас суматошно искал бы новую работу.CrowdStrike вроде не монополисты, однако цветёт и пахнет. Тоже клиенты "поняли и простили"?
> CrowdStrike вроде не монополистыну здрасьте, как это не. Вариантов не вляпаться для крупняка считай что не было.
> Тоже клиенты "поняли и простили"?
конечно, куда ж они с подводной лодки-то денутся. Тем более им честное-пречестное пионерское было дано что впредь не повторится.
Более трёх часов простояли.
> Все как и ожидалось.Всё идёт по плану.
>Вообще-то даКогда такого будет много и в критическом проде, что делать?
Данные можно охранять, дублировать и подобное. Что делать с лежащем бизнес-сервисом?
> Данные можно охранять, дублировать и подобное. Что делать с лежащем бизнес-сервисом?охранять, дублировать, много всякой фигни можно сделать. Только бестолку. Он же лежит.
Это самая крутая новость, что я читал на опеннете!! Паблишеру громадный лайк! Потому что:1. Сразу понятна суть инцидента
2. (самое главное) приведён пример бажного кода - по его уровню можно судить о том, какого уровня uндycятuна была нанята на такую важную инфраструктуру. Да и в целом видно, насколько долго и непрофессионально чинили элементарный баг.
3. Наглядно показана несуразность Ржи и её нелепый рекламный слоган "зато безопасная память!". Как видно, программы состоят ДАЛЕКО не только из памяти! Вся программа зависит от КВАЛИФИКАЦИИ программиста и практически невозможно придумать "инструмент для дураков" (Rust), потому что только дурак и захочет им пользоваться.
> 2. (самое главное) приведён пример бажного кода - по его уровню можно
> судить о том, какого уровня uндycятuна была нанята на такую важнуючо ты к claude докопался? Или что у них там - копилот? Они даже не индусские.
покажи язык программирования, в котором физически нельзя избежать проверки результата работы функции.
> покажи язык программирования, в котором физически нельзя избежать проверки результата работы функции.C++: [[nodiscard]] в объявлении функции, компиляция с -Werror=unused-result
Конечно, сделать с результатом все равно можно что угодно, но всё-таки сделать что-то нужно обязательно.
> Конечно, сделать с результатом все равно можно что угодно, но
> всё-таки сделать что-то нужно обязательно.std::ignore = MySuperDuperNodiscard();
Что-то сделали, ога)))
unwrap()еще лучше сделали ;)
Всего лишь (пока) отсутствует предупреждение компилятора для unwrap().
>отсутствует предупреждение компилятораВсё есть. Выше показан пример с
#![deny(
clippy::unwrap_used,
clippy::expect_used,
clippy::panic
)]
где прямо запрещается использовать эти функции и макросы.
Это не было сделано по каким-то причинам.
> Всё есть. Выше показан пример с
> #![deny(
> clippy::unwrap_used,
> clippy::expect_used,
> clippy::panic
> )]
> где прямо запрещается использовать эти функции и макросы.
> Это не было сделано по каким-то причинам.Но вы же пиндите на тему статических анализаторов и MISRA C. Значит и на это можно симметрично поныть.
Так пиндят, как ты выразился, не на то, что они есть, а на то, что сишные ковбои ими не пользуется.
> Так пиндят, как ты выразился, не на то, что они есть, а
> на то, что сишные ковбои ими не пользуется.Ну так растовые - тоже как видим ваш совет не юзали и положили дохреналион сайтов на несколько часов. А разница в каком месте? :)
а можно сделать #![deny(rust)] ?
> 3. Наглядно показана несуразность Ржи и её нелепый рекламный слоган "зато безопасная
> память!". Как видно, программы состоят ДАЛЕКО не только из памяти! Вся
> программа зависит от КВАЛИФИКАЦИИ программиста и практически невозможно придумать "инструмент
> для дураков" (Rust), потому что только дурак и захочет им пользоваться.Что, операторы компиляторов на поверку оказались не инженерами? Задвигал я на форуме пространные мысли, что диды подчастую лучше делали (с учётом отсутствия нынешних инструментария и мощностей). Апологеты хрустишки и платного ПО поржали.. ну вот, безопасТное (ржавое), платное ПО тоже плохо пахнет. Клиенты привыкшие - всё сожрут.
А вот если бы писал ИИ такого не было бы!
>Обычно unwrap() применяется в процессе отладки или при написании тестового кода и не рекомендован для использования в рабочих проектах.Помогите разобраться, это Rust не позволяет писать нормальный код и из-за чего приходится прибегать к отладочным методам или это т.н. дилетанты работают в Cloudflare?
Это и есть самое нормальное поведение программы - грохнуться при любом ненормальном поведении себя.
самое нормальное поведение раст-программы - грохнуться
>грохнутьсяРождена, чтобы грохнуться в самый неподходящий момент. )
Разумеется, нет. Это заблуждение, распространённое именно в среде растоманов. Нормальные люди делают прод сервисы устойчивыми к багам и лёгкимм в диагностики, что бы эти баги быстро заметить.
Сказал бы ты так же если бы это была ошибка программы на Си? Только честно.
Если падает — норм. Мониторинг заметит что что-то не так и начнёт сигналить. Если портит память — вот это плохо, от такого мониторинга пока не придумали.
> от такого мониторинга пока не придумали.Придумали. В ARM уже есть -- MTE, для x86_64 ждем ChkTag.
> Придумали. В ARM уже есть -- MTE,С 2018 года.
Но RCE-дырень в Bluetooth-стеке платформы Android на 9.8 из 10 оно не предотвратило.
Наверное что-то пошло не так 🤷🏻♂️> для x86_64 ждем ChkTag.
Лет 5 или 10ть.
Ох уж эти смузихлебы любят выдумать серебрянную пулю которая уж точно решит все проблемы и молиться на нее)
> Но RCE-дырень в Bluetooth-стеке платформы Android на 9.8 из 10 оно не предотвратило.Не особо вникал, но емнип, там даже до работоспособного эксплойта на реальном железе дело не дошло, так что как там повел бы себя MTE -- неизвестно, неизвестно даже, задействован ли он там был.
> Не особо вникал, но емнип, там даже до работоспособного эксплойта на реальном железе дело не дошло,Ты хотел сказать "эксплойт не опубликовали")?
> так что как там повел бы себя MTE -- неизвестно,
Он должен был бы уронить приложение.
> неизвестно даже, задействован ли он там был.
И вот это основная проблема.
Если нет жесткого требования - то на на все стат анализаторы, флажки компилятора просто забьют.
Не придумали. Единственный 100% рабочий способ узнать о порче памяти — сравнение с эталоном. Но для этого надо, во-первых, иметь эталон, и, во-вторых, как-то быть уверенным, что он не испортился, что возвращается нас в самое начало задачи. Добавить немного динамики, и приходим к выводу, что надо делать как в космической отрасли: три одинаковых системы выполняющих одну и ту же задачу и сравнение результатов работы. И даже это не спасает на 100%.
Это означает, что Rust, конечно, кое от чего страхует, но задачу "думать головой при написании кода" не отменяет.
Программист взял откуда-то/вспомнил типовой пример, не прочитал/не вспомнил как работает unwrap() и получил, что при невыполненном условии, мы получаем не отработку ошибки, а у нас стоит unwrap(), который говорит "всё, звиздец, здесь сделать ничего нельзя, валим приложение в panic-у".
Программист явно недоработал. Функция возвращает Result. Вызов unwrap() внутри такой функции даже на беглый взгляд — максимально некрасиво; на ревью такое не должно было пройти. И заметим, что в отличие от ошибок, вызывающих UB в Си (вроде целочисленного переполнения), такие ошибки выявляются простым грепом.
> вызывающих UB в Си (вроде целочисленного переполнения)да ктож вас, детей, так напугал этим UB? маркетологи раста?
переполнение это фича, которая вполне используется для переxода через ноль в миллионе вещей, в те же счётчикаx пакетов
если тебе не нужно переполнение, ты просто берёшь и проверяешь, чтобы его не было, и такие случаи встречаются довольно редко и сами просятся на такие проверки
Это лишь один из примеров UB. Ох уж эти иксперты опеннета.
клоудиот выше говорил о переполнееии, киксперд
Слово "вроде" ты игнорируешь? Остановись уже.
сам придумал или подсказал кто?
> если тебе не нужно переполнение, ты просто берёшь и проверяешь, чтобы егону вот еще! s/int/unsigned int/g
ВСЕГДА ж так делаем!
(причем в процессоре вполне может быть автоматика обработки переполнений - но вот покажи-ка мне такой нескучный йезычок, который умеет ей пользоваться хоть на какой архитектуре?)
> (причем в процессоре вполне может быть автоматика обработки переполнений - но вот
> покажи-ка мне такой нескучный йезычок, который умеет ей пользоваться хоть на
> какой архитектуре?)Ну раз в процессоре инструкции и обработчики исключения/прерывания/события (понравившееся подчеркнуть) на этот счёт есть, то нескучный йоузычок - ассмеблер этого проца. А на другой архитектуре и процессор другой, может не уметь такого колдунства.
> Ну раз в процессоре инструкции и обработчики исключения/прерывания/события (понравившееся
> подчеркнуть) на этот счёт есть, то нескучный йоузычок - ассмеблер этогону и вот каждую операцию с целыми числами будем на ассемблере переписывать?
> проца. А на другой архитектуре и процессор другой, может не уметь
> такого колдунства.на какой ЖИВОЙ архитектуре a[i++] имеет физический смысл? (извинитя, сорок лет прошло, я мог перепутать с какой стороны плюсики)
А язычок все еще помнящий именно эту особенность - есть! (причем только и исключительно если *a - int, для любых других типов фокус не работал - но язык не делал различия)
> извинитя, сорок лет прошло, я мог перепутать с какой стороны плюсики)А можно поставить с любой!
ba-dum-tss
> А можно поставить с любой!ты бы хоть погуглил... хотя куда тебе...
поставить-то можно. Но смысл появления этой странной формы в одном-единственном языке (единственном на тот момент предназначенном и изначально придуманном для системного программирования) был в том, что она отражала одну специфическую архитектурную особенность конкретной машины.
Точно так же как само по себе i++; транслируется в inc [гдеонотам] - если для этого типа на этом процессоре существует inc. А не в add единички. Компиляторы еще не очень умели в оптимизации, и им приходилось вот так, вручную, подсказывать.
Но есть нюанс - архитектурная особенность работала только в одну сторону. Предполагалось, разумеется, что системный программист об этом в курсе.
> на какой ЖИВОЙ архитектуре a[i++] имеет физический смысл? (извинитя, сорок лет прошло, я
> мог перепутать с какой стороны плюсики)
> А язычок все еще помнящий именно эту особенность - есть! (причем только и исключительно
> если *a - int, для любых других типов фокус не работал - но язык не делал различия)
> Точно так же как само по себе i++; транслируется в inc [гдеонотам]
> - если для этого типа на этом процессоре существует inc.Вот теперь я и правда запутался. При чем тут тип *a? Что именно, по твоему, увеличивается здесь: a[i++] ? Написано крайне невнятно, но похоже, ты считаешь, что увеличится *(a + i)
> Вот теперь я и правда запутался. При чем тут тип *a?мля... выросло поколение. Ни гуглить, ни хотя бы посмотреть в соседний коммент (оказывается есть теперь такие процессоры, не прошло и сорока лет, как появились. Правда, такая ручная оптимизация стала совсем не нужна.)
При том он, что только с 16битными операторами в той самой PDP11 для которой и придумали тот самый Си - можно было одной и той же командой проделать операцию с памятью и автоматически сдвинуть счетчик - просто у команды косвенной адресации был такой битик. И именно эту уникальную фичу одного-единственного процессора и подразумевали ритчи с керниганом, добавив в язык причудливые конструкции. Процессор был мягко говоря небыстрым, и экономия целой одной команды (обычно внутри цикла) была важна.
В других языках того времени ничего подобного не было (потому что их не на pdp разрабатывли и не для нее).
Причем оно работало только в виде i++ и --i - если знак поставить с другой стороны, компилятор автоматически разворачивал это в отдельно i+=1; отдельно обращение к a[i]... потому что симметричной команды там не было, битик был всего один. Естественно, если тип отличался от приводимого к 16 битам - компилятор тоже генерил несколько инструкций вместо одной.Тем не менее - К&R сочли эту специфическую оптимизацию для вырожденного случая (даже для строк, кажись, не работало) достаточным поводом, чтобы сделать ее поддержку частью синтаксиса языка, которого до них не было ни в каком другом языке.
А вот целочисленное переполнение сделать частью синтаксиса - за 40 лет последователи нишмагли, лапки.
В следующей серии, детишки, я вам расскажу почему у нас строки - null terminated.
> При том он, что только с 16битными операторами в той самой PDP11
> для которой и придумали тот самый Си - можно было одной
> и той же командой проделать операцию с памятью и автоматически сдвинуть
> счетчик - просто у команды косвенной адресации был такой битик.Уважуха тебе, конечно, что ты знаешь такие мелочи, но никто не обязан помнить всё про все раритеты, вымершие примерно сразу после динозавров..
> А язычок все еще помнящий именно эту особенность - есть! (причем только и исключительно если *a - int, для любых других типов фокус не работал - но язык не делал различия)Честно-честно?
double h = 0.5;
std::print("before: {}\n", h++);
std::print("after: {}\n", h);
--------------
before: 0.5
after: 1.5Что тебя удивило в инкременте?
> Что тебя удивило в инкременте?меня удивляет ваше неумение понимать текст.
Не менее удивляет ваше неумение связно излагать ваши соображения.
>на какой ЖИВОЙ архитектуре a[i++] имеет физический смысл?ARM64:
ldr x0, [x1], #8
>>на какой ЖИВОЙ архитектуре a[i++] имеет физический смысл?
> ARM64:
>
> ldr x0, [x1], #8
>кросивое, хотя это не совсем то что имелось в виду в оригинале. (a[i] обычно ж никуда не загружается, с ним какая-то операция сразу же выполнялась)
но забавно что разработчики архитектуры об этом подумали.Интересно, знали, или это от обратного - попытка оптимизировать существующий код...
>если тебе не нужно переполнение, ты просто берёшь и проверяешь, чтобы его не былоКомпилятор берет и просто удаляет проверку, потому что переполнения не может быть никогда.
>>если тебе не нужно переполнение, ты просто берёшь и проверяешь, чтобы его не было
> Компилятор берет и просто удаляет проверку, потому что переполнения не может быть
> никогда.если его там и правда быть не может - молодец, хорошо.
Если потом ты менял код и переполнение снова может возникнуть - проверку вернут.А если компилятор нафантазировал - это ошибка конкретного компилятора. Он завтра тебе компилируя 2+2 подставит 43 - и кто тут виноват?
В отличие от s/int32/int64/g
> Программист явно недоработал.Ясно, это какие-то неправильные программисты на сиш^W расте.
> на ревью такое не должно было пройти.
но тем не менее прошло.
> И заметим, что в отличие от ошибок, вызывающих UB в Си (вроде целочисленного переполнения)
Ты хоть понимаешь что такое UB при переполнении? Беззнаковое переполнение это не UB, а wraparound, который точно задокументирован и всегда одинаковый везде! Со знаковыми типами - да, UB потому что есть три разных представления отрицательных чисел в бинарном виде. Было бы одно единственное - не было бы UB.
> Ты хоть понимаешь что такое UBМне кажется вы не понимаете что такое UB.
> Со знаковыми типами - да, UB потому что есть три разных представления отрицательных чисел
> в бинарном виде. Было бы одно единственное - не было бы UB.Поэтому его нужно было делать Implementation-defined behavior, а не UB.
А UB - это то, что никогда не должно произойти. Вот прям вообще никогда.
При наличии UB программа теряет conformance и компилятор волен сделать что угодно - выкинуть проверки, захардкодить результат, вызвать какую-то левую функцию или даже опровергнуть теорему Ферма.
Тебе какая разница как именно это называется: UB или ID? GCC, к примеру, генерирует отрицательные целые только(!) в допкоде, поэтому там такое переполнение явно определено. Если тебе и этого мало есть -fno-strict-overflow.
> GCC, к примеруА при чем тут GCC?
Тут проблема что стандарт, который должен твердо и четко описывать как оно должно быть говори "а буй его знает... вы там сами как-то разберитесь!" А компиляторы реализуют как хотят. Потому что стандарт - овно.
>> GCC, к примеру, генерирует отрицательные целые только(!) в допкоде
> А компиляторы реализуют как хотят. Потому что стандарт - овно.Блин, ну вы чего.
GCC не может не генерировать 2's complement для процессоров с 2's complement, потому что... ну... он должен генерировать правильные числа, а не неправильные. Это, блин, компилятор, он ещё и инструкции целевого процессора знает, не только его представление чисел.Стандарт до C23 держал в уме также поддержку экзотического железа с 1's complement. Больше не держит.
https://en.wikipedia.org/wiki/C23_(C_standard_revision)#Obsolete_features
если стандарт четко будет все описывать то останется как в расте только 3 процессора поддерживаются
> программа теряет conformanceНе теряет. Она перестает быть strictly conforming (но при наличии implementation-defined/unspecified - тоже перестаёт).
> и компилятор волен сделать что угодно
Здесь следует исступлённо кричать "даже отформатировать диск!!1", стуча клавиатурой по стене.
UB для начала значит, что у стандарта нет требований к поведению в этом месте. А компилятор может вместо форматирования диска, например, определить поведение. Linux без UB не работает - он нарушает прописанные в стандарте правила алиасинга указателей - это UB. И требует -fno-strict-aliasing, который определяет поведение в случае нарушений (отключает оптимизации). Но это всё равно UB с точки зрения стандарта (а других и нет, это же термин из стандарта), можно его уточнить как implementation-defined undefined behavior.
Потом видно потенциальное благое намерение - разрешить оптимизировать, исходя из отсутствия знаковых переполнений при работе программы. Программист обязуется не подавать в функцию неправильные данные, а компилятор не генерирует ветки, в которые можно попасть только с неправильными данными, убирает избыточные условия.
Ну и в конце видно, что получилась полная хрень:
- стандарт не требует компенсировать оптимизации реализацией проверок в отладочным сборках и даёт даЯЖдуЗдесьЗнаковоеПереполнение-функции с опозданием на 30 лет
- Linux и здесь отключает оптимизации (-fno-strict-overflow)
- опыт Linux говорит, что type-based alias analysis был ошибкой в стандарте
- разработчики компиляторов восприняли UB как разрешение творить дичь в случаях, когда в стандарте подразумевалась поблажка для слабых компиляторов и трудноуловимых ошибок
- стандарт тоже постоянно проваливается, когда должен дать строгость и определённость (порядок битовых полей - implementation-defined? тогда хотя бы дайте способ его выяснить заранее...)> Поэтому его нужно было делать Implementation-defined behavior, а не UB.
Судя по Linux - да, эта оптимизация не стоит того. Её надо или локально включать, или вручную через if(...) __builtin_unreachable().
> Беззнаковое переполнение это не UBЭту проблему можно пофиксить через арифметику над беззнаковыми типами, чтобы получить promotion в знаковый тип: `unsigned short - unsigned short = signed int` и т.д.
> Программист явно недоработал. Функция возвращает Result. Вызов unwrap() внутри такой функции даже на беглый взгляд — максимально некрасиво; на ревью такое не должно было пройти.Да. Забыли. Недосмотрели. Смерджили. Вот так оно бывает в реальном мире. И в результате -- веб во всём мире на 3 часа прилёг.
В других языках часто оставляют ассерты в релизном коде, потому что отладочный не всегда можно запустить на реальных данных. И это лежит на ответственности программиста. Rust заставляет делать такое, если уж кто-то не хочет обработать ошибку нормально. Метод unwrap() — аналог ассерта. То есть данный инцидент продемонстрировал преимущество Rust, чего наши лучшие эксперты Опеннета даже не попытались понять.
Произошла всепланетная презентация преимущества Rust. Чтобы никто не отвлекался от нее, пришлось отключить Интернет на три часа.
> это Rust не позволяет писать нормальный код ... или это т.н. дилетанты работают в Cloudflare?В данном случае и то, и другое. Что вы ожидали от языка, который разрабатывается 20 лет, не имеет стандартов и до сих пор unstable?
Это криворукие программисты:
1. Не понимают, к чему приводит паника в их системе
2. Не понимают, что прод надо делать надёжным, а не крешиться по мелочиПервое - непрофессионализм. Второе - отсутствие должного образования. Оба пункта лечатся прочтением Release It! автора Michael Nygard - никто лучше него пока про эту тему не написал.
Это про Си или про Раст? Дежавю какое-то.
Когда про Си говорят про ошибки работы с памятью и "просто надо уметь" - это глупость, потому что уметь это не просто, поэтому практически все программисты на Си и не умеют.Здечь же речь про простейшие основы разработки софта, уметь которые очень просто. Другое дело, что этим основам систематически не обучают, а самообучением люди из вузов занимаются не очень охотно. А набирают, увы, именно таких - из вузов.
То есть если короче: "Это другое!"
> 1. Не понимают, к чему приводит паника в их системеС чего ты взял?
Если система пришла в невалидное состояние то прекратить выполнение это вполне нормальный подход.> 2. Не понимают, что прод надо делать надёжным, а не крешиться по мелочи
Пусть лучше крешится с расследованием, чем данные утекают месяцами.
Хм.. покажите мне "надежный прод", который никогда не крашился)
А где стектрейс или логгирование?
> Обычно unwrap() применяется в процессе отладки или при написании тестового кода и не рекомендован для использования в рабочих проектах.Значит это была лишь отладка. Всё логично.
Когда ты Cloudflare и пишешь на Rust - весь мир твои тестировщики.
Ситуация конечно неприятная.
Но это все равно намного лучше чем предыдущая ошибка клаудфари.Cloudbleed was a Cloudflare buffer overflow.
Data from Cloudflare customers was leaked to all other Cloudflare customers that had access to server memory. This occurred, according to numbers provided by Cloudflare at the time, more than 18,000,000 times before the problem was corrected. Some of the leaked data was cached by search engines.И как мы видим тут просто все упало, а не "приватные данные утекли в поисковик".
Ага, лучше. Полпланеты на день оставили без интернета.
> Полпланеты на день оставили без интернета.Не на день, а на несколько часов.
> Ага, лучше.
Конечно лучше чуток посидеть без инета, чем потом твои секреты будут торговаться в даркнете.
Но васянам этого не понять.
Рассуждение "лучше чуток посидеть без инета" выдают человека ничего важнее чем Wi-Fi чайником через интернет не управлявшим. С разморозкой, сейчас вся жизнь завязана на интернет, бизнес. авиаперелеты, логистика, корпоративные сервисы - проще перечислить что не завязано. И тут Раст показал себя во всей красе. Подождем еще оценок убытков за эти несколько часов простоя бизнесов на всей планете. "чуток посидеть без инета"
Отсутствие интернета - это штатное свойство интернета. Если ваша инфраструктура, жизнь и доходы всецело зависят от наличия стабильного интернета, то это только ваша вина и ответственность. Никто не будет вам обещать "не единого разрыва".А вот защиту от утечки приватных данных вполне себе обещают, а где-то даже и обязаны предоставлять под угрозой административки или уголовки.
Если выбирать из этих двух неприятностей, то Клаудфлара "сделала" правильный выбор.
> Отсутствие интернета - это штатное свойство интернетаого. А отсутствие мозгов это штатное свойство мозгов?
> то это только ваша вина и ответственность
платишь деньги, а получаешь вину и ответственность…
> Никто не будет вам обещать "не единого разрыва".
ну таки в sla у cf гордые 100%
> Клаудфлара "сделала" правильный выбор.
тут должен быть мем с рукопожатием из "Офиса"
> Если ваша инфраструктура, жизнь и доходы всецело зависят от наличия стабильного интернета, то это только ваша вина и ответственность. Никто не будет вам обещать "не единого разрыва".Это не разрыв.
Простая функция - билеты на поезда. Ты приходишь - интернета нет. Билета, считай нет. Что делать?
> Простая функция - билеты на поезда. Ты приходишь - интернета нет. Билета,на самолет. Поезда (в одной отдельно взятой) еще в принципе можно запустить без интернетов, только на изолированной внутренней сети.
(любители электронных билетов - ну, не уедут в этот раз)С самолетами практически с _самого_начала_ пассажирской авиации - именно так. Сдохла сеть? Все, приземлились, кто куда смог, и ничего не может взлететь. Убытки измеряются миллиардами, деваться совершенно некуда. Даже если билеты по всем правилам иата оформлять на бумазецьках с копироцькой.
> cейчас вся жизнь завязана на интернет, бизнес. авиаперелеты, логистика, корпоративные сервисыИ чуваки которые всё это завязывали должны были слышать про всякие SLA.
Сомневаюсь что ты об этом слышал, но для "доступность 99.9%" допустимое время простоя будет чуть меньше 9 часов в год.
Клоудларя была недоступна 6 часов, от и до. У части клиентов меньше.Мораль сей басни такова: открывайте контракт и смотрите что подписывали.
Penalties там есть, если вам что-то должны - вам заплатят.> И тут Раст показал себя во всей красе.
Ыкспиртиза продолжается)
> Подождем еще оценок убытков за эти несколько часов простоя бизнесов на всей планете.
Можешь даже статью написать про это.
А потом сравнить с "пользовательские секреты утекали пол года" - Cloudbleed из-за buffer overflow.
За последнее по GDPR нагнут так, что мало не покажется
Я думаю у них SLA 99.999%.99.9% я сделаю на, прости Господи, локалхосте в виде mini PC или планшета. Хороший ИБП (на 24 часа) и зеркальный RAID и уже можно будет замахнуться на 99.99 %.
> Я думаю у них SLA 99.999%Очень сомневаюсь.
Т.е такое стоит денег, а не все клиенты готовы платить.
Поэтому можно сделать и б0мж версию для босоты.И да, я оказался прав, для бесплатного и Pro никаких SLA нет (но 20 баксов - это 20 баксов).
Для Бузинеса уже "100% uptime service level agreement"*
Правда в случае факапа, мы вам просто сделаем скидку на следущий период.* 6.1 For any and each Outage Period during a monthly billing period the Company will provide as a Service Credit an amount calculated as follows: Service Credit = (Outage Period minutes * Affected Customer Ratio) ÷ Scheduled Availability minutes
В Австралии человек умер... не смог дозвониться до экстренных служб из-за невозможности получить обновление ПО. Жизнь без интернета сейчас опасна для здоровья.
Такое бывает когда кодишь на яп, а он постоянно меняется на минорных версиях.
Лишь бы какую глупость ляпнуть невпопад.
Так не ляпай.
Unwrap существует давно и стабилен.
то, что раст стабильно падает, уже не новость.
> то, что раст стабильно падает, уже не новость.При явном вызове метода, который должен запаниковать в случае ошибки - конечно.
Тут проблема не в расте и т.д. ибо ошибки случаются всегда и везде. Нужно смотреть шире — проблема в монополии, когда все подвязано на один сервис.
раст агрессивно пропиxивают монополии в попытке завязать всё на себя же, если ты не заметил
А во главе этих монополий рептилоиды с Нибиру?
Нет, NSA - главное агентство по интернет-слежке в США. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre.../
"Тут проблема не в Си, ибо ошибки случаются всегда и везде."
Кто-то заставляет пользоваться этим одним сервисом? Кто-то мешает создавать альтернативные?
да. Обязательные зависимости и монополия трансканалов. Ты не можешь вот взять и прокинуть свой канал через океан.
И когда это я говорил - закончатся тупенькие проблемы с памятью - начнутся серьезные проблемы с логикой софта. И будет таких проблем все больше и больше. Расто-маны будут патчить ошибки меняя несуществующий стандарт, и "хождение по мукам" будет продолжаться вечно
Каждый раз, когда сишечник закрывает очередное CVE, в коде появляется минимум еще два переполнения буфера...
Ну и что? Полинтернета из-за этого не падает.
Каждый раз, когда сишечник закрывает очередное CVE, на опеннете появляется двадцать новых комментариев про раст. Внимание, вопрос: что приносит большую пользу?
Логика какое отношение имеет к ЯП? Эти проблемы от отсутствия опыта, а не из-за ЯП.
Верно, а значит переписывать на другом языке нет смысла.
> Эти проблемы от отсутствия опыта, а не из-за ЯП.У Клауфлары нет денег на опытных?
Так кто решение принимает чтобы платить больше и искать опытных? Это вопрос не в деньгах.
> закончатся тyпенькие проблемы с памятьюТак это же отлично что вы признаете, что раст позволит избавиться от тyпеньких проблем с памятью, от которых некоторые тyпенькие не может избавиться уже почти полвека)))
> начнутся серьезные проблемы с логикой софта.
которые у других тоже есть и с которыми пока что не научились бороться дешево.
>> закончатся тyпенькие проблемы с памятью
> Так это же отлично что вы признаете, что раст позволит избавиться от
> тyпеньких проблем с памятью, от которых некоторые тyпенькие не может избавиться
> уже почти полвека)))Нет, не признаю. А признаю что от тупеньких проблем с памятью rust приведет к асболютно тупым лжепрограммистам. Вот это 100%, что еще очень больно стрельнет по отрасли в целом.
TL;DR: понижение порога входа
> Так это же отлично что вы признаете, что раст позволит избавиться от
> тyпеньких проблем с памятью, от которых некоторые тyпенькие не может избавиться
> уже почти полвека)))...заменив их другими тупыми проблемами, с памятью и паниками? И сломав половину интернета? Ох, вау, вот это апгрейд... :)
Что у них не отнять это умение признавать ошибки и объяснять их. Понятно что маркетинговая политика, но она реально оптимальная с точки зрения репутационных рисков. Не многие компании позволяют себе такой подход. Где бы почитать как обсирается например рнк.
а ты попробуй не признать и не объяснить, почему пол интернета лежало. Тебя же конкуренты смешают с чем угодно после такого
А что у них есть конкуренты?
1. Находим в гитхабе проект ClickHouse
2. Видим на главной странице комит с именем Initial support for e2k (Elbrus-2000)
3. Угораем
Мне лень. Перескажи.
в чем юмор?
подозрение Cloudflare наш слоняра - работает на Elbrus2000
Ващето КликХаус разработка Яндекса, а его использует КлаудФлэйр
Что вы все волнуетесь? Подумаешь, авиадиспетчеры ослепли от падения сети... Зато софт у прова безопасно упал, не выдав данных.
Классика интеграции через базу данных. Энтерпрайз невер ченджес.
Напомню как в Cloudflare было раньше
https://www.opennet.dev/46100 - ошибка привела к утечке неинициализированных отрывков оперативной памяти прокси-серверов. Утечка привела к появлению в открытом доступе такой информации, как пароли, токены OAut, сессионные cookie, закрытые сообщения, ключи для доступа к API и другие конфиденциальные данные.
еще не вечер
а уже сегодня мы видим, что "снижение вероятности совершения ошибок, связанных с работой с памятью" не добавило им возможностей правильно обработать слишком большой файл
> не добавило им возможностей правильно обработать слишком большой файлОни его обработали не правильно, но при этом не слили в инет тонны приватных данных пользователей.
Видишь - уже прогресс!
вижу, что еще не вечер :)
вот вдруг они сейчас кинутся избавляться от unwrap и как заживут…
>кинутся избавляться от unwrap и как заживут…"черт его его знает, что там понастроено в меняющемся языке" - вот слова программиста Rust, на предложение отказаться от unwrap().
Почему не правильно? А что должна была сделать программа, если в "конфигурации" для её работы есть ошибка? Самостоятельно выдумать для себя конфигурацию и продолжить работать с ней?С таким подходом надо срочно бежать в репы всех консольных утилит для линуха и писать им issues, что эта дрянная поделка от лжепрограммистов не запускается, если ей передать неправильные параметры.
Мы ведь не знаем как в Клаудфларе устроен этот бот-фильтр. Может это утилита, которая при запуске читает настройки из базы, после чего работает с этими настройками. А что бы изменить настройки, надо перезапустить утилиту. В таком режиме работает очень много программ.
Хотя, они конечно же могли просто отключать работу фильтра - пропускать все запросы без проверок. Это было бы лучше, чем уронить всю систему. Но нет ничего идеального. Всё улучшается постепенно. Сейчас наверное запретят для всех критичных систем использовать uwnrap. Ещё раз напомнят разработчикам, что любые данные, поступающие снаружи, по умолчанию считаются содержащими ошибки.
> А что должна была сделать программаВроде на русском написано, что она должна была сделать: продолжить использовать прошлую версию (уже загруженную в память) и проинформировать систему мониторинга
В cf считают, что должно было быть так, зачем переходить на "мы не знаем, как оно там работает"?
> Вроде на русском написано, что она должна была сделать: продолжить использовать прошлую
> версию.Сама клаудфлара не писала такого (тем более по русски). Это кто-то в коментах предложил эту идею.
В их статье много раз упоминается configuration file и его deploy. Что и наводит на идею того как всё работает. Какая-то система выгребает данные из КликХауса, создаёт на их основе файл-конфигурации и деплоит его на все сервера с бот-фильтром. После чего, как я полагаю, перезапускаются процессы фильтра. В таком случае ни какого старого конфига уже нет ни в памяти, ни даже, скорее всего, на диске сервера.
Только когда они разобрались в причинах, они сформировали старую версию конфига, раздеплоили его и перезапустили всё.
Очень нелепое перекрытие уровня "А вот у соседа еще хуже"
Да только пароли не понятно от чего это даже не взлом. И сервис оставался работать.
кстати, тогда никого не хакнули. А утекли что-то типа «assword».
https://www.opennet.dev/46100
Вот уж напомнил как напомнил. Новость аж из 2017 года, тогда еще мамонты водились. Восемь лет переписывали на Раст, кое-как переписали с ошибками да так что опозорились на всю планету. И скорее всего не в последний раз.
Как же могут быть данные в неинициализированной памяти? Наверно она уже была инициализирована, но не очищена перед освобождением?
Сколько воды налили... и даже написали не-не, нас не взломали ))Я попробую обобщить где они обгадились. Эти покемоны, решили, что надо выгружать данные используя имя столбца в таблице. Зная имя столбца его можно записать как заголовок в выходном файле, а также выбрать все доступные значения, соответственно в файле оказалось два одинаковых заголовка на каждый столбец, и по набору данных на каждый заголовок (2 на столбец).
Запрос из статьи выбирает не данные фильтров, а метаданные!
И так вышло, что если есть две БД с одной и той же таблицей 'http_requests_features':default.http_requests_features - distributed обвертка
r0.http_requests_features - реальная таблица на шардето они обе есть в метаданных, удивительно да? не может быть ))
В общем как и в любой другой СУБД какие метаданные запросил такие и получишь, и никакие оправдания про права здесь не причем.
P.S. Формат файла не специфицирован, но размер мы ограничим, и руководствовались не наличием ресурсов явно от фонаря... сказочная секта.
Может этот код пишет нейросеть?
>Обычно unwrap() применяется в процессе отладки или при написании тестового кода и не рекомендован для использования в рабочих проектах.а после отладки код переписывать надо, да?
Нет боров чекер же под пропустил значит безопасно.
Если нужно грохнуть программу в определённом месте когда возникла ошибка (например потому, что такую ошибку в принципе программа не способна обработать корректно), то используется вызов .expect - это тот же самый .unwrap, только с пользовательским сообщением, которое должно пояснять, почему в данном месте допустилась паника. Поэтому в нормальном коде в местах ожидаемой паники принято использовать .expect, а не .unwrap. В тестах же нет смысла заморачиваться с сообщениями, поэтому часто используют .unwrap.Есть ещё один случай, когда использование .unwrap оправдано в нормальном коде: это когда нужно развернуть Result и программист знает, что в этом месте точно ошибки не случится. Например в силу того, что строчкой выше он уже проверил, что в Result пришёл вариант Ok, а не Err.
Ну надо же какой простой, однозначный язык. Прям создан чтобы не допускать ошибок.
> Например в силу того, что строчкой выше он уже проверил, что в Result пришёл вариант Ok, а не Err.и в силу того, что он зарекся переписывать этот участок кода когда-либо?
Есть ли в этом вина языка? Нет. Вина его библиотеки? Да. Unwrap всегда был частью плохого дизайна.Но то, что программисты CF не только пишут такой плохой код, но ещё и пропускают его через ревью - это показатель криворукости сотрудников.
Остаётся пожелать им внедрения ИИ в разработку, что бы хотябы он по рукам бил и объяснял, что так делать нельзя.
Это ИИ и написал. А то что боров пропустил такой код в прод как раз вина языка. Главное изменение объектов боров не пропускает, а не продовве команды пропускает. Растовая дырень.
"Боров" занимается памятью, которая тут вообще не при чём.Unwrap - это не "непродовая команда", это обычный API. Если ты не понимаешь, чем язык отличается от API - почитай интернет.
К дырам этот кривой API не приводит, только к отказам сервиса.
Но если ты хочешь сравнить этот кривой механизм обработки ошибок с Си, то в Си вообще никакого нет.
Есть ли в вина Си в ошибках связанных с памятью? Или дело все же в прокладке?
> большая часть сети доставки контента оказалась неработоспособной
> на протяжении более 3 часов.Подтверждаю. Захожу я на фороникс - а мне клаудспайварь и говорит что 500 internal error - про себя. Честно пишет что мой комп - ок, фороникс - ок, а клаудспайварь - ек! Ну хоть за честность спасибо.
> Ошибка была вызвана использованием в коде на
> языке Rust метода unwrap()Achievement unlocked: безопасТно завалить клаудспайварь по всему глобусу. Или к вопросу о майнтенансе ревью софта на Rust.
> и не рекомендован для использования в рабочих проектах
Ну конечно, девеолп софта так прямо и работает - все переписывают прод относительно девелопа. Аж два раза. Или к вопросу о пригодности софта на Rust к майнтенансу еще раз.
> Ошибка была вызвана использованием в коде на языке RustСобственно, как и ожидалось - все эти переписывания на Раст - переливание из пустого в порожнее. Уязвимости и сбои были, есть и будут, и память здесь совершенно не при чём.
> Уязвимости и сбои были, есть и будут,но именно в этом случае уязвимости не было :)
В отличие от предыдущего обоcpaмса клаудфари.> и память здесь совершенно не при чём.
Еще как причем))
Если Интернет не работает, то никакие персональные данные не утекут. Б - безопасТность!
>> Уязвимости и сбои были, есть и будут,
> но именно в этом случае уязвимости не было :)То-есть DoS атака по всей планете и завал клаудспайвари и всех сайтов за ней - это не атака? А что тогда? Внутренний саботаж? Надеюсь у всех причастных вычтут убытки и клаудфлари и клиентуры :))
Австралиец не смог набрать 000 на телефоне, потому что ПО не было обновлено.
P.S. Спасти человека не удалось :(
этот новомодный суперязык, который собирается исключительно самим собой, ещё и без доступа в интернет собрать невозможнополучается что с версии 1.81.0
https://github.com/rust-lang/rust/blob/1.81.0/src/tools/tidy...
собрать полноценный rust из официального архива релиза практически невозможно.Да, по сути, ты правильно понял. 😅
Начиная с Rust 1.81, процесс сборки сильно ужесточили в части управления зависимостями:
x.py и bootstrap Cargo теперь почти всегда используют --frozen для root-сборки, чтобы гарантировать воспроизводимость.
Любые изменения в исходниках, патчи или локальные зависимости требуют, чтобы Cargo.lock точно соответствовал состоянию исходников, иначе сборка падает с ошибкой вроде:
the lock file ... needs to be updated but --frozen was passed to prevent this
При оффлайн-сборке это особенно болезненно, потому что обновить lock через cargo update без сети невозможно.⚠️ Итог: собрать Rust из официального релиза без доступа к сети и без точного lock-файла, если есть локальные патчи, становится практически нереально.
Фактически, это означает, что для воспроизводимой оффлайн-сборки:
Нужно заранее подготовить все актуальные Cargo.lock для bootstrap, library и инструментов.
Либо патчить x.py, чтобы убрать --frozen при оффлайн root-сборке — но это официально не поддерживается.
Такое ощущение, что они какой-то велосипед у себя нагородили.
Трехколесный, для безопасности, но тут его внезапно переехал грузовик...
С квадратными колёсами для безопасности, чтобы случайно не покатился.
"Предварительная оценка убытков мировой экономики от глобального сбоя Cloudflare 18 ноября 2025 года составила примерно от 1.6 до 3.5 миллиардов долларов США. За основу был взят прецедент - сбой у CDN-провайдера Fastly в июне 2021 года. Он длился около часа и обошелся мировой экономике в $300-600 миллионов. Cloudflare значительно более крупный игрок, чем Fastly и обслуживает гораздо больший процент интернет-трафика."
> "Предварительная оценка убытков мировой экономики от глобального сбоя Cloudflare 18 ноября
> 2025 года составила примерно от 1.6 до 3.5 миллиардов долларов США.Testimonials от переписывания на Rust с его офигенной моделью обработки ошибок нехватки памяти и проч. Всего на пару гигабаксов клаудфларь и клиентов поставили? Думаю что тут даже продажа почек всем офисом - не поможет.
Их почки в безопасТности, юристы сформулировали договор очень safely: "мы не несем никакой ответственности, если что не нравится - пошли вон". Почти монопольное положение имеет свои преимущества.
На самом деле, вот этот подход с unwrap() - это вполне разумное и правильное решение. Прямо из курса "защитное программирование" - результаты любой операции надо проверять, и по умолчанию при ошибке - немедленный останов. Чтобы потом не искать, "где же эта хрень началась".Другое дело, что надо чётко отличать ошибки, которые возникли "внутри" вашей программы/системы, и по которым нужно немедленно останавливаться.
И ошибки, которые вызваны воздействием "извне" - входными данными, пакетом из сети, ошибкой доступа к файлу.
Во всех таких случаях, надо провести анализ: "какое может быть разумное поведение при обнаружении вот здесь ошибки" - и или реализовать это разумное поведение, или оставить как есть - т.е. немедленный останов.
Очень часто люди, привыкшие писать в стиле "защитного программирования" могут или ошибиться, и обработать "внешние" данные как внутренние - или просто в процессе разработки сначала оставить "падаем если что" - а потом забыть добавить реальный обработчик ошибок.
До тех пор, пока "защита" не сработает.
-----------------------
В данном случае, ошибка не в данной строчке программы - ошибка в том, что из-за падения данной программы нагнулась вся инфраструктура.
Если данная программа такая критически важная, её надо реализовывать с использованием соответствующих техник: например - диверсификации. Т.е. пишем код в нескольких экземплярах разными разработчиками, по единому подробному ТЗ, желательно на разных языках программирования - и в процессе выполнения или сравниваем результаты - или переключаемся между ними.
Как вариант - сложный компонент - и "аварийный" его вариант, который решает подмножество задач, зато надёжно.
-----------------------
По большому счёту, в будущем такие факапы будут происходить всё чаще и чаще. Система сложная, масштабная, и постоянно изменяемая - исправить все дефекты без шансов, их скорее всего добавляют быстрее, чем они правятся.
да ладно
ИИ всё исправит и быстро ;-)
> ИИ всё исправит ......ой, сетка упала... не исправит.
Без ChatGPT сеньеры не могли починить Cloudflare, а без Cloudflare не работал ChatGPT. Хорошо еще были живы деды, за ними послали самолет.
> Без ChatGPT сеньеры не могли починить Cloudflare, а без Cloudflare не работал ChatGPT. Хорошо еще были живы деды, за ними послали самолет.Хорошо, что пока самолет не управляется по ChatGPT, пришлось бы коней запрягать.
> На самом деле, вот этот подход с unwrap() - это вполне разумное и правильное решение. Прямо из курса "защитное программирование" - результаты любой операции надо проверять, и по умолчанию при ошибке - немедленный останов. Чтобы потом не искать, "где же эта хрень началась".defensive programming более широкое понятние. unwrap() - это аналог просто складываться при исключениях в других яп. Но исключений нет, а каждую ошибку запаришься обрабатывать, да и что будешь делать? Просто в лог напишешь и выйдешь в 95% случаев. Поэтому все и пишут этот глупый unwrap везде, а чем больше пишешь однообразный код, тем больше вероятность ошибиться, что мы и видим.
Совершенно согласен, видимо, ржавика так запарила необходимость явно обработать каждый Result, что он пихал свой unwrap на автомате куда попало. Тот же эффект имеет место от контролируемых исключений в java: под какой ковер их только не заметают, лишь бы избавиться от необходимости явной обработки.
Так сишники, у меня к вам вопрос: разыменноывание нулевого указателя - это UB. Код с разыменновыванием нулевого указателя в си компилируется вообще без каких либо намёков, что что-то не так. Зачем вам это нужно? Почему синтаксически некорректный код не компилируется, а с разыменновыванием - компилируется?Почему при работе с массивами возможно выйти за границу массива и попортить данные?
Зачем вам нужны негигиенические макросы?
> Зачем вам нужны негигиенические макросы?Как бы без гигиены они сильно проще. Просто сравни первоисточники: макросы и CommonLisp и Scheme и посмотри, где проще.
Но в Си макросы даже не про гигиену - это просто текстовая замена.
Пока кажется, что более верное направление - это compile time programming как в zig или современном с++.
>Как бы без гигиены они сильно проще.Проще в чём, в отстреле ноги?
>это compile time programming как в zigНестабильно
>или современном с++Как это отражается на скорости компиляции?
> Зачем вам нужны негигиенические макросы?Макросы вообще крайне плохая идея, даже если они над AST. Они добавляют в код неочевидностей и усложняют долговременное сопровождение, особенно если проект пилится во много рыл. Поди пойми, что за макрос наваял некто вася много лет назад без тщательного вчитывания в код макроса. Крайне странно, что хруст пошел по этому пути, учитывая, что на момент создания были вполне адекватные альтернативы. То, что даже для элементарного текстового вывода в хрусте нужно использовать макрос -- это абзац.
> учитывая, что на момент создания были вполне адекватные альтернативыКакие?
Да хотя бы CTFE в D, вдохновивший comptime в zig.
Функциональное прошлое требовало городить AST-макросы, видимо. Lisp -> ... -> OCaml -> Rust.> Поди пойми, что за макрос наваял
Ну, хотя бы результат подстановки можно посмотреть, правда без контроля над глубиной, как и в сишке (gcc -E).
Решил посмотреть, как printf в этих языках сделан.
Rust[1]: в макрос завёрнут комментарий /* compiler built-in */.
Zig[2]: читаемо; из минусов - нельзя одним и тем же кодом покрыть случай, когда строка формата неизвестна в compile-time.
D[3]: какая-то глупость - валидация иногда[4] делается в compile-time, но дальше вызывается[5] runtime-версия. Но compile-time валидация как будто тоже как-то вызывает[6][7] runtime-версию...
А проблема зига в D в принципе вроде решаема через `if (__ctfe) {} else {}`.
А это вообще что? Шаблон анонимного enum'а из одного члена[8], который... мда...
package(std) enum checkFormatException(alias fmt, Args...)
= { /* тело с try-catch, return и прочим */ }();[1] https://doc.rust-lang.org/src/core/macros/mod.rs.html#992
[2] https://ziglang.org/documentation/master/std/#std.Io.Writer....
[3] https://github.com/dlang/phobos/blob/master/std/stdio.d#L164...
[4] если явно инстанцировать нужный шаблон - https://godbolt.org/z/19svbTaW1
[5] https://github.com/dlang/phobos/blob/master/std/stdio.d#L1655
[6] https://github.com/dlang/phobos/blob/master/std/format/packa...
[7] https://github.com/dlang/phobos/blob/master/std/format/write...
[8] https://docarchives.dlang.io/v2.087.0/spec/enum.html#manifes...
Ну можно было не копировать 1:1, а просто развить идею.
> который... мда...Который при инстанцировании возвращает результат, тип которого выводится по return'ам?..
А валидация срабатывает в compile-time от того, что в formattedWrite подают заглушки для аргументов после строки формата - из типов получают дефолтные значения этих типов.
>Поди пойми, что за макрос наваял некто вася много лет назад без тщательного вчитывания в код макроса.Значит код на крестах, наваянный несколько лет назад, вы понять можете, а макрос - ну никак?
>Они добавляют в код неочевидностей и усложняют долговременное сопровождение, особенно если проект пилится во много рылТем не менее, в крупных проектах почему-то макросы есть. Вы не знаете почему?
>То, что даже для элементарного текстового вывода в хрусте нужно использовать макрос -- это абзац.Зато в сишке вам кроме макроса нужно ещё и парсить строку во время исполнения, с риском получить уязвимость. Вот это хорошо, вот это правильно, нет.
Забавно, что кроме макросов, местные апологеты си/крестов на остальные вопросы решили не отвечать. В следующий раз надо будет спросить, почему это программы на крестах так долго собираются.
Ну надо же, на форумах ржавиков активно обсуждаются проблемы с макросами, но анонимы с опеннета, конечно, на такие мелочи внимания не обращают:https://github.com/rust-lang/unsafe-code-guidelines/issues/278
И IDE испытывают траблы при их обработке, но кого это волнует?
https://rust-analyzer.github.io//blog/2021/11/21/ides-and-ma...
И вишенка на торте:
https://internals.rust-lang.org/t/hidden-unsafe-due-to-unint...
> Обычно unwrap() применяется в процессе отладки или при написании тестового кода и не рекомендован для использования в рабочих проектах.Не, не обычно. Unwrap в большинстве случаев применяется там, где программист знает, что ошибки не случится, но не может доказать это компилятору.
Например, ты только что создал непустой массив, отсортировал его и теперь хочешь достать последний элемент. Метод last возвращает Option, так как в общем случае массивы могут быть нулевого размера. Но в данном случае можно безопасно сделать unwrap.
Так же паники используют для неописываемых типами языка контрактов. Например, максимальная длина вектора признаков для нейросети - 100 штук, что делать при превышении - не ясно, и такой ситуации просто не должно возникнуть. Тогда в док-комментарии пишем "will panic if len > 100", чтобы вызывающий сам позаботился о гарантиях.
Но когда параметры приходят извне, из какой-нибудь базы данных, которые не зависят от этого кода, то тут уже соблюдение их корректности нужно проверять. Ну а натыкать unwrap-ов в там случае можно только, если код одноразовый, да.
> Unwrap в большинстве случаев применяется там, где программист знает, что ошибки не случится, но не может доказать это компилятору.То есть, почти нигде?
везде, достаточно доказывать компилятору. а то что при этом все вальнется, надо сказать менеджерам, что в сишке не сразу все вальнется, а потихоньку все пароли утекут. надеюсь этих растов не пустят в критические сферы чреватые техногенными катастрофами.
> везде, достаточно доказывать компилятору. а то что при этом все вальнется, надо
> сказать менеджерам, что в сишке не сразу все вальнется, а потихоньку
> все пароли утекут. надеюсь этих растов не пустят в критические сферы
> чреватые техногенными катастрофами.Везде используют unwrap = нигде не могут доказать компилятору отсутсвите ошибки, а он слишком туп.
да чел не знает про отсутствие памяти
везде unrap фигачит
че тут дальше обсуждать
То есть почти везде.
>То есть, почти нигде?Почти везде. В расте нет зависимых типов и с доказательствами всё крайне туго. Хуже только в си/крестах.
о создал непустой массив =)
уже может быть ошибка
даже malloc может не сработать
>Unwrap в большинстве случаев применяется там, где программист знает, что ошибки не случится, но не может доказать это компилятору.Просто растовики прогулявали уроки, когда преподавали зависимые типы. И за это растовиков нужно безжалостно критиковать.
Не знаю как в расте, а в скале и других функциональных языках есть NonEmpty коллекции, никаких небезопасных методов там использовать не нужно.
Никто в Cloudflare не вспомнил что программы ещё и тестировать нужно. Хоспадя. Всего-то 200 параметров лимит. Опять с хРустом сломали что-то... Гениально назвать функцию безусловного останова unwrap()
> что программы ещё и тестировать нужноРазве на расте это требуется? На расте сразу безопасные программы пишутся!
Столкнулся тут по работе с этим - лютое оно.
Тот же Fastly гораздо приятнее.