37.8K subscribers
1.53K photos
38 videos
5 files
1.69K links
加入频道
Пост об аудите криптографии Go от Trail of Bits

Статья на [go.dev](http://go.dev/blog/tob-crypto-audit) посвящена аудиту безопасности криптографических библиотек Go, проведенному Trail of Bits. Основные моменты:

🔐 Высокая надежность криптографии Go: Аудит подтвердил безопасность криптографических пакетов Go, которые отличаются строгим подходом к безопасности, минимальной сложностью кода и тщательным тестированием. Это обеспечивает защиту от уязвимостей, включая проблемы управления памятью, благодаря свойствам языка Go.

🛠 Единственная уязвимость: Обнаружена одна потенциально эксплуатируемая проблема (TOB-GOCL-3) низкой серьезности в экспериментальной интеграции Go+BoringCrypto, используемой только внутри Google. Уязвимость связана с управлением памятью и уже исправлена в Go 1.25. Она не затрагивает стандартные сборки Go, так как Go+BoringCrypto не включена по умолчанию.

🕒 Тайминговые атаки: Найдены незначительные риски тайминговых побочных каналов (TOB-GOCL-1, TOB-GOCL-2, TOB-GOCL-6). Только TOB-GOCL-2 затрагивает операции с секретными данными, но лишь на платформах Power ISA (ppc64, ppc64le). Все замечания исправлены в Go 1.25.

🔍 Дополнительные улучшения: Аудит выявил несколько информационных замечаний, включая потенциальные риски неправильного использования API (TOB-GOCL-4) и отсутствие проверки недостижимого лимита (TOB-GOCL-5). Эти рекомендации также учтены в разработке Go 1.25.

🚀 Будущее криптографии Go: Команда Go планирует внедрить новые высокоуровневые API, упрощающие выбор безопасных алгоритмов, начиная с API для хеширования паролей с автоматическим переходом на новые алгоритмы по мере развития технологий.

https://go.dev/blog/tob-crypto-audit

@golang_google
👣 Stateless Postgres Query Router — это система шардирования для PostgreSQL-кластера, доступная с открытым исходным кодом. Её основной компонент, роутер, анализирует запросы и определяет, на каком конкретном PostgreSQL-кластере следует выполнить транзакцию или запрос.

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

SPQR поддерживает как запросы к определённому шарду, так и запросы ко всем шардам. В ближайших планах — добавить поддержку двухфазных транзакций и референсных таблиц.

Исходный код SPQR распространяется под лицензией PostgreSQL Global Development Group

⚡️ Ссылки:
🟢https://github.com/pg-sharding/spqr
🟢https://pg-sharding.tech/

@golang_google
Please open Telegram to view this post
VIEW IN TELEGRAM
🕊️ RoadRunner — высокопроизводительный application server на Go. Этот проект заменяет связку Nginx+PHP-FPM, позволяя запускать PSR-7-совместимые приложения с поддержкой HTTP/3, WebSockets и даже Temporal workflow.

Конфигурация через .rr.yaml напоминает docker-compose: можно подключать очереди, кеш и метрики как плагины. Рабочие процессы PHP остаются в памяти, что даёт до 10x прирост скорости против традиционного FPM. Особенно радует встроенная система мониторинга и автоматические рестарты упавших воркеров.

🤖 GitHub

@golang_google
👣 FFmate — умная автоматизация на базе FFmpeg

FFmate — это современный и мощный уровень автоматизации поверх FFmpeg. Он упрощает работу с видео и аудио, превращая хаос транскодирования в чистые, надёжные потоки обработки :contentReference[oaicite:0]{index=0}.

Ключевые возможности

- REST API — программно отправлять и управлять задачами
- Веб-интерфейс — мониторинг и контроль без командной строки
- Watchfolders — автоматически обрабатывать файлы, появившиеся в папке
- Presets — готовые настройки для типичных задач
- Webhooks — уведомления о событиях задач
- Wildcards — универсальные шаблоны для именования и папок
- Hooks pre/post-processing — запуск скриптов до и после задач
- Встроенная очередь — управление приоритетами и параллельностью :contentReference[oaicite:1]{index=1}

Примеры применения

- Автоматическое преобразование видео, извлечение аудио и создание превью
- Постпродакшн-пайплайны и медиа-публикации
- Интеграция с MAM-системами через вебхуки
- Централизованное API-first управление задачами FFmpeg
- Обработка файлов из папки (например, камеры) — всё без ручного запуска :contentReference[oaicite:2]{index=2}

🛠 Архитектура и запуск

FFmate написан на Go, распространяется под лицензией SSPL. В репозитории есть:
- Клиент и сервер (REST API + Web UI)
- Dockerfile и шаблоны для сборки
- Документация и примеры в docs/ :contentReference[oaicite:3]{index=3}

📣 Мнение сообщества

Из обсуждений на Reddit:
> “If you've ever struggled with managing multiple FFmpeg jobs, messy filenames, or automating transcoding tasks, FFmate might be just what you need.” :contentReference[oaicite:4]{index=4}

Это резюмирует суть — упростить задачу массового и автоматизированного транскодирования.

🔗 Полезные ссылки

- GitHub: https://github.com/welovemedia/ffmate
- Документация: https://docs.ffmate.io

@golang_google
Please open Telegram to view this post
VIEW IN TELEGRAM
🛠️ История создания “storage-agnostic” message queue

Контекст:
Работая на Go, автор вдохновился инструментами из Node.js экосистемы (BullMQ, RabbitMQ) и захотел сделать что-то похожее, но с нуля, без зависимостей. Так родилась идея — сначала он создал Gocq (Go Concurrent Queue): простую concurrent-очередь, работающую через каналы.

Основная проблема


Gocq отлично работал в памяти, но не поддерживал устойчивое хранение задач.
Автор задумался: а можно ли сделать очередь, не зависящую от конкретного хранилища — так, чтобы её можно было подключить к Redis, SQLite или совсем без них?

🧱 Как это реализовано в VarMQ

После рефакторинга Gocq был разделён на два компонента:
1) Worker pool — пул воркеров, обрабатывающих задачи
2) Queue interface — абстракция над очередью, не зависящая от реализации

