Я не программист, языков не знаю, я небольшой руководитель отдела в айти, неплохо знаю серверную архитектуру. Но у меня была простая боль: недавно завел для себя и родни сервер Hysteria 2, до этого было с VLESS на сервере и устал каждый раз руками править YAML, когда нужно:

добавить или удалить пользователя, выдать доступ, проверить статус, перезапустить сервис и при этом ничего не сломать

Перерыл интернет и какое было мое удивление, когда я не нашел ничего, абсолютно, то есть единственное решение - либо лазить каждый раз на сервер либо сделать самому.

Сразу честно: делал с помощью LLM. Статью эту тоже, кстати. Панаму я приготовил. Цель статьи не выпендреж, а просто рассказать о боте, что бы его уже нормальные разработчики посмотрели переделали, может на основе его сделали адекватный продукт

Почему не SSH?

Да, можно через SSH, nano и systemctl. Но когда делаешь это регулярно — растёт шанс ошибки.

Хотелось проще: открыть Telegram, нажать пару кнопок и выдать доступ без ручного редактирования config.yaml.

Веб-панель тоже рассматривал, но бот оказался быстрее и удобнее “на ходу”.

Что умел MVP

Минимум, который был нужен:

/status — жив ли сервис /users — список пользователей add / delete / enable / disable генерация hy2:// ссылки /logs — последние логи /restart — перезапуск с подтверждением

Звучит просто. Пока не думаешь о безопасности.

Главная проблема: бот ≠ root

Первая (и плохая) идея — дать боту полный доступ: пусть сам правит YAML, дергает systemctl и читает логи.

Это почти готовый root-доступ извне.

Я сделал иначе:

Бот — это интерфейс, не исполнитель.

Бот хранит данные (SQLite) Все опасные действия делает отдельный helper на сервере Helper: генерирует YAML делает backup валидирует только потом применяет и перезапускает

В sudoers разрешены только конкретные команды helper-а, а не shell.

Безопасность (без этого смысла нет)

Сделал максимально жёстко:

deny by default доступ только по Telegram user ID (не username) админ-команды только в личке в группах — никаких опасных действий delete/apply/restart — через подтверждение audit log: кто, когда и что сделал

Бот должен быть параноидальным, а не “удобным для всех”.

Грабли, на которые я наступил

1. Права на конфиг permission denied на /etc/hysteria/config.yaml — лечится не перезапуском, а нормальными правами.

2. Cert/key Один неправильный путь — сервис не стартует. Плюс легко сломать доступ к privkey.pem.

3. URI и userpass

hy2:// и hysteria2:// формат username:password спецсимволы нужно кодировать

Очень легко получить “почти рабочую” ссылку.

4. Клиенты На iOS импорт URI иногда работает хуже, чем ручной ввод.

5. OpenWrt + sing-box Сначала “не работает”, потом “работает, но не так”, и только после настройки DNS и роутинга — всё нормально.

Что получилось

Сейчас это нормальный админ-пульт:

управляю доступами из Telegram не трогаю YAML руками опасные действия подтверждаются и главное — нет полного root-доступа у бота

Удобство появилось без видимых дыры в безопасности.

Про LLM

Да, я использовал нейронку. Но это не “магическая кнопка”.

Без продуманной архитектуры (права, границы, apply, валидация, rollback) получилась бы просто опасная игрушка.

Что бы сделал иначе сразу делал бы helper-архитектуру добавил бы audit log с самого начала разделил бы read и write операции по правам сделал бы preflight-проверки перед apply

Что дальше

Планирую:

улучшить UX, возможно добавить лёгкую веб-панель, оставить Telegram, как быстрый пульт

Уверен, что в коде кучу дыр в безопасности, еще раз говорю, я код не знаю, мои были идеи, промты и направление, как сделать лучше на самом сервере.

P.S. Это моя первая статья, готов ко всем минусам, хейту и так далее. Единственная цель этого поста - рассказать о боте и дать его в народ

ссылка не репу https://github.com/Ramisya4ka/hysteria-bot-manager (внутри есть очень подробное Readme)

Меня зовут Виталий, я из команды ArcaneGaming.
Сегодня я хочу рассказать вам о своем пет-проекте, который немного вышел из-под контроля и превратился в полноценный продукт.
Встречайте - Snuffer !

😫 С чего всё началось?
Знаете это чувство, когда вам пишет клиент (или, что еще хуже, мама):

