Go *

NotCVE-2025-0003 и NotCVE-2025-0004

Продолжаю по мере сил пополнять базу проекта NotCVE информацией о проблемах безопасности, которым разработчики не желают присваивать CVE (делал заметку об этом проекте). В этот раз одна проблема в компиляторе Go привела к регистрации сразу 2-х записей:

• NotCVE-2025-0003

• NotCVE-2025-0004

Т.к. помимо самого компилятора Go, пострадал и Kubernetes:

The Go team has released a fix in Go versions 1.21.11 and 1.22.4 addressing a symlink race condition when using os.RemoveAll. The Kubernetes Security Response Committee received a report that this issue could be abused in Kubernetes to delete arbitrary directories on a Node with root permissions by a local non-root user with the same UID as the user in a Pod.

Из сообщения в гитхабе Kubernetes видно насколько заразительна тенденция вместо регистрации CVE называть фикс проблемы безопасности хардерингом:

The Go team has not issued a CVE for this, as it is considered a hardening issue, and the SRC is following that decision as well.

Собственно, в случае с Docker в этом году было то же самое, для них это тоже хардеринг (моё обращение в MITRE так и не привело к появлению CVE, поэтому я зарегистрировал NotCVE-2025-001).

Как видно, ситуации, когда проблемы безопасности не приводят к появлению CVE случаются не редко. А некоторые разработчики даже пытаются оспаривать назначение CVE.

Привет Хабр! Это мой первый пост, и я просто хотелось спросить, стоит ли уходить в Go? У меня есть небольшая база в программировании, делал сайты на реакт и ларавел, реализовывал бэкенд с Солид и паттернами, писал на нативном пхп файловые обменники и апи. Не много знаю базы данных соответственно, гит, докер. Сейчас засматриваюсь на Go, где то вычитал что мол крутая штука для бигтехов в России, а сам я студент и пока сижу на шее у родителей, но в следующем году я окончу к курс, и хочу где то месяца за 4-5 изучить все нужное в го и во всех других сопутствующих технологиях для разработки высоконагруженных приложений и микросервисов и всякого подобного. Стоит ли сворачивать на этот путь, или добить стек ларавел плюс вью? Немного боюсь, так как слышал что в го нужны уже 25 летние синьоры со стажем работы минимум в 20 лет, но и не хочется проторчать всю жизнь в челябинской галере на фуллстеке за 70 деревянных на руки.

Хочу поделиться с вами видением хорошей архитектуры Go проекта, к которой я пришёл на данный момент и также интересно послушать ваши варианты и мнения по данному поводу.

Моё видение:

У нас ядро приложения это сервисный слой (юзкейсы), именно ядро самая основная часть приложения, которая взаимодействует с какой‑то логикой.

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

Так как мы не хотим, чтобы логика из ядра уходила во внешние компоненты (по моему мнению, это повлечет переплетение зависимостей и нарушение принципов разделения ответственности), то вся логика должна выполняться на уровне ядра (например, вместо default значений полей в базе, мы создаём модель на уровне ядра, а база служит лишь в качестве хранилища, не выполняя какой‑либо бизнес логики). То есть бизнес‑валидация (инварианты агрегатов) остаётся в ядре, а адаптеры проводят schema‑валидацию (обязательные поля и форматы) до передачи в юзкейсы, тем самым мы избегаем лишних вызовов ядра (при некорректных данных), и не засоряя само ядро валидацией (отличным примером служит то, когда HTTP адаптер валидирует модель до передачи её в юзкейсы).

При этом всё, самое лучше место для интерфейсов (портов) будет отдельный пакет в ядре, к которому могут иметь доступ адаптеры, чтобы проверить реализации контракта (при это адаптеры будут "знать" лишь интерфейсы, а не весь сервисный слой, если бы порты хранились бы в месте использования), а также сами сервисы могут спокойно ссылаться на данные интерфейсы, не подтягивая их с адаптеров (в том случае, если бы мы хранили интерфейсы по месту имплементации).

То есть я считаю идеальной архитектурой для большинства Go проектов, работающих на основании адаптеров (к примеру, REST или gRPC сервис) гексагональную архитектуру с включением подхода DDD.

У меня остались также холиварные вопросы к вам. Как считаете:

• Передавать в юзкейсы структуру или поля по отдельности?

• Должно ли хранилище, в виде БД например, иметь валидацию данных? Операции по крону? Дефолтные значения полей?

• Транзакции: где их начинать/заканчивать?