Теперь воркер просто берёт задачи из очереди, не зная, где они хранятся.

🧠 Пример использования

• In-memory очередь:


w := varmq.NewVoidWorker(func(data any) {
// обработка задачи
}, 2)
q := w.BindQueue()


• С SQLite-поддержкой:


import "github.com/goptics/sqliteq"

db := sqliteq.New("test.db")
pq, _ := db.NewQueue("orders")
q := w.WithPersistentQueue(pq)


• С Redis (для распределённой обработки):


import "github.com/goptics/redisq"

rdb := redisq.New("redis://localhost:6379")
pq := rdb.NewDistributedQueue("transactions")
q := w.WithDistributedQueue(pq)


В итоге воркер обрабатывает задачи одинаково — независимо от хранилища.

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

• Гибкость: адаптеры позволяют легко менять хранилище без правок воркера
• Минимальные зависимости: в яд

📌 Читать
⚡️ OneUptime — open-source-платформа для мониторинга всего и сразу. Этот инструмент предлагает готовый комплект: от мониторинга uptime до управления инцидентами. Редкий случай, когда open-source-проект не уступает коммерческим аналогам по функционалу.

Особенность проекта в глубокой интеграция компонентов. Например, при падении сервиса система автоматически создаёт инцидент, уведомляет ответственных через эскалацию и обновляет статус-страницу. Есть даже встроенный APM с трейсами и метриками производительности. Развернуть можно на Kubernetes или через Docker Compose.

🤖 GitHub

@golang_google
🧪 Go synctest — решение для нестабильных (flaky) тестов

Flaky-тесты в многопоточном Go-коде — боль. Новый экспериментальный инструмент synctest из Go 1.24 решает эту проблему с помощью синтетического времени и контроля исполнения goroutine.

📌 Что это такое:
synctest — специальный режим, запускающий тесты в изолированной "песочнице", где:
time.Sleep не ждёт реального времени
• все goroutine исполняются детерминированно
• нет зависимости от планировщика и нагрузки ОС

🔧 Пример:


import "testing/synctest"

func TestSharedValue(t *testing.T) {
synctest.Run(func() {
var shared atomic.Int64
go func() {
shared.Store(1)
time.Sleep(1 * time.Microsecond)
shared.Store(2)
}()
time.Sleep(5 * time.Microsecond)
if shared.Load() != 2 {
t.Errorf("shared = %d, want 2", shared.Load())
}
})
}


Даже с Sleep, результат всегда стабилен. Без synctest такой тест может иногда проваливаться.

⚙️ Преимущества:
Устранение race-условий при тестировании
Нет задержек — Sleep срабатывает мгновенно
Можно тестировать поведение с точностью до микросекунды
Подходит для любых atomic, mutex, select, time.After и др.

🚫 Ограничения:
• Пока экспериментально: нужно запускать с GOEXPERIMENT=synctest
• Не подходит для ввода-вывода, работы с сетью или временем вне "bubble"

📖 Подробнее:
https://victoriametrics.com/blog/go-synctest/

