Безопасный логгинг

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

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

Вторая – как не допустить утечки. Из подходов на уровне кода есть паттерн типа read-once/read-twice/read-X-times, когда для объекта вы контролируете счетчик чтений и ставите такой максимум, чтобы «лишние» чтения (в том числе в лог) не состоялись. Другой вариант — использовать отдельное хранилище для секретов, чтобы в памяти процесса plain-ом чувствительные данные в принципе не фигурировали. Также подходы уровня кода можно разнообразить расширением процессов — например, более строгие процессы code review, или CI с сервисами, проверяющими на типичные секреты, типа snyk.io.

Третья – как проверить. Для полноценных проверок нужна высокая степень покрытия (юнитами и фаззингом), приправленная прогоном утилит, которые бы искали уже утекшие секреты в логе (DLP-alike). Однако системы, оперирующие сенситивными данными, не должны писать в лог; а если уж писать, то очень боязливо. Хотя лучше никому в лог не писать вообще, потому что неясно, какие данные сенситивные. Но здесь security сталкивается с debugability, удобством отладки. А к debugability прилегает скорость расследования инцидента, которая тоже про безопасность.

В общем, логи нужны, логи важны, но не забывайте правильно их обезопасить.

#digest

Легкий рабочий стеб над собственными стеками становится для нас традиционным – раньше мы уже осмысливали архитектуру пива в Haskell и придумывали язык будущего с оператором «Fuck you, Rust!». Теперь пришла очередь типов переменных в Python, JavaScript и C++ :)

#fun

Код, как известно, может служить не только силам добра – продуктам, фичам, компонентам и вот этому вот всему – с его помощью можно, увы, создавать и вредоносы :(

Этот хабрапост написал профессиональный исследователь угроз и реверсер. В нем он подробно рассказал о своем «взгляде с обратной стороны»: как он разбирает самплы и читает двоичный код на реальных, «боевых» примерах. Очень полезно для всестороннего понимания разработки.

#digest

Homebrew CPUs

Хотели ли вы когда-нибудь сделать процессор с собственной архитектурой? Начать с простых вентилей и закончить полноценным устройством, способным выполнять произвольные программы? Для этого уже давно не нужно устраиваться на полупроводниковое производство с современным фотолитографом, достаточно запастись хорошей литературой, например книгой «Цифровая схемотехника и архитектура компьютера», и платой с FPGA.

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

Обратите внимание на такие проекты, как BMOW (Big Mess of Wires) и MyCPU. Кажется, что это уже не совсем игрушечные вычислительные машины, на которых можно выполнять какую-то реальную работу. Например, компьютер на базе MyCPU вполне может хостить сайт о себе любимом.

Ну и на закуску — не совсем традиционные проекты: например, FORTH-машины или даже вычислители без арифметико-логического устройства!

#digest

В вашем любимом (судя по количеству реакций) нашем внутреннем чатике – баттл мемов :)

И даже интересно, а как скоро к такому баттлу сможет релевантно подключиться нейросеть? Ну а что: она уже не то что диссеры пишет, а на работу устраивается. А бугурты вообще 5 лет назад генерить научилась.

#fun

Топ-10 докладов FOSDEM-2023

Каждый год в Брюсселе проходит FOSDEM (Free and Open source Software Developers' European Meeting) — встреча, где собираются разработчики (и не только) свободного и открытого ПО со всего мира.

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

Спойлер: доклад Дрю Деволта, основанный на его собственном ЯП Hare – просто огонь!

#digest

Почти как Rust, только проще, или Пишем свой компилятор

Новые языки программирования появляются постоянно. Только популярных современных проектов масса: Go, Rust, Nim, Zig, Crystal, Swift, Kotlin, Pony. Кроме того, есть проекты и поменьше. Ну а любительские — так вообще появляются каждую неделю!

Конечно, не во всех новых языках программирования присутствует какая-то техническая или научная новизна, некоторые пытаются быть просто удобным инструментом, заботятся о том, чтобы программисту были доступны привычные концепции, но в более удачной упаковке (Go, Kotlin, Swift).

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

Продолжение 👉 ЗДЕСЬ

P.S. Ставьте палец вверх, если вам интересна эта тема! Наберем 10 лайков — посоветуем вам еще больше проектов, туториалов и книг :)

#digest

Вчера заспорили между собой о том, кто как пришел в сеньоры. Точнее, сами пути споров не вызывали – спорили главным образом о том, какой из них проще. Выделились два основных способа: линейно расти на одном проекте, или же сменить работу с повышением.

Большинство, как оказалось, уходило-переходило. Но были и совершенно нетипичные истории. Так, сестру одного из наших авторов взяли из науки – и сразу старшим аналитиком.

А как стали сеньором вы? Ждали? Уходили? Или может, как-то совсем по-иному? А если вы еще не сеньор, какой способ вам кажется проще?

👇

Пример качественной документации

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

Для нас, авторов этого канала, образцом качественной документации по проекту стала книга Genode Foundations. В действительности это постоянно обновляемая документация по внутренностям Genode Operating System Framework — конструктора операционных систем, построенного для работы над целой плеядой различных микроядер.

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