"А почему сайт не открывается?"
И ты такой:
"Да ладно, у меня всё работает!"
А потом оказывается, что сервер упал 3 часа назад, база данных ушла в дедлок, а ты в это время спокойно пил кофе и смотрел мемы.

Я перепробовал кучу сервисов: UptimeRobot, Pingdom, Better Uptime. Они крутые, спору нет.
Но:

• Дорого , если нужно много проверок.

• Ограниченные локации . Иногда нужно проверить доступность именно из конкретной сети или региона.

• Скучно . Где веселье в том, чтобы просто заплатить денег?

И тут я посмотрел на ящик своего стола. Там лежали они... Герои прошлых лет. Samsung Galaxy S7, какой-то старый Xiaomi с треснутым экраном и Pixel первого поколения. Они смотрели на меня своими пыльными камерами и шептали: "Мы еще можем быть полезны..."

И меня осенило! 💡

А что, если использовать эти устройства как узлы мониторинга? 
Ведь смартфон - это мощный компьютер с Wi-Fi и GSM модулем. Он может пинговать, делать HTTP-запросы, проверять порты. И если раздать такие телефоны друзьям в разных городах (или просто подключить к разным провайдерам), получится настоящая распределенная сеть мониторинга .
Так родился Snuffer

📱 Что такое Snuffer?
Если говорить умными словами, это распределенная система мониторинга доступности сервисов с использованием мобильных агентов .

"Давай короче, что это такое?":

1. Вы регистрируетесь в админке .

2. Скачиваете Android-приложение .

3. Сканируете QR-код.

4. БУМ! Ваш телефон превращается в "Снуффера" (нюхача), который постоянно проверяет, живы ли ваши сайты.

🛠 Что он умеет?

• HTTP / Keyword Monitor : Проверяет, отдает ли сайт 200 OK и есть ли на странице нужное слово (например, "Success"). Если нет - бьет тревогу.

• Ping / Port Monitor : Пингует серверы и проверяет открытые порты (полезно для баз данных или кастомных сервисов).

• DNS Monitor : Следит, чтобы ваши домены резолвились куда надо (а не на фишинговые заглушки).

• Vulnerability Scanner : В админке есть встроенный сканер уязвимостей! (Но я пока его еще не сделал, но обязательно доделаю, честно!)

• Telegram Бот : Уведомления прилетают мгновенно. Потому что почту мы читаем редко, а телегу - каждые 5 минут.

🤓 Немного "под капотом"
Я люблю, когда всё работает быстро и четко. Поэтому стек выбрал проверенный и надежный:

• Backend : Node.js + Express (старая добрая классика).

• Database : PostgreSQL + Prisma (потому что писать SQL руками в 2025 — это моветон, хотя я умею!).

• Frontend : React + Tailwind CSS (чтобы было красиво и адаптивно).

• Mobile : React Native / Expo (одна кодовая база, минимум боли).

Самое интересное - это архитектура .
Сервер раздает "задачи" (tasks) подключенным устройствам через WebSocket. Устройства выполняют проверки и шлют отчеты обратно.

Если устройство говорит "Сайт лежит", сервер не верит ему на слово (вдруг у телефона просто Wi-Fi отвалился?). Он ждет подтверждения от других узлов или от самого сервера. Это минимизирует ложные срабатывания.

🌍 Почему это круто?

1. Вторая жизнь вещам . Ваши старые гаджеты не загрязняют природу, а приносят пользу. Экологично! 🌱

2. Полный контроль . Вы сами выбираете, откуда мониторить. Хотите проверить доступность из офиса конкурента? Просто подбросьте им телефон с Snuffer (шутка... или нет?).

3. Бесплатно (почти). Вы платите только за электричество для зарядки телефона.

Проект живет и развивается. Сейчас я выкатил версию v4.15.11 (да, мы часто обновляемся!).
В планах:

• iOS версия (Apple, пустите в AppStore, ну пожалуйста!).

• Больше типов проверок (например, скриншоты сайтов).

• Публичное API.
  

  Если вам интересно попробовать или просто потыкать палочкой — залетайте:
  👉 snuffer.net

Буду рад любому фидбеку, критике или просто комментариям.

Если вы работаете с AI-агентами для написания или ревью кода, то знаете эту боль: агент не знает ваш проект. Каждый новый чат — с нуля. Агент начинает читать, читать, читать... И часто читает то что вообще не нужно. Чтобы он хоть что-то понял, нужно дать контекст.

