Задача с полуоткрытым кодом
На днях, в процессе создания одного приложения, столкнулся с интересной задачей, кейсом которой хочу сегодня поделиться с вами.
История разработки долгая, поэтому опишу ее кратко: в работе я пришел к потребности отслеживать состояние сервера vps и сайтов в каком-нибудь "одном окне". Существующие решения меня не устроили и я захотел создать свое приложение, которое будет решать мои задачи. Ну, и в последствии сделать проект доступным для каждого.
Суть заключается в том, что ты ставишь пакет с опенсорс решениями к себе на vps и приложение может читать данные на основе запросов этого пакета. По сути, это полностью независимое локальное приложение. Данные никуда не уходят к третьим лицам. Только прямая связь между приложением на компьютере и личным vps. Работает без облака, без регистрации и смс.
И вот встала проблема доверия. Я-то понятно, создал приложение, собрал пакет, знаю, что там и как работает. Но если кто-то попросит меня установить к себе на сервер vps какое-то опенсорс решение без возможности изучить его, я просто пошлю подальше такую просьбу.
Задача осложнялась тем, что я не хотел открывать фактический код приложения. В идеале предполагалось, чтобы пользователи могли заранее изучить, все то, что будет ставиться на их сервер (сами или с нейронкой) и, что еще важнее, быть уверенными, что это будет именно тот пакет, который был открыт. Дальше будут технические подробности решения.
Граница проведена так: открыто всё, что работает на сервере клиента. Это установочные файлы (скрипты установки, обновления и отката, шаблон docker-compose, конфиг Caddy), исходники агента мониторинга на Go, наша сборка Caddy с модулями ограничения частоты и DNS, а также каждая команда, которую приложение отправляет по SSH: поиск сайтов и сертификатов, копии, проверка безопасности, чтение журнала установки. Само приложение для компьютера остаётся закрытым. Проверить, что закрытое приложение отправляет именно эти команды, по репозиторию нельзя — но всё выполненное на вашем сервере видно в журнале sudo или auditd.
Первая сложность была в самих командах. Они жили строками внутри кода приложения на Rust и собирались на лету, а выложенная копия рано или поздно разошлась бы с тем, что реально выполняется. Пришлось вынести все 36 скриптов в отдельные файлы. Приложение встраивает их в себя при сборке без изменений и добавляет только две вещи: параметры строками вида ИМЯ='значение' в начале файла и данные (содержимое загружаемого конфига или текст SQL-запроса) на место специальной метки — только вызовами функций, объявленных в самом файле. К каждому скрипту есть строка в описи SERVER-SIDE.md: когда запускается, что читает, что меняет. Автоматические тесты следят, чтобы опись не отставала: каждый файл назван в описи, каждый модуль приложения, который ходит на сервер по SSH, тоже в ней есть, а скрипт, собранный строкой в коде на Rust, роняет тесты. Все скрипты прогнаны на настоящем Linux, включая полный запуск установки.
На днях, в процессе создания одного приложения, столкнулся с интересной задачей, кейсом которой хочу сегодня поделиться с вами.
История разработки долгая, поэтому опишу ее кратко: в работе я пришел к потребности отслеживать состояние сервера vps и сайтов в каком-нибудь "одном окне". Существующие решения меня не устроили и я захотел создать свое приложение, которое будет решать мои задачи. Ну, и в последствии сделать проект доступным для каждого.
Суть заключается в том, что ты ставишь пакет с опенсорс решениями к себе на vps и приложение может читать данные на основе запросов этого пакета. По сути, это полностью независимое локальное приложение. Данные никуда не уходят к третьим лицам. Только прямая связь между приложением на компьютере и личным vps. Работает без облака, без регистрации и смс.
И вот встала проблема доверия. Я-то понятно, создал приложение, собрал пакет, знаю, что там и как работает. Но если кто-то попросит меня установить к себе на сервер vps какое-то опенсорс решение без возможности изучить его, я просто пошлю подальше такую просьбу.
Задача осложнялась тем, что я не хотел открывать фактический код приложения. В идеале предполагалось, чтобы пользователи могли заранее изучить, все то, что будет ставиться на их сервер (сами или с нейронкой) и, что еще важнее, быть уверенными, что это будет именно тот пакет, который был открыт. Дальше будут технические подробности решения.
Граница проведена так: открыто всё, что работает на сервере клиента. Это установочные файлы (скрипты установки, обновления и отката, шаблон docker-compose, конфиг Caddy), исходники агента мониторинга на Go, наша сборка Caddy с модулями ограничения частоты и DNS, а также каждая команда, которую приложение отправляет по SSH: поиск сайтов и сертификатов, копии, проверка безопасности, чтение журнала установки. Само приложение для компьютера остаётся закрытым. Проверить, что закрытое приложение отправляет именно эти команды, по репозиторию нельзя — но всё выполненное на вашем сервере видно в журнале sudo или auditd.
Первая сложность была в самих командах. Они жили строками внутри кода приложения на Rust и собирались на лету, а выложенная копия рано или поздно разошлась бы с тем, что реально выполняется. Пришлось вынести все 36 скриптов в отдельные файлы. Приложение встраивает их в себя при сборке без изменений и добавляет только две вещи: параметры строками вида ИМЯ='значение' в начале файла и данные (содержимое загружаемого конфига или текст SQL-запроса) на место специальной метки — только вызовами функций, объявленных в самом файле. К каждому скрипту есть строка в описи SERVER-SIDE.md: когда запускается, что читает, что меняет. Автоматические тесты следят, чтобы опись не отставала: каждый файл назван в описи, каждый модуль приложения, который ходит на сервер по SSH, тоже в ней есть, а скрипт, собранный строкой в коде на Rust, роняет тесты. Все скрипты прогнаны на настоящем Linux, включая полный запуск установки.