@golang_google
📦 Как оптимизировать struct в Go: выравнивание, паддинг и порядок полей

Когда ты работаешь с Go и структурой данных (`struct`), порядок полей — это не просто эстетика. Это напрямую влияет на:
• размер занимаемой памяти
• эффективность использования кэша
• и в итоге — на производительность твоей программы.

Автор [buarki на DEV.to](https://dev.to/buarki/optimizing-struct-layout-and-padding-in-practice-23p1) показывает, как правильно выстраивать поля в структурах, чтобы избежать лишнего паддинга и сделать struct более компактным и быстрым.

🔍 Что такое padding?

Go автоматически выравнивает поля структур по их размеру. Например:

type Bad struct {
a bool // 1 байт
b int64 // 8 байт
c bool // 1 байт
}

Кажется, что struct должен занимать 10 байт. Но из-за выравнивания Go вставит паддинг, и итоговый размер окажется 24 байта.

Как это исправить?

Меняем порядок полей:

type Good struct {
b int64 // 8 байт
a bool // 1 байт
c bool // 1 байт
}

Теперь структура занимает 16 байт, а не 24 — и всё благодаря грамотному размещению полей.

📌 Рекомендации:

• Сортируй поля от самых крупных к самым мелким
• Группируй однотипные поля
• Избегай перемешивания bool`/`byte с int64`/`float64
• Используй визуализацию (например, viztruct) для анализа struct'ов
• Проверяй размер struct через unsafe.Sizeof()

🎯 Это особенно важно при:
• массовом использовании struct в массивах и слайсах
• передаче struct между потоками
• работе с бинарными протоколами или mmap

📖 Подробнее с примерами: https://dev.to/buarki/optimizing-struct-layout-and-padding-in-practice-23p1
👣 Как предотвратить "молчаливую смерть" горутин в Go?

В статье рассматривается, как реализовать механизм "сердцебиения" (heartbeat) для горутин в Go, чтобы отслеживать их активность и своевременно обнаруживать сбои.

🔍 Зачем нужны heartbeats?
Иногда горутина может завершиться неожиданно без явных ошибок или логов, что затрудняет диагностику. Механизм heartbeats позволяет периодически отправлять сигналы о том, что горутина все еще работает, даже если она ожидает задания. Это особенно полезно для:

Мониторинга состояния фоновых задач

Обнаружения и перезапуска "зависших" горутин

Улучшения надежности и отказоустойчивости систем

🛠 Как это реализовать?
Используя time.Ticker, можно настроить горутину на периодическую отправку сигналов активности через канал. Пример функции dowork:


func dowork(done <-chan interface{}, pulseInterval time.Duration) (<-chan interface{}, <-chan struct{}) {
heartbeater := make(chan interface{})
result := make(chan struct{})
go func() {
defer close(result)
defer close(heartbeater)

pulse := time.NewTicker(pulseInterval)
workGen := time.NewTicker(3 * pulseInterval)

defer pulse.Stop()
defer workGen.Stop()

sendPulse := func() {
select {
case heartbeater <- struct{}{}:
default:
// если никто не слушает, пропускаем
}
}

sendResult := func(res struct{}) {
for {
select {
case <-done:
return
case <-pulse.C:
sendPulse()
case result <- res:
return
}
}
}

for {
select {
case <-done:
return
case <-pulse.C:
sendPulse()
case <-workGen.C:
sendResult(struct{}{})
}
}
}()
return heartbeater, result
}


🧪 А в main можно следить за этим:


for {
select {
case <-heartbeat:
log.Println("Still alive")
case <-time.After(5 * time.Second):
log.Println("Timeout! Goroutine might be dead")
}
}
}()


🎯 Зачем это нужно:
• Обнаружение зависших/умерших горутин
• Реализация watchdog'ов
• Надежность фоновых процессов в проде

🔗 Статья: https://blog.devgenius.io/how-to-build-heartbeats-in-go-let-your-goroutines-say-still-breathing-d047253d5c78

@golang_google
Please open Telegram to view this post
VIEW IN TELEGRAM
🗃️ Stoolap — лёгкая и быстрая SQL-база данных на чистом Go без зависимостей

Stoolap — это современный HTAP-движок (Hybrid Transactional/Analytical Processing), сочетающий OLTP и OLAP в одном ядре. Подходит как для транзакционных задач, так и для аналитики.

🚀 Возможности:
• Полностью написан на Go — никаких внешних зависимостей
• ACID-транзакции через MVCC
• Колонковое хранение с SIMD-ускорением
• Поддержка SQL: JOIN, агрегаты, оконные функции
• Встроенный тип JSON
• Поддержка database/sql и интеграция с GORM
• CLI-режим и in-memory база