• Когда и где вводить versioning: в HTTP‑уровне, в домене (разные агрегаты) или в репозиториях (Multi‑tenant)?

• Должны ли доменные ошибки возвращать rich‑error (с кодом/контекстом) или достаточно обычных error с текстом?

Мои коллеги по ИТ-компании "Криптонит" пишут на Go. Я попросила их придумать ошибку — сможете её найти? Ждём в комментариях ваши варианты.

package main

import "fmt"

type User struct {
 name string
 meta map[string]string
 }

func (u *User) SetMeta(key, value string) {
 u.meta[key] = value
 }

func main() {
 u := &User{name: "Alice"}
 u.SetMeta("role", "admin")
 fmt.Println("Meta:", u.meta)
 }

.

.

.

ОСТОРОЖНО! ДАЛЬШЕ СПОЙЛЕР

В main() мы создаём указатель на User, но не инициализируем вложенную map[string]string (Meta)

Присвоение значения через u.Meta[key] = value, вызовет панику (panic: assignment to entry in nil map), потому что u.Meta всё ещё nil, и в Go нельзя присваивать значения в nil-мапу.

Одним из вариантов было бы добавить функцию NewUser(), создавать пользователя через нее, и сразу инициализировать мапу:

 func NewUser(name string) *User {
 return &User{
 name: name,
 meta: make(map[string]string),
 }
 }

func main() {
 u := NewUser("Alice")
 u.SetMeta("role", "admin")
 fmt.Println("Meta:", u.meta)
 }

