Датасет в опенсорс
Так как я решил завязать с аудитами смарт контрактов до какого-нибудь следующего "большого бума" в этой сфере, то смысла держать проекты по этой теме на сервере нет. Поэтому я решил открыть код одного проекта, который так и не вышел из беты и большой датасет с уязвимостями в смарт контрактах.
1. https://huggingface.co/datasets/Zaevlad/audit-findings-dataset
Тут находится датасет с 23 625 уязвимостями, которые я собрал весь прошлый год из различных аудиторских отчетов частных аудиторов и конкурсных платформ.
И тут его версия на гитхаб: https://github.com/zaevlad/solidity-audit-findings-dataset
Буду признателен за пару звезд!
P.S. Единственно что, я не нашел полностью очищенный и подготовленный сет для тренировки моделей, и данный вариант его исходная версия. Другими словами, все уязвимости распределены по категориям, по весу, по описаниям и т.д. Но чтобы обучат нейронки на них, потребуется привести все к общему формату и убрать большие части.
2. https://github.com/zaevlad/lazyauditor_open
Это был проект, который я делал для себя для ленивого аудита контрактов. Грубо говоря, тут мы добавляем проект смарт контракта с гитхаб, он парсится и разбивается по функциям в древо. Потом можно изучать каждую функцию отдельно и задавать вопросы нейронке прямо во встроенном чате.
Также можно добавлять документацию для дополнительного контекста, которая через rag будет добавляться к запросам к модели ии.
Отдельно стоит упомянуть, что тут я экспериментировал с сжатием смарт контрактов для экономии токенов без потери качества и смысла. В некоторых случаях удавалось сократить контекст контракта до 60%!
Это бета версия, так как содержит ошибки и недочеты, до которых не дошли руки. Если вы делаете что-то подобное, то может какие идеи из моего репо придутся вам по вкусу или какой-то код сможете взять к себе в наработки.
Надеюсь, у вас тут получится лучше, чем у меня!
#opensource
Так как я решил завязать с аудитами смарт контрактов до какого-нибудь следующего "большого бума" в этой сфере, то смысла держать проекты по этой теме на сервере нет. Поэтому я решил открыть код одного проекта, который так и не вышел из беты и большой датасет с уязвимостями в смарт контрактах.
1. https://huggingface.co/datasets/Zaevlad/audit-findings-dataset
Тут находится датасет с 23 625 уязвимостями, которые я собрал весь прошлый год из различных аудиторских отчетов частных аудиторов и конкурсных платформ.
И тут его версия на гитхаб: https://github.com/zaevlad/solidity-audit-findings-dataset
Буду признателен за пару звезд!
P.S. Единственно что, я не нашел полностью очищенный и подготовленный сет для тренировки моделей, и данный вариант его исходная версия. Другими словами, все уязвимости распределены по категориям, по весу, по описаниям и т.д. Но чтобы обучат нейронки на них, потребуется привести все к общему формату и убрать большие части.
2. https://github.com/zaevlad/lazyauditor_open
Это был проект, который я делал для себя для ленивого аудита контрактов. Грубо говоря, тут мы добавляем проект смарт контракта с гитхаб, он парсится и разбивается по функциям в древо. Потом можно изучать каждую функцию отдельно и задавать вопросы нейронке прямо во встроенном чате.
Также можно добавлять документацию для дополнительного контекста, которая через rag будет добавляться к запросам к модели ии.
Отдельно стоит упомянуть, что тут я экспериментировал с сжатием смарт контрактов для экономии токенов без потери качества и смысла. В некоторых случаях удавалось сократить контекст контракта до 60%!
Это бета версия, так как содержит ошибки и недочеты, до которых не дошли руки. Если вы делаете что-то подобное, то может какие идеи из моего репо придутся вам по вкусу или какой-то код сможете взять к себе в наработки.
Надеюсь, у вас тут получится лучше, чем у меня!
#opensource
🔥23❤2😱1
Рефлексия в понедельник утром
Раньше многие мелкие предприниматели шутили, что чем меньше у тебя денег, тем больше ты сам маркетолог, seo'шник, юрист, бухгалтер и уборщик. Эта тенденция сохраняется и сейчас, только теперь к ним добавились еще и разработчики, они же вайбкодеры.
Еще буквально год-два назад тебе было достаточно иметь хорошие знания в одной области разработки: фронтенд, бекенд, девопс и т.д. Да и специализация была зачастую в одном языке программирования.
Сейчас же границы стираются, и разработчику потребуется понимать вообще всю теорию, на которой ведется его проект: от фронтенд фреймворка и устройства бекенда до серверных движков и различий в мощностях vps.
Когда я разрабатывал свои проекты mcp клиента, lazyauditor или пайплайны для аудита, то одним из требований для нейронки было использование того стека, что я хорошо знаю. Я хотел контролировать каждый шаг claude и проверять код практически вручную. Тогда единственным новым шагом было для меня загрузка на vps сервер. С подсказками нейросети все прошло отлично.
Далее были еще пара проектов, где я столкнулся с проблемой мощности сервера. Пришлось изучать как это все устроено и что с некоторыми проблемами можно справиться только "рублем", но я уже представлял, какая нагрузка меня ждет и к чему нужно быть готовым.
Чуть позже, этой весной, когда вышли более сильные модели типа claude 4.8, я решил прогнать проекты на безопасность. И вот тут меня и накрыло...
В каждом случае, когда я полагал, что предусмотрел все дыры в реализации, всегда находились серьезные проблемы, в тех местах, о которых я даже не подозревал. Тогда я понял, что если разработчик специально не изучал безопасность и взлом вебсайтов, то он никогда не сможет предусмотреть и половины всех проблем в своем проекте. Не потому что он может плохо знать какой-то язык, а потому, что он просто не увидит всю картину целиком.
В смарт контрактах, даже в тех, что считали крупными на 5000 - 10 000 строк, всегда находили проблемы. А представьте, сколько проблем может быть в коде на 100 000 строк или миллион?
Сейчас же, с выходом передовых моделей, все грани языков и разработки полностью стираются. Уже не важно знаешь ли ты язык и на каком уровне им владеешь, нейронка будет делать это лучше.
P.S. Я не беру сейчас во внимание разработчиков уровня Линуса Торвальдса. Речь идет о 99% остальных программистах.
Сейчас я пробую создавать проекты на Rust и Go, вообще не проверяя код, а только финальный результат. И это действительно работает. Базовые знания алгоритмов, циклов, структур данных - помогают мне понимать код с подсказками нейронок.
Разбивка по спринтам, циклы аудитов кода, проверка на безопасность различными моделями позволяют создавать достаточно хороший код в сжатые сроки. И я понимаю, что даже со знаниями этих языков, я бы не написал лучше...
Все это я веду к тому, что через год-два разработчикам нужно будет изучать только теорию. Но теорию вообще всего: и фронтенд языка, и бекенд, и девопс, и контейнеров, и всего остального. Просто потому, что нейронка все равно сделает это лучше.
Лучшее, что вы можете сейчас сделать для себя, это купить книги, типа "Разработка высоконагруженных приложений" и потихоньку изучать, как все устроено.
Люди становятся оркестраторами высшего уровня для нейросетей.
#dev
Раньше многие мелкие предприниматели шутили, что чем меньше у тебя денег, тем больше ты сам маркетолог, seo'шник, юрист, бухгалтер и уборщик. Эта тенденция сохраняется и сейчас, только теперь к ним добавились еще и разработчики, они же вайбкодеры.
Еще буквально год-два назад тебе было достаточно иметь хорошие знания в одной области разработки: фронтенд, бекенд, девопс и т.д. Да и специализация была зачастую в одном языке программирования.
Сейчас же границы стираются, и разработчику потребуется понимать вообще всю теорию, на которой ведется его проект: от фронтенд фреймворка и устройства бекенда до серверных движков и различий в мощностях vps.
Когда я разрабатывал свои проекты mcp клиента, lazyauditor или пайплайны для аудита, то одним из требований для нейронки было использование того стека, что я хорошо знаю. Я хотел контролировать каждый шаг claude и проверять код практически вручную. Тогда единственным новым шагом было для меня загрузка на vps сервер. С подсказками нейросети все прошло отлично.
Далее были еще пара проектов, где я столкнулся с проблемой мощности сервера. Пришлось изучать как это все устроено и что с некоторыми проблемами можно справиться только "рублем", но я уже представлял, какая нагрузка меня ждет и к чему нужно быть готовым.
Чуть позже, этой весной, когда вышли более сильные модели типа claude 4.8, я решил прогнать проекты на безопасность. И вот тут меня и накрыло...
В каждом случае, когда я полагал, что предусмотрел все дыры в реализации, всегда находились серьезные проблемы, в тех местах, о которых я даже не подозревал. Тогда я понял, что если разработчик специально не изучал безопасность и взлом вебсайтов, то он никогда не сможет предусмотреть и половины всех проблем в своем проекте. Не потому что он может плохо знать какой-то язык, а потому, что он просто не увидит всю картину целиком.
В смарт контрактах, даже в тех, что считали крупными на 5000 - 10 000 строк, всегда находили проблемы. А представьте, сколько проблем может быть в коде на 100 000 строк или миллион?
Сейчас же, с выходом передовых моделей, все грани языков и разработки полностью стираются. Уже не важно знаешь ли ты язык и на каком уровне им владеешь, нейронка будет делать это лучше.
P.S. Я не беру сейчас во внимание разработчиков уровня Линуса Торвальдса. Речь идет о 99% остальных программистах.
Сейчас я пробую создавать проекты на Rust и Go, вообще не проверяя код, а только финальный результат. И это действительно работает. Базовые знания алгоритмов, циклов, структур данных - помогают мне понимать код с подсказками нейронок.
Разбивка по спринтам, циклы аудитов кода, проверка на безопасность различными моделями позволяют создавать достаточно хороший код в сжатые сроки. И я понимаю, что даже со знаниями этих языков, я бы не написал лучше...
Все это я веду к тому, что через год-два разработчикам нужно будет изучать только теорию. Но теорию вообще всего: и фронтенд языка, и бекенд, и девопс, и контейнеров, и всего остального. Просто потому, что нейронка все равно сделает это лучше.
Лучшее, что вы можете сейчас сделать для себя, это купить книги, типа "Разработка высоконагруженных приложений" и потихоньку изучать, как все устроено.
Люди становятся оркестраторами высшего уровня для нейросетей.
#dev
🤔12👍9❤2🎉1
Поиск на основе триграмм
Если вы разрабатываете свои агентные системы и "второй мозг", где необходим поиск по огромным массивам документов, то эта новость для вас.
Microsoft выпустила tgrep — инструмент для очень быстрого поиска текста по большим кодовым базам. Он уже используется внутри GitHub Copilot CLI.
Главное отличие tgrep от обычного grep или ripgrep в том, что он использует предварительно построенный индекс.
Обычный поиск при каждом запросе проходит по файлам проекта и проверяет их содержимое. ripgrep делает это очень эффективно и быстро, но принцип остаётся тем же: файлы нужно просмотреть при выполнении поиска.
tgrep сначала индексирует проект. Во время индексации он анализирует содержимое файлов и создаёт специальный триграммный индекс. Триграмма — это последовательность из трёх символов. Для каждой такой последовательности индекс хранит информацию о том, в каких файлах она встречается.
После этого при поиске tgrep сначала обращается к индексу и определяет небольшой набор файлов, в которых вообще может находиться искомый текст. И только затем проверяет эти файлы непосредственно.
Например, если в репозитории 500 тысяч файлов, поиск не обязательно будет читать все 500 тысяч. Индекс может показать, что подходящие файлы находятся, например, среди нескольких сотен — и проверить нужно уже их.
При этом индекс не остаётся статичным. tgrep может работать в режиме сервера, который отслеживает изменения в проекте и обновляет индекс при изменении файлов.
Именно поэтому основное преимущество tgrep проявляется при повторных поисках в очень больших репозиториях.
В тестах Microsoft поиск по Firefox занимал у ripgrep около 33 секунд, а у tgrep — около 643 миллисекунд. Для Chromium результаты составляли примерно 41 секунду против 2,6 секунды, а для Linux — 5,4 секунды против 256 миллисекунд.
То есть в зависимости от проекта поиск может ускоряться в несколько, десятки и даже больше раз.
При этом tgrep не является безусловной заменой ripgrep. Для небольших проектов предварительная индексация может быть просто не нужна. Если нужно один раз найти что-то в нескольких тысячах файлов, обычный ripgrep зачастую будет проще.
tgrep имеет смысл там, где кодовая база очень большая, а поиск выполняется постоянно.
По сути, его основная идея довольно простая: не искать одно и то же по всему проекту заново при каждом запросе, а заранее создать индекс и использовать его для следующих поисков.
Для агентных ИИ такая система поиска тоже может быть очень полезна. Агенту часто приходится много раз искать по исходному коду: находить функции, классы, места использования переменных, похожие участки кода или конкретные реализации. Если проект большой, использование индексированного поиска позволяет выполнять такие операции значительно быстрее и не тратить время на повторное сканирование всей кодовой базы.
В RAG-системах принцип похожий. Вместо того чтобы каждый раз просматривать весь набор документов или файлов, можно использовать индекс для быстрого определения релевантных документов, а уже затем передавать найденное содержимое модели. При этом tgrep не заменяет векторный поиск: это другой подход. Его сильная сторона — очень быстрый точный поиск по содержимому, который можно использовать как отдельный этап retrieval или вместе с семантическим поиском.
#indexsearch
Если вы разрабатываете свои агентные системы и "второй мозг", где необходим поиск по огромным массивам документов, то эта новость для вас.
Microsoft выпустила tgrep — инструмент для очень быстрого поиска текста по большим кодовым базам. Он уже используется внутри GitHub Copilot CLI.
Главное отличие tgrep от обычного grep или ripgrep в том, что он использует предварительно построенный индекс.
Обычный поиск при каждом запросе проходит по файлам проекта и проверяет их содержимое. ripgrep делает это очень эффективно и быстро, но принцип остаётся тем же: файлы нужно просмотреть при выполнении поиска.
tgrep сначала индексирует проект. Во время индексации он анализирует содержимое файлов и создаёт специальный триграммный индекс. Триграмма — это последовательность из трёх символов. Для каждой такой последовательности индекс хранит информацию о том, в каких файлах она встречается.
После этого при поиске tgrep сначала обращается к индексу и определяет небольшой набор файлов, в которых вообще может находиться искомый текст. И только затем проверяет эти файлы непосредственно.
Например, если в репозитории 500 тысяч файлов, поиск не обязательно будет читать все 500 тысяч. Индекс может показать, что подходящие файлы находятся, например, среди нескольких сотен — и проверить нужно уже их.
При этом индекс не остаётся статичным. tgrep может работать в режиме сервера, который отслеживает изменения в проекте и обновляет индекс при изменении файлов.
Именно поэтому основное преимущество tgrep проявляется при повторных поисках в очень больших репозиториях.
В тестах Microsoft поиск по Firefox занимал у ripgrep около 33 секунд, а у tgrep — около 643 миллисекунд. Для Chromium результаты составляли примерно 41 секунду против 2,6 секунды, а для Linux — 5,4 секунды против 256 миллисекунд.
То есть в зависимости от проекта поиск может ускоряться в несколько, десятки и даже больше раз.
При этом tgrep не является безусловной заменой ripgrep. Для небольших проектов предварительная индексация может быть просто не нужна. Если нужно один раз найти что-то в нескольких тысячах файлов, обычный ripgrep зачастую будет проще.
tgrep имеет смысл там, где кодовая база очень большая, а поиск выполняется постоянно.
По сути, его основная идея довольно простая: не искать одно и то же по всему проекту заново при каждом запросе, а заранее создать индекс и использовать его для следующих поисков.
Для агентных ИИ такая система поиска тоже может быть очень полезна. Агенту часто приходится много раз искать по исходному коду: находить функции, классы, места использования переменных, похожие участки кода или конкретные реализации. Если проект большой, использование индексированного поиска позволяет выполнять такие операции значительно быстрее и не тратить время на повторное сканирование всей кодовой базы.
В RAG-системах принцип похожий. Вместо того чтобы каждый раз просматривать весь набор документов или файлов, можно использовать индекс для быстрого определения релевантных документов, а уже затем передавать найденное содержимое модели. При этом tgrep не заменяет векторный поиск: это другой подход. Его сильная сторона — очень быстрый точный поиск по содержимому, который можно использовать как отдельный этап retrieval или вместе с семантическим поиском.
#indexsearch
👍5
Работа с чистой энергией
Дисклеймер
Сегодня ава и название канала, наконец, поменялись. Я долго колебался на этот счет и думал оставить "как есть", но лучше уже сделать этот шаг и перейти более регулярным постам на темы, которые заходят и нравятся мне самому. Надеюсь, вам все также будут заходить формат.
---
Мне нравится, что когда коммерческая технология заходит в тупик, она ищет новые пути решения намного эффективнее, чем какая-либо другая структура. Она нанимает специалистов из смежных областей, открывает гранты и лаборатории, старается найти решение в местах, куда другие даже не смотрят.
Также произошло и с компанией Cerebras. Это компания, которая разрабатывает суперкомпьютеры и процессоры для ускорения работы искусственного интеллекта.
Недавно она презентовала свои новые чипы, которые по площади гораздо объемнее всех остальных чипов (она на фото к посту). И многие стали шутить, что с такими "решениями" чипы станут размером с солнечные панели.
Но для тех, кто попытался разобраться в этом, открылась реальная причина в таком размере.
Cerebras долго разбиралась как сделать свои чипы эффективнее. Все мы знаем, что в мире, из-за развития ИИ, стало строиться гораздо больше дата центров и выпускаться чипов для них. И в какой-то момент это стало практически лидером по потреблению электроэнергии.
На регулярное обучение сверхмоделей и поддержки бесплатного доступа к чату (а значит и к вычислительным мощностям миллионам пользователей) требуется огромный расход энергии каждый день.
В итоге все упирается в то, сколько энергии и как потребляют эти чипы.
По расчетам Cerebras для перемещения 1 бита информации в чипе требуется около 1–10 pJ энергии. А с их новым чипом большей площади для той же операции требуется всего 0.1 pJ энергии! Экономия значительная!
Это достигается за счет того, что перемещение битов информации в рамках чипа намного дешевле, чем перемещение данных с одного чипа на другой.
На мой взгляд это потрясающе! В то время, как все взгляды устремлены на флагманские модели типа Астры и Фейбл, такие компании действительно делают революцию в мире.
#chips
Дисклеймер
Сегодня ава и название канала, наконец, поменялись. Я долго колебался на этот счет и думал оставить "как есть", но лучше уже сделать этот шаг и перейти более регулярным постам на темы, которые заходят и нравятся мне самому. Надеюсь, вам все также будут заходить формат.
---
Мне нравится, что когда коммерческая технология заходит в тупик, она ищет новые пути решения намного эффективнее, чем какая-либо другая структура. Она нанимает специалистов из смежных областей, открывает гранты и лаборатории, старается найти решение в местах, куда другие даже не смотрят.
Также произошло и с компанией Cerebras. Это компания, которая разрабатывает суперкомпьютеры и процессоры для ускорения работы искусственного интеллекта.
Недавно она презентовала свои новые чипы, которые по площади гораздо объемнее всех остальных чипов (она на фото к посту). И многие стали шутить, что с такими "решениями" чипы станут размером с солнечные панели.
Но для тех, кто попытался разобраться в этом, открылась реальная причина в таком размере.
Cerebras долго разбиралась как сделать свои чипы эффективнее. Все мы знаем, что в мире, из-за развития ИИ, стало строиться гораздо больше дата центров и выпускаться чипов для них. И в какой-то момент это стало практически лидером по потреблению электроэнергии.
На регулярное обучение сверхмоделей и поддержки бесплатного доступа к чату (а значит и к вычислительным мощностям миллионам пользователей) требуется огромный расход энергии каждый день.
В итоге все упирается в то, сколько энергии и как потребляют эти чипы.
По расчетам Cerebras для перемещения 1 бита информации в чипе требуется около 1–10 pJ энергии. А с их новым чипом большей площади для той же операции требуется всего 0.1 pJ энергии! Экономия значительная!
Это достигается за счет того, что перемещение битов информации в рамках чипа намного дешевле, чем перемещение данных с одного чипа на другой.
На мой взгляд это потрясающе! В то время, как все взгляды устремлены на флагманские модели типа Астры и Фейбл, такие компании действительно делают революцию в мире.
#chips
👍10❤4
GTA6, Cyberleek, блокчейн и безопасность
Увидел несколько постов (тут и тут) про Cyberleek — хакера или группу, стоящую за утечками материалов по GTA 6, — и решил сделать пост на канале, так как это высший уровень анонимности и профессионализма!
У них довольно необычная система контакта, построенная вокруг Session и Monero.
Пройдусь кратко, о чем узнал из твитов.
На странице Contact сайт сначала генерирует новую анонимную учётную запись Session и выдаёт recovery-фразу из 12 слов. Её нужно сохранить самостоятельно: если потерять эти слова, восстановить аккаунт уже невозможно, и Cyberleek не сможет связаться с вами.
После этого генерируется уникальная сумма в Monero. Например, на скриншоте — 400.818811529987 XMR. И здесь самое интересное: Cyberleek прямо пишет, что цифры после десятичной точки являются уникальным ID. Отправить нужно именно эту сумму, без округления.
Получается, 400 XMR — это contact fee, а 12 цифр после запятой используются как идентификатор конкретного Session-аккаунта. По описанию системы, эта информация генерируется на стороне клиента, поэтому после получения платежа Cyberleek может определить соответствующий Session и связаться с отправителем.
Именно поэтому они рекомендуют отправлять Monero с личного кошелька вроде Cake Wallet или Feather, а не с биржи. При выводе с exchange дробная часть суммы может быть округлена или изменена, и тогда идентификатор перестанет работать.
При этом это не совсем тот ransom-сценарий, который можно было представить из новостей о хакере. На самом сайте Cyberleek отдельно подчёркивает, что это не выкуп за прекращение утечек. Они заявляют, что привлекают средства через поддержку сообщества и стратегические партнёрства, а Monero-платёж используется как плата за установление контакта. Через Session можно обсуждать рекламные размещения, например watermark'и в видео, или заказывать эксклюзивные и кастомные игровые материалы для конкретных брендов.
Интересно устроен и сам сайт. Он размещён через Arweave — децентрализованную сеть хранения данных, а доступ к нему осуществляется через множество gateway сети ar.io. Поэтому отключение одного сервера или gateway не означает, что сайт исчезнет: тот же контент продолжает храниться в Arweave и может быть доступен через другие точки входа.
В итоге получается довольно необычная комбинация: Session для приватной коммуникации, Monero одновременно как платёж и механизм идентификации контакта, а Arweave — для устойчивого размещения сайта.
Это, конечно, само по себе не доказывает, что Cyberleek — именно группа профессиональных хакеров. Но их инфраструктура явно отличается от банальной схемы с Telegram, обычным криптокошельком и арендованным сервером. Здесь заметен осознанный упор на приватность, децентрализацию и устойчивость инфраструктуры.
И что особенно интересно — за довольно троллинговым образом Cyberleek скрывается достаточно продуманная техническая часть.
P.S. Сайт хакеров не хочу распространять, поэтому ссылок не будет.
#leak #monero
Увидел несколько постов (тут и тут) про Cyberleek — хакера или группу, стоящую за утечками материалов по GTA 6, — и решил сделать пост на канале, так как это высший уровень анонимности и профессионализма!
У них довольно необычная система контакта, построенная вокруг Session и Monero.
Пройдусь кратко, о чем узнал из твитов.
На странице Contact сайт сначала генерирует новую анонимную учётную запись Session и выдаёт recovery-фразу из 12 слов. Её нужно сохранить самостоятельно: если потерять эти слова, восстановить аккаунт уже невозможно, и Cyberleek не сможет связаться с вами.
После этого генерируется уникальная сумма в Monero. Например, на скриншоте — 400.818811529987 XMR. И здесь самое интересное: Cyberleek прямо пишет, что цифры после десятичной точки являются уникальным ID. Отправить нужно именно эту сумму, без округления.
Получается, 400 XMR — это contact fee, а 12 цифр после запятой используются как идентификатор конкретного Session-аккаунта. По описанию системы, эта информация генерируется на стороне клиента, поэтому после получения платежа Cyberleek может определить соответствующий Session и связаться с отправителем.
Именно поэтому они рекомендуют отправлять Monero с личного кошелька вроде Cake Wallet или Feather, а не с биржи. При выводе с exchange дробная часть суммы может быть округлена или изменена, и тогда идентификатор перестанет работать.
При этом это не совсем тот ransom-сценарий, который можно было представить из новостей о хакере. На самом сайте Cyberleek отдельно подчёркивает, что это не выкуп за прекращение утечек. Они заявляют, что привлекают средства через поддержку сообщества и стратегические партнёрства, а Monero-платёж используется как плата за установление контакта. Через Session можно обсуждать рекламные размещения, например watermark'и в видео, или заказывать эксклюзивные и кастомные игровые материалы для конкретных брендов.
Интересно устроен и сам сайт. Он размещён через Arweave — децентрализованную сеть хранения данных, а доступ к нему осуществляется через множество gateway сети ar.io. Поэтому отключение одного сервера или gateway не означает, что сайт исчезнет: тот же контент продолжает храниться в Arweave и может быть доступен через другие точки входа.
В итоге получается довольно необычная комбинация: Session для приватной коммуникации, Monero одновременно как платёж и механизм идентификации контакта, а Arweave — для устойчивого размещения сайта.
Это, конечно, само по себе не доказывает, что Cyberleek — именно группа профессиональных хакеров. Но их инфраструктура явно отличается от банальной схемы с Telegram, обычным криптокошельком и арендованным сервером. Здесь заметен осознанный упор на приватность, децентрализацию и устойчивость инфраструктуры.
И что особенно интересно — за довольно троллинговым образом Cyberleek скрывается достаточно продуманная техническая часть.
P.S. Сайт хакеров не хочу распространять, поэтому ссылок не будет.
#leak #monero
🔥11❤3
Графы повсюду
Если вы также следите за новостями в мире ИИ, то наверняка уже все чаще встречаете слово "граф": graph Rag, графовые нейронные сети, графовые агенты и т.д. Даже популярный блогер - математик Tivadar Danka обращал внимание, что "самый недооценённый факт линейной алгебры заключается в том, что матрицы - это графы, а графы - это матрицы".
И тогда я задумался, что, вероятно, графы это не просто схематическое изображение чего-либо, а какая-то неизученная мной сфера. И оказалось, что есть полноценная математическая область посвященная исключительно изучению графов - Теория графов.
В то же время мне на Озоне попалась книга "Введение в теорию графов" от Робина Уилсона, пятое издание. После быстрого изучения содержания книги и радости, что там много рисунков графов, я решил купить ее. Далее пару слов скажу о книге.
Если вы не математик и не любите математику, то не покупайте эту книгу. Только поначалу она кажется понятной, но чуть дальше идут сплошные теоремы и их доказательства. Это действительно сложно читать, если вы не собираетесь сильно погружаться в детали. Все эти обороты: "тогда и только тогда, когда...", "из следствия выше исходит, что..."... Очень мало понятной теории.
Лучше посмотрите видео на Ютуб по теории графов...
В общем, графы оказались куда более глубокой и интересной темой. И результаты работ по этой области окружают нас повсюду: от нейронных сетей до навигации по картам в городе!
Это сложно (пока что) объяснить, но при понимании структур графов (узлы, грани, вершины, листы, циклы и петли) начинаешь по-другому смотреть на некоторые концепции линейной алгебры и манипуляцией с пространством в ней: растяжение, сжатие и повороты. Понимаешь, что "самый быстрый маршрут" на карте, это проработанный алгоритм Дейкстры, и в основе его те же взвешенные графы и поиск пути между вершинами. Удивляешься, что графы можно легко переложить в матрицы и проводить матричные операции.
А если вы научитесь понимать продвинутые концепции теории графов типа матроидов и трансверсалей, то даже сложные алгоритмы вам покажутся очень логичными и простыми.
Если вы хотели получить новые интересные теоретические знания за пару недель, то очень рекомендую обратить внимание на теорию графов и изучить базис.
#graph
Если вы также следите за новостями в мире ИИ, то наверняка уже все чаще встречаете слово "граф": graph Rag, графовые нейронные сети, графовые агенты и т.д. Даже популярный блогер - математик Tivadar Danka обращал внимание, что "самый недооценённый факт линейной алгебры заключается в том, что матрицы - это графы, а графы - это матрицы".
И тогда я задумался, что, вероятно, графы это не просто схематическое изображение чего-либо, а какая-то неизученная мной сфера. И оказалось, что есть полноценная математическая область посвященная исключительно изучению графов - Теория графов.
В то же время мне на Озоне попалась книга "Введение в теорию графов" от Робина Уилсона, пятое издание. После быстрого изучения содержания книги и радости, что там много рисунков графов, я решил купить ее. Далее пару слов скажу о книге.
Если вы не математик и не любите математику, то не покупайте эту книгу. Только поначалу она кажется понятной, но чуть дальше идут сплошные теоремы и их доказательства. Это действительно сложно читать, если вы не собираетесь сильно погружаться в детали. Все эти обороты: "тогда и только тогда, когда...", "из следствия выше исходит, что..."... Очень мало понятной теории.
Лучше посмотрите видео на Ютуб по теории графов...
В общем, графы оказались куда более глубокой и интересной темой. И результаты работ по этой области окружают нас повсюду: от нейронных сетей до навигации по картам в городе!
Это сложно (пока что) объяснить, но при понимании структур графов (узлы, грани, вершины, листы, циклы и петли) начинаешь по-другому смотреть на некоторые концепции линейной алгебры и манипуляцией с пространством в ней: растяжение, сжатие и повороты. Понимаешь, что "самый быстрый маршрут" на карте, это проработанный алгоритм Дейкстры, и в основе его те же взвешенные графы и поиск пути между вершинами. Удивляешься, что графы можно легко переложить в матрицы и проводить матричные операции.
А если вы научитесь понимать продвинутые концепции теории графов типа матроидов и трансверсалей, то даже сложные алгоритмы вам покажутся очень логичными и простыми.
Если вы хотели получить новые интересные теоретические знания за пару недель, то очень рекомендую обратить внимание на теорию графов и изучить базис.
#graph
🔥10❤2
Интересная модель Jev
Буквально пару дней назад в Твиттере многие начали обсуждение новой модели Jev от TypeSafe. Вообще, сначала появился небольшой пост на HackerNews, а затем пошел какой-то невиданный ажиотаж вокруг этой недо-llm пере-ml. Далее расскажу, что в ней особенного.
Jev показался мне интересным не столько как очередная AI-модель, сколько как попытка переосмыслить интерфейс между AI и обычным софтом.
Классический ML обычно решает конкретную задачу: классификация, ранжирование, регрессия. Если появляется новая задача, под неё часто приходится собирать данные и обучать отдельную модель.
LLM пошли в другую сторону: одна универсальная модель может решать огромное количество задач, но взаимодействие с ней обычно происходит через генерацию текста. Даже когда мы просим JSON, внутри всё равно остаётся token-by-token генерация, а значит появляются задержки, стоимость, парсинг и проблемы с надёжностью интерфейса.
Jev предлагает промежуточный вариант. Вместо генерации произвольного текста модель возвращает типизированное решение и вероятность этого решения. То есть AI становится чем-то вроде "вероятностной функции" внутри программы.
Условно:
То есть модель не генерирует произвольный текст. Вместо этого разработчик задаёт пространство возможных решений, а модель возвращает структурированный результат и confidence.
В таком виде AI становится похож на "вероятностную функцию" внутри обычного software:
Это особенно интересно для AI workflows и агентов, где не обязательно отдавать модели контроль над всем процессом. Можно декомпозировать workflow на десятки небольших решений: routing, classification, risk assessment, tool selection, human escalation и т.д.
При этом Jev не заменяет классический ML там, где есть много хорошо размеченных данных и одна стабильная задача. И это не замена LLM для сложного reasoning или генерации текста.
Интереснее другое: может появиться отдельный слой между task-specific ML и большими генеративными моделями — достаточно универсальный, чтобы не обучать новую модель под каждое решение, но достаточно специализированный, чтобы работать намного быстрее и дешевле LLM.
Если такой подход действительно удастся масштабировать для реальных приложений, у разработчиков может появиться новый базовый инструмент для создания ИИ-систем — не чат-бот и не обычный классификатор, а модель, которую можно напрямую встраивать в логику программы и использовать для принятия отдельных решений.
На данном этапе модель находится в стадии листов ожидания, и подать заявку можно здесь: https://typesafe.ai/
А буквально утром, пару часов назад, они выкатили доступ и на OpenRouter: https://openrouter.ai/~typesafe/jev-latest
#jev
Буквально пару дней назад в Твиттере многие начали обсуждение новой модели Jev от TypeSafe. Вообще, сначала появился небольшой пост на HackerNews, а затем пошел какой-то невиданный ажиотаж вокруг этой недо-llm пере-ml. Далее расскажу, что в ней особенного.
Jev показался мне интересным не столько как очередная AI-модель, сколько как попытка переосмыслить интерфейс между AI и обычным софтом.
Классический ML обычно решает конкретную задачу: классификация, ранжирование, регрессия. Если появляется новая задача, под неё часто приходится собирать данные и обучать отдельную модель.
LLM пошли в другую сторону: одна универсальная модель может решать огромное количество задач, но взаимодействие с ней обычно происходит через генерацию текста. Даже когда мы просим JSON, внутри всё равно остаётся token-by-token генерация, а значит появляются задержки, стоимость, парсинг и проблемы с надёжностью интерфейса.
Jev предлагает промежуточный вариант. Вместо генерации произвольного текста модель возвращает типизированное решение и вероятность этого решения. То есть AI становится чем-то вроде "вероятностной функции" внутри программы.
Условно:
input → model → { decision, probability } → application logicТо есть модель не генерирует произвольный текст. Вместо этого разработчик задаёт пространство возможных решений, а модель возвращает структурированный результат и confidence.
В таком виде AI становится похож на "вероятностную функцию" внутри обычного software:
if model(x).probability > threshold:
Это особенно интересно для AI workflows и агентов, где не обязательно отдавать модели контроль над всем процессом. Можно декомпозировать workflow на десятки небольших решений: routing, classification, risk assessment, tool selection, human escalation и т.д.
При этом Jev не заменяет классический ML там, где есть много хорошо размеченных данных и одна стабильная задача. И это не замена LLM для сложного reasoning или генерации текста.
Интереснее другое: может появиться отдельный слой между task-specific ML и большими генеративными моделями — достаточно универсальный, чтобы не обучать новую модель под каждое решение, но достаточно специализированный, чтобы работать намного быстрее и дешевле LLM.
Если такой подход действительно удастся масштабировать для реальных приложений, у разработчиков может появиться новый базовый инструмент для создания ИИ-систем — не чат-бот и не обычный классификатор, а модель, которую можно напрямую встраивать в логику программы и использовать для принятия отдельных решений.
На данном этапе модель находится в стадии листов ожидания, и подать заявку можно здесь: https://typesafe.ai/
А буквально утром, пару часов назад, они выкатили доступ и на OpenRouter: https://openrouter.ai/~typesafe/jev-latest
#jev
👍7
Какой язык программирования учить сейчас?
На днях в Твиттере увидел небольшой пост о развитии нейронок и агентов для программирования и то, как это влияет на текущий тренд в использовании языков для разработки проектов. Кратко говоря, там говорилось, что при стирании границ между сложностью изучения языков, ведь для llm вообще без разницы, что использовать, чаша весов будет склоняться в сторону более быстрых и оптимальных языков программирования, вроде Rust или Go. Python же может отойти на второй план.
В общем, мне кажется, что это имеет смысл.
Я работаю сейчас над двумя своими новыми задумками, и с развитием моделей вроде Opus 5 / Fable 5.1, я перестал контролировать выбор языка для написания приложений. После нескольких итераций по архитектуре приложений, выбор был сделан в сторону Rust в одном случае, и Rust / Go в другом. И выбор аргументировался тем, что с ними будет меньше проблем при реализации кода, а также они намного быстрее работают.
К чему это может привести на рынке?
1. На мой взгляд, в течение последующих нескольких лет крупные игроки также начнут оптимизировать свои платформы, снижая затраты на оборудования и нагрузку на него.
2. Знания языков, в плане технических интервью, могут отойти на второй план. На собеседованиях могут начать спрашивать не столько самому написать код, сколько написать запрос в нейронку на создание блока кода с определенным техническим решением. И тут от кандидата потребуется знать намного больше "общей" информации о языках и программировании, чем о формировании циклов в Python или Rust. Нужны будут знания алгоритмов, сетевых архитектур, базовой математики, работы dns и cdn, и т.д.
3. Оценены будут только сеньоры с опытом до бума программирования с нейронками. Вероятно, только они смогут создавать абсолютно новые решения, тем самым двигая и развитие нейронок.
4. Для нас с вами появятся места для поддержания и развития продукта, мелкой разработки и оркестрации потоков агентов.
5. При этом вполне вероятно, что задачи в компаниях уже будут распределяться не тимлидами и руководящими должностями, а другим типом нейронок типа Jev. Это сделает процессы более быстрыми и прозрачными.
Вообще очень интересно к чему это действительно приведет. А какие у вас прогнозы?
#langs
На днях в Твиттере увидел небольшой пост о развитии нейронок и агентов для программирования и то, как это влияет на текущий тренд в использовании языков для разработки проектов. Кратко говоря, там говорилось, что при стирании границ между сложностью изучения языков, ведь для llm вообще без разницы, что использовать, чаша весов будет склоняться в сторону более быстрых и оптимальных языков программирования, вроде Rust или Go. Python же может отойти на второй план.
В общем, мне кажется, что это имеет смысл.
Я работаю сейчас над двумя своими новыми задумками, и с развитием моделей вроде Opus 5 / Fable 5.1, я перестал контролировать выбор языка для написания приложений. После нескольких итераций по архитектуре приложений, выбор был сделан в сторону Rust в одном случае, и Rust / Go в другом. И выбор аргументировался тем, что с ними будет меньше проблем при реализации кода, а также они намного быстрее работают.
К чему это может привести на рынке?
1. На мой взгляд, в течение последующих нескольких лет крупные игроки также начнут оптимизировать свои платформы, снижая затраты на оборудования и нагрузку на него.
2. Знания языков, в плане технических интервью, могут отойти на второй план. На собеседованиях могут начать спрашивать не столько самому написать код, сколько написать запрос в нейронку на создание блока кода с определенным техническим решением. И тут от кандидата потребуется знать намного больше "общей" информации о языках и программировании, чем о формировании циклов в Python или Rust. Нужны будут знания алгоритмов, сетевых архитектур, базовой математики, работы dns и cdn, и т.д.
3. Оценены будут только сеньоры с опытом до бума программирования с нейронками. Вероятно, только они смогут создавать абсолютно новые решения, тем самым двигая и развитие нейронок.
4. Для нас с вами появятся места для поддержания и развития продукта, мелкой разработки и оркестрации потоков агентов.
5. При этом вполне вероятно, что задачи в компаниях уже будут распределяться не тимлидами и руководящими должностями, а другим типом нейронок типа Jev. Это сделает процессы более быстрыми и прозрачными.
Вообще очень интересно к чему это действительно приведет. А какие у вас прогнозы?
#langs
🤔11
Задача с полуоткрытым кодом
На днях, в процессе создания одного приложения, столкнулся с интересной задачей, кейсом которой хочу сегодня поделиться с вами.
История разработки долгая, поэтому опишу ее кратко: в работе я пришел к потребности отслеживать состояние сервера 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, включая полный запуск установки.
Вторая сложность — как доказать, что установилось именно опубликованное. В первом варианте плана человек должен был сравнить скачанный архив с архивом, собранным из открытого кода. Это оказалось невыполнимо: сервер упаковывает архив сам, и байты сжатия могут отличаться. Решение такое: подписывается не архив, а опись версии — список файлов с правами и отпечатком SHA-256 каждого. Подпись делается ключом minisign (Ed25519 поверх хеша BLAKE2b), тем же, которым подписываются обновления приложения, и приложение не ставит версию без годной подписи. Приватная половина ключа хранится только на компьютере разработчика и никогда не попадает ни на сервер, ни в CI. Каталог версии в открытом репозитории — содержимое архива байт в байт, разложенное тем же кодом, которым сервер этот архив раздаёт. В репозитории лежит небольшая утилита на Go: одна команда проверяет подпись, сверяет каждый файл с описью, проверяет, что все образы закреплены дайджестом, а с ключом - archive сравнивает с тегом скачанный архив файл за файлом. Подпись можно проверить и стандартной программой minisign — публичный ключ лежит в репозитории, а его отпечаток опубликован ещё в двух независимых местах.
Третья часть — образы Docker. Раньше я собирал их на своей машине, и связь «этот образ собран из этого кода» держалась на моем честном слове. Теперь образы агента и Caddy собирает GitHub Actions самого открытого репозитория по метке agent-<версия> или caddy-<версия>, сразу для amd64 и arm64. Go кросс-компилируется, а не собирается в эмуляции: под QEMU он у нас однажды намертво зависал. Каждый образ получает аттестацию происхождения через Sigstore — подписанную запись о том, из какого коммита и каким процессом он собран. Проверить её можно командой gh attestation verify. По дороге обнаружилось, что сборка Caddy брала сторонние модули «самые свежие на сегодня», и из одного и того же кода в разные дни получался немного разный результат. Теперь модули закреплены точными версиями, а базовые образы — дайджестами.
На каждую метку версии GitHub запускает публичную проверку. Она сверяет подпись и опись, проверяет аттестацию наших образов и сравнивает исходники агента в коммите, из которого собран образ, с исходниками в метке версии, а заодно ищет в коде случайно попавшие секреты. Красный крестик у метки видят все. Сам CI защищён: все сторонние действия закреплены полным хешем коммита, а не тегом, который автор может передвинуть. У процессов минимальные права, сборка из чужих pull request не запускается вовсе. Опубликованные метки нельзя удалить или передвинуть никому, включая нас, поэтому ошибка в выпущенной версии исправляется только следующей версией. Так и случилось с первым выпуском: мы опубликовали его не в том порядке, и исходники агента в нём на пару комментариев новее образа. Переписывать опубликованное не стали, а написали об этом прямо в README. Начиная со следующей версии такое расхождение ловит автоматическая проверка.
Публикует всё это скрипт: он собирает зеркало строго по белому списку каталогов, сам гоняет те же проверки и откажется публиковать, если нашёл адрес наших серверов, путь с машины разработчика, приватный ключ или токен. Ссылки на открытый код есть на главной сайта (расскажу о нем позже), в документации, на странице загрузки и в самом приложении: на шаге проверки сервера ещё до установки и на экране установки — со ссылкой на метку именно той версии, которая поедет на ваш сервер.
Если все вышесказанное обобщить в пару слов то: я постарался сделать так, чтобы весь код, который будет установлен на сервере клиента мог быть проверен как вручную, так и автоматически. Кроме того, построена достаточно сильная защита от подделки пакета на каком-либо этапе.
Думаю, нужно добавить, что я сам бы такую систему не смог бы придумать, и всю работу сделал Claude Code, объясняя мне каждый этап и отвечая на вопросы "почему и как".
На самом деле, нейронки могут вас очень круто обучить новым сферам разработки, если вы будете не просто соглашаться со всем, что он предлагает, а задавать вопросы и также погружаться в тему.
Третья часть — образы Docker. Раньше я собирал их на своей машине, и связь «этот образ собран из этого кода» держалась на моем честном слове. Теперь образы агента и Caddy собирает GitHub Actions самого открытого репозитория по метке agent-<версия> или caddy-<версия>, сразу для amd64 и arm64. Go кросс-компилируется, а не собирается в эмуляции: под QEMU он у нас однажды намертво зависал. Каждый образ получает аттестацию происхождения через Sigstore — подписанную запись о том, из какого коммита и каким процессом он собран. Проверить её можно командой gh attestation verify. По дороге обнаружилось, что сборка Caddy брала сторонние модули «самые свежие на сегодня», и из одного и того же кода в разные дни получался немного разный результат. Теперь модули закреплены точными версиями, а базовые образы — дайджестами.
На каждую метку версии GitHub запускает публичную проверку. Она сверяет подпись и опись, проверяет аттестацию наших образов и сравнивает исходники агента в коммите, из которого собран образ, с исходниками в метке версии, а заодно ищет в коде случайно попавшие секреты. Красный крестик у метки видят все. Сам CI защищён: все сторонние действия закреплены полным хешем коммита, а не тегом, который автор может передвинуть. У процессов минимальные права, сборка из чужих pull request не запускается вовсе. Опубликованные метки нельзя удалить или передвинуть никому, включая нас, поэтому ошибка в выпущенной версии исправляется только следующей версией. Так и случилось с первым выпуском: мы опубликовали его не в том порядке, и исходники агента в нём на пару комментариев новее образа. Переписывать опубликованное не стали, а написали об этом прямо в README. Начиная со следующей версии такое расхождение ловит автоматическая проверка.
Публикует всё это скрипт: он собирает зеркало строго по белому списку каталогов, сам гоняет те же проверки и откажется публиковать, если нашёл адрес наших серверов, путь с машины разработчика, приватный ключ или токен. Ссылки на открытый код есть на главной сайта (расскажу о нем позже), в документации, на странице загрузки и в самом приложении: на шаге проверки сервера ещё до установки и на экране установки — со ссылкой на метку именно той версии, которая поедет на ваш сервер.
Если все вышесказанное обобщить в пару слов то: я постарался сделать так, чтобы весь код, который будет установлен на сервере клиента мог быть проверен как вручную, так и автоматически. Кроме того, построена достаточно сильная защита от подделки пакета на каком-либо этапе.
Думаю, нужно добавить, что я сам бы такую систему не смог бы придумать, и всю работу сделал Claude Code, объясняя мне каждый этап и отвечая на вопросы "почему и как".
На самом деле, нейронки могут вас очень круто обучить новым сферам разработки, если вы будете не просто соглашаться со всем, что он предлагает, а задавать вопросы и также погружаться в тему.
👍3