Обновить
36
0.5

Пользователь

Отправить сообщение

Насчет GIMPS — есть более продвинутый проект на базе распределенных вычислений, PrimeGrid www.primegrid.com. Они там ищут несколько разных форм простых чисел — числа Прота, например, m*2n+1.

Хорошо бы было в таких курсах уровни сделать. Хотя бы в SQL injection. Первый уровень — поймать на апострофе. Второй — поймать на необработанном поле нестрокового типа. Третий (или какой получится) — найти место под blind SQL injection. И так далее.

Реакция на КДПВ: А если обозвать myDick как long double, длиннее станет или нет?


Про скриншоты: Мне казалось, что если у нас есть сцена, то и скриншот это фактически рендер сцены на битмап, и не более того. Отсюда всего один шаг до создания кастомного битмапа для рендера на него сцены. Или просто юнити это такой тридэ, который забыл уже, что бывают плоские битмапы? :)

При взгляде на NK-автомат у меня строгая ассоциация вида "О! PRNG!". И ничего про зависимости, гены и остальное.

Я просто оставлю это здесь...


http://bash.im/quote/392678


(Конечно, анализировать цитаты с башорга проще, просто потому, что они короче, но сам принцип!)

А что мешает сразу поднять cwnd до ожидаемого значения, если заранее известно, скажем, что интерфейс отдачи гигабитный и может быть полностью занят N соединениями (если у нас, например, веб-сервер)? То есть имеем пропускную способность 1Gb/s, размер пакета 1460, в среднем число соединений, скажем, 1000, и средняя задержка round-trip 100ms — тогда cwnd можно смело выставлять в величину, которая уже сразу будет забивать канал в 1mbps (125 kbytes/s)… кстати, получается 9… интересно. Но если число соединений ожидается малым, например, интерфейс внутри сети, клиентов мало, а запросов много, вариант поднять сразу. Возможным кандидатом кажется SQL-сервер.

TOTIPv6!


Осталось продумать, что делать в случае коллизий и расхождения мирового времени из-за того, что кто-то влез в NTP, либо просто его не настроил.

ИМХО нужно популяризировать статический анализ, в том числе и как SaaS, и сделать его доступным, скажем, инди-студиям за пару тыщщ деревянных за запуск. Они будут пользоваться им раз в полгода, найдя все опечатки, потом подсядут, а то и лучше кодить начнут — особенно если из-за какого-нибудь интересного бага, который не вылавливается силами программистов по какой-либо причине, но ловится стат.анализатором, придется его запустить, после чего какой-нибудь git blame покажет, кто сделал этот баг, и с него полетят денежки. Денежный стимул — самый серьезный в современном мире "волшебный пендаль". Если вы сможете (вопрос, к сожалению, сложный — для проверки проекта потребуется реально развернуть весь проект со всеми сторонними библиотеками, если я правильно понимаю механизм работы PVS-Studio) предоставить статический анализ как услугу, мне кажется, она будет востребована довольно большим числом людей, чтобы появилась достаточная для окупаемости конверсия.

Да об обычный if (a=b) вместо if (a==b) сколько копий сломано, что уж говорить о чем-то более сложном.

Они просто поставили его в режим аудита — посмотреть, насколько движок справляется, посчитать альфа-бета ошибки и прочее. Включить убирание теперь будет довольно легко.

В этом и цель! Точнее, конверсия будет, но ниже качеством — конвертироваться будут только те, кто не режет у себя рекламу таким образом. Так можно голосовать за качественную рекламу — что-то может даже и посмотреть, а вырвиглаз вырвать из браузера.


PS: у меня большинство рекламы выкусывает NoScript в режиме белого списка. Просто блокируются домены, выделенные под рекламу, обычно хватает.

Есть один минус у этого сайта — не дает проверить, подписан ли домен первого уровня, иначе невозможно подписать домены следующих уровней. Может, скажем, .de не подписан — и всё, никаких вам google.de или, скажем, t-mobile.de.

Хм. Познавательно :) и ссылка интересная. Обнаружил, что домен paypal.com решил внедрить у себя DNSSEC, возможно, в связи с отсутствием альтернатив.


