Козёл Горный
Надёжный пароль - это может быть плохо.
Надысь пил пиво, и была мне мысль. Если у нас есть юзвера, и они сами себе придумывают пароли, а мы им устанавливаем ограничения типа "8 знаков и обязательно с цифрами" - то значимая часть этих юзеров будет придумывать пароль, минимально подходящий под эти правила. Таким образом, если мы опасаемся брутфоса (а зачем ещё нужны сложные пароли?) а атакующему нужно сбрутить не конкретного юзверя, а хоть кого-нибудь, то ограничения пойдут атакующему на пользу.
Стоит минимальная длина 6 знаков - перебираем только 6 знаков и переходим к следующему пользователю.
Требуются обязательно буквы и цифры - перебираем варианты с 1-2 цифрами в конце, переходим к следующему.
Требуются буквы, цифры, знаки препинания, не менее 4-х разных видов - это вообще лафа. Ставлю свою недопитую бутылку пива, что хоть у одного юзера будет пароль ABCD1234!@#$. Генерируем список тупых паролей под правила и брутим только по нему.
Всё сказал. Что делать с этой мыслью я не знаю, так что нате вам её.
Блин, Хабр! Я полчаса писал комментарий на комментарий, перепроверяя каждое слово гуглежом. Нажимаю отправить — позавчерашняя статья убрана в черновики! Фу так делать!
Пишу здесь комментарий ни к селу ни к городу ни о чём.
‑--‑--‑--‑--
Современные embedded языки имеют такие правила типизации, которые позволяют в тестах перебрать все возможные варианты значений или хотя бы категории вариантов (типа как для int: -1,1,0,min_int, max_int).
В Си и других языках той эпохи в любой аргумент (указатель) любой функции может прилететь nullptr, но в большинстве функций это никак не обрабатывается, потому что программист решил, что до сюда nullptr никак не долетит. Но по правилам языка может. Из‑за этого невозможно проверить покрытие тестами всех вариантов,потому что все возможные варианты даже по задумке работать не должны.
Си это не про надёжно. Си это про быстро летает и авось не упадёт.
С++11 пришёл и сел в ту же кучу, сделав допустимым shared_ptr<MyClass> sptr(nullptr); Его, конечно, можно запретить в своём проекте, но там ещё много чего учесть придётся, в итоге модерновый С++ тоже не тестируемый язык.
Почему я докапываюсь именно до Си? Потому что бортовое ПО всех трёх самолётов, где погибли люди из‑за ошибки в ПО было написано на Си и Ada. В том числе в 2018 году. Потому что всегда ж на них писали.
Есть языки типа Coq, тестируемые полностью. Есть языки типа Rust, тестируемые желудочно достаточно. Но авиация выбрала языки, где три иконки на панели компилятора лишними не будут.
Как включить доступ к CUDA внутри контейнера Podman.
Как полагается, и на сей раз официальные инструкции не работают. А надо так.
Ставим Podman если нет.
dnf install podmanПодключаем репу и ставим Nvidia container toolkit.
wget https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo
sudo cp nvidia-container-toolkit.repo /etc/yum.repos.d/
sudo dnf update
sudo dnf nvidia-container-toolkit
В процессе dnf ругнётся на отсутствующие сертификаты, предложит скачать.Вводим в Podman параметры аккаунта на Docker Hub.
podman login docker.ioА дальше отвечаем на вопросы.Скачиваем образ заранее. Заковыка в том, что Podman может скачать только образ, которому указана полная версия. И никаких latest. Варианты смотреть на Docker Hub. Например
podman pull nvidia/cuda:12.3.1-runtime-rockylinux9Создаём конфиг Container Device Interface
sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yamlЕго есть смысл проверить (от юзера!):
nvidia-ctk cdi listНу и наконец запускаем и проверяем. Должна вылезти табличка с параметрами видеокарты, это значит что всё работает.
podman run --rm --device nvidia.com/gpu=all --security-opt=label=disable nvidia/cuda:12.3.1-runtime-rockylinux9 nvidia-smi
Вот теперь на основании этого образа можно клепать свои контейнеры.
P.S. Проверял на Nobara, это Федоры кусок, но должно работать так же на всей РэдХат-е.