Получается, этот разработчик, чтобы выучить котлин, вначале должен выучить старую 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.
Другие потенциально интересные мне разделы вместо хоть какой-то полезной информации содержат заглушку «Информация о %количество% СФБ скрыта разработчиками, авторизуйтесь для получения доступа», причём количество — это часто «1»:
Eсть ли способ сохранить веб-страницу не в смысле исходного HTML-кода [...], а в виде состояния в процессе работы, со всеми промежуточными данными джаваскрипта и вот эти всем?
Есть отличное расширение SingleFile, которое, буквально, сохраняет загруженную страницу в один файл: дампит DOM, встраивает стили, шрифты и картинки. Сохранённый файл потом можно открыть оффлайн и он выглядит один в один как страница, со всей вёрсткой и дизайном, обычно даже ресайзится корректно, но вся динамическая функциональность, ожидаемо, отваливается. Работает практически идеально, я пока что столкнулся только с одним недостатком — почему-то не сохранилось состояние чекбоксов и пользовательский ввод в поля формы.
Работает в Firefox (в каталоге расширений оно даже с плашкой «рекомендованное»), Chrome-браузерах и Safari (но в сафари я не сам тестировал).
Другой способ — выбрать название песни и объединить его с именем исполнителя и знаками/цифрами
Пожалуйста, не рекомендуйте людям подобную ерунду с серьёзным видом. То, что вы предлагаете — это лишь разновидность словарного пароля. Если атакующий в какой-то момент получит (солёный) хеш пароля, он в первую очередь будет перебирать именно такие пароли из «аугментированных» названий песен и фильмов, строчек из песен, имён персонажей и т. д. Хотя интуитивно кажется, что количество вариантов огромно и никто не сможет догадаться, как именно вы исказили название любимой песни, пространство поиска таких паролей ничтожно по сравнению с честным случайным паролем такой же длины.
UPD: Не заметил, что это перевод. Что ж, удачи Центру кибербезопасности Дании с такими шикарными парольными рекомендациями.
... точно ли важно знать цвет машины и показывать пользователю ошибку, если сервис, извлекающий цвет из хранилища данных об авто, недоступен?
Пожалуйста, скажите мне кто-нибудь, что отдельный микросервис ради цвета машины — это лишь художественное преувеличение.
Не лучше ли показать машину без цвета?
Думаю, что в реальности, всё же, этот сервис отвечает не только за цвет, но и за остальные данные о машине. Имеет ли смысл показывать пользователю машину без цвета, модели и регистрационного номера? Имхо, далеко не всегда.
Я не буду говорить, что удалённый рабочий стол не нужен, потому что есть консоль, ssh и tmux. Хорошего удалённого рабочего стола в линуксах нет, из-за этого люди и предпочитают работать через консоль. А нет его, потому что никто не сел и не положил свою жизнь на то, чтобы он там появился, в чём сложно кого-то винить. Вместо него в линуксе есть хорошее что-то другое.
К слову, удалённый рабочий стол сам по себе как решен?
Существуют в виде зоопарка технологий. На выбор RDP, VNC, ssh -X. Есть линуксовые клиенты TeamViewer и AnyDesk. Оно всё в целом работает, но иногда не работает.
Начну издалека: какие там есть решения для организации видеоконференций так, чтобы окно можно было транслировать во встречу, при этом ссылки в этом окне были кликабельные для всех участников, как это сделано в PowerPoint/Teams?
Мне такие решения неизвестны. Но требовать такую функциональность от открытого софта просто нечестно (и несколько мелочно). Какой открытый стандарт описывает взаимодействие между софтом для видеоконференций и софтом для показа презентаций? Я такого стандарта не знаю. Одна конкретная компания сделала такую интеграцию между своими программами, и что теперь? Что именно должны предпринять, скажем, LibreOffice и Okular, чтобы ссылки в документах открывались на видеосозвонах в Teams? Какой-то другой софт, кроме PowerPoint, вообще умеет так делать?
Чем можно организовать прозрачный проброс аппаратного средства аутентификации в удаленный рабочий стол
Во FreeRDP заявлена поддержка проброса USB и смарт-карт. Но оно может и не заработать: там то версия протокола на сервере не та, то в udev правила не прописаны, то ещё что-то. Но в целом, клиент такое умеет. Но опенсорсного RDP-сервера с поддержкой проброса USB, скорее всего, не существует.
... тем не менее, без проблем удостоверяю свою личность лицом через локальную камеру в сессии удаленного рабочего стола
Мне совсем не понятно, что вообще может удостоверять видеопоток с удалённой видеокамеры. Это точно нужная фича?
Требуется решение, работающее глобально
В вашем случае оно «работает глобально» только по той причине, что и ОС, и RDP-клиент, и RDP-сервер, и служба сертификатов, и вообще весь софт в цепочке, вплоть до серверов Azure, подконтрольны одной компание. Причём эта компания активно старается сделать удобно тем, кто внутри пузыря, и неудобно тем, кто снаружи.
Как по мне, пусть лучше оно работает менее глобально.
Теперь у вас получился (модифицированный) шифр из второй главы учебника. Он тоже стойкий, причём, в более широком смысле, и тоже, в конечном итоге, сводится к классической конструкции. И, само собой, по-прежнему непрактичен.
Давайте посмотрим на ваш алгоритм:
Из тех же соображений, что приведены в моём первом комментарии, мы можем заменить его на эквивалентный по стойкости шифр
где PRF — некая стойкая псевдослучайная функция. Однако, PBKDF2 — это тоже ни что иное, как стойкая псевдослучайная функция с настраиваемой степенью сложности. То есть, мы можем записать и так:
Композиция по ключу двух стойких псевдослучайных функций сама является стойкой псевдослучайной функцией, и мы можем дальше рассматривать одну функцию:
Это выражение, в общем-то, ни что иное, как обобщённая схема блочного шифра в режиме работы со счётчиком и nonce. Она стойкая, если:
ключ k выбирается случайным образом,
для шифрования каждого нового сообщения используется уникальное значение величины s.
Вообще говоря, тут от соли не требуется быть случайной, требуется только уникальность пары (k, s). Поэтому соль тут не вектор инициализации, как написано у вас, а именно nonce. Можно использовать простой счетчик сообщений, и это не повлияет на стойкость.
Проблема с вашим шифром в том, что вы опять изобрели блочный шифр со счётчиком на основе алгоритмов, и так построенных на блочных шифрах. Кроме того, вам потребуется заново вычислять PBKDF2 (она очень медленная) после каждого сообщения, хотя если бы вы просто применили классическую схему, это нужно было бы делать только лишь при смене ключа.
Рекомендую прекратить изобретать велосипеды и пройти уже, наконец, на курсере стенфордский онлайн-курс по криптографии. Он очень классный, странно, что ещё никто не порекомендовал.
Я вас, наверное, не обрадую, но вы не изобрели ничего нового или, хотя бы, нетривиального. Шифр, который вы предложили, построен по классической схеме из первой же главы учебника. Как будто бы можно даже показать его криптостойкость в некотором смысле, если потребовать соблюдение ряда дополнительных условий.
Я не профессиональный криптограф, поэтому вывод строгого доказательства со всеми нужными ссылками займёт у меня неоправданно много времени. Но приведу общую идею почему я считаю, что шифр стойкий.
Вот ваш шифр:
Давайте дополнительно потребуем, что:
ключ должен быть фиксированной битовой ширины (то есть, никаких «main key» произвольной длины!),
счётчик тоже должен быть фиксированной битовой ширины (достаточной для хранения индекса блока даже безумно длинного сообщения).
Эти дополнительные требования исключают length-extension-атаку на хеш-функцию, поэтому, интуитивно, её стойкость в этом сценарии будет эквивалентна стойкости конструкции HMAC от неё. Поэтому мы можем переписать ваш шифр на эквивалентный по стойкости:
Далее предположим, что функция построена по схеме Меркла-Дамгора (SHA-256 именно такая) и лежащая в её основе функция компрессии является криптоскойкой псевдослучайной функцией (для функций семейства SHA на данный момент не доказано обратного). Для таких хеш-функций доказано†, что является стойкой псевдослучайной функцией (PRF) относительно ключа. Следовательно, снова можем переписать шифр на эквивалентный по стойкости:
Это выражение — классический блочный шифр в режиме со счётчиком. Его стойкость доказана при условии, что:
ключ выбирается случайным образом из множества возможных ключей,
ключ используется для шифрования не более чем одного сообщения.
Этот вывод, вообще говоря, довольно очевиден с самого начала, если вспомнить, что SHA-256 построена на основе полноценного блочного шифра SHACAL-2. С тем же успехом можно было бы просто применить этот блочный шифр напрямую.
In particular, Mihir Bellare proved that HMAC is a pseudo-random function (PRF) under the sole assumption that the compression function is a PRF. [далее ссылка на PDF с публикацией]
Где ответ NULL зарезервирован и является индикатором ошибки.
Это неправда. Стандарт прямо говорит, что у memset и memcpyникакое значение не зарезервировано для индикации ошибки. То есть, ни NULL, ни какое-то ещё. Ваши функции тестируют невозможные ситуации.
The memcpy() function shall return s1; no return value is reserved to indicate an error.
И то же самое сказано на странице про memset. Для меня это выглядит так, как будто проверять, не вернули ли эти функции NULL, нет никакого смысла.
С функцией malloc() действительно другая история (и к ней у меня вопросов не было): проверять возврат на не-NULL надо, хотя на практике это не даёт гарантии того, что память реально была выделена и ею можно пользоваться без опаски.
Судя по тому, что на баннере написано «source code available» и далее по ссылкам лишь обтекаемые формулировки и нет подробностей о лицензии, исходный код они не открывают, а показывают. Видимо, «модель совместного развития» — это когда сообщество помогает делать проприетарный продукт.
Вот еще пара функций, которая мне также неоднократно пригождалась
А для чего именно вам были полезны такие memset и memcpy? Я вижу, что при некоторых значениях аргумента n они просто возвращают NULL вместо того, чтобы делать свою работу, но ума не приложу, зачем такое поведение может понадобиться в тестах.
В дикой природе эти функции никогда не сигнализируют об ошибке таким образом. Они вообще не умеют сигнализировать об ошибке, и определять, что произошла какая-то ошибка, тоже не умеют. Вызывающему их коду нет смысла проверять возвращаемое значение, потому что оно им и так известно (если функция в принципе вернула управление, а не, например, вызвала аппаратное исключение).
Кроме того, memset и memcpy — в некотором роде волшебные функции: компилятор, если увидит такую возможность, реализует их эффект прямо на месте, без вызова библиотечной функции.
Несколько лет назад, когда преподавал в университете, покупал для лаб за свои деньги полдюжины плат Lattice MachXO3L StarterKit — стоили они тогда примерно 30 баксов за штуку. Сами платы довольно приятные, но слегка спартанские: есть программатор, тактовый генератор, несколько светодиодов и DIP-свитчей и тонна GPIO — если для лабы нужно что-то ещё (например, семисегментный индикатор или угловой энкодер, до звука и видео просто не успевали дойти за семестр), студенты собирали это что-то рядом на макетках. Это занимало кучу времени, но студенты готовы заниматься чем угодно, лишь бы код не писать.
Поэтому они стараются использовать один тип плат в фиксированной конфигурации, если всего этого нельзя избежать вообще и просто показывать плату издалека.
И правильно делают, в противном случае преподаватель только тем и будет заниматься, что бегать от студента к студенту, разбираясь с их «А почему у меня не работает?!». Я бы ещё и периферию всю использовал максимально одинаковую, чтобы не получить комбинаторный взрыв у себя в голове.
Возможно, это непопулярная точка зрения, но да, я считаю, что разработчик на котлине так или иначе будет вынужден знать «яву образца 2011 года». Ну просто потому, что жизнь такая. Знать только котлин получится лишь до тех пор, пока всё идёт хорошо. В какой-то момент что-то сломается, что-то начнёт тормозить, потребуется интеграция с какой-нибудь библиотекой, которая вроде как на яве, но, вообще говоря, обёртка вокруг нативного кода — и всё, теперь от разработчика требуется понимать все слои абстракции: и котлин, и яву, и си, и ассемблер.
Вообще говоря, давайте. Си — на два порядка проще плюсов, и, так или иначе, его всё равно придётся выучить. Зато после полугода интенсивной практики программирования на чистых сях у студента не останется вопросов, зачем нужны шаблоны, RAII, исключения, корутины и модули, потому что он на своей шкуре прочувствует, какого без них.
А для чего эта штука полезна? А то может мне тоже нужна, а я и не в курсе. В интернете одни только общие слова и инструкции, как установить, а хотелось бы подборку конкретных кейсов, что люди этой штукой делают.
Но троян или шифровальщик ведь не только на флешке можно притащить.
Как мне кажется, вариант получше — закрыть через Software Restriction Policies запуск любых эксешников и скриптов, кроме как из доверенных каталогов (закрытых от пользователей на запись, конечно) и/или подписанных доверенными подписями. Причём — вообще всем пользователям, которые не админы и не разработчики. А если есть какие-то эксешники, которые пользователем нужно запускать не из доверенных каталогов, самостоятельно подписать их своим сертификатом.
Так переврать источник надо ещё постараться. Основная мысль Торвальса: «Ребят, я из ваших описаний пулл-реквестов собираю сводный текст мерж-коммитов, а из-за того, что вы пишете их вразнобой, я не могу просто копировать предложения, мне приходится их переписывать в другую грамматику, это тратит время!».
Думаю, отслеживают совпадения фото с предыдущими подачами.
Не слышал раньше об этом сайте, но попробую оценить ситуацию.
Каталог в целом производит впечатление полупустого. Одни потенциально интересные мне разделы не содержат ничего, вот прям ноль блоков:
https://сф-блоки.рф/catalog/displayporthdmi
https://сф-блоки.рф/catalog/mipi
Другие потенциально интересные мне разделы вместо хоть какой-то полезной информации содержат заглушку «Информация о %количество% СФБ скрыта разработчиками, авторизуйтесь для получения доступа», причём количество — это часто «1»:
https://сф-блоки.рф/catalog/ethernet
https://сф-блоки.рф/catalog/pcie
https://сф-блоки.рф/catalog/ddr-sdram
https://сф-блоки.рф/catalog/satasas
https://сф-блоки.рф/catalog/usb
В разеделе «Ethernet» есть один не скрытый результат, но никакой информации, кроме названия, узнать о нём без регистрации всё равно нельзя.
Чтобы зарегистрироваться на сайте, нужно предоставить почтовый адрес, телефон и ИНН компании, а также «ФИО ответственного лица».
Ситуацию оцениваю как удручающую.
Есть отличное расширение 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. Оно всё в целом работает, но иногда не работает.
Мне такие решения неизвестны. Но требовать такую функциональность от открытого софта просто нечестно (и несколько мелочно). Какой открытый стандарт описывает взаимодействие между софтом для видеоконференций и софтом для показа презентаций? Я такого стандарта не знаю. Одна конкретная компания сделала такую интеграцию между своими программами, и что теперь? Что именно должны предпринять, скажем, LibreOffice и Okular, чтобы ссылки в документах открывались на видеосозвонах в Teams? Какой-то другой софт, кроме PowerPoint, вообще умеет так делать?
Во FreeRDP заявлена поддержка проброса USB и смарт-карт. Но оно может и не заработать: там то версия протокола на сервере не та, то в udev правила не прописаны, то ещё что-то. Но в целом, клиент такое умеет. Но опенсорсного RDP-сервера с поддержкой проброса USB, скорее всего, не существует.
Мне совсем не понятно, что вообще может удостоверять видеопоток с удалённой видеокамеры. Это точно нужная фича?
В вашем случае оно «работает глобально» только по той причине, что и ОС, и RDP-клиент, и RDP-сервер, и служба сертификатов, и вообще весь софт в цепочке, вплоть до серверов Azure, подконтрольны одной компание. Причём эта компания активно старается сделать удобно тем, кто внутри пузыря, и неудобно тем, кто снаружи.
Как по мне, пусть лучше оно работает менее глобально.
В продолжение моего комментария к первой части статьи.
Теперь у вас получился (модифицированный) шифр из второй главы учебника. Он тоже стойкий, причём, в более широком смысле, и тоже, в конечном итоге, сводится к классической конструкции. И, само собой, по-прежнему непрактичен.
Давайте посмотрим на ваш алгоритм:
Из тех же соображений, что приведены в моём первом комментарии, мы можем заменить его на эквивалентный по стойкости шифр
где PRF — некая стойкая псевдослучайная функция. Однако, PBKDF2 — это тоже ни что иное, как стойкая псевдослучайная функция с настраиваемой степенью сложности. То есть, мы можем записать и так:
Композиция по ключу двух стойких псевдослучайных функций сама является стойкой псевдослучайной функцией, и мы можем дальше рассматривать одну функцию:
Это выражение, в общем-то, ни что иное, как обобщённая схема блочного шифра в режиме работы со счётчиком и nonce. Она стойкая, если:
ключ k выбирается случайным образом,
для шифрования каждого нового сообщения используется уникальное значение величины s.
Вообще говоря, тут от соли не требуется быть случайной, требуется только уникальность пары (k, s). Поэтому соль тут не вектор инициализации, как написано у вас, а именно nonce. Можно использовать простой счетчик сообщений, и это не повлияет на стойкость.
Проблема с вашим шифром в том, что вы опять изобрели блочный шифр со счётчиком на основе алгоритмов, и так построенных на блочных шифрах. Кроме того, вам потребуется заново вычислять PBKDF2 (она очень медленная) после каждого сообщения, хотя если бы вы просто применили классическую схему, это нужно было бы делать только лишь при смене ключа.
Рекомендую прекратить изобретать велосипеды и пройти уже, наконец, на курсере стенфордский онлайн-курс по криптографии. Он очень классный, странно, что ещё никто не порекомендовал.
Я вас, наверное, не обрадую, но вы не изобрели ничего нового или, хотя бы, нетривиального. Шифр, который вы предложили, построен по классической схеме из первой же главы учебника. Как будто бы можно даже показать его криптостойкость в некотором смысле, если потребовать соблюдение ряда дополнительных условий.
Я не профессиональный криптограф, поэтому вывод строгого доказательства со всеми нужными ссылками займёт у меня неоправданно много времени. Но приведу общую идею почему я считаю, что шифр стойкий.
Вот ваш шифр:
Давайте дополнительно потребуем, что:
ключ
должен быть фиксированной битовой ширины (то есть, никаких «main key» произвольной длины!),
счётчик
тоже должен быть фиксированной битовой ширины (достаточной для хранения индекса блока даже безумно длинного сообщения).
Эти дополнительные требования исключают length-extension-атаку на хеш-функцию, поэтому, интуитивно, её стойкость в этом сценарии будет эквивалентна стойкости конструкции HMAC от неё. Поэтому мы можем переписать ваш шифр на эквивалентный по стойкости:
Далее предположим, что функция
построена по схеме Меркла-Дамгора (SHA-256 именно такая) и лежащая в её основе функция компрессии является криптоскойкой псевдослучайной функцией (для функций семейства SHA на данный момент не доказано обратного). Для таких хеш-функций доказано†, что 
является стойкой псевдослучайной функцией (PRF) относительно ключа. Следовательно, снова можем переписать шифр на эквивалентный по стойкости:
Это выражение — классический блочный шифр в режиме со счётчиком. Его стойкость доказана при условии, что:
ключ
выбирается случайным образом из множества возможных ключей,
ключ используется для шифрования не более чем одного сообщения.
Этот вывод, вообще говоря, довольно очевиден с самого начала, если вспомнить, что SHA-256 построена на основе полноценного блочного шифра SHACAL-2. С тем же успехом можно было бы просто применить этот блочный шифр напрямую.
† В доказательство этого утверждения я никогда подробно не вчитывался, поэтому сошлюсь тут Википедию, https://en.wikipedia.org/wiki/HMAC:
О какой вы субъективности?
Это неправда. Стандарт прямо говорит, что у
memsetиmemcpyникакое значение не зарезервировано для индикации ошибки. То есть, ниNULL, ни какое-то ещё. Ваши функции тестируют невозможные ситуации.Там по вашей второй ссылке написано:
И то же самое сказано на странице про
memset. Для меня это выглядит так, как будто проверять, не вернули ли эти функцииNULL, нет никакого смысла.С функцией
malloc()действительно другая история (и к ней у меня вопросов не было): проверять возврат на не-NULLнадо, хотя на практике это не даёт гарантии того, что память реально была выделена и ею можно пользоваться без опаски.Судя по тому, что на баннере написано «source code available» и далее по ссылкам лишь обтекаемые формулировки и нет подробностей о лицензии, исходный код они не открывают, а показывают. Видимо, «модель совместного развития» — это когда сообщество помогает делать проприетарный продукт.
А для чего именно вам были полезны такие
memsetиmemcpy? Я вижу, что при некоторых значениях аргументаnони просто возвращаютNULLвместо того, чтобы делать свою работу, но ума не приложу, зачем такое поведение может понадобиться в тестах.В дикой природе эти функции никогда не сигнализируют об ошибке таким образом. Они вообще не умеют сигнализировать об ошибке, и определять, что произошла какая-то ошибка, тоже не умеют. Вызывающему их коду нет смысла проверять возвращаемое значение, потому что оно им и так известно (если функция в принципе вернула управление, а не, например, вызвала аппаратное исключение).
Кроме того,
memsetиmemcpy— в некотором роде волшебные функции: компилятор, если увидит такую возможность, реализует их эффект прямо на месте, без вызова библиотечной функции.А как атакующему воспользоваться этой уязвимостью? Промежуток времени такой есть, но всё это время каталог пуст.
А можно подробнее? А то я что-то нагуглить не могу.
Несколько лет назад, когда преподавал в университете, покупал для лаб за свои деньги полдюжины плат Lattice MachXO3L StarterKit — стоили они тогда примерно 30 баксов за штуку. Сами платы довольно приятные, но слегка спартанские: есть программатор, тактовый генератор, несколько светодиодов и DIP-свитчей и тонна GPIO — если для лабы нужно что-то ещё (например, семисегментный индикатор или угловой энкодер, до звука и видео просто не успевали дойти за семестр), студенты собирали это что-то рядом на макетках. Это занимало кучу времени, но студенты готовы заниматься чем угодно, лишь бы код не писать.
И правильно делают, в противном случае преподаватель только тем и будет заниматься, что бегать от студента к студенту, разбираясь с их «А почему у меня не работает?!». Я бы ещё и периферию всю использовал максимально одинаковую, чтобы не получить комбинаторный взрыв у себя в голове.