Агент видит список файлов, но не понимает, что в них без прочтения всего файла.
Это не всегда требуется - для мелких задач часто нужно работать с несколькими файлами и в целов читать нужно срез проекта а не проверять все

Я написал небольшую CLI-утилиту для саммаризации файлов в проекте через LLM.

Запускаешь sumr в корне проекта — и получаешь дерево файлов, где у каждого файла есть однострочное описание от LLM:

src/
├── cli.ts          Entry point, Commander.js commands and orchestration
├── scanner.ts      Recursive file walker with regex include/exclude filters
├── summarizer.ts   OpenAI-compatible API pool with concurrency control
└── renderer.ts     Terminal tree output with chalk coloring

Добавляешь агенту инструкцию начинать задачи с этой команды.

Внутри утилита рекурсивно обходит директорию, фильтрует файлы по настраиваемым regex-паттернам, потом отправляет каждый файл в LLM с просьбой дать однострочное описание. Запросы идут параллельно, результаты кэшируются в комментарии в файле — при повторном запуске уже обработанные файлы пропускаются.

Инструмент совместим с любым OpenAI-совместимым API. Можно подключить LM Studio или Ollama - справляются мелкие вроде новых Qwen 3.5 0.5b, 1.5b, 3b.

Ещё начал делать режим паттернов без LLM — извлечение комментариев и сигнатур по regex. Пока не уверен, нужно ли это кому-то.

Первый запуск:

npm i summariser -g
sumr config init

Далее в папке проекта:

sumr

Если добавили новые файлы sumr обработает их а кэш не тронет

Для очистки кэша:

sumr clear

Для обновления кэша:

sumr rescan

Я добавил такую инструкцию в CLAUDE.MD и он буквально сразу начинает с тех файлов которые нужны.

* Всегда начинай ЛЮБУЮ задачу с команды 'sumr' для получения общей структуры проекта и понимания, где что находится.

Хотя вопрос экономии конечно открытый - тут по разному бывает экономит прям нормально не читая весь проект ради вычленения 1-го модуля, а бывает работает на уровне обычного regex-поиска. Но результат лично мной ощущается!

Для саммари использую новый qwen 3.5 0.8b - мелкая моделька в lm studio

Если этот подход будет интересен и имеет смысл - могу поразвивать утилиту или принять любого кому интересно развить. Возможно что то можно доработать чтобы это было удобнее

Много времени на это не тратил любую обратную связь приму по возможности )

Репозиторий: https://github.com/BuddaArt/Summariser

Как?

Реально, как? Скажите мне. Почему это происходит так..

Даль сформулировал свою позицию в посте в X: «Это говорили уже тысячу раз, но я тоже вставлю слово: времена, когда код писали люди, закончилась. Это тревожно для тех из нас, кто называет себя инженерами ПО, но от этого не менее верно. Это не значит, что у инженеров больше не будет работы, но про написание синтаксиса напрямую она больше не будет».

Обо мне: 40 лет, из которых 17 лет в коммерческой разработке. Прошел долгий путь как в fullstack-разработке (web), так и в создании embedded-решений (каршеринг), администрировании и DevOps.

Раньше мой процесс найма редко выходил за рамки одного интервью. Сейчас же я регулярно сталкиваюсь с многоступенчатыми отказами, иногда даже на этапе HR-скрининга. Этот контраст заставил меня задуматься: что делает найм эффективным, а что превращает его в фарс? Решил систематизировать свои наблюдения и поделиться тем, что в современных собеседованиях кажется здравым, а что — откровенно лишним.

Описываю позитивные практики, с которыми сталкивался, практики за которые я уважаю потенциальных работодателей и команды. Это парадигма, в которой я вёл деятельность с начала карьеры.

1. Диалог на равных.
   Мое лучшее интервью: техлид не мучил теорией, а предложил обсудить реальную дилемму, которую он решает в данный момент (внедрение NoSQL-хранилища ради одного специфичного сервиса, т.е. доп. точка отказа vs производительность). Без таймера и стресса мы искали решение. Итог — оффер и годы отличной работы.

2. Проверка логики, а не памяти.
   Люблю кейсы в духе: «Вот дано А, почему происходит Б?». Из банального: может ли Вася из другого города достучаться до вашего локального IP? Это показывает понимание базы лучше любого теста.

3. Ценность универсальных знаний.
   Универсальные знания долгое время позволяли быстро находить решение практически любой проблемы от хардверной, до нарушения самых элементарных паттернов проектирования в коде и эффективно их устранять. Мне нравятся задачи, где проблема может быть скрыта на любом уровне и нравятся клиенты, понимающие, как я могу снять их головную боль обеспечив работоспособность ПО в любой среде и условиях.