Вообще, технология хотя и сыровата, но позволяет двойной контроль над защищенным соединением — сервер отдает сертификат, DNS TLSA+DNSSEC обеспечивает (если его проверять), что другой сертификат выдаст ошибку согласования TLS-соединения. В итоге одновременно строится доверие между клиентом и сервером с помощью ЦС, и указывается, какой именно должен быть ЦС (а то и вообще точный сертификат, какой вариант TLSA-записи настроен на этот сервер).


А вообще — как организация, эксплуатирующая сервер, может удостовериться, что при попытке зайти на их сервер клиент не попадет на поддельный сервер? Раньше было достаточно соглашения между ЦСами, что они не выдают сертификат на SSL без проверки запроса. LetsEncrypt это немного сломал, одновременно расширив границы использования SSL на довольно большой сегмент веб-сайтов. Нужна новая технология. Подняли старую (раз уж 1999 года идея), но не задействованную технологию, решили её поддерживать и форсить. Почему бы и нет? Делать-то надо сейчас.

Не помню. Кажется, в 2014м его ещё не было, но тогда я в DNS так глубоко не закапывался — есть, работает, и хватит с меня. Сейчас видел в одном месте точно, но по чужим серверам не ходил, чтобы искать у остальных. Кроме того, оба RFC поддерживают fallback на текущую конфигурацию вида permit any any, а те, кто будут себе настраивать CAA и TLSA, заботясь о своей безопасности от атаки со стороны ЦС, будут поднимать DNSSEC, иначе у них это нормально работать не будет. И думаю, что технология будет-таки развиваться — DNS для этого самый подходящий хост, так как их обязательно надо держать доступными снаружи, и обязательно защищать достаточным образом, чтобы кто попало не мог их поломать. При этом большинство организаций, которые держат хотя бы публичный DNS-сервер, уже хотя бы как-то заботятся о его безопасности. А кто не заботится, тот уже ССЗБ.

Вообще-то для этого придумали DNSSEC. Мало того, что CAA, что клиентская сторона TLSA рекомендуют использовать DNSSEC для верификации соответствующих записей.

А как насчет поделиться техническими данными, хотя бы где этот вирус держит автозапуск? Лучше, конечно, всеми, которые определяют сам вирус, но не определяют атакованного клиента.

Вот и не стоит вендору публиковать исходники и облегчать работу хакерам.

Это маркетинг. С одной стороны плохой, с другой хороший. Плохой в том, что человек, узнавший, что в его телефоне уязвимость, которую вендор патчить именно в этом телефоне не станет, может выбрать другого производителя смартфонов — благо сейчас их довольно много. Хороший в том, что найденные уязвимости с куда большей вероятностью будут пропатчены в текущих и следующих моделях того же производителя, а значит, в конечном итоге с безопасностью у производителя, открывающего код, будет получше, чем у того, который это в принципе делать не станет. К чему это приведет — неясно. Хм.


Я бы, наверно, вначале натравил относительно широкий аудит кода на модули, которые планирую опубликовать как открытый код, каких-нибудь пентестеров или подобных специалистов по поиску уязвимостей, под NDA и другими юридическими ограничениями, потом всё это позакрывал, обновил прошивки для всех актуальных моделей своего оборудования, и только потом выпускал патченый код наружу. Встало бы такое исследование в серьезную сумму, закрытие всех дыр ещё раз в десять больше, правда. Может, у хуавея столько денег нет? :-)

Интересно, если зафлудить микротик, на котором поднят IPsec в каком-то виде, пакетами IKE (TCP/500, UDP/500) — он тоже подвиснет?

нам придется беспокоиться об эффектах QED второго порядка

читаю: "об эффектах quod erat demonstrandum второго порядка", и думаю, а что это за эффекты, если QED значит "всё"? :)

Да мало ли что. По идее никакой разницы, какой именно зловред прилетает через такой скачивальщик — скачать можно любой, включая скрипт. Главное, что он вообще прилетает.

Информация

В рейтинге
2 026-й
Зарегистрирован
Активность