Второй вариант решения изменить SetMeta что бы инициализировать мапу, если она равна nil

 func (u *User) SetMeta(key, value string) {
 if u.meta == nil {
 u.meta = make(map[string]string)
 }
 u.meta[key] = value

Ошибку и решение нам помог составить Алексей Косов, системный инженер департамента инфраструктуры в «Криптоните». Его материал про особенности, применение, плюсы и минусы Golang можно прочитать в этой статье.

Всем привет. В свободное время создаю игру, хотел привлечь студентов для реальной практики, которую студенту без опыта получить практически нереально (опробовал на себе лет 10 назад), знал что есть такое место как GB, но и тут облом, оказывается раздел уже не актуален, где можно было бы разместить информацию о своем проекте, и привлечь молодую кровь, жаждущих практики на реальных проектах.

Но где сейчас обитает студент? Где можно рассказать о себе, и закинуть удочку для поиска интернов? Хотелось бы и собрать команду, и дать молодым специалистам возможность пополнить свое портфолио реальным кейсом. Заранее спасибо.

Поддержка должна быть бесплатной. Всегда!

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

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

Я основатель облака для простого деплоя проектов через Git push – Amvera Cloud. И вижу, что пользователи пишут нам в поддержку. И говоря честно – люди пишут только тогда, когда другие способы не помогли и они не знают, как решить их насущную проблему. А это значит мы не доработали и сделали что-то непонятно или неудобно. И это наша обязанность постараться им помочь. И я не вижу морального права просить за это с них деньги.

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

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

Поддержка должна быть бесплатной, всегда, и без всяких но! 

Оплачиваемая стажировка Cloud.ru Camp — успей подать заявку до 12 мая 📢

Присоединяйся к Cloud.ru Camp — оплачиваемой стажерской программе, которая поможет студентам и начинающим специалистам прокачать скиллы и с головой погрузиться в IT-сферу. 

Ты можешь выбрать направления:

• Продуктовая разработка: DevOps или Golang.

• Кибербезопасность: мониторинг событий и автоматизация или сертификация программных продуктов.

• Команда внедрения: QA.

• Технические продажи: технический менеджер клиентов.

Что тебя ждет:

• оплачиваемая стажировка,

• работа в реальных проектах,

• поддержка наставников и экспертов,

• регулярная обратная связь.

А у лучших стажеров будет возможность попасть в штат Cloud․ru.

Прием заявок открыт до 16 мая включительно, а для прошедших все этапы отбора стажировка начнется 16 июня. Пройти стажировку можно очно в офисе Cloud.ru в Москве, а также удаленно из любой точки РФ. График гибкий — от 20 часов в неделю.

📬 Подать заявку на Cloud.ru Camp

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

Есть такая мантра в гошке - "всегда обрабатывать ошибки"

А ведь так хочется чтобы они сами наверх прокидывались...

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

То есть ошибка равна панике

validator.Register("", func any)

if err := validator.Register("", func(
  
); err != nil {
  return err
}

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

В 2ГИС мы пишем на Go и помогаем инженерам перейти на него с других языков. Знакомство с Go открывает возможность контрибьютить в одну из самых востребованных технологий современности. На Go написаны проекты, без которых сложно представить мир распределённых систем: K8s, CockroachDB, Badger, Prometheus, VictoriaMetrics, Jaeger, NATS, Temporal. 

Переход на Go — реальность! В карточках рассказываем, как это получилось у Саши ↓

Хочешь так же? Прямо сейчас ищем ребят с Java и C#.

От картотеки Лумана к современным графам: учим языки программирования с методом Цеттелькастен

В середине XX века социолог Никлас Луман разработал метод организации информации Цеттелькастен (Zettelkasten). Он создавал множество заметок и, чтобы не терять знания, начал вести картотеку. Система нумерации и ссылок помогала ориентироваться в карточках. У каждой заметки был уникальный номер, отражающий тему и дополнения.

Спустя полвека идеи Лумана остаются актуальными. Более того, появились программные обеспечения для ведения базы знаний. Заметки сохраняются в облаке и отображаются в виде графа.

Веб-разработчик в YADRO Дмитрий сохраняет заметки в сервисе Obsidian. Дмитрий услышал о ПО от инженера и блогера Николая Тузова и понял, что система, похожая на картотеку, ему близка.

Программа оказалась понятной, легко адаптируемой под разные задачи. Когда Дмитрий перенес данные из Notion в Obsidian, образовалось несколько графов: по Go, хешированию и базам данных. В этой базе знаний все концепции в Go пересеклись в двух точках — интерфейсе и горутинах. Есть еще слайсы, но в основном все «лучи» сходятся именно в эти две точки. 

Как Дмитрию удалось упорядочить большие объемы знаний и кому он рекомендует Цеттелькастен, читайте в статье →

Новый запуск Route 256 эксклюзивно для Go-разработчиков.

Это бесплатные курсы от экспертов Ozon Tech.
2 месяца онлайн-занятий.
Реальные задачи бигтеха.

Чтобы попасть на Route 256, нужно пройти отборочный контест. Он состоится 20 апреля.

Зачем это вам?

• получить передовые знания от IT-команды ведущего e-com;

• попробовать работу в бигтехе;

• пополнить портфолио крутыми проектами для миллионов пользователей;

• получить оффер в команду Ozon Tech.

Почему именно Go?
У Ozon высоконагруженная и отказоустойчивая микросервисная инфраструктура. Сервисы выдерживают до 382 000 RPS к бэкенду с мобильных приложений и сайта — и это не стресс-тесты. Команде нужны сильные Go-разработчики, чтобы развивать и масштабировать маркетплейс.

🎓Если вы ещё учитесь в вузе, но уже имеете небольшой опыт программирования и понимаете, как устроены алгоритмы и базы данных, регистрируйтесь на уровень junior: https://s.ozon.ru/3lip8Ey

💻Если вы уже имеете опыт коммерческой разработки (на любом языке кроме низкоуровневых, 1С и low-code), регистрируйтесь на уровень middle: https://s.ozon.ru/Q1vHnSc

Переходите по ссылкам, чтобы узнать все детали и отправить заявку на отборочный тур.
Удачи!

А почему нет нормального дженерика для мап? 👀

У кого-то спина белая, а мы собрали бинго из боли, кринжа и немного гордости каждого гошника. Наши ребята из Go-сообщества отобрали самый сок!

Пишите в комментариях, что прожито на личном опыте. Есть чем дополнить? Смело предлагайте 😉

Конкурентность в Go: просто запустить — сложнее управлять

Go предлагает удобный механизм конкурентности, позволяющий запускать задачи максимально просто — достаточно добавить go перед вызовом функции, и она начнет выполняться параллельно с основным потоком. Однако для эффективного использования такого кода важно правильно управлять синхронизацией: собирать результаты, обрабатывать ошибки и учитывать возможные сценарии выполнения. На практике этому аспекту часто уделяют недостаточно внимания.

Полезные материалы о конкурентности в Go можно найти в блоге Дейва Чени. Он рассматривает различные решения в Go, объясняя их происхождение и способы использования. В своих статьях он также подробно разбирает тему конкурентности.

Например, в статье Curious Channels Дейв Чени описывает два важных свойства каналов в Go:

1. Закрытый канал не блокируется. После закрытия в него нельзя отправлять данные, но можно читать. Если данных нет, возвращается нулевое значение. Это удобно при использовании range, который автоматически завершает цикл.

2. Закрытие канала уведомляет все горутины. Вместо того чтобы отправлять сигнал каждой горутине, достаточно закрыть канал — все ожидающие горутины получат сигнал завершения.

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

Владислав Белогрудов, эксперт по разработке ПО в YADRO, собрал полезные материалы про конкурентность в Go. В статье — блоги, выступления и книги, которые помогут разобраться, как в Go работать с горутинами и каналами без хаоса и дедлоков.

Как не надо использовать Assert, если реализуете подход Design by Contract

Использовать Assert вместо if err != nil { return err}

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

Выполнять вычисления при вызове Assert

Еще одна распространенная и трудно выявляемая ошибка — это выполнение вычислений и присваивание значений переменным прямо при вызове Assert, которые могут быть упразднены при оптимизации кода компилятором:

•  e.g. Assert(i++ > 0, “осторожно, не факт, что в релизе i увеличится”),

•  Assert(call_to_f1(), “осторожно, не факт, что call_to_f1() будет вызвана в релизе”).

Удалять Assert, несмотря на то, что это часть описания контракта

Непонимание, что Assert — это реализация контракта, может привести к тому, что разработчик, незнакомый с DbC, захочет просто удалить проверку. Однако нужно всегда помнить, что срабатывание Assert говорит о нарушении контракта одной из сторон. То есть, если срабатывает Assert, надо прежде всего найти баг и пофиксить. А уж если контракт действительно должен быть изменен, Assert подскажет, где находятся участки кода, на которые нужно обратить внимание.

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

В реализации пакета Go 1.23 fmt-функция Printf всегда возвращает err = nil. И практически все игнорируют возвращающееся значение ошибки, тогда как могли бы проверять постусловие assertion.Assert (err == nil). Так, рано или поздно в последующих версиях можно научить код реагировать на err, отличный от nil.

Как правильно применять assertions, если реализуете подход Design by Contract для улучшения производительности кода в продакшене? Читайте в статье →

Приглашаем на первый Cloud․ru Tech Lab: Golang — митап для Go-разработчиков и технических лидеров 🎙️

📅 Дата: 13 марта, 19:00
📍 Место: Москва, Большая Почтовая улица, 40с7, Гоэлро Лофт

В программе четыре доклада от разработчиков Cloud․ru и приглашенного гостя. А еще — нетворкинг и afterparty с диджеем, музыкой и ужином.

Темы докладов:

• Как устроена Go-разработка в Cloud․ru — Александр Шакмаев и Андрей Рацеров, технические лидеры;

• Балансировка gRPC в Kubernetes — Михаил Абраш, старший Go-разработчик;

• Как мы бутстрапим пользовательское окружение с Go, Temporal и Kubernetes — Евгений Третьяков, ведущий Go-разработчик;

• Осторожно unsafe! Практические примеры и ошибки использования — Владимир Балун, основатель balun․courses.

👉 Зарегистрироваться

А еще заглядывайте в наши статьи и делитесь размышлениями в комментариях:

• Клиентоцентричность с точки зрения Go-разработчика и причем тут рефлексия

• Гармония железа и кода: ускоряем Go, проектируя приложение с учетом архитектуры процессора

Почему Go — выбор крупных IT-компаний? Узнайте в нашем новом подкасте 🎧

В нем Владимир Балун, основатель Балун.Курсы, пообщался с командой Cloud.ru про тренды в программировании, опыт перехода на Go и подготовку к алгоритмическим собеседованиям.

А еще:

• как глобальные изменения в отрасли влияют на требования к разработчикам;

• почему Go стал одним из основных языков для веб-разработки и высоконагруженных приложений;

• как AI и автоматизация формируют будущее простых задач, таких как верстка.

👉 Посмотреть подкаст также можно на YouTube.

Все топовые фичи нового релиза Go

Случился релиз новой версии языка Go: 1.24. Разбираем основные нововведения и используем улучшенные инструменты по максимуму.

В новом выпуске avito.code Павел Агалецкий, техлид и бэкенд-разработчик Авито, рассказывает о самых топовых фичах, а также делится их особенностями, благодаря которым писать код станет еще проще.

Смотреть выпуск на YouTube
Смотреть выпуск в VK

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Нам нужно больше capacity: как растет вместимость в слайсах на Go

Чтобы выяснить, во сколько раз Go увеличивает внутренний массив элементов в слайсах, проведем небольшой тест. Добавим один элемент к уже заполненным слайсам:

На графике видно, что в районе 200 элементов увеличенный слайс вмещает уже 400 элементов, а в районе 800 — 1200, то есть вместимость выросла сначала в два раза, потом — в полтора. 

В коде рантайма можно найти простую формулу: если в слайсе capacity элементов было меньше 256, то вместимость увеличится в два раза. Если больше 256, то на четверть. Таким образом мы пытаемся экономить память.

Существует забавная константа для вычисления вместимости: три четвертых от 256. Разработчики на Go посчитали, что так происходит более плавный переход от фактора 2x к фактору 1.25

Почему на графике образовались «ступеньки» вместо привычной кривой и что еще нужно знать о слайсах Go-разработчику — читайте в статье →

Что написать на Go, если «вывод суммы на экран» вы уже переросли

На этот вопрос нашел ответ Игорь Горбунов. Он разрабатывает платформу базовой станции в YADRO и второй год изучает Go. Когда стандартные задачи ему надоели, он придумал челлендж: построить приложение, похожее на утилиту ping в UNIX-подобных системах.

Первым делом разработчик набросал список требования к приложению, чтобы опираться на него в процессе работы:

• Возможность запросов Echo-Request по протоколам ICMP и ICMPv6 и поддержка IPv4 и IPv6 со стороны ping.

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

• Возможность менять из командной строки размер отправляемых запросов и их количество.

• Подсчет и вывод в консоль статистики отправленных запросов, полученных и неполученных ответов, ошибок, минимального, среднего, максимального времени круговой задержки (rtt), а также стандартного отклонения rtt.

Получилось ли у Игоря реализовать настоящий ping и какую проблему ему так и не удалось решить — читайте в статье.

Google выпустила новое API для Protocol Buffers в Go

Команда Go представила новое API для работы с Protocol Buffers, получившее название Opaque API. Это важное обновление, которое должно сделать работу с protobuf более эффективной и безопасной. 

До сих пор в Go использовалось так называемое Open Struct API, где все поля структур были доступны напрямую. Например, так:

type LogEntry struct {
  BackendServer *string
  RequestSize   *uint32
  IPAddress     *string
}

С новым Opaque API все поля становятся приватными, а доступ к ним осуществляется через методы:

type LogEntry struct {
  xxx_hidden_BackendServer *string
  xxx_hidden_RequestSize   uint32
  xxx_hidden_IPAddress    *string
  // …внутренние поля опущены
}

// Доступ через методы
func (l *LogEntry) GetBackendServer() string
func (l *LogEntry) HasBackendServer() bool
func (l *LogEntry) SetBackendServer(string)
func (l *LogEntry) ClearBackendServer()
//...

Зачем это сделано?

Новый подход значительно экономит память. Вместо использования указателей для хранения информации о наличии значения в поле (presence), теперь используются битовые поля. В некоторых случаях это позволяет сократить количество аллокаций памяти почти на 60%. (речь идет про элементарные типы, такие как целые числа, булевы и т.д)

Появилась возможность реализовать ленивое декодирование сообщений. Теперь вложенные сообщения декодируются только при первом обращении к ним, а не при общей десериализации. Для некоторых приложений это дает колоссальный прирост производительности и уменьшает аллокации

Новое API предотвращает некоторые ошибки. Например, раньше было легко случайно сравнить указатели вместо значений при работе с enum:

/*
message LogEntry {
  enum DeviceType {
    DESKTOP = 0;
    MOBILE = 1;
    VR = 2;
  };
  DeviceType device_type = 1;
}
*/

// Неправильно и незаметно:
if cv.DeviceType == logpb.LogEntry_DESKTOP.Enum()

// Правильно:
if cv.GetDeviceType() == logpb.LogEntry_DESKTOP

С новым API такая ошибка просто невозможна, так как прямого доступа к полям нет.

Еще одно улучшение касается работы с reflection. Раньше разработчики могли случайно использовать стандартный пакет reflect вместо специального protobuf-reflection, что приводило к неожиданным результатам. Теперь такие ошибки исключены.

Google предлагает постепенный путь миграции через "гибридное" API, которое поддерживает оба способа работы. Для новых проектов рекомендуется сразу использовать Opaque API. В 2024 году оно станет стандартным подходом в новой версии Protocol Buffers (Edition 2024).

Старое API никуда не исчезнет – принцип обратной совместимости. 

Для перехода на новое API Google предоставляет инструмент open2opaque, который помогает автоматически переписывать код. Внутри самого Google большинство protobuf-файлов уже переведено на новое API, и оно активно используется на проде.

cross-пост из tg-канала Cross Join