А теперь я хочу описать то, от чего меня бомбит. Это факторы которые будут отпугивать меня вплоть до момента, когда будет нечего кушать и я буду вынужден прогнуться под выгодное предложение.

1. Лайвкодинг.
   В 40 лет написание кода для меня — процесс интимный... хотя я практикую парное программирование в реальной команде и это мне нравится, но в предвкушении собеседований иногда хочется "психануть" и на предложение выбрать время для лайвокдинга сказать — "предлагаю парное программирование с одним из ваших специалистов, ведь для меня тоже важно, с кем я буду вести разработку". (Не пробовал так отвечать, но попробую, как только выдастся случай).

2. Вакансии-обманки.
   Зачем заманивать стеком DevOps (Linux, Nginx, Ansible, Terraform, Puppet, Docker, Kubernetes, MySQL, PostgreSQL, Elasticsearch, Logstash, Kibana, Zabbix), если по факту сообщаете, что ничего этого не будет, а ищите классического сисадмина 9-18? — Давайте адкеватный запрос, а не тратьте время.

3. Терминологическая каша. Сложно отвечать экспертно, когда интервьюер путает CI и OCI или Redis и Rabbit. Если нет погружения в контекст, конструктивного диалога не выйдет. Готовиться к собеседованию должен не только соискатель, но и тот, кто нанимает.

4. Отсутствие пунктуальности.
   Для меня было шоком, что фаундер может просто не явиться на собседование, или рекретер забывает о диалоге и назначенной встрече. У вас там всё нормально?) Хотя рекрутер мало чем отличается от агента недвижимости, но фаундер забывающий про собеседование для меня персонаж странный.

5. Узкая специализация.
   Раньше, как мне кажется, ценилась универсальность, способность разработчика понимать инфраструктуру, а инженера/админа — код. Сегодня индустрия уходит в жесткую сегментацию, видимо, для более точного просчёта рисков. А я считаю, что именно универсальность — это страховка проекта от того, что решение будет принято в вакууме одного стека, без учета общей картины.

API-ключ — это уникальный набор символов, который подтверждает, что запрос к API отправлен авторизованным приложением. Он помогает управлять доступом, считать обращения и защищать данные.

Чтобы использовать API-ключ, нужно:

1. Получить его в личном кабинете сервиса.

2. Добавить в запрос — обычно в заголовке Authorization.

3. Следить за безопасностью: не хранить ключ в коде и регулярно менять.

Пример запроса в Node.js:

const axios = require('axios');

const API_KEY = process.env.MY_API_KEY;

axios.get('https://api.example.com/data', {

  headers: { 'Authorization': Api-Key ${API_KEY} }

})

.then(r => console.log(r.data))

.catch(e => console.error('Ошибка', e.response?.status));

В базе знаний Рег.облака поделились подробной инструкцией: как создать, подключить и защитить API-ключ. Заходите, сохраняйте и используйте :) 

На днях стало известно о компрометации почти 2-х десятков npm-пакетов (подробнее в этой статье). Зловредный код может похищать криптовалюту. Это не первый раз, когда в зависимости попадает зловред (например, в 2022 году зловред удалял данные).

Один из вариантов поиска наличия скомпрометированных пакетов среди сотен проектов - использование Dependency Track. При этом поиск возможен и в транзитивных зависимостях тоже. На картинке ниже показан процесс. Заходим в раздел "Components", вводим название в формате "pkg:npm/$name$". Далее остаётся отсортировать по версии и найти среди них скомпрометированную (сейчас это легко - нужно смотреть самую старшую версию). Можно поиск производить сразу по конкретной версии. Пример:

pkg:npm/simple-swizzle@0.2.3

Если пакет нашёлся - можно не только узнать в каком именно проекте, но и увидеть где именно в дереве зависимостей проекта используется (нажать на иконку, обведённую красным).

Если знаете альтернативные варианты поиска скомпрометированных пакетов другими средствами - напишите в комментариях.

баг, который 'уже почти пофиксили' никуда из прода не девался
фича, которую 'вот-вот запустим' — всё ещё в черновиках
команда уже тихо ненавидит слово 'архитектура'

А техлид? Техлид как будто ничего не замечает.
Как это работает (точнее, не работает)
Слова вместо кода

вместо пулл-реквестов - диаграммы.
демо нет - зато вот вам слайды.
вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').

Бесконечный 'анализ'

'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться'
'Это нетривиальная задача' = 'Мне лень разбираться'

Ответственность - это не про нас
Любимый приём - щедро размазать вину:

'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').

Реальный кейс (чтобы было не абстрактно)

В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу.
Провёл 8 митингов, написал 50 страниц документации.

А потом... уволился.

Оставив после себя:
красивые схемы в Confluence
ни одной строчки кода
команду, которая теперь на рефакторинг смотреть не может

Как понять, что ваш техлид центральная часть системы самообмана?

главный результат его работы - не код, а презентации
коронный вопрос - 'А как мы это будем масштабировать?' (но не сам масштабирует)
после разговора с ним хочется или закодить, или закопать

Что прикажете с этим делать?

тупо запретить 'стратегировать' без кода*
нет пулл-реквеста - нет права говорить про архитектуру.

ввести 'день испанского стыда'
раз в месяц техлид показывает руками, что сделал. Не слайды - код.

Задавать всего один вопрос

'Что конкретно изменится после твоего решения?'
Если ответ начинается со слов 'теоретически....' - это тревога.

Вывод
Хороший техлид — не тот, кто красиво говорит о проблемах.
А тот, кто их решает.

Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.

P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение

Сегодня мы выпускаем функционал расширенных алертов.

Теперь каждый наш пользователь сможет получать уведомления в специальный бот, если:

1. Проект ушел в ошибку.

2. Произошло превышение ОЗУ или ЦПУ выше заданного порога

3. Сработала Liveness или Readiness проба.

4. Произошла ошибка сборки или запуска проекта.

5. Встретилась заданная фраза в логе.

Amvera Cloud — это облако для простого деплоя приложений через git push. Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS или Kubernetes-кластера.

C 14 января 2025 в Amvera Cloud доступны RabbitMQ и Memcached.

Для создания достаточно выбрать необходимый сервис в разделе «Преднастроенные сервисы» и заполнить название и несколько переменных.

В ближайшее время планируется релиз отдельного сервиса управления очередями.

Amvera Cloud — это облако для простого деплоя приложений через git push. Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS или Kubernetes-кластера.

Многие ждали, писали, но нет, мы цены повышать не будем!)

Зато сразу после 1 января праздников, ориентировочно 13—17 января

1. Выкатим новый фронт. Надеемся, все станет понятнее.

2. Появятся преднастроенные RabbitMQ и Memcached.

3. Расширенные алерты и пробы. Можно будет настроить алерты на падение проекта, превышение заданного потребления ОЗУ и CPU и появления определенных ошибок в логах. Дополнительно появятся liveness и readiness пробы.

4. Мы вводим SLA. Осенью 2024 были инциденты с падением сервисов. Мы готовы нести ответственность за безотказность работы сервиса. Начиная с января 2025, если наша надежность окажется ниже 99,5% в месяц, можно будет претендовать на компенсации с нашей стороны.

SLA действует с 1 января 2025

Amvera Cloud — это облако для простого деплоя приложений через git push. Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS или Kubernetes-кластера.

Привет всем! Мы в MetaLamp давно занимаемся обучение разработчиков, у нас есть свои программы обучения по фронтенду и бэкенду, а недавно мы запустили обучения по смарт-контрактам Solidity и фронтенду в web3.

Теперь мы решили расширить список наших курсов и создали программу обучения по Node.js в связке с web3.

Почему все говорят про Node.js

Node.js уже давно стал одним из главных инструментов для разработки серверной части. Его используют, чтобы строить быстрые и масштабируемые веб-приложения и не только. К примеру, Netflix, LinkedIn и Uber сделали Node.js значимой частью своей инфраструктуры. Так что эта платформа не просто тренд, а эффективный инструмент.

Кроме того, JavaScript (js), на котором базируется Node.js, занимает лидирующие позиции среди языков программирования. И это легко объяснить. Он универсален, используется как на фронтенде, так и на бэкенде, и у него огромное сообщество. Node.js уверенно стоит на первом месте среди серверных технологий. Освоивший ноду, во-первых, станет специалистом по серверным технологиям. Во-вторых, сможет легко изучить фронтенд и перейти в лигу fullstack.

И еще одна приятная деталь: зарплаты в этой сфере радуют. По данным Хабр Карьера, джуниоры на Node получают около 85 тысяч рублей, мидлы — 220 тысяч, а сеньоры могут зарабатывать до 330 тысяч рублей в месяц.

Читайте подробнее о программе в нашей новой статье!

В нашем телеграм-канале мы часто обсуждаем новые инструменты для разработчиков, делаем обзоры продуктов и все вместе обсуждаем новости. В комментариях под постами  — у нас отдельный холивар. Присоединяйтесь!

В Сравни мы используем NestJS, широко применимый фреймворк для Node.js-разработки, который из коробки умеет в Dependency Injection.

Ранее на внутреннем митапе разобрали основы внедрения зависимостей (ссылка ниже) — теперь же рассмотрели динамическое создание и удаление модулей.

В частности:

• Правила: что от чего не должно зависеть

• Какие ставить для себя ограничения

• Как хранить сервисы на нужных уровнях/слоях

• Как избежать циклической зависимости

• forRoot/forChild

• Возможно ли сделать hot module replacement в работающем сервисе

Посмотреть запись митапа можно здесь:

✅YouTube

✅RUTUBE

✅VK

Запись нашего первого митапа по DI доступна в этом плейлисте.

Поддержка TypeScript включается при помощи опции "--experimental-strip-types" и сводится к очистке специфичных для данного языка определений типов, то есть преобразованию перед выполнением исходного кода в JavaScript.

Не связанные с описанием типов возможности TypeScript пространства имён, декораторы, свойства параметров и перечисляемые типы (enum) пока не поддерживаются. Протестировать новую опцию можно в ночных сборках Node.js 23.

Для трансляции задействован компилятор SWC (Speedy Web Compiler), написанный на языке Rust. Чтобы не добавлять дополнительные зависимости к Node.js, задействовано представление компилятора swc/wasm-typescript в промежуточном коде WebAssembly и уже применяемое для тех же целей в платформе Deno.

Это изменение добавлено в ответ на просьбы пользователей реализовать возможность запуска кода на TypeScript без установки внешних загрузчиков и дополнительных зависимостей. В проектах Deno и Bun поддержка TypeScript реализована изначально.

Ключевым отличием TypeScript от JavaScript является явное определение типов. Статическая типизация позволяет избежать многих ошибок в процессе разработки, даёт возможность задействовать дополнительные техники оптимизации и упрощает отладку.

В добавленной в Node.js реализации данные возможности TypeScript теряются, в процессе трансляции исходных текстов в JavaScript проверка типов не осуществляется.

Источник: OpenNET.

Команда Honeypot выпустила документальный фильм об истории Node.js. В часовом видео подробно рассказали о том, как создавали популярную среду выполнения кода на JavaScript. Фильм продолжает серию, в которой уже есть следующие документальные картины: 

• Ruby on Rails;

• React;

• Prometheus;

• Vue.js;

• GraphQL;

• Ember.js;

Elixir.

Доступ через VPN пока работает, но мы с друзьями подумали, что это неудобно, и опубликовали документацию OpenAI у себя:

https://openai-docs.ru

Более того, с помощью GPT-4 мы перевели содержание на русский язык и где возможно, заменили ссылки на дополнительные статьи (Wikipedia и подобные) на русскоязычные версии. За бесплатный доступ к GPT-4 для нашего проекта благодарим  ProxyAPI — доступ к OpenAI API в России. 

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

• CVE-2024-21892 — возможность подстановки непривилегированным пользователем кода, наследующего расширенные привилегии, с которыми выполняется рабочий процесс;

• CVE-2024-22019  — отказ в обслуживании через исчерпание доступных ресурсов (нагрузка на CPU и расходование пропускной способности) при обработке встроенным HTTP-сервером специально оформленных chunked-запросов;

• CVE-2024-21896 — выход за границу базового каталога в файловых путях, уязвимость позволяет обойти нормализации файловых путей при помощи path.resolve() в случае передачи пути с использованием класса Buffer;

• CVE-2024-22017 — вызов setuid() не сбрасывал все привилегии;

• CVE-2023-46809 — уязвимость в API privateDecrypt(), допускающая применение атаки Marvin для расшифровки RSA на основе измерения времени операций;

• CVE-2024–21 891 — возможность обхода модели прав доступа при использовании пользовательских обработчиков нормализации файловых путей;

• CVE-2024-21890 — некорректная обработка масок в параметрах "--allow-fs-read" и "--allow-fs-write";

• CVE-2024-22025 — отказ в обслуживании через израсходование ресурсов при декодировании сжатых данных в формате Brotli, полученных через вызов fetch().

Источник: OpenNET.