Pull to refresh
4
0

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

Send message

А чего только на рутовую?

В общем случае да, хорошие пароли на все учётки. Когда писал, в голове был кейс «виртуалка за 5 баксов специально под прокси, настроил и забыл», где нет смысла заводить простых пользователей.

На последок хотелось бы сказать самые простые и примитивные вещи [...]

Не думаю, что люди, которые копипастят гайды, способны просто взять и последовать вашим рекомендациям. К тому же они не бесспорные. Вместо всего этого я бы рекомендовал неопытным админам, которым просто нужна виртуалка для VPN:

  • не трогать дефолтные настройки sshd и фаервола, они совершенно нормальны из коробки,

  • если по какой-то причине ваш хостер настроил авторизацию по паролям, поставить на рутовую учётку хороший пароль из 30+ случайных символов.

Слово «ёкодзуна» пишется, всё-таки, через «ё». Или это умышленное искажение?

Но вообще почему только от сверхновых?

Потому что не хотелось слишком уж сильно душнить, да и тогда бы пришлось думать, а по сверхновым быстро удобная формула попалась на глаза. И постановка задачи (кубический километр льда) как будто бы прям отсылка к IceCube.

над проблемой сохранности сверхбольших объемов данных

Недавно пытался разгрести свои старые файлы — не сверхбольшие объёмы, конечно, просто каталоги «Разобрать»/«Старое»/«Не знаю куда» где-то за десять лет — и много раз ловил себя на мысли, что из всего этого барахла через условные сто лет представлять хотя бы крошечный интерес ну хотя бы для кого-то в мире будет хорошо если пара мегабайт. Возможно, человечеству, как и мне, стоит хранить поменьше барахла и поменьше о нём переживать.

становится измеримой величина ошибок, которые могут вызвать частицы, приходящие из космоса

Да тут, увы, даже ECC-память в масс-маркет никак не завезут. Давно присматриваюсь, но прям дорого как-то получается. Так и приходится жить с осознанием риска.

Кстати, а у вас случайно нет реальных цифр, сколько примерно в год на среднем сервере набегает ошибок ECC? Контроллер памяти ведь ведёт такую статистику?

раскроет правильный ответ под этим постом.

Думаю, у этой задачи нет правильного ответа, есть некая модель в голове автора, которую предлагается угадать. Если это серьёзная задача на реалистичную оценку числа событий взаимодействия излучения с веществом, не очень-то интересно его считать на серьёзных щах. Если это «задача с подвохом», не очень интересно его искать.

Если пытаться придерживаться реализма, то могу дать такую оценку на пальцах:

  • По данным Википедии, в среднем в нашей галактике случается 2-12 сверхновых в год.

  • Диаметр галактики 30 кпс, то есть до средней сверхновой получается примерно 20 кпс расстояния.

  • Тогда по формуле из Википедии кубический километра льда наловит за 7,5 млн лет примерно 10^16 достаточно злых нейтрино.

  • Влияние солнечных нейтрино за тот же срок будет пренебрежимо мало, а от других частиц «сверхразумная раса», надеюсь, уж как-нибудь защитит свой вычислительный куб.

Так что пусть будет 10^16 «ошибок». И дальше-то с этой цифрой что делать?

А также о том, что целевая аудитория нашего курса - разработчики, которым требуется выучить C++. То есть люди с ненулевым багажом знаний и опыта.

Пока дочитал статью до конца, забыл начало.

Даже безотносительно опыта и знаний студентов, я всё же считаю, что C++ относится к тем технологиям, которые нельзя нормально понять и эффективно использовать без изучения внутреннего устройства. Си прям неплохо подходится для этого: вверх по абстракциям идти проще, чем вниз.

Меня смущает, что вы говорите про разработчика на C++, но в 3-х пунктах из 4-х C++ вообще отсутствует

Так мой тезис же был про то, что C++-разработчику нужно знать и то, что не си++.

Интересно было бы послушать про ваш бэкграунд

Я бы назвал свой бэкграунд «R&D без привязки к языку», в последнее время больше с FPGA работаю. Из недавнего на си++ — математика (линейная алгебра, многопараметрическая оптимизация), микроконтроллеры (да, на C++), тестбенчи для FPGA-кода (если добавить к Verilator немного обвязки на корутинах, получает весьма неплохо по производительности и выразительности кода). Периодически пишу что-нибудь с кнопками при помощи Qt.

