Модули в Golang: термины

Ограничение сборки (build constraint): условие, определяющее, используется ли исходный файл Go при компиляции пакета. Ограничения сборки могут быть выражены суффиксами имени файла (например, foo_linux_amd64.go) или комментариями ограничений сборки (например, // +build linux,amd64).

Список сборки (build list): список версий модуля, который будет использоваться для команды сборки, такой как go build, go list или go test. Список сборки определяется из файла go.mod основного модуля и файлов go.mod в транзитивно необходимых модулях с использованием минимального выбора версии. Список сборки содержит версии для всех модулей в графе модулей, а не только тех, которые относятся к конкретной команде.

Каноническая версия (canonical version): правильно отформатированная версия без суффикса метаданных сборки, кроме +incompatible. Например, v1.2.3 является канонической версией, а v1.2.3+meta - нет.

Текущий модуль (current module): синоним основного (main) модуля.

Файл go.mod: файл, который определяет путь к модулю, требования и другие метаданные. Появляется в корневом каталоге модуля.

Путь импорта (import path): строка, используемая для импорта пакета в исходный файл Go. Синоним пути к пакету.

Основной (main) модуль: модуль, в котором вызывается команда go. Главный модуль определяется файлом go.mod в текущем или родительском каталоге.

Основная версия (major version): первое число в семантической версии (1 в v1.2.3). В выпуске с несовместимыми изменениями необходимо увеличить основную версию, а для вспомогательной (minor) версии и версии исправления (patch) необходимо установить значение 0. Семантические версии с основной версией 0 считаются нестабильными.

Подкаталог основной версии (major version subdirectory): подкаталог в репозитории управления версиями, соответствующий суффиксу основной версии модуля, в котором может быть определен модуль. Например, модуль example.com/mod/v2 в репозитории с корневым путем example.com/mod может быть определен в корневом каталоге репозитория или в подкаталоге основной версии v2.

Суффикс основной версии (major version suffix): суффикс пути к модулю, соответствующий номеру основной версии. Например, /v2 в example.com/mod/v2. Суффиксы основной версии требуются в версии 2.0.0 и новее и не допускаются в более ранних версиях.

Выбор минимальной версии (MVS, minimal version selection): алгоритм, используемый для определения версий всех модулей, которые будут использоваться в сборке.

Второстепенная версия (minor version): второе число в семантической версии (2 в v1.2.3). В релизе с новой обратно совместимой функциональностью необходимо увеличить второстепенную версию, а для версии исправления (patch) необходимо установить значение 0.

Модуль (module): набор пакетов, которые выпускаются, контролируются версиями и распространяются вместе.

Кеш модулей (module cache): локальный каталог, в котором хранятся загруженные модули, расположенный в GOPATH/pkg/mod.

Граф модуля (module graph): направленный граф требований к модулю, основанный на основном модуле. Каждая вершина в графе - это модуль; каждое ребро является версией оператора require в файле go.mod (при условии, что операторы replace и exclude в файле go.mod основного модуля).

Путь к модулю (module path): путь, который идентифицирует модуль и действует как префикс для путей импорта пакетов внутри модуля. Например, "golang.org/x/net".

Прокси модуля (module proxy): веб-сервер, реализующий протокол GOPROXY. Команда go загружает информацию о версии, файлы go.mod и zip-файлы модуля с прокси-серверов модуля.

Корневой каталог модуля (module root directory): каталог, содержащий файл go.mod, определяющий модуль.

Подкаталог модуля (module subdirectory): часть пути к модулю после корневого пути репозитория, которая указывает подкаталог, в котором определен модуль. Если не пусто, подкаталог модуля также является префиксом для тегов семантической версии. Подкаталог модуля не включает суффикс основной версии, если он есть, даже если модуль находится в подкаталоге основной версии.

Пакет (package): набор исходных файлов в одном каталоге, которые скомпилированы вместе.

Путь к пакету (package path): путь, который однозначно определяет пакет. Путь к пакету - это путь к модулю, соединенный с подкаталогом внутри модуля. Например, "golang.org/x/net/html" - это путь пакета для пакета в модуле "golang.org/x/net" в подкаталоге "html". Синоним пути импорта.

Версия исправления (patch version): третье число в семантической версии (3 в v1.2.3). В релизе без изменений в общедоступном интерфейсе модуля версия исправления должна быть увеличена.

Предварительная версия (pre-release version): версия с дефисом, за которой следует ряд идентификаторов, разделенных точками, сразу после версии исправления, например v1.2.3-beta4. Предварительные версии считаются нестабильными и не считаются совместимыми с другими версиями. Предварительная версия сортируется перед соответствующей версией выпуска: v1.2.3-pre предшествует v1.2.3.

Псевдоверсия (pseudo-version): версия, которая кодирует идентификатор ревизии (например, хеш коммита Git) и временную метку из системы контроля версий. Например, v0.0.0-20191109021931-daa7c04131f5. Используется для совместимости с немодульными репозиториями и в других ситуациях, когда версия с тегами недоступна.

Версия релиза (release version): версия без суффикса предварительного выпуска. Например, v1.2.3, а не v1.2.3-pre.

Корневой путь репозитория (repository root path): часть пути к модулю, соответствующая корневому каталогу репозитория системы управления версиями.

Отозванная версия (retracted version): версия, от которой не следует полагаться либо потому, что она была опубликована преждевременно, либо потому, что после публикации была обнаружена серьезная проблема.

Семантический тег версии (semantic version tag): тег в репозитории управления версиями, который сопоставляет версию с определенной ревизией.

Каталог vendor (vendor directory): каталог с именем vendor, который содержит пакеты из других модулей, необходимые для сборки пакетов в основном модуле. Поддерживается go mod vendor.

Версия: идентификатор неизменяемого снимка (snapshot) модуля, записанный буквой v, за которой следует семантическая версия.

---

Читайте также:

• Модули в Golang: аутентификации модулей, файлы go.sum
• Модули в Golang: аутентификации модулей, база данных контрольных сумм
• Модули в Golang: переменные среды

Канал в Телеграм

Модули в Golang: переменные среды

Поведение модуля в команде go можно настроить с помощью переменных среды, перечисленных ниже. В этот список входят только переменные среды, относящиеся к модулю.

GO111MODULE

Управляет запуском команды go в режиме с поддержкой модуля или в режиме GOPATH. Распознает три значения:

• off: команда go игнорирует файлы go.mod и работает в режиме GOPATH.
• on (или не установлен): команда go выполняется в режиме с учетом модуля, даже если файл go.mod отсутствует.
• auto: команда go запускается в режиме с учетом модуля, если файл go.mod присутствует в текущем или любом родительском каталоге. В Go 1.15 и ниже это было по умолчанию.

GOMODCACHE

Каталог, в котором команда go будет хранить загруженные модули и связанные файлы.

Если GOMODCACHE не установлен, по умолчанию используется $GOPATH/pkg/mod.

GOINSECURE

Разделенный запятыми список glob шаблонов (в синтаксисе Go path.Match) префиксов пути модуля, которые всегда могут быть получены небезопасным образом. Применяется только к зависимостям, которые извлекаются напрямую.

В отличие от флага -insecure при go get, GOINSECURE не отключает проверку базы данных контрольной суммы модуля. Для этого можно использовать GOPRIVATE или GONOSUMDB.

GONOPROXY

Разделенный запятыми список glob шаблонов (в синтаксисе Go path.Match) префиксов путей к модулям, которые всегда следует получать непосредственно из репозиториев системы контроля версий, а не из прокси-серверов модулей.

Если GONOPROXY не установлен, по умолчанию используется GOPRIVATE.

GONOSUMDB

Список разделенных запятыми glob шаблонов (в синтаксисе Go path.Match) префиксов путей модулей, для которых go не должен проверять контрольные суммы с помощью базы данных контрольных сумм.

Если GONOSUMDB не установлен, по умолчанию используется GOPRIVATE.

GOPATH

В режиме GOPATH переменная GOPATH представляет собой список каталогов, которые могут содержать код Go.

В режиме с поддержкой модулей кеш модуля хранится в подкаталоге pkg/mod первого каталога GOPATH. Исходный код модуля вне кеша может храниться в любом каталоге.

Если GOPATH не установлен, по умолчанию используется подкаталог go домашнего каталога пользователя.

GOPRIVATE

Список разделенных запятыми glob шаблонов (в синтаксисе Go path.Match) префиксов путей к модулям, которые следует считать частными. GOPRIVATE - это значение по умолчанию для GONOPROXY и GONOSUMDB. GOPRIVATE также определяет, считается ли модуль частным для GOVCS.

GOPROXY

Список URL-адресов прокси модуля, разделенных запятыми (,) или вертикальными чертами (|). Когда команда go ищет информацию о модуле, она последовательно связывается с каждым прокси в списке, пока не получит успешный ответ или ошибку терминала. Прокси-сервер может ответить статусом 404 (Not Found) или 410 (Gone), чтобы указать, что модуль недоступен на этом сервере.

Резервное поведение при ошибке команды go определяется символами-разделителями между URL-адресами. Если после URL-адреса прокси-сервера стоит запятая, команда go возвращается к следующему URL-адресу после ошибки 404 или 410; все остальные ошибки считаются окончательными. Если за URL-адресом прокси-сервера следует канал (|), команда go возвращается к следующему источнику после любой ошибки, включая ошибки, не связанные с HTTP, такие как таймауты.

URL-адреса GOPROXY могут иметь схемы https, http или file. Если URL-адрес не имеет схемы, предполагается https. Кеш модуля может использоваться напрямую как файловый прокси:

GOPROXY=file://$(go env GOMODCACHE)/cache/download

Вместо URL прокси можно использовать два ключевых слова:

• off: запрещает загрузку модулей из любого источника.
• direct: загрузка напрямую из репозиториев системы контроля версий вместо использования прокси-сервера модуля.

GOPROXY по умолчанию использует https://proxy.golang.org,direct. В этой конфигурации команда go сначала связывается с зеркалом модуля Go, запущенным Google, а затем возвращается к прямому подключению, если зеркало не имеет модуля. Переменные среды GOPRIVATE и GONOPROXY могут быть установлены для предотвращения загрузки определенных модулей с использованием прокси.

GOSUMDB

Определяет имя используемой базы данных контрольных сумм и, при необходимости, ее открытый ключ и URL. Например:

GOSUMDB="sum.golang.org"
GOSUMDB="sum.golang.org+<publickey>"
GOSUMDB="sum.golang.org+<publickey> https://sum.golang.org

Команде go известен открытый ключ sum.golang.org, а также то, что имя sum.golang.google.cn (доступно на территории материкового Китая) подключается к базе данных sum.golang.org; использование любой другой базы данных требует явного указания открытого ключа. По умолчанию используется URL-адрес https://, за которым следует имя базы данных.

GOSUMDB по умолчанию использует sum.golang.org, базу данных контрольных сумм Go, управляемую Google.

Если GOSUMDB выключен или go get вызывается с флагом -insecure, база данных контрольных сумм не запрашивается, и все нераспознанные модули принимаются, за счет отказа от гарантии безопасности проверенных повторяющихся загрузок для всех модулей. Лучший способ обойти базу данных контрольных сумм для определенных модулей - использовать переменные среды GOPRIVATE или GONOSUMDB.

GOVCS

Управляет набором инструментов управления версиями, которые команда go может использовать для загрузки общедоступных и частных модулей (определяемых тем, соответствуют ли их пути шаблону в GOPRIVATE) или других модулей, соответствующих glob шаблону.

Если GOVCS не установлен или модуль не соответствует какому-либо шаблону в GOVCS, команда go может использовать git и hg для общедоступного модуля или любой известный инструмент контроля версий для частного модуля. Конкретно, команда go действует так, как если бы GOVCS был установлен на:

public:git|hg,private:all

---

Читайте также:

• Модули в Golang: кеш модуля
• Модули в Golang: аутентификации модулей
• Модули в Golang: аутентификации модулей, файлы go.sum
• Модули в Golang: аутентификации модулей, база данных контрольных сумм

Канал в Телеграм

Модули в Golang: аутентификации модулей, база данных контрольных сумм

База данных контрольных сумм - это глобальный источник строк go.sum. Команда go может использовать это во многих ситуациях для обнаружения неправильного поведения прокси или исходных серверов.

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

База данных контрольных сумм обслуживается sum.golang.org, которым управляет Google. Это прозрачный журнал (или "дерево Меркла") хешей строки go.sum, поддерживаемый Trillian. Основное преимущество дерева Меркла заключается в том, что независимые аудиторы могут проверить, что оно не было изменено, поэтому оно более надежно, чем простая база данных.

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

Ниже указаны запросы, на которые должна отвечать база данных контрольных сумм. Для каждого пути $base - это часть пути URL-адреса базы данных контрольных сумм, $module - это путь к модулю, а $version - это версия. Например, если URL-адрес базы данных контрольных сумм - https://sum.golang.org, а клиент запрашивает запись для модуля golang.org/x/text в версии v0.3.2, клиент отправит запрос GET для https://sum.golang.org/lookup/golang.org/x/text@v0.3.2.

Чтобы избежать неоднозначности при обслуживании из файловых систем без учета регистра, элементы $module и $version кодируются с учетом регистра, заменяя каждую прописную букву восклицательным знаком, за которым следует соответствующая строчная буква. Это позволяет хранить на диске модули example.com/M и example.com/m, поскольку первый кодируется как example.com/!m.

Части пути, окруженные квадратными скобками, например [.p/$W], обозначают необязательные значения.

Путь $base/latest

Возвращает подписанное закодированное древовидное описание для последнего журнала. Это подписанное описание имеет форму примечания, которое представляет собой текст, подписанный одним или несколькими ключами сервера, и его можно проверить с помощью открытого ключа сервера. В описании дерева указан размер дерева и хеш-код заголовка дерева этого размера. Эта кодировка описана в golang.org/x/mod/sumdb/tlog#FormatTree.

Путь $base/lookup/$module@$version

Возвращает номер записи журнала для записи о $module в $version, за которыми следуют данные для записи (то есть строки go.sum для $module в $version) и подписанное закодированное древовидное описание, содержащее запись.

Путь $base/tile/$H/$L/$K[.p/$W]

Возвращает [log tile](плитка журнала)(https://research.swtch.com/tlog#serving_tiles), которая представляет собой набор хешей, которые создают раздел журнала. Каждая плитка определяется в двумерной координате на уровне плитки $L, $K-й слева, с высотой плитки $H. Необязательный суффикс .p/$W указывает на частичную плитку журнала, содержащую только $W хешей. Клиенты должны вернуться к получению полной плитки, если частичная плитка не найдена.

Путь $base/tile/$H/data/$K[.p/$W]

Возвращает данные записи для листовых хешей в /tile/$H/0/$K[.p/$W] (с буквальными элементами данных пути).

Если команда go обращается к базе данных контрольных сумм, то первым шагом является получение данных записи через конечную точку /lookup. Если версия модуля еще не записана в журнал, база данных контрольных сумм попытается получить ее с исходного сервера перед ответом. Эти /lookup данные предоставляют сумму для этой версии модуля, а также его позицию в журнале, который информирует клиента о том, какие плитки следует выбрать для выполнения проверки. Перед добавлением новых строк go.sum в файл go.sum главного модуля команда go выполняет проверки "включения" (наличие определенной записи в журнале) и "согласованности" (отсутствие изменений в дереве). Важно, чтобы данные из /lookup никогда не использовались без предварительной аутентификации по подписанному хешу дерева и аутентификации подписанного хеша дерева по временной шкале подписанных хешей дерева.

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

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

Переменная среды GOSUMDB определяет имя используемой базы данных контрольных сумм и, при необходимости, ее открытый ключ и URL-адрес, например:

GOSUMDB="sum.golang.org"
GOSUMDB="sum.golang.org+<publickey>"
GOSUMDB="sum.golang.org+<publickey> https://sum.golang.org"

Команде go известен открытый ключ sum.golang.org, а также то, что имя sum.golang.google.cn (доступно на территории материкового Китая) подключается к базе данных контрольных сумм sum.golang.org; использование любой другой базы данных требует явного указания открытого ключа. По умолчанию используется URL-адрес https://, за которым следует имя базы данных.

GOSUMDB по умолчанию использует sum.golang.org, базу данных контрольных сумм Go, управляемую Google.

Если GOSUMDB выключен или go get вызывается с флагом -insecure, база данных контрольных сумм не запрашивается, и все нераспознанные модули принимаются, за счет отказа от гарантии безопасности проверенных повторяющихся загрузок для всех модулей. Лучший способ обойти базу данных контрольных сумм для определенных модулей - использовать переменные среды GOPRIVATE или GONOSUMDB.

Команду go env -w можно использовать для установки этих переменных для будущих вызовов команды go.

---

Читайте также:

• Модули в Golang: кеш модуля
• Модули в Golang: аутентификации модулей
• Модули в Golang: аутентификации модулей, файлы go.sum

Канал в Телеграм

Модули в Golang: аутентификации модулей, файлы go.sum

Модуль может иметь текстовый файл с именем go.sum в его корневом каталоге вместе с файлом go.mod. Файл go.sum содержит криптографические хеши прямых и косвенных зависимостей модуля. Когда команда go загружает файл .mod или .zip модуля в кеш модуля, она вычисляет хеш и проверяет, совпадает ли хеш с соответствующим хешем в файле go.sum главного модуля. go.sum может быть пустым или отсутствовать, если у модуля нет зависимостей или если все зависимости заменены локальными каталогами с помощью директив replace.

Каждая строка в go.sum имеет три поля, разделенных пробелами: путь к модулю, версию (возможно, заканчивающуюся на /go.mod) и хеш.

• Путь к модулю - это имя модуля, которому принадлежит хеш.
• Версия - это версия модуля, которому принадлежит хеш. Если версия заканчивается на /go.mod, хеш предназначен только для файла go.mod модуля; в противном случае хеш предназначен для файлов в .zip архиве модуля.
• Столбец хеша состоит из имени алгоритма (например, h1) и криптографического хеша в кодировке base64, разделенных двоеточием (:). В настоящее время SHA-256 (h1) - единственный поддерживаемый алгоритм хеширования. Если в будущем будет обнаружена уязвимость в SHA-256, будет добавлена поддержка другого алгоритма (с именем h2 и т. д.).

Файл go.sum может содержать хеши для нескольких версий модуля. Команде go может потребоваться загрузить файлы go.mod из нескольких версий зависимости, чтобы выполнить выбор минимальной версии. go.sum также может содержать хеши для версий модуля, которые больше не нужны (например, после обновления). go mod tidy добавит недостающие хеши и удалит ненужные хеши из go.sum.

---

Читайте также:

• Модули в Golang: частные модули, конфиденциальность
• Модули в Golang: кеш модуля
• Модули в Golang: аутентификации модулей

Канал в Телеграм

Модули в Golang: аутентификации модулей

Когда команда go загружает zip-файл модуля или файл go.mod в кеш модуля, она вычисляет криптографический хеш и сравнивает его с известным значением, чтобы убедиться, что файл не изменился с момента его первой загрузки. Команда go сообщает об ошибке безопасности, если загруженный файл не имеет правильного хеша.

Для файлов go.mod команда go вычисляет хеш из содержимого файла. Для zip-файлов модуля команда go вычисляет хеш из имен и содержимого файлов в архиве в детерминированном порядке. На хеш не влияют порядок файлов, сжатие, выравнивание и другие метаданные.

Команда go сравнивает каждый хеш с соответствующей строкой в файле go.sum главного модуля. Если хеш отличается от хеша в go.sum, команда go сообщает об ошибке безопасности и удаляет загруженный файл, не добавляя его в кеш модуля.

Если файл go.sum отсутствует или он не содержит хеш для загруженного файла, команда go может проверить хеш с помощью базы данных контрольных сумм, глобального источника хешей для общедоступных модулей. После проверки хеша команда go добавляет его в go.sum и добавляет загруженный файл в кеш модуля. Если модуль является частным (соответствует переменным среды GOPRIVATE или GONOSUMDB) или если база данных контрольных сумм отключена (путем установки GOSUMDB=off), команда go принимает хеш и добавляет файл в кеш модуля без его проверки.

Кеш модуля обычно используется всеми проектами Go в системе, и каждый модуль может иметь свой собственный файл go.sum с потенциально разными хешами. Чтобы избежать необходимости доверять другим модулям, команда go проверяет хеши, используя go.sum основного модуля, всякий раз, когда она обращается к файлу в кеше модуля. Хеши zip-файлов требуют больших затрат на вычисление, поэтому команда go проверяет предварительно вычисленные хеши, хранящиеся вместе с zip-файлами, вместо повторного хеширования файлов. Команду go mod verify можно использовать для проверки того, что zip-файлы и извлеченные каталоги не были изменены с момента добавления в кеш модуля.

---

Читайте также:

• Модули в Golang: частные модули, передача учетных данных в частные репозитории
• Модули в Golang: частные модули, конфиденциальность
• Модули в Golang: кеш модуля

Канал в Телеграм

Модули в Golang: кеш модуля

Кеш модуля - это каталог, в котором команда go хранит загруженные файлы модулей. Кеш модуля отличается от кеша сборки, который содержит скомпилированные пакеты и другие артефакты сборки.

Расположение кеша модуля по умолчанию - $GOPATH/pkg/mod. Чтобы использовать другое расположение, установите переменную среды GOMODCACHE.

Кеш модуля не имеет максимального размера, и команда go не удаляет его содержимое автоматически.

Кеш может использоваться несколькими проектами Go, разработанными на одной машине. Команда go будет использовать один и тот же кеш независимо от расположения основного модуля. Несколько экземпляров команды go могут одновременно безопасно обращаться к одному и тому же кешу модуля.

Команда go создает исходные файлы модулей и каталоги в кеше с разрешениями только для чтения, чтобы предотвратить случайные изменения модулей после их загрузки. Это имеет неприятный побочный эффект, затрудняя удаление кеша с помощью таких команд, как rm -rf. Вместо этого кеш можно удалить с помощью go clean -modcache. В качестве альтернативы, когда используется флаг -modcacherw, команда go создаст новые каталоги с разрешениями на чтение и запись. Это увеличивает риск того, что редакторы, тесты и другие программы изменят файлы в кеше модуля. Команду go mod verify можно использовать для обнаружения изменений зависимостей основного модуля. Он сканирует извлеченное содержимое каждой зависимости модуля и подтверждает, что оно соответствует ожидаемому хешу в go.sum.

Ниже объясняется назначение большинства файлов в кеш-памяти модуля. Некоторые временные файлы (файлы блокировки (lock files), временные каталоги) опускаются. Для каждого пути $module - это путь к модулю, а $version - это версия. Пути, заканчивающиеся косой чертой (/), являются каталогами. Заглавные буквы в путях и версиях модулей экранируются восклицательными знаками (Azure заменяется !azure), чтобы избежать конфликтов в файловых системах без учета регистра.

Путь $module@$version/

Каталог, содержащий извлеченное содержимое .zip файла модуля. Он служит корневым каталогом для загруженного модуля. Он не будет содержать файл go.mod, если его не было в исходном модуле.

Путь cache/download/

Каталог, содержащий файлы, загруженные из прокси-серверов модуля, и файлы, полученные из систем контроля версий. Структура этого каталога соответствует протоколу GOPROXY, поэтому этот каталог может использоваться в качестве прокси-сервера, когда он обслуживается файловым сервером HTTP или когда на него ссылается URL-адрес file://.

Путь cache/download/$module/@v/list

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

Путь cache/download/$module/@v/$version.info

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

Путь cache/download/$module/@v/$version.mod

Файл go.mod для этой версии. Если в исходном модуле не было файла go.mod, это синтезированный файл без требований.

Путь cache/download/$module/@v/$version.zip

Заархивированное содержимое модуля.

Путь cache/download/$module/@v/$version.ziphash

Криптографический хеш файлов в .zip файле. Обратите внимание, что сам файл .zip не хешируется, поэтому порядок файлов, сжатие, выравнивание и метаданные не влияют на хеш. При использовании модуля команда go проверяет, соответствует ли этот хеш соответствующей строке в go.sum. Команда go mod verify проверяет соответствие хешей .zip файлов модуля и извлеченных каталогов этим файлам.

Путь cache/download/sumdb/

Каталог, содержащий файлы, загруженные из базы данных контрольных сумм (обычно sum.golang.org).

Путь cache/vcs/

Содержит клонированные репозитории управления версиями для модулей, извлеченных непосредственно из их источников. Имена каталогов представляют собой хеши в шестнадцатеричной кодировке, производные от типа репозитория и URL-адреса. Репозитории оптимизированы по размеру на диске. Например, клонированные репозитории Git по возможности являются пустыми и неглубокими.

---

Читайте также:

• Модули в Golang: частные модули, передача учетных данных частным прокси
• Модули в Golang: частные модули, передача учетных данных в частные репозитории
• Модули в Golang: частные модули, конфиденциальность

Канал в Телеграм

Модули в Golang: частные модули, конфиденциальность

Команда go может загружать модули и метаданные с прокси-серверов модулей и систем контроля версий. Переменная среды GOPROXY определяет, какие серверы используются. Переменные среды GOPRIVATE и GONOPROXY управляют тем, какие модули выбираются из прокси.

Значение GOPROXY по умолчанию:

https://proxy.golang.org,direct

С этой настройкой, когда команда go загружает модуль или метаданные модуля, она сначала отправляет запрос на proxy.golang.org, публичный прокси-сервер модуля, управляемый Google (политика конфиденциальности). Команда go не передает личную информацию, но передает полный путь к модулю, который запрашивается. Если прокси-сервер отвечает статусом 404 (Not Found) или 410 (Gone), команда go попытается подключиться напрямую к системе контроля версий, предоставляющей модуль.

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

GOPRIVATE=*.corp.example.com,*.research.example.com

GOPRIVATE просто действует по умолчанию для GONOPROXY и GONOSUMDB, поэтому нет необходимости устанавливать GONOPROXY, если GONOSUMDB не должно иметь другое значение. Когда путь к модулю совпадает с GONOPROXY, команда go игнорирует GOPROXY для этого модуля и извлекает его непосредственно из своего репозитория управления версиями. Это полезно, когда прокси-сервер не обслуживает частные модули.

Если есть доверенный прокси, обслуживающий все модули, то GONOPROXY не следует устанавливать. Например, если для GOPROXY задан один источник, команда go не будет загружать модули из других источников. GONOSUMDB все равно должен быть установлен в этой ситуации.

GOPROXY=https://proxy.corp.example.com
GONOSUMDB=*.corp.example.com,*.research.example.com

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

GOPROXY=https://proxy.corp.example.com,https://proxy.golang.org
GONOSUMDB=*.corp.example.com,*.research.example.com

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

go mod download corp.example.com/secret-product/typo@latest

Команда go сначала запрашивает этот модуль с proxy.corp.example.com. Если этот прокси-сервер отвечает 404 (Not Found) или 410 (Gone), команда go вернется к proxy.golang.org, передав путь секретного продукта в URL-адресе запроса. Если частный прокси-сервер отвечает любым другим кодом ошибки, команда go распечатывает ошибку и не будет обращаться к другим источникам.

Помимо прокси, команда go может подключаться к базе данных контрольных сумм для проверки криптографических хешей модулей, не перечисленных в go.sum. Переменная среды GOSUMDB устанавливает имя, URL-адрес и открытый ключ базы данных контрольных сумм. Значение GOSUMDB по умолчанию - sum.golang.org, общедоступная база данных контрольных сумм, управляемая Google (политика конфиденциальности). Как и в случае с прокси, команда go не передает личную информацию, но передает полный путь к запрошенному модулю, а база данных контрольных сумм не может вычислять контрольные суммы для непубличных модулей.

Переменная среды GONOSUMDB может быть установлена на шаблоны, указывающие, какие модули являются частными и не должны запрашиваться из базы данных контрольных сумм. GOPRIVATE действует по умолчанию для GONOSUMDB и GONOPROXY, поэтому нет необходимости устанавливать GONOSUMDB, если только GONOPROXY не имеет другого значения.

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

GOSUMDB может быть отключен (off), чтобы полностью отключить использование базы данных контрольных сумм. С этим параметром команда go не будет аутентифицировать загруженные модули, если они еще не находятся в go.sum.

---

Читайте также:

• Модули в Golang: частные модули, прямой доступ к частным модулям
• Модули в Golang: частные модули, передача учетных данных частным прокси
• Модули в Golang: частные модули, передача учетных данных в частные репозитории

Канал в Телеграм