Что еще желать?!

А можете ли вы привести пример документации, которая вам нравится?

#literature

Ода предметно-ориентированным языкам

Хороший DSL (Domain Specific Language, предметно-ориентированный язык) бывает на вес золота и помогает элегантно решать довольно сложные проблемы. Часто такие мини-языки применяют там, где требуется много работать с бизнес-логикой и необходимо привлекать эксперта из предметной области, причем этот эксперт может плохо владеть программированием. Здесь подобные языки хорошо себя зарекомендовали, и причины для их применения абсолютно ясны.

Но DSL-и способны помочь и с совершенно иной точки зрения.

Продолжение 👉 ЗДЕСЬ

#digest

Технологии или польза?

Одна из статей Джеймса Хага (James Hague) поднимает важнyю тему в мире программирования. Многие из нас занимаются своей профессией именно потому, что любят технологии. Какой кайф пощупать что-нибудь новенькое, а главное использовать в своей работе (или, на худой конец, в хоббийном проекте)! Оттого на форумах и в профильных сообществах часто звучит вопрос: «Мне нравится язык X, что бы мне такое на нем написать?» Или: «Мне нравится ОС Y, какой бы проект мне сделать на ее основе?»

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

Не надо переписывать Photoshop на Rust, просто потому что любите Rust, особенно если вы профессионально не пользуетесь графическими редакторами! Да, вы получите удовольствие от кодирования, но результат, скорее всего, получится не очень. Ведь первичным окажется инструмент, язык программирования, а не польза. Лучше всего, заявляет Джеймс, подумать над своими непосредственными задачами и проблемами, а потом попробовать решить их наиболее удобным для вас способом. В том числе, применяя полюбившийся инструментарий.

С другой стороны все понимают, что выбор инструмента часто влияет на финальный образ результата деятельности. Вопрос не так-то и прост.

А что вы думаете на этот счет?

#literature

Синтез гитарного звука миниатюрной программой на C

Цифровая обработка сигналов (DSP, Digital Signal Processing) — область знания немного магическая, поскольку достаточно простые алгоритмы порой выдают очень интересные результаты. Как и в этом случае: в небольшом GitHub gist приведен пример банальнейшего кода на C (обернут shell-скриптом), вывод которого проигрывается аудиокартой.

Звучит почти как гитара!

(Если вдруг вы не хотите запускать скрипт, послушайте mp3 примеры, идущие в комплекте.)

#fun

Токсичные персонажи в open source сообществах

Сегодня мы не можем представить свою жизнь без open source. Даже те, кто не участвуют в открытых проектах сами, наверняка используют софт, который полностью или частично создан open source сообществом. Идея, что код или какой-либо цифровой контент может создаваться полностью открыто, сообща, с передачей прав на воспроизведение, копирование, создание производных работ, захватывает ум и заставляет мурашки бежать по спине, не правда ли?

К сожалению, любые сообщества состоят из людей, а люди преследуют разные интересы. И в мире open source сообществ есть свои тролли, персонажи, практикующие буллинг, оскорбления других членов сообщества и авторов открытых проектов. Есть и люди, считающие, что авторы проектов им что-то должны. Они не оставляют запросы в issue tracker, не предлагают своих изменений через pull request, а просто требуют в грубой манере, чтобы автор добавил то или иное изменение. И если человек отказывается — поднимают настоящую шумиху с публичной травлей.

Но бывает и так, что все эти неприятные персонажи собираются в команду, и ставят своей целью захватить чужой проект, а неудобного автора оставить не у дел. Так, например, обошлись с автором Non DAW, Джонатаном Муром Лилзом (Jonathan Moore Liles).

Джонатан своими силами долгие годы разрабатывал комплект программ для профессиональной звукозаписи. Non DAW создавался модульным, быстрым, не жадным к ресурсам. Эту музыкальную студию можно запустить даже на дешевом EeePC или самых старых моделях RaspberryPi, где она будет сносно работать. Даже графический тулкит для своего детища Джонатан сделал сам, переработав FLTK.

Все началось с того, что трое персонажей потребовали от автора доработок в менеджере сессий NSM. Именно потребовали, а когда услышали отказ — начали травить Джонатана в тематических сообществах. Через время появился форк NSM, который сохранил аббревиатуру, но изменил ее расшифровку, при этом «банда» начала продвигать свой форк как «более новую версию, очищенную от рекламы и трекеров».

Через список рассылки «Linux Audio Announce» Джонатан пытался указать на некорректное поведение этих товарищей, но не прошел премодерации, потому что один из них, David Runge, оказался среди модераторов! Более того, будущие анонсы по релизам реального NSM также не были допущены до публикации, а Джонатан получил вечный бан в сообществе.

У Джонатана оставался сайт оригинального проекта, где он опубликовал свои мысли о происходящем. На этот раз ему и хостингу, где располагался сайт, пригрозили судом, потому как опубликованные материалы порочат чьи-то честь и достоинство. Джонатан убрал материал с сайта, но оставил ссылку на archive.org с сохраненной копией.

И так бывает… А приходилось ли вам сталкиваться с подобным в open source сообществах? Поделитесь!

#digest