... ситуации, в которых ассемблерным вставкам нет альтернатив.

Например, когда вам нужно написать свой (или адаптировать вендорный) стартовый файл для нового микроконтроллера. Увести МК в прерывание. На лету переключить потоку стек. Вставить memory fence, CAS, векторную инструкцию. Часть этих кейсов закрывается интринсиками, но например, интринсиков под нужные инструкции RISC-V в компиляторе может просто ещё не быть.

Куда чаще на ассемблер приходится смотреть, чтобы хотя бы поверхностно понять, заинлайнились ли вызовы, догадался ли компилятор развернуть или векторизовать цикл, и тому подобное.

Но если вы погружаетесь именно в C++

Вот только C++ отвратителен как первый язык. Погружаться в плюсы, не имея базы приемлемой низкоуровневой базы, как по мне, неудачная идея. Ну не может компетентный C++-разработчик не представлять, во что его структуры выложатся в памяти, как компилятор реализует виртуальные функции, как раскручивается стек при исключениях, и т.д. И тут можно опираться только на ассемблер (в совсем низкоуровневых вещах) да на си без плюсов (в менее низкоуровневых).

Это будет плохой код.

На самом деле нет. Плохой код будет только в том случае, если после курса по C студент решит, что и С++ он уже знает и незачем ещё чему-то учиться. Таких людей обучать можно любым языкам в любой последовательности, с тем же результатом.

Но согласитесь, он далек от оптимума по соотношению затраченных сил/времени к результату.

(В ответ на сообщение уровнем выше)

Это зависит от того, каким вы видите результат. В моём представлении требования к компетентному C++-разработчику включают в себя:

  • знание отличий C и C++;

  • умение при необходимости программировать на C в согласии с местными идиомами (привет goto exit;);

  • умение при необходимости сориентироваться в ассемблерном листинге;

  • способность при необходимости разобраться, как написать ассемблерную вставку или линкер-скрипт, даже если это нужно всего раз в год.

Получается, этот разработчик, чтобы выучить котлин, вначале должен выучить старую java образца 2011 года?

Возможно, это непопулярная точка зрения, но да, я считаю, что разработчик на котлине так или иначе будет вынужден знать «яву образца 2011 года». Ну просто потому, что жизнь такая. Знать только котлин получится лишь до тех пор, пока всё идёт хорошо. В какой-то момент что-то сломается, что-то начнёт тормозить, потребуется интеграция с какой-нибудь библиотекой, которая вроде как на яве, но, вообще говоря, обёртка вокруг нативного кода — и всё, теперь от разработчика требуется понимать все слои абстракции: и котлин, и яву, и си, и ассемблер.

Давайте тогда вначале выучим Си.

Вообще говоря, давайте. Си — на два порядка проще плюсов, и, так или иначе, его всё равно придётся выучить. Зато после полугода интенсивной практики программирования на чистых сях у студента не останется вопросов, зачем нужны шаблоны, RAII, исключения, корутины и модули, потому что он на своей шкуре прочувствует, какого без них.

на случай, если у тебя его ещё нет в преддверии 2025 года

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

Опять пример: юзер Иванова приносит флешки с непонятным содержимым. [...] Самый хороший вариант - заблокировать ее USB-порты намертво.

Но троян или шифровальщик ведь не только на флешке можно притащить.

Как мне кажется, вариант получше — закрыть через Software Restriction Policies запуск любых эксешников и скриптов, кроме как из доверенных каталогов (закрытых от пользователей на запись, конечно) и/или подписанных доверенными подписями. Причём — вообще всем пользователям, которые не админы и не разработчики. А если есть какие-то эксешники, которые пользователем нужно запускать не из доверенных каталогов, самостоятельно подписать их своим сертификатом.

Линус Торвальдс попросил разработчиков не использовать в коммитах страдательный залог, поскольку в языке есть более благозвучный действительный.

Так переврать источник надо ещё постараться. Основная мысль Торвальса: «Ребят, я из ваших описаний пулл-реквестов собираю сводный текст мерж-коммитов, а из-за того, что вы пишете их вразнобой, я не могу просто копировать предложения, мне приходится их переписывать в другую грамматику, это тратит время!».