📦 Установка:

go get github.com/stoolap/stoolap


🔥 Быстрый старт (CLI):

stoolap -db memory://


📎 Репозиторий: https://github.com/stoolap/stoolap
🌐 Сайт: https://stoolap.io


@golang_google
🏗️ Как строить масштабируемые multi-tenant приложения на Go — опыт Atlas Cloud

В этой статье команда Atlas делится практическими стратегиями масштабирования multi-tenant приложений на Go, основанными на опыте разработки бэкенда для Atlas Cloud — части их коммерческого продукта.

🔍 Что такое multi-tenancy?

Multi-tenancy — это архитектура, при которой один инстанс системы обслуживает сразу нескольких клиентов (арендаторов).

📦 Но тут важен нюанс: клиенты ожидают, что сервис будет работать так, как будто он только для них — без потерь в скорости, надёжности и безопасности.

Именно поэтому вы *молча* обещаете каждому клиенту две вещи:

1. Изоляция данных — никакой арендатор не должен иметь доступ к чужим данным
2. Стабильная производительность — нагрузка одного арендатора не должна замедлять других

🛡️ Стратегия №1 — Физическая изоляция (Dedicated Instances)

Самый прямой способ выполнить эти обещания — запуск отдельного инстанса приложения на каждого арендатора.

Что это даёт:

Данные арендаторов хранятся в отдельных БД (или даже в разных VPC/облаках)
Полная изоляция ресурсов — никто не шумит и не мешает
Безопасность на уровне инфраструктуры

💸 Но у такого подхода есть и минусы:

Сложность в управлении: сотни и тысячи развёрнутых инстансов, каждая со своей БД и конфигурацией
Стоимость: каждый инстанс потребляет ресурсы, и это дорого
Проблемы масштабирования: каждый новый клиент = новый деплой
Сложности с наблюдаемостью: логи, метрики и дебаг — теперь распределены по куче окружений

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

🔗 Продолжение читай тут:
https://atlasgo.io/blog/2025/05/26/gophercon-scalable-multi-tenant-apps-in-go

@golang_google
📦 godump — удобный Go-инструмент для дампа объектов в читаемом виде

godump — это мощная альтернатива fmt.Printf("%#v") и spew.Dump для Go-разработчиков.

Инструмент помогает красиво и наглядно выводить внутреннее содержимое структур, карт, срезов и других объектов.

🛠️ Что умеет godump:
• Красиво форматирует вложенные структуры и срезы
• Поддерживает карты, интерфейсы, указатели, циклы
• Вывод в цвете (ANSI) и с отступами
• Умеет обходить циклические ссылки
• Простой API: godump.Dump(anyObject)

💡 Отлично подходит для:
- Отладки и логирования сложных структур
- Инспекции JSON-данных после анмаршалинга
- Быстрой визуальной проверки содержимого без IDE

🔍 Пример использования:

import "github.com/goforj/godump"

type User struct {
Name string
Tags []string
}

func main() {
user := User{"Alice", []string{"dev", "golang"}}
godump.Dump(user)
}


🚀 Установка:

go get github.com/goforj/godump


🔗 https://github.com/goforj/godump

Если fmt.Println уже не справляется — попробуй godump. Красиво. Быстро. Глубоко.

@golang_google
👣 Tyk Gateway

Это современный, сверхпроизводительный, специально разработанный API-шлюз с открытым исходным кодом.

Tyk Operator предоставляет возможности полного жизненного цикла управления API в Kubernetes. Вы можете настраивать Ingress, API, политики безопасности, аутентификацию, авторизацию, посредничество, используя лучшие практики GitOps с помощью пользовательских ресурсов и примитивов, присущих Kubernetes.

📌 Github

#golang #devops #девопс

@golang_google
Please open Telegram to view this post
VIEW IN TELEGRAM
🏠 MCP для умного дома

Тысячи бессонных ночей сотен ресёрчеров и ML-инженеров дали миру сначала большие языковые модели, а потом MCP-протокол - открытый стандарт, который связал эти модели и дал возможность подключаться к приложениям, системам и API.

Они мечтали о будущем, где ИИ будет решать климатические кризисы, расшифровывать геном, найдет решение глобальных проблем или, в крайнем случае, будет писать вам стихи и поэмы.

Как это используют люди? Пилят действительно важные и нужные интеграции.

Проект поддерживает Ollama, подключение к экосистеме управления умным домом HomeAssistant MCP и написан на Go.


🖥 Github

@golang_google
Please open Telegram to view this post
VIEW IN TELEGRAM
👣 Uzi — параллельный запуск AI-кодинг-агентов из терминала

