Ясно, спасибо за объяснения. В целом понятно, у метода есть своя область применения.
вот вы написали что «Borg ещё и сжатие умеет.» — для меня это странно, потому что это gzip уметь должен
А вот тут не всё так просто — дело в том что сжатие происходит не целыми файлами и не после того как сформирован архив, оно применяется к найденным (посредством CDC) блокам, которые ищутся в процессе разбора исходников, и каждый блок представляет собой разную часть файла, к тому же, эти блоки могут быть разной длины (потому что зависят от контента).
При таком раскладе иного способа кроме как интегрировать сжатие в основной алгоритм — увы, нет. Да, можно извратится и вызывать gzip/7z/bzip/что-скажут на каждый найденный блок, но это существенный оверхед (особенно если много сравнительно мелких блоков), хотя в самом архиваторе есть выбор различных алгоритмов.
Если упрощенно, архив от borg или restic это нечто вроде базы данных, где индексом служит хэш блока, а собственно блок может быть сжат и зашифрован перед записью. На самом деле, конечно, всё чуть сложнее (метаданные и прочая) — и именно эта сложность не позволяет легко использовать внешние процессы. Особенно это актуально когда вы восстанавливаете из архива — в этом случае архиватор выдёргивает нужные блоки из архива и собирает результат по кусочкам, да и собственно организация в виде БД позволяет на лету его реорганизацию (удаление старых снапшотов, неиспользуемых блоков) — без необходимости полностью его распаковывать для этого.
К тому же, вызов внешних процессов сильно усложняет обработку ошибок — мало утилит имеют чёткие и стабильные коды возвратов и сообщения об ошибках, т.е. если что-то идёт не так после вызова gzip, трудно понять что это — нехватка памяти, ошибка ввода-вывода, etc. Умножте это на то что каждый внешний компрессор имеет свои коды возвратов, свой набор опций для выбора метода сжатия, а сообщения об ошибках могут быть локализованы, не говоря уже о том что и первое и второе может меняться от версии к версии — и представьте сложность интеграции и поддержки, не говоря же о том что это внешние зависимости.
Да, для скриптов в оболочке это не проблема, там важно «пан или пропал» (и вылет по ошибке с надеждой что пользователь решит что делать дальше), а вот для сложной системы архивации это слишком напряжно — к примеру, завис gzip где-то на чтении/записи, и пойди пойми почему — то ли в свопе, то ли диск тормозит, то ли сеть (если NFS/SMB/CEPH), то ли ещё чего, при «ручной» обработке это всё же проще контролировать, а если учесть что архив (точнее, конкретный snapshot) можно монтировать (посредством fuse) — то вызов декомпрессора в отдельном процессе (скорее всего многократный) при чтении файлов — это уже явный перебор.
Но ведь то что публично доступно (и, собственно, позволяет экономить) — это меньшая часть от бэкапов, разве нет? Большую часть ведь составляют уникальные данные, более того, такие которые не выложить публично, и даже ещё хуже — эти данные (БД и подобное) меняются сравнительно часто.
В связи с этим вопрос — в чём выигрыш кроме как для темплейтов контейнеров или VM?
И другой момент — если у получателя проблемы с интернетом, то маленький размер архива hashget мало ему поможет — пакеты всё равно придётся тянуть (причём целиком — даже ради одного файла), хотя бы один раз, и это уже мало отличается от простого списка того что должно быть установлено (даже с учётом версий) + tar.gz от уникальных данных (конфигурация и тонкие настройки), плюс тут разве что в удобной среде для создания архивов.
И наконец — без CDC дедупликация уникального (для пользователя) контента будет не настолько эффективной, потому что изменение одного байта в одном файле приведет к новой копии всего файла (а он может оказаться очень немаленьким).
Что же до «холодных» копий — Glacier и его аналоги как раз плохи тем что доступны не мгновенно — т.е. hashget будет весьма тормозить на том что окажется в холодной копии, а если речь о данных (а не о пакетах) — то велик шанс что в Glacier вообще нет нужной версии файла.
мы просто можем один раз сделать полный бэкап со всеми пакетами, и далее опираться уже на него
А почему не использовать решения типа borg или restic? Умная дедупликация (смещение на несколько байт не порушит хэши) и минимум места для бэкапов. Borg ещё и сжатие умеет.
Бонус — никакой привязки ни к интернету, ни к пакетам, бэкапить можно всё что угодно, реально только первый бэкап может занять сравнительно много места, причём эффективно дедуплицируются даже файлы баз данных или образы дисков (благодаря CDC — Content Defined Chunking).
В качестве примера — есть система с кучей медиа-контента + база с WP + много логов веб-сервера, общий объем около 380G (на этом фоне пакеты можно просто не считать, в лучшем случае 2-3G). 30 дней бэкапов занимают около 280G, при этом любой из них — полный.
Они и не обязаны это делать — вас ведь никто не нанимал для поиска уязвимости, так что это ваши проблемы.
Сроки не жесткие по причине того, что она фиксится в 2 щелчка.
Тем кто не понимает в js и html — тоже фиксится? Вот есть абстрактный магазин ёлочных игрушек, они наняли Васю Пупкина который им сделал сайт, прошло много лет, Вася Пупкин давно уехал — кто будет фиксить? Специалиста нужно найти — а это время. Ему нужно заплатить — а это деньги. Ему нужно доверять — значит быстро не найти. Вот вы доверите фиксить баг на своём сайте кому-то незнакомому или хотя бы просто мало кому неизвестному?
То, что для вас кажется быстрым и естественным, для человека далекого от области может быть в принципе непреодолимым препятствием, и не у всех есть знакомые «тыжпрограммисты» в шаговой доступности, не говоря уже о специально нанятых сотрудниках, которые бдят 48 часов в сутки.
Ты находишь уязвимость, которую не заметили разработчики — как минимум с них спросят: «как же так?».
Не секрет что людям свойственно ошибаться, всем людям — так что ошибки это часть процесса разработки. Если о них не сообщать — они не будут пофиксены, так что нет ничего неэтичного в том чтобы их искать и сообщать. А вот требовать за это денег или обещать всем рассказать (особенно если это некритичная уязвимость) — это неэтично. Ставить какие-то сроки перед тем как рассказать, без согласования с компанией — тоже неэтично, вы ведь не знаете их ситуацию и возможности.
Я бы ещё понял если бы вы нашли серьезную уязвимость в онлайн-банкинге или там портале госуслуг — да, там это может привести к куче проблем у кучи людей, и можно попытаться подтолкнуть их исправить побыстрее — но промо-код? Извините, но это не та уязвимость ради которой стоит всё бросить и начать фиксить прям счас, если это, к примеру, не Amazon или крупный мобильный оператор (где благодаря XSS много чего плохого можно сделать).
Даже для критичных уязвимостей можно поступить более корректно — не публиковать саму уязвимость и способ её эксплуатации, а только сам факт её обнаружения — это как раз и может стать побудительной причиной для компании заняться проблемой, при этом минимизируя возможность угрозы.
Компания должна либо заботиться о своих сервисах, либо это ей выходит в копеечку.
Да, должна. Но так как считает нужным — не вам решать как именно и как быстро. Нашли, сообщили — молодец. Не дали денег? Так и не обещали вроде. Не исправили за 48 часов? Так см. выше — много причин почему. Но угроза «разоблачения» если не исправят — это как минимум подстава, потому что вы можете быть вообще единственным кто нашёл этот баг за 5-10 лет, и без вашей статьи угроза просто минимальна, а после неё — вы её увеличили на порядки. За это, кстати, по крайней мере в ЕС, можно статью получить — и это правильно.
Представьте это с другой стороны — вы ходите по улице с рядом домов и пробуете спичкой открывать двери. А потом бросаете им в почтовый ящик письмо «У вас дверь открывается спичкой, а ну быстро исправьте или я через двое суток расскажу всему интернету». А теперь, для полноты картины, представьте что кто-то так поступил с вашим домом — как вы к его поступку отнесётесь? А если вы были в недельном походе в горах и почту проверить не могли?
И ещё — я, конечно, не юрист, но мне почему кажется что если кто-то пострадает из-за опубликовайнной вами уязвимости, при этом если это произойдёт после публикации — то у них будет хороший шанс притянуть вас к ответственности (если, конечно, они вас найдут) — как раз потому что 48 часов это очень мало.
Я же этой компании отдал уязвимость бесплатно, не взяв ничего и предоставив время на исправление.
Ещё раз — если это не супер-пупер критичная уязвимость с важностью землетрясения — то вообще некорректно ставить сроки, особенно если это не угрожает вам лично. Если критичная — то нужно договариваться о сроках, почему — см. раньше.
Если за 2 дня компания не может написать одну строчку — виноваты полностью они.
Снова абстрактный магазин ёлочных игрушек, никаких своих девелоперов или сисадмина, владельцы в IT почти ни бум-бум. Бизнес семейный, вся семья в двухнедельном отпуске на Гаваях. В чём их вина? В том что у них нет денег на то чтобы постоянно отслеживать и отвечать на email? Да даже если не в отпуске — если нет специально выделенного email для таких случаев, вы понятия не имеете как много писем им приходит, сколько там спама, какова вероятность того что ваше попало в спам или ждёт своей очереди. Вспомните все эти письма в духе «я хакнул ваш рутер и теперь у меня видео как вы смотрите порно, заплатите на bitcoin или я всем расскажу» (тоже, кстати, дают 48 часов) — и поймёте как может быть воспринято ваше сообщение.
Может быть потом, когда у вас будет своя компания, или просто свой бизнес без компании, вы поймёте что не всё в этом мире идеально, и то что кажется «пустяком» на самом деле требует больше усилий, времени и ресурсов чем кажется кому-то со стороны. А в идеальном мире оно конечно, легко во всех тыкать палочкой и говорить «это неправильно» и «вы должны».
Вообще-то далеко не во всех IT компаниях сотрудники работают 24/7/365, и даже наличие специалистов не всегда даёт возможность исправить что-то за 48 часов.
Простой пример из жизни одного из крупнейших телеком-операторов — для внесения изменений в код на их сайте и последущего выкатывания на прод нужно пройти сложную бюрократическую процедуру согласования, не говоря уже тестировании, даже если речь об исправлении пунктуации в тексте, и это может занять от нескольких дней до нескольких недель(!).
Вы, конечно, можете сказать что они «сами виноваты», но это реальная жизнь — т.е. это даже при желании исполнителей просто может быть невозможно в короткие сроки, если только не обнаружена уязвимость которая приводит к чудовищным последствиям, причём она очевидна даже для ничего не понимающих в IT и уже активно эксплуатируется.
Или совсем другой вариант. Есть у меня один знакомый, он предоставляет услуги хостинга, хотя сам в этой области обладает минимальными знаниями — он банально перепродаёт услуги другого хостера, добавив чуть-чуть сервиса, и всё очень автоматизировано. Несмотря на это, ему удалось построить вполне прибыльный и стабильный бизнес, а когда нужно сделать что-то сложнее стандартного развёртывания сайта или VPS (как раз то что автоматизировано), он привлекает фрилансеров. Разумеется, у него есть сайт, где всё это продаётся, и выглядит он совсем не колхозно, создаётся впечатление что компания вполне даже IT, солидная и совсем немаленькая, хотя де-факто это один человек.
Теперь представьте, что вы находите уязвимость на его сайте, и даёте ему 48 часов. Ему нужно найти того кто делал сайт (или того кто в нём разбирается), договориться о том когда можно глянуть, как исправить — т.е. нужно и время, и деньги. Вполне может оказаться что он в отпуске, или у него любимая собака заболела, в общем масса всего что может сделать невозможным исправление в эти самые 48 часов, а тут вы со своими требованиями — ведь вы же уверены что «это IT компания», «они должны», etc. — в то время как это что ни на есть малый бизнес с минимальными знаниями, который жил себе спокойно 10 лет и никого не трогал, даже своего веб-девелопера не имеет в связи с отсутствием необходимости (ибо всё настроено и работает почти полностью автоматически).
Подумайте — этично ли в такой ситуации ставить условия и столь жёсткие сроки? А ведь большинство сайтов (в т.ч. тех кто выглядит как IT компании и предлагают хостинг) — это именно малый бизнес, у некоторых даже постоянных изредка приходящих админов нет, и просто глядя на сайт вы никогда на 100% не можете быть уверены что компания действительно способна быстро всё исправить.
Нет. Он отвечает за то чтобы найти все совпадения (не только первое), а не проверить всю строку. Без якоря он найдёт все правильные символы, всего-то, но неправильные просто проигнорирует.
Для конкретной задачи (проверка промо-кода) — вообще-то не единственное, потому что без валидации данных в шаблон попадёт мусор, пусть даже и преобразованный в html entities. Да, вреда он не нанесёт, но его там быть просто не должно.
Правильный вариант (опять-таки, для данного случая) — как раз убедиться что промо-код содержит только допустимые символы, с чем отлично справится регулярка.
Это, разумеется, не избавляет от необходимости при генерации страницы убедится что все спец-символы преобразованы в entities там где не должно быть html — но без валидации это может быть как минимум некрасиво.
Если бы ещё устройства сами могли останавливать заряд при достижении 80%… следить за зарядкой как-то не особо приятно, особенно если телефон ставится на зарядку прямо перед сном (потому что в остальное время он нужен).
Когда был патч, это ещё не считалось уязвимостью, но если судить по тому что пишут нашедшие, не так всё страшно (вроде):
To remotely exploit this vulnerability in the default configuration, an attacker must keep a connection to the vulnerable server open for 7 days (by transmitting one byte every few minutes). However, because of the extreme complexity of Exim's code, we cannot guarantee that this exploitation method is unique; faster methods may exist.
Или в переводе:
Чтобы удаленно применить эту уязвимость в конфигурации по умолчанию, злоумышленник должен держать соединение с уязвимым сервером открытым в течение 7 дней (передавая по одному байту каждые несколько минут). Однако из-за крайней сложности кода Exim, мы не можем гарантировать, что этот метод эксплуатации является уникальным; могут существовать более быстрые методы.
Что-то кажется слишком сложно для «эпидемии»… Плюс ещё нужно наличие чего-то типа «local_part_suffix = +*: -*» (для удаленного случая и наличии локального пользователя в local_part), или же exim должен быть настроен как relay.
Т.е. удаленно это провернуть должно быть довольно сложно, что, разумеется, не освобождает от необходимости обновления.
VirusTotal это всего лишь агрегатор, писать нужно автору каждого антивируса и убеждать что это ложная тревога. Антивирусов там около 60, и если хотя бы 30 из них говорят «плохой мальчик» — каковы шансы всё это разрулить, даже если вы на 200% правы?
Проблема как раз в том что Comodo использует VirusTotal как источник абсолютной истины, в то время как большинство специалистов в IT отлично понимают что не существует антивируса (или методов) на 100% исключить false positive, и на самом деле это случается чуть реже чем очень часто, равно как и c false negative.
Если бы у меня были ресурсы Comodo, то на каждую такую жалобу я бы давал задание своим сотрудникам лично проверить приложение и предоставить развернутый отчёт (с фактами, коли таковые обнаружатся), особенно если учесть что сам Comodo имеет свой собственный антивирус и соответствующих специалистов — и был бы уверен что клиенты получают то за что платят, а не филькину грамоту.
Фактически вы обвиняете автора в том что его приложение — malware, при том что ни лично вы, ни CA этого не проверяли — вы слепо следуете тому что так утверждают совсем не идеальные антивирусы.
Поймите простую вещь — если вы что-то утверждаете, будьте готовы нести ответственность за это, в противном случае, даже если закон (и «устоявшиеся практики бизнеса») на вашей стороне, ничего хорошего, кроме плохого, вы не получите в качестве реакции.
И пока вы не провели соответствующее экспертное расследование — таки да, любые обвинения голословны.
Думаю, если бы кто-то на вас настучал что вы храните наркотики (в то время как это не так), с последующими маски-шоу, вы бы сильно возмущались и вряд-ли посчитали бы действия правоохранителей правомерными — так в чём же разница в данной ситуации? Те же маски-шоу, только в цифровом виде, по ничем не подтвержденному стуку.
Если VirusTotal не упомянут как возможное основание для определения статуса «malware», то грош ему цена, и доказательством это быть не может (чисто формально).
Я не юрист, но думаю любой суд с этим согласится — для того чтобы что-то признать malware, нужно доказать как минимум намерение и функциональность, чего явно нет в случае софта автора, а экспертной оценки явно не проводилось.
Эдак и Task Scheduler можно malware обозвать — там же можно создать task который файлы будет удалять, без явного действия пользователя.
В ЕС, равно как и в США, создание или распостранение malware является уголовным преступлением, а в уголовном праве действует презумпция невиновности (в отличие от гражданского).
Comodo (посредством реселлера) фактически обвинил автора в уголовном преступлении, а вот как раз это нужно доказывать даже в ЕС и США.
Будь у автора время, желание и деньги на адвокатов, он бы мог подать на Comodo в суд и с вероятностью 99% выиграть процесс, проиграть он его мог бы только если в самом договоре где-то мелким текстом упомянут VirusTotal или нечто аналогичное. Увы, затраты на суд несоразмеримы с нанесенным ущербом (в большинстве аналогичных случаев) — именно это «спасает» Comodo.
Я почему-то уверен что окажись в подобной ситуации какая-нибудь известная и мощная компания, с популярным софтом у которого отозвали бы сертификат, Comodo шустренько бы «дал заднюю» и извинился за ошибку.
именно так же банковские проверки AML блокируют счета и просят клиентов уйти в другие банки
Есть небольшой нюанс с этой аналогией. Банк должен:
— сослаться на конкретные основания для блокировки;
— дать клиенту возможность доказать свою правоту;
— компенсировать клиенту прямой ущерб если банк оказался неправ.
У меня была ситуация когда банк заблокировал мой счёт потому что их письмо мне вернулось с пометкой «адресат не проживает по адресу» (косяк почты), пришлось явится к ним и с паспортом и регистрацией для опровержения. За эти дни (меня даже не проинформировали о блокировке, хотя телефон им был известен) у меня были отменены несколько транзакций и я попал на штрафные санкции (прямой ущерб) — всё это банк мне компенсировал.
В данном же случае, Comodo просто тихо слился — благо он не банк и не обязан отвечать за свои косяки (увы), в то время как у клиента тоже могут быть прямые потери связанные с отзывом сертификата.
Жаль что деятельность CA не регулируется, обязать их расследовать такие случаи и нести ответственность было бы очень здорово, особенно за те деньги что они гребут.
Какой реальный смысл отозвать сертификат просто так и лишится клиента и продлений?
Если конкретная причина не указана — это и есть «просто так». При сотнях тысяч клиентов (если не миллионах) потеря даже тысячи клиентов — ничто для компании, уж вы-то точно знаете что затраты на издание сертификата (себестоимость) минимум на порядок ниже его цены (letencrypt это ярко продемонстрировал).
Другой косяк заключается в том что в чатах вообще бывают боты — если человек обращается за поддержкой отличной от технической, там должны быть живые люди.
В общем куда не плюнь, пока везде только косяки от Comodo (или их реселлеров), ибо клиент (автор) вообще ничего не нарушил, и не его вина что антивирусы с VirusTotal явно ошибочно посчитали его приложение вредоносным.
Как я уже упомянул выше, мошенничеством это можно назвать потому что:
— не был назван конкретный пункт правил, который был нарушен;
— не было приведено доказательство, что он нарушен.
Получая права на вождение, вы соглашаетесь соблюдать ПДД и соглашаетесь нести ответственность за их нарушение. Вас останавливает дорожный инспектор и отбирает права, ссылаясь на то что вы «нарушили ПДД» — вот примерно так поступили в Comodo. А с учётом озвученной выше причины, инспектор объяснил свои действия как «Вася Пупкин говорит что видел как вы, кажется, превысили скорость».
И с каких это пор сам факт появления в VirusTotal является гарантией того что нечто является тем чем его обзывает антивирус? Про ложные срабатывания (которые совсем нередки) в Comodo не слышали?
Порядочная компания должна дать клиенту объяснится, а не молча отказывать в услуге (причём не называя конкретной причины — не будь здесь вас, она бы осталась неизвестной, как, вероятно, и происходит в 99% остальных подобных случаев).
К тому же, в данном конкретном случае я не вижу какой из пунктов правил был нарушен — по крайней мере пока не доказано что приложение автора действительно является malware, а в списке основания для отзыва VirusTotal даже не упоминается, равно как нет и ни слова о том что считается «вредоносным программным обеспечением».
Грубо говоря, Comodo просто прикрыл свою задницу чисто на всякий случай, за счёт клиента, без проверки, потому что «нам кажется» и "миллионы мух антивирусы не могут ошибаться" — может, формально это и не мошенничество, но по сути — таки да.
Вы не проверяли все свои сборки на VirusTotal? Некоторый софт часто оказывается в категории «unwanted» или типа того, после чего начинает убиваться рядом антивирусов.
К примеру, многие утилиты Нира Софера (NirSoft) оказываются в этой категории. Вероятно, что-то подобное могло случится и у вас, кто-то настучал и в Comodo среагировали без углубления в детали.
Дайте закону повзрослеть, он ещё маленький… По сравнению с тем что было раньше — это просто гигантский шаг вперед в сфере защиты ПД, по крайней мере в ЕС.
А бабло выжимать стоит — потому что бизнесы идут на любые ухищрения чтобы отжать ПД, даже когда они не нужны, а потом они гуляют по спамерам (или просто утекают).
В любом случае, сразу не рубят и бабло не требуют — дают шанс исправиться (если явного ущерба не было, по крайней мере).
А вот тут не всё так просто — дело в том что сжатие происходит не целыми файлами и не после того как сформирован архив, оно применяется к найденным (посредством CDC) блокам, которые ищутся в процессе разбора исходников, и каждый блок представляет собой разную часть файла, к тому же, эти блоки могут быть разной длины (потому что зависят от контента).
При таком раскладе иного способа кроме как интегрировать сжатие в основной алгоритм — увы, нет. Да, можно извратится и вызывать gzip/7z/bzip/что-скажут на каждый найденный блок, но это существенный оверхед (особенно если много сравнительно мелких блоков), хотя в самом архиваторе есть выбор различных алгоритмов.
Если упрощенно, архив от borg или restic это нечто вроде базы данных, где индексом служит хэш блока, а собственно блок может быть сжат и зашифрован перед записью. На самом деле, конечно, всё чуть сложнее (метаданные и прочая) — и именно эта сложность не позволяет легко использовать внешние процессы. Особенно это актуально когда вы восстанавливаете из архива — в этом случае архиватор выдёргивает нужные блоки из архива и собирает результат по кусочкам, да и собственно организация в виде БД позволяет на лету его реорганизацию (удаление старых снапшотов, неиспользуемых блоков) — без необходимости полностью его распаковывать для этого.
К тому же, вызов внешних процессов сильно усложняет обработку ошибок — мало утилит имеют чёткие и стабильные коды возвратов и сообщения об ошибках, т.е. если что-то идёт не так после вызова gzip, трудно понять что это — нехватка памяти, ошибка ввода-вывода, etc. Умножте это на то что каждый внешний компрессор имеет свои коды возвратов, свой набор опций для выбора метода сжатия, а сообщения об ошибках могут быть локализованы, не говоря уже о том что и первое и второе может меняться от версии к версии — и представьте сложность интеграции и поддержки, не говоря же о том что это внешние зависимости.
Да, для скриптов в оболочке это не проблема, там важно «пан или пропал» (и вылет по ошибке с надеждой что пользователь решит что делать дальше), а вот для сложной системы архивации это слишком напряжно — к примеру, завис gzip где-то на чтении/записи, и пойди пойми почему — то ли в свопе, то ли диск тормозит, то ли сеть (если NFS/SMB/CEPH), то ли ещё чего, при «ручной» обработке это всё же проще контролировать, а если учесть что архив (точнее, конкретный snapshot) можно монтировать (посредством fuse) — то вызов декомпрессора в отдельном процессе (скорее всего многократный) при чтении файлов — это уже явный перебор.
В связи с этим вопрос — в чём выигрыш кроме как для темплейтов контейнеров или VM?
И другой момент — если у получателя проблемы с интернетом, то маленький размер архива hashget мало ему поможет — пакеты всё равно придётся тянуть (причём целиком — даже ради одного файла), хотя бы один раз, и это уже мало отличается от простого списка того что должно быть установлено (даже с учётом версий) + tar.gz от уникальных данных (конфигурация и тонкие настройки), плюс тут разве что в удобной среде для создания архивов.
И наконец — без CDC дедупликация уникального (для пользователя) контента будет не настолько эффективной, потому что изменение одного байта в одном файле приведет к новой копии всего файла (а он может оказаться очень немаленьким).
Что же до «холодных» копий — Glacier и его аналоги как раз плохи тем что доступны не мгновенно — т.е. hashget будет весьма тормозить на том что окажется в холодной копии, а если речь о данных (а не о пакетах) — то велик шанс что в Glacier вообще нет нужной версии файла.
А почему не использовать решения типа borg или restic? Умная дедупликация (смещение на несколько байт не порушит хэши) и минимум места для бэкапов. Borg ещё и сжатие умеет.
Бонус — никакой привязки ни к интернету, ни к пакетам, бэкапить можно всё что угодно, реально только первый бэкап может занять сравнительно много места, причём эффективно дедуплицируются даже файлы баз данных или образы дисков (благодаря CDC — Content Defined Chunking).
В качестве примера — есть система с кучей медиа-контента + база с WP + много логов веб-сервера, общий объем около 380G (на этом фоне пакеты можно просто не считать, в лучшем случае 2-3G). 30 дней бэкапов занимают около 280G, при этом любой из них — полный.
Они и не обязаны это делать — вас ведь никто не нанимал для поиска уязвимости, так что это ваши проблемы.
Тем кто не понимает в js и html — тоже фиксится? Вот есть абстрактный магазин ёлочных игрушек, они наняли Васю Пупкина который им сделал сайт, прошло много лет, Вася Пупкин давно уехал — кто будет фиксить? Специалиста нужно найти — а это время. Ему нужно заплатить — а это деньги. Ему нужно доверять — значит быстро не найти. Вот вы доверите фиксить баг на своём сайте кому-то незнакомому или хотя бы просто мало кому неизвестному?
То, что для вас кажется быстрым и естественным, для человека далекого от области может быть в принципе непреодолимым препятствием, и не у всех есть знакомые «тыжпрограммисты» в шаговой доступности, не говоря уже о специально нанятых сотрудниках, которые бдят 48 часов в сутки.
Не секрет что людям свойственно ошибаться, всем людям — так что ошибки это часть процесса разработки. Если о них не сообщать — они не будут пофиксены, так что нет ничего неэтичного в том чтобы их искать и сообщать. А вот требовать за это денег или обещать всем рассказать (особенно если это некритичная уязвимость) — это неэтично. Ставить какие-то сроки перед тем как рассказать, без согласования с компанией — тоже неэтично, вы ведь не знаете их ситуацию и возможности.
Я бы ещё понял если бы вы нашли серьезную уязвимость в онлайн-банкинге или там портале госуслуг — да, там это может привести к куче проблем у кучи людей, и можно попытаться подтолкнуть их исправить побыстрее — но промо-код? Извините, но это не та уязвимость ради которой стоит всё бросить и начать фиксить прям счас, если это, к примеру, не Amazon или крупный мобильный оператор (где благодаря XSS много чего плохого можно сделать).
Даже для критичных уязвимостей можно поступить более корректно — не публиковать саму уязвимость и способ её эксплуатации, а только сам факт её обнаружения — это как раз и может стать побудительной причиной для компании заняться проблемой, при этом минимизируя возможность угрозы.
Да, должна. Но так как считает нужным — не вам решать как именно и как быстро. Нашли, сообщили — молодец. Не дали денег? Так и не обещали вроде. Не исправили за 48 часов? Так см. выше — много причин почему. Но угроза «разоблачения» если не исправят — это как минимум подстава, потому что вы можете быть вообще единственным кто нашёл этот баг за 5-10 лет, и без вашей статьи угроза просто минимальна, а после неё — вы её увеличили на порядки. За это, кстати, по крайней мере в ЕС, можно статью получить — и это правильно.
Представьте это с другой стороны — вы ходите по улице с рядом домов и пробуете спичкой открывать двери. А потом бросаете им в почтовый ящик письмо «У вас дверь открывается спичкой, а ну быстро исправьте или я через двое суток расскажу всему интернету». А теперь, для полноты картины, представьте что кто-то так поступил с вашим домом — как вы к его поступку отнесётесь? А если вы были в недельном походе в горах и почту проверить не могли?
И ещё — я, конечно, не юрист, но мне почему кажется что если кто-то пострадает из-за опубликовайнной вами уязвимости, при этом если это произойдёт после публикации — то у них будет хороший шанс притянуть вас к ответственности (если, конечно, они вас найдут) — как раз потому что 48 часов это очень мало.
Ещё раз — если это не супер-пупер критичная уязвимость с важностью землетрясения — то вообще некорректно ставить сроки, особенно если это не угрожает вам лично. Если критичная — то нужно договариваться о сроках, почему — см. раньше.
Снова абстрактный магазин ёлочных игрушек, никаких своих девелоперов или сисадмина, владельцы в IT почти ни бум-бум. Бизнес семейный, вся семья в двухнедельном отпуске на Гаваях. В чём их вина? В том что у них нет денег на то чтобы постоянно отслеживать и отвечать на email? Да даже если не в отпуске — если нет специально выделенного email для таких случаев, вы понятия не имеете как много писем им приходит, сколько там спама, какова вероятность того что ваше попало в спам или ждёт своей очереди. Вспомните все эти письма в духе «я хакнул ваш рутер и теперь у меня видео как вы смотрите порно, заплатите на bitcoin или я всем расскажу» (тоже, кстати, дают 48 часов) — и поймёте как может быть воспринято ваше сообщение.
Может быть потом, когда у вас будет своя компания, или просто свой бизнес без компании, вы поймёте что не всё в этом мире идеально, и то что кажется «пустяком» на самом деле требует больше усилий, времени и ресурсов чем кажется кому-то со стороны. А в идеальном мире оно конечно, легко во всех тыкать палочкой и говорить «это неправильно» и «вы должны».
Простой пример из жизни одного из крупнейших телеком-операторов — для внесения изменений в код на их сайте и последущего выкатывания на прод нужно пройти сложную бюрократическую процедуру согласования, не говоря уже тестировании, даже если речь об исправлении пунктуации в тексте, и это может занять от нескольких дней до нескольких недель(!).
Вы, конечно, можете сказать что они «сами виноваты», но это реальная жизнь — т.е. это даже при желании исполнителей просто может быть невозможно в короткие сроки, если только не обнаружена уязвимость которая приводит к чудовищным последствиям, причём она очевидна даже для ничего не понимающих в IT и уже активно эксплуатируется.
Или совсем другой вариант. Есть у меня один знакомый, он предоставляет услуги хостинга, хотя сам в этой области обладает минимальными знаниями — он банально перепродаёт услуги другого хостера, добавив чуть-чуть сервиса, и всё очень автоматизировано. Несмотря на это, ему удалось построить вполне прибыльный и стабильный бизнес, а когда нужно сделать что-то сложнее стандартного развёртывания сайта или VPS (как раз то что автоматизировано), он привлекает фрилансеров. Разумеется, у него есть сайт, где всё это продаётся, и выглядит он совсем не колхозно, создаётся впечатление что компания вполне даже IT, солидная и совсем немаленькая, хотя де-факто это один человек.
Теперь представьте, что вы находите уязвимость на его сайте, и даёте ему 48 часов. Ему нужно найти того кто делал сайт (или того кто в нём разбирается), договориться о том когда можно глянуть, как исправить — т.е. нужно и время, и деньги. Вполне может оказаться что он в отпуске, или у него любимая собака заболела, в общем масса всего что может сделать невозможным исправление в эти самые 48 часов, а тут вы со своими требованиями — ведь вы же уверены что «это IT компания», «они должны», etc. — в то время как это что ни на есть малый бизнес с минимальными знаниями, который жил себе спокойно 10 лет и никого не трогал, даже своего веб-девелопера не имеет в связи с отсутствием необходимости (ибо всё настроено и работает почти полностью автоматически).
Подумайте — этично ли в такой ситуации ставить условия и столь жёсткие сроки? А ведь большинство сайтов (в т.ч. тех кто выглядит как IT компании и предлагают хостинг) — это именно малый бизнес, у некоторых даже постоянных изредка приходящих админов нет, и просто глядя на сайт вы никогда на 100% не можете быть уверены что компания действительно способна быстро всё исправить.
Правильный вариант (опять-таки, для данного случая) — как раз убедиться что промо-код содержит только допустимые символы, с чем отлично справится регулярка.
Это, разумеется, не избавляет от необходимости при генерации страницы убедится что все спец-символы преобразованы в entities там где не должно быть html — но без валидации это может быть как минимум некрасиво.
Или в переводе:
Что-то кажется слишком сложно для «эпидемии»… Плюс ещё нужно наличие чего-то типа «local_part_suffix = +*: -*» (для удаленного случая и наличии локального пользователя в local_part), или же exim должен быть настроен как relay.
Т.е. удаленно это провернуть должно быть довольно сложно, что, разумеется, не освобождает от необходимости обновления.
Проблема как раз в том что Comodo использует VirusTotal как источник абсолютной истины, в то время как большинство специалистов в IT отлично понимают что не существует антивируса (или методов) на 100% исключить false positive, и на самом деле это случается чуть реже чем очень часто, равно как и c false negative.
Если бы у меня были ресурсы Comodo, то на каждую такую жалобу я бы давал задание своим сотрудникам лично проверить приложение и предоставить развернутый отчёт (с фактами, коли таковые обнаружатся), особенно если учесть что сам Comodo имеет свой собственный антивирус и соответствующих специалистов — и был бы уверен что клиенты получают то за что платят, а не филькину грамоту.
Фактически вы обвиняете автора в том что его приложение — malware, при том что ни лично вы, ни CA этого не проверяли — вы слепо следуете тому что так утверждают совсем не идеальные антивирусы.
Поймите простую вещь — если вы что-то утверждаете, будьте готовы нести ответственность за это, в противном случае, даже если закон (и «устоявшиеся практики бизнеса») на вашей стороне, ничего хорошего, кроме плохого, вы не получите в качестве реакции.
И пока вы не провели соответствующее экспертное расследование — таки да, любые обвинения голословны.
Думаю, если бы кто-то на вас настучал что вы храните наркотики (в то время как это не так), с последующими маски-шоу, вы бы сильно возмущались и вряд-ли посчитали бы действия правоохранителей правомерными — так в чём же разница в данной ситуации? Те же маски-шоу, только в цифровом виде, по ничем не подтвержденному стуку.
Я не юрист, но думаю любой суд с этим согласится — для того чтобы что-то признать malware, нужно доказать как минимум намерение и функциональность, чего явно нет в случае софта автора, а экспертной оценки явно не проводилось.
Эдак и Task Scheduler можно malware обозвать — там же можно создать task который файлы будет удалять, без явного действия пользователя.
Comodo (посредством реселлера) фактически обвинил автора в уголовном преступлении, а вот как раз это нужно доказывать даже в ЕС и США.
Будь у автора время, желание и деньги на адвокатов, он бы мог подать на Comodo в суд и с вероятностью 99% выиграть процесс, проиграть он его мог бы только если в самом договоре где-то мелким текстом упомянут VirusTotal или нечто аналогичное. Увы, затраты на суд несоразмеримы с нанесенным ущербом (в большинстве аналогичных случаев) — именно это «спасает» Comodo.
Я почему-то уверен что окажись в подобной ситуации какая-нибудь известная и мощная компания, с популярным софтом у которого отозвали бы сертификат, Comodo шустренько бы «дал заднюю» и извинился за ошибку.
Есть небольшой нюанс с этой аналогией. Банк должен:
— сослаться на конкретные основания для блокировки;
— дать клиенту возможность доказать свою правоту;
— компенсировать клиенту прямой ущерб если банк оказался неправ.
У меня была ситуация когда банк заблокировал мой счёт потому что их письмо мне вернулось с пометкой «адресат не проживает по адресу» (косяк почты), пришлось явится к ним и с паспортом и регистрацией для опровержения. За эти дни (меня даже не проинформировали о блокировке, хотя телефон им был известен) у меня были отменены несколько транзакций и я попал на штрафные санкции (прямой ущерб) — всё это банк мне компенсировал.
В данном же случае, Comodo просто тихо слился — благо он не банк и не обязан отвечать за свои косяки (увы), в то время как у клиента тоже могут быть прямые потери связанные с отзывом сертификата.
Жаль что деятельность CA не регулируется, обязать их расследовать такие случаи и нести ответственность было бы очень здорово, особенно за те деньги что они гребут.
Если конкретная причина не указана — это и есть «просто так». При сотнях тысяч клиентов (если не миллионах) потеря даже тысячи клиентов — ничто для компании, уж вы-то точно знаете что затраты на издание сертификата (себестоимость) минимум на порядок ниже его цены (letencrypt это ярко продемонстрировал).
Другой косяк заключается в том что в чатах вообще бывают боты — если человек обращается за поддержкой отличной от технической, там должны быть живые люди.
В общем куда не плюнь, пока везде только косяки от Comodo (или их реселлеров), ибо клиент (автор) вообще ничего не нарушил, и не его вина что антивирусы с VirusTotal явно ошибочно посчитали его приложение вредоносным.
— не был назван конкретный пункт правил, который был нарушен;
— не было приведено доказательство, что он нарушен.
Получая права на вождение, вы соглашаетесь соблюдать ПДД и соглашаетесь нести ответственность за их нарушение. Вас останавливает дорожный инспектор и отбирает права, ссылаясь на то что вы «нарушили ПДД» — вот примерно так поступили в Comodo. А с учётом озвученной выше причины, инспектор объяснил свои действия как «Вася Пупкин говорит что видел как вы, кажется, превысили скорость».
Порядочная компания должна дать клиенту объяснится, а не молча отказывать в услуге (причём не называя конкретной причины — не будь здесь вас, она бы осталась неизвестной, как, вероятно, и происходит в 99% остальных подобных случаев).
К тому же, в данном конкретном случае я не вижу какой из пунктов правил был нарушен — по крайней мере пока не доказано что приложение автора действительно является malware, а в списке основания для отзыва VirusTotal даже не упоминается, равно как нет и ни слова о том что считается «вредоносным программным обеспечением».
Грубо говоря, Comodo просто прикрыл свою задницу чисто на всякий случай, за счёт клиента, без проверки, потому что «нам кажется» и "
миллионы мухантивирусы не могут ошибаться" — может, формально это и не мошенничество, но по сути — таки да.К примеру, многие утилиты Нира Софера (NirSoft) оказываются в этой категории. Вероятно, что-то подобное могло случится и у вас, кто-то настучал и в Comodo среагировали без углубления в детали.
А бабло выжимать стоит — потому что бизнесы идут на любые ухищрения чтобы отжать ПД, даже когда они не нужны, а потом они гуляют по спамерам (или просто утекают).
В любом случае, сразу не рубят и бабло не требуют — дают шанс исправиться (если явного ущерба не было, по крайней мере).