I try to make my merge commit messages be somewhat "cohesive", and so I often edit the pull request language to match a more standard layout and language. It's not a big deal, and often it's literally just about whitespace so that we don't have fifteen different indentation models and bullet syntaxes. I generally do it as I read through the text anyway, so it's not like it makes extra work for me.

But what does make extra work is when some maintainers use passive voice, and then I try to actively rewrite the explanation (or, admittedly, sometimes I just decide I don't care quite enough about trying to make the messages sound the same).

So I would ask maintainers to please use active voice, and preferably just imperative.

Думаю, отслеживают совпадения фото с предыдущими подачами.

Ситуацию с отечественными IP можно оценить на ресурсе https://сф-блоки.рф

Не слышал раньше об этом сайте, но попробую оценить ситуацию.

Каталог в целом производит впечатление полупустого. Одни потенциально интересные мне разделы не содержат ничего, вот прям ноль блоков:

Другие потенциально интересные мне разделы вместо хоть какой-то полезной информации содержат заглушку «Информация о %количество% СФБ скрыта разработчиками, авторизуйтесь для получения доступа», причём количество — это часто «1»:

В разеделе «Ethernet» есть один не скрытый результат, но никакой информации, кроме названия, узнать о нём без регистрации всё равно нельзя.

Чтобы зарегистрироваться на сайте, нужно предоставить почтовый адрес, телефон и ИНН компании, а также «ФИО ответственного лица».

Ситуацию оцениваю как удручающую.

Eсть ли способ сохранить веб-страницу не в смысле исходного HTML-кода [...], а в виде состояния в процессе работы, со всеми промежуточными данными джаваскрипта и вот эти всем?

Есть отличное расширение SingleFile, которое, буквально, сохраняет загруженную страницу в один файл: дампит DOM, встраивает стили, шрифты и картинки. Сохранённый файл потом можно открыть оффлайн и он выглядит один в один как страница, со всей вёрсткой и дизайном, обычно даже ресайзится корректно, но вся динамическая функциональность, ожидаемо, отваливается. Работает практически идеально, я пока что столкнулся только с одним недостатком — почему-то не сохранилось состояние чекбоксов и пользовательский ввод в поля формы.

Работает в Firefox (в каталоге расширений оно даже с плашкой «рекомендованное»), Chrome-браузерах и Safari (но в сафари я не сам тестировал).

Другой способ — выбрать название песни и объединить его с именем исполнителя и знаками/цифрами

Пожалуйста, не рекомендуйте людям подобную ерунду с серьёзным видом. То, что вы предлагаете — это лишь разновидность словарного пароля. Если атакующий в какой-то момент получит (солёный) хеш пароля, он в первую очередь будет перебирать именно такие пароли из «аугментированных» названий песен и фильмов, строчек из песен, имён персонажей и т. д. Хотя интуитивно кажется, что количество вариантов огромно и никто не сможет догадаться, как именно вы исказили название любимой песни, пространство поиска таких паролей ничтожно по сравнению с честным случайным паролем такой же длины.

UPD:
Не заметил, что это перевод. Что ж, удачи Центру кибербезопасности Дании с такими шикарными парольными рекомендациями.

Прямая ссылка на оригинал, которую автор перевода, почему-то, постеснялся привести:
https://www.cfcs.dk/globalassets/cfcs/dokumenter/vejledninger/en/cfcs-password-security-en-2023.pdf

... точно ли важно знать цвет машины и показывать пользователю ошибку, если сервис, извлекающий цвет из хранилища данных об авто, недоступен?

Пожалуйста, скажите мне кто-нибудь, что отдельный микросервис ради цвета машины — это лишь художественное преувеличение.

Не лучше ли показать машину без цвета?

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

Я не буду говорить, что удалённый рабочий стол не нужен, потому что есть консоль, ssh и tmux. Хорошего удалённого рабочего стола в линуксах нет, из-за этого люди и предпочитают работать через консоль. А нет его, потому что никто не сел и не положил свою жизнь на то, чтобы он там появился, в чём сложно кого-то винить. Вместо него в линуксе есть хорошее что-то другое.

К слову, удалённый рабочий стол сам по себе как решен?

Существуют в виде зоопарка технологий. На выбор RDP, VNC, ssh -X. Есть линуксовые клиенты TeamViewer и AnyDesk. Оно всё в целом работает, но иногда не работает.

Начну издалека: какие там есть решения для организации видеоконференций так, чтобы окно можно было транслировать во встречу, при этом ссылки в этом окне были кликабельные для всех участников, как это сделано в PowerPoint/Teams?

Мне такие решения неизвестны. Но требовать такую функциональность от открытого софта просто нечестно (и несколько мелочно). Какой открытый стандарт описывает взаимодействие между софтом для видеоконференций и софтом для показа презентаций? Я такого стандарта не знаю. Одна конкретная компания сделала такую интеграцию между своими программами, и что теперь? Что именно должны предпринять, скажем, LibreOffice и Okular, чтобы ссылки в документах открывались на видеосозвонах в Teams? Какой-то другой софт, кроме PowerPoint, вообще умеет так делать?

Чем можно организовать прозрачный проброс аппаратного средства аутентификации в удаленный рабочий стол

Во FreeRDP заявлена поддержка проброса USB и смарт-карт. Но оно может и не заработать: там то версия протокола на сервере не та, то в udev правила не прописаны, то ещё что-то. Но в целом, клиент такое умеет. Но опенсорсного RDP-сервера с поддержкой проброса USB, скорее всего, не существует.

... тем не менее, без проблем удостоверяю свою личность лицом через локальную камеру в сессии удаленного рабочего стола

Мне совсем не понятно, что вообще может удостоверять видеопоток с удалённой видеокамеры. Это точно нужная фича?

Требуется решение, работающее глобально

В вашем случае оно «работает глобально» только по той причине, что и ОС, и RDP-клиент, и RDP-сервер, и служба сертификатов, и вообще весь софт в цепочке, вплоть до серверов Azure, подконтрольны одной компание. Причём эта компания активно старается сделать удобно тем, кто внутри пузыря, и неудобно тем, кто снаружи.

Как по мне, пусть лучше оно работает менее глобально.

В продолжение моего комментария к первой части статьи.

Теперь у вас получился (модифицированный) шифр из второй главы учебника. Он тоже стойкий, причём, в более широком смысле, и тоже, в конечном итоге, сводится к классической конструкции. И, само собой, по-прежнему непрактичен.

Давайте посмотрим на ваш алгоритм:

c_i = H(\mathrm{PBKDF2}(k, s) \mathbin\Vert i) \oplus m_i.

Из тех же соображений, что приведены в моём первом комментарии, мы можем заменить его на эквивалентный по стойкости шифр

c_i = \mathrm{PRF}(\mathrm{PBKDF2} (k, s) \mathbin\Vert i) \oplus m_i,

где PRF — некая стойкая псевдослучайная функция. Однако, PBKDF2 — это тоже ни что иное, как стойкая псевдослучайная функция с настраиваемой степенью сложности. То есть, мы можем записать и так:

c_i = \mathrm{PRF}(\mathrm{PRF2}(k, s), i) \oplus m_i.

Композиция по ключу двух стойких псевдослучайных функций сама является стойкой псевдослучайной функцией, и мы можем дальше рассматривать одну функцию:

c_i = \mathrm{PRF}' (k, (s, i)) \oplus m_i.

Это выражение, в общем-то, ни что иное, как обобщённая схема блочного шифра в режиме работы со счётчиком и nonce. Она стойкая, если:

  • ключ k выбирается случайным образом,

  • для шифрования каждого нового сообщения используется уникальное значение величины s.

Вообще говоря, тут от соли не требуется быть случайной, требуется только уникальность пары (k, s). Поэтому соль тут не вектор инициализации, как написано у вас, а именно nonce. Можно использовать простой счетчик сообщений, и это не повлияет на стойкость.

Проблема с вашим шифром в том, что вы опять изобрели блочный шифр со счётчиком на основе алгоритмов, и так построенных на блочных шифрах. Кроме того, вам потребуется заново вычислять PBKDF2 (она очень медленная) после каждого сообщения, хотя если бы вы просто применили классическую схему, это нужно было бы делать только лишь при смене ключа.

Рекомендую прекратить изобретать велосипеды и пройти уже, наконец, на курсере стенфордский онлайн-курс по криптографии. Он очень классный, странно, что ещё никто не порекомендовал.

1
23 ...

Information

Rating
4,629-th
Location
Воронеж, Воронежская обл., Россия
Registered
Activity