Проект, который превращает терминал в многопоточную машину для работы с LLM-агентами: Claude, GPT, Aider, Codex и другими.

🧠 Что делает Uzi:
• Запускает несколько агентов параллельно
• Каждому агенту — свой git worktree, tmux и порт
• Можно задавать общую задачу, а агенты предложат решения независимо
• Позволяет наблюдать за прогрессом, подтверждать или отклонять шаги
• Упрощает слияние финальных изменений — без ручной рутины

🛠 Пример:

uzi prompt --agents claude:2,gpt4:1 "Добавь в проект GraphQL API и авторизацию"


Затем:
- uzi auto — агентам можно доверить автоматические действия
- uzi broadcast "Обнови документацию" — отправить команду всем
- uzi checkpoint — сохранить и закоммитить результат

🧪 Идеально подходит для:
— Быстрой генерации MVP
— Прототипирования фичей сразу в нескольких вариантах
— Параллельной работы с кодовыми ассистентами
— Демонстраций, где хочется "показать мощь LLM сразу в действии"

📦 Установка:

go install github.com/devflowinc/uzi@latest


📌 Репозиторий

#AI #DevTools #CLI #LLM #CodeGeneration #OpenSource

@golang_google
Please open Telegram to view this post
VIEW IN TELEGRAM
👣 Представлен язык программирования Gauntlet, расширяющий возможности Go

Доступен первый альфа-выпуск языка программирования Gauntlet, надстройки над языком Go, решающей некоторые архитектурные проблемы и добавляющей дополнительную функциональность.
Программы на языке Gauntlet поддерживают все возможности языка Go, транслируются в представление на языке Go и интегрируются с существующей экосистемой Go без необходимости задействования обвязок (binding).

Развиваемый проектом инструментарий написан на языке F# и распространяется пол лицензией GPLv3. Для работы с кодом предоставляется дополнение к редактору VSCode.

Решаемые в Gauntlet проблемы:

• Назойливый вывод ошибок, связанных с неиспользуемыми переменными (Gauntlet добавляет для всех неиспользуемых переменных заглушки вида "_ = a").
• Раздутый код для обработки ошибок. В Gauntlet вместо условных блоков вида "if err != nil" используются однострочные выражения "try-with".
• Назойливый способ импорта и экспорта (например, в Go необходимо, чтобы экспортируемые имена начинались на заглавную букву).
• Отсутствие тенарного оператора. В Gauntlet можно использовать выражения вида 'let properWord = @String len(lines) > 1 ? "lines" : "line"'.
•Отсутствие синтаксиса switch-case.
• Усложнённые циклы "for". В Gauntlet можно писать "for let _, c in "Hello" {" вместо "for _, c := range "Hello" {".
• Необычный оператор присваивания (":=" для одновременного объявления и инициализации переменных; "=" для изменения значения уже объявленных переменных).
• Невозможность вызова функций по цепочке (в Gauntlet поддерживается вызов вида 'let trimmedLines = fileContentStrVersion => strings.trimSpace(_) => strings.split(_, "\n")'.

Расширенные возможности Gauntlet:

• Синтаксис "when-is" похожий на switch.case, но манипулирующий выражениями.
• Поддержка pipe-каналов, позволяющих по цепочке пропускать значение через несколько выражений или функций. например "10 => add(_, 10) => add(_, 30) => divide(_, 2)".
• Выражения "try .. with" и "force .. with".
• Выражение "wrapper" для создания псевдонимов типов (например. "wrapper Int Dollars").


✔️ Github
✔️ Gauntlet
✔️ Новость

#Gauntlet #golang

@golang_google
Please open Telegram to view this post
VIEW IN TELEGRAM
📡 apimocker — простой мокер REST API без бэкенда

apimocker — это легкий TUI-инструмент на Go, который поднимает фейковый API из YAML/JSON за секунды. Идеален для фронтенда, тестов и прототипов.

🛠 Что умеет:
• Динамичные JSON-ответы с шаблонами ("id": "uuid", "email": "email")
• Задержки, ошибки с вероятностью
• Отдача файлов (изображений и др.)
• Логирование (plain/json)
• TUI-интерфейс с активными маршрутами

💡 Подходит для:
• Быстрого мокинга
• Демонстраций и тестов
• Изоляции от реального API

🚀 Установка:

yay -S apimocker # Arch
# или:
git clone https://github.com/Hanashiko/apimocker.git
cd apimocker && go build -o apimocker main.go
sudo mv apimocker /usr/bin/

🔗 https://github.com/Hanashiko/apimocker

Нужен API-сервер без сервера? Используй apimocker.

@golang_google