Очередное причёсывания зеркал

В 087600cd166642c95809f63d4de0342d705d1c6 писал про то, что напрописывал
всяких приоритетов и местоположений для URL-ов в BASS distfiles. Писал,
что первыми идут CDN по приоритету. Передумал. Ведь получается, что у
всех весь трафик будет идти исключительно с CDN-ов, тогда как просто
зеркала не особо будут затрагиваться. С них уйдёт трафик. Владельцы
будут видеть простой. Будут думать об их бесполезности. Будут закрывать
за ненадобностью. В итоге мы придём к тому, что останутся только CDN. А
это одна точка отказа, очень чувствительная ко всякой геополитике и
просто вообще предпринимательству.

Поэтому приоритетность такая:
* балансировщики, которые HTTP/DNS перенаправлением уже на нужный сервер
  пошлют. Можно считать, что это аналогично списку зеркал в .meta4
  файле, но в теории балансировщики же могут и доступность файлов
  проверить и загруженность серверов. Быть более интеллектуальными
* зеркала. Чтобы с них трафик не уходил, поддерживалась живая
  экосистема, а не дышащее на ладан CDN-only решение
* CDN-ы
* основной сайт, master
* GitHub. Идёт в конце, чтобы, опять же, не концентрировать на нём весь
  трафик. Плюс эти уроды до сих пор не поддерживают IPv6. И в целом со
  скоростями до них всё плачевно

Разделение HTTP и HTTPS сохраняется. HTTP идёт первым: время
затрачиваемое на TLS рукопожатие -- визуально хорошо заметно. Смысла в
HTTPS для distfiles нет.

ISO по country code-ам не запрещает использовать XA->XZ диапазон (плюс
ещё есть) для собственных нужд. Так почему бы не воспользоваться этим? В
этом диапазоне указал некоторые CDN: xa -> Akamai; xc -> Cloudflare;
xf -> Fastly; xg -> GitHub; xl -> Leaseweb; xp -> PlanetUnix; xs -> CDN77.

А в meta4ra-url-sort утилиту -- возможность сортировки в обратном
направлении, для уменьшения приоритета, добавляя "!" в команды. Теперь
моя строчка сортировки URL-ов такая:

    meta4ra-url-sort [-6] ru "dk fi nl se" '!ua' '!xf' '!xc' "" c:eu c:na rand

С -6 надо ещё разобраться, ибо есть distfiles которые есть только на
GitHub. Надо это в shell какой-нибудь обернуть, чтобы при вообще
отсутствии IPv6 варианта (не считая fallback до distcache.FreeBSD.org)
добавлять legacy IP выбор.

РФ первая. Далее Дания, Нидерланды, Швеция и Финляндия одним
приоритетом, так как с ними, как правило, уж очень хорошие задержки и
скорости, насколько мне запомнилось (или нагрузка на сервера меньше чем
в Германии или Франции?). Украину, по понятным причинам (связанность с
их сетями отвратная), в наименьший приоритет. Fastly CDN наименее
предпочтителен. Cloudflare туда же. Если есть варианты без указания
местоположения, то наверх их -- но в моих distfiles они и так в группах
приоритетов идут первыми. Далее предпочесть в целом Европейские
варианты, потом североамериканские.

Посмотрел как вообще работают с зеркалами в других дистрибутивах и ОС.
Всё очень плохо: кроме Gentoo из GNU/Linux-ов не вспомню кто использовал
бы хотя бы несколько ссылок для скачивания софта. Да и в Gentoo, по
сравнению с FreeBSD, начальный уровень какой-то. Много кто ходит по
ссылкам типа ftp.gnu.org, полностью минуя их систему балансировки и
зеркалирования. По моему, это очень плохо и не уважительно, особенно
когда проект просит их использовать. gnupg.org просит использовать
зеркала по возможности.

комментарий 0:

From: Stepan Zolotuev
Date: 2026-03-29 10:51:05Z

Насчёт HTTP вместо HTTPS при скачивании сурсов:
А что насчёт обновления сурсов? Когда заранее неизвестна контрольная
сумма?

Обычно в системах по типу BASS (openbsd ports, nixpkgs, freebsd ports)
есть функция для скачивания и вычисления контрольной суммы. Супер удобно
для мейнтейнера, но теряет всякий смысл когда нет гарантии того, что
скачано ровно то, что опубликовал разработчик. Не видел нигде системы
приоритетов для ссылок для скачивания сурсов, где выбираемое зеркало
зависело бы от выполняемого действия.

комментарий 1:

From: Sergey Matveev
Date: 2026-03-29 11:19:51Z

*** Stepan Zolotuev [2026-03-29 10:23]:
>А что насчёт обновления сурсов? Когда заранее неизвестна контрольная
>сумма?

Во первых, многие проекты предоставляют PGP подписи. Я их всегда
проверяю, перед добавлением в BASS. Само собой это не отменяет
вероятности того, что при первоначальном доставании публичных ключей,
кто-то возможно их подменил. Это вечная проблема получения хоть
какого-либо начального доверия к ключам. У меня вот на диске есть
ключница для всех ключей проектов что использовал:

    % ls ~keyrings/keyrings | wc -l
         323

плюс ключницы от Debian, FreeBSD, GNU, Linux проектов.

Во вторых, многие проекты при публикации анонсов о выходе новой версии
софта, в письмах в рассылки публикуют хоть какие-то криптографические
хэши или же хотя бы отпечатки публичных ключей. Ещё один косвенный путь
для получения намёков о trust anchor. Рассылки (и их архивы) не редко
хостятся где-то на других машинах/сервисах, поэтому это ещё один
косвенный путь.

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

Если же проект дурацкий и не предоставляет никаких способов offline
проверки и прочего, коих тоже не мало, то да, остаётся хотя бы
TLS-защищённое соединение, которое лишь немного (на практике, так как
засилье Let's Encrypt) защищает от возможности MitM, и не "передаёт"
доверия от автора к пользователю (как в случае с подписями). TLS не
сильно увеличивает доверие.

>Обычно в системах по типу BASS (openbsd ports, nixpkgs, freebsd ports)
>есть функция для скачивания и вычисления контрольной суммы.

В BASS предполагается ручное добавление всего этого. Допустим,
предоставляю я ссылку на какой-нибудь GnuPG из его списка рассылки. Ведь
я же ещё должен скачать и подпись. А ещё бы указать, что подпись должна
быть сделана вот на таком ключе (хотя бы отпечаток указать). Не, вообще
идея то здравая и ключницу рядом в репозитории можно было бы хранить. Я
пока в BASS храню только файлы с подписями, а ключницы особняком. Но
лично мне пока этого хватает (не так часто что-то обновляется, не так
много работы).

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