про первый вопрос, честно – нет. внутреннего аудита в том смысле, в котором это слово имеет право употребляться, независимая построчная вычитка криптографии человеком, который в ней разбирается – не было. и подписаться своим именем без дисклеймера я не могу; дисклеймер в статье стоит не для красоты, а потому что это ровно то, за что я могу отвечать. с моей человеческой стороны были требования, неудобные вопросы к слопусу клодусу, +-полтора месяца почти ежедневного использования на собственных серверах и функциональное тестирование, но это не относится именно к аудиту безопасности
вы правы насчет бремени доказательства, и спорить не стану, но тезис «вайбкоду можно доверять секреты» я не выдвигал, и лично доказать его не смог бы – оно либо есть и так, либо оно накапливается в процессе использования / анализа и подобных процессах. мой тезис скромнее: вот код, threat model и воспроизводимая сборка – любой сможет проверить это самостоятельно. это не доказательство корректности, это условия, при которых мою некорректность может обнаружить кто угодно. согласен, что финальный абзац статьи прозвучал как «докажите, что я неправ» – это неудачная формулировка, имелось в виду приглашение к проверке, а не перекладывание бремени доказательства
и дополнительный факт – клиентом можно пользоваться не доверяя ему секреты, но без синхронизации и используя системный ссш-агент
1) да, по сути, клиенты сами по себе совпадают, но есть несколько отличий: проект полностью бесплатный и полностью опенсорсный, и для организации синхронизации достаточно поднять лишь свой сервер для синхронизации
2) ффи фасад действительно большой, но это чисто фасад для клиента, но я подумаю, как это можно улучшить
3) такое есть, но это только при сценариях того, что пользователь просматривает / экспортирует секрет, а в основном пути (ссш-подключения) оно через жс не проходит
а если сервер требует какого либо интерактивного ввода (пароль / 2фа), то оно все равно проходит через интерфейс
4) это не мастер-токен, это одноразовый бутстрап-токен, который по сути живет всего несколько минут до момента того, как администратор инстанса его введет в панельке. его можно задать еще через энв в UNISSH__SETUP__CODE, чтобы он не генерировался случайным образом. в случае с энвом на данный момент, он попадет в логи, но я запишу и исправлю это. но даже если его украдут до момента инициализации инстанса и инициализируют его, то максимум, что получит злоумышленник – это пустой инстанс в который все равно врядли попадут данные
5) справедливо, формулировка не совсем точна, на остальных платформах используются системные кейчейны, андроид в доработке пока
6) запись сессий выключена по умолчанию и тумблер для записи надо включать отдельно в настройках конкретного хоста в клиенте. запись хранится в зашифрованном виде в волте, как еще один вид секрета. ну и отправляется оно куда-либо только в случае синхронизации волта с сервером синхронизации
7) наиболее зрелая и живая реализация протокола, которую и я и клод отдельно друг от друга смогли найти; позволяет использовать только его на все 5 платформ
для синхронизации у него требуется подписка 10$/мес, и честно говоря, я вообще не помню никаких упоминаний локального ключа и мало представляю, как оно работает, если там достаточно входа с своего аккаунта даже без наличия второго устройства
ну и экспортировать данные без подписки оттуда – довольно сомнительный экспериенс)
подобных клиентов существует множество, но есть проблема в том, что они так или иначе не совпадали с тем, что я хотел:
1) настоящая кроссплатформенность (макос, винда, линукс + айос и андроид) 2) хороший (для меня) дизайн 3) возможность синхронизации без платной подписки, и в идеале не через костыли по типу отдельных гистов / гугл доков и прочего 4) иметь возможность хорошо организовать сервера, если их становятся минимум десятки
я не спорю, что оно надо не всем, но личные предпочтения и выбор все еще остаются вашими
согласен, это очень удобная идея, однако здесь есть нюанс
я изучал последний раз это примерно полгода назад, и вывод все еще таков, что оно обычно генерирует код такого качества, что этим конечно можно пользоваться, но не очень-то и хочется
у меня в планах сделать опенапи генератор с использованием unihttp, но до этого дойдут руки немного позже
про первый вопрос, честно – нет. внутреннего аудита в том смысле, в котором это слово имеет право употребляться, независимая построчная вычитка криптографии человеком, который в ней разбирается – не было. и подписаться своим именем без дисклеймера я не могу; дисклеймер в статье стоит не для красоты, а потому что это ровно то, за что я могу отвечать. с моей человеческой стороны были требования, неудобные вопросы к слопусу клодусу, +-полтора месяца почти ежедневного использования на собственных серверах и функциональное тестирование, но это не относится именно к аудиту безопасности
вы правы насчет бремени доказательства, и спорить не стану, но тезис «вайбкоду можно доверять секреты» я не выдвигал, и лично доказать его не смог бы – оно либо есть и так, либо оно накапливается в процессе использования / анализа и подобных процессах. мой тезис скромнее: вот код, threat model и воспроизводимая сборка – любой сможет проверить это самостоятельно. это не доказательство корректности, это условия, при которых мою некорректность может обнаружить кто угодно. согласен, что финальный абзац статьи прозвучал как «докажите, что я неправ» – это неудачная формулировка, имелось в виду приглашение к проверке, а не перекладывание бремени доказательства
и дополнительный факт – клиентом можно пользоваться не доверяя ему секреты, но без синхронизации и используя системный ссш-агент
спасибо за фидбек, да, сделаю. другим пожеланиям / замечаниям буду рад
я не утверждаю, что оно всем надо, каждый может использовать способы для синхронизации, которые ему угодно
лично мне вместо развлечений с гитами / гугл доками и прочими вещами, проще поднять свой собственный сервер за несколько минут
привет! спасибо за замечание, записал, обязательно добавлю
привет! спасибо за большой фидбек
1) да, по сути, клиенты сами по себе совпадают, но есть несколько отличий: проект полностью бесплатный и полностью опенсорсный, и для организации синхронизации достаточно поднять лишь свой сервер для синхронизации
2) ффи фасад действительно большой, но это чисто фасад для клиента, но я подумаю, как это можно улучшить
3) такое есть, но это только при сценариях того, что пользователь просматривает / экспортирует секрет, а в основном пути (ссш-подключения) оно через жс не проходит
а если сервер требует какого либо интерактивного ввода (пароль / 2фа), то оно все равно проходит через интерфейс
4) это не мастер-токен, это одноразовый бутстрап-токен, который по сути живет всего несколько минут до момента того, как администратор инстанса его введет в панельке. его можно задать еще через энв в UNISSH__SETUP__CODE, чтобы он не генерировался случайным образом. в случае с энвом на данный момент, он попадет в логи, но я запишу и исправлю это. но даже если его украдут до момента инициализации инстанса и инициализируют его, то максимум, что получит злоумышленник – это пустой инстанс в который все равно врядли попадут данные
5) справедливо, формулировка не совсем точна, на остальных платформах используются системные кейчейны, андроид в доработке пока
6) запись сессий выключена по умолчанию и тумблер для записи надо включать отдельно в настройках конкретного хоста в клиенте. запись хранится в зашифрованном виде в волте, как еще один вид секрета. ну и отправляется оно куда-либо только в случае синхронизации волта с сервером синхронизации
7) наиболее зрелая и живая реализация протокола, которую и я и клод отдельно друг от друга смогли найти; позволяет использовать только его на все 5 платформ
не удивлюсь кстати, если не смотрели
но в любом случае я рад любому хорошему фидбеку
xterm.js + можно включить gpu-рендеринг
рендеринг на мой взгляд выглядит хорошо в том числе, когда в терминал выводится огромное количество текста постоянно
я лично пользовался термиусом очень много лет
для синхронизации у него требуется подписка 10$/мес, и честно говоря, я вообще не помню никаких упоминаний локального ключа и мало представляю, как оно работает, если там достаточно входа с своего аккаунта даже без наличия второго устройства
ну и экспортировать данные без подписки оттуда – довольно сомнительный экспериенс)
подобных клиентов существует множество, но есть проблема в том, что они так или иначе не совпадали с тем, что я хотел:
1) настоящая кроссплатформенность (макос, винда, линукс + айос и андроид)
2) хороший (для меня) дизайн
3) возможность синхронизации без платной подписки, и в идеале не через костыли по типу отдельных гистов / гугл доков и прочего
4) иметь возможность хорошо организовать сервера, если их становятся минимум десятки
я не спорю, что оно надо не всем, но личные предпочтения и выбор все еще остаются вашими
что будет через полгода-год, пожалуй, мало кто знает)
но я сомневаюсь, что оно перестанет быть мне нужным
в библиотеке есть мидлварь встроенная (правда я не подсветил это в ридми): https://github.com/goduni/unihttp/blob/master/src/unihttp/middlewares/retry.py, базовые случаи, полагаю, она решает спокойно
но я подумаю, возможно получится сделать удобную интеграцию с той же stamina для более продвинутой поддержки, потому что верная мысль в общем
не пропустил, но у Тишки в descanso используется все же немного иной подход к формированию клиентов, который лично мне не очень нравится
моя библиотека больше вдохновлена https://github.com/IvanKirpichnikov/retejo, но увы, Иван ее забросил
согласен, это очень удобная идея, однако здесь есть нюанс
я изучал последний раз это примерно полгода назад, и вывод все еще таков, что оно обычно генерирует код такого качества, что этим конечно можно пользоваться, но не очень-то и хочется
у меня в планах сделать опенапи генератор с использованием unihttp, но до этого дойдут руки немного позже