Когда F-Droid не видит tags, обновления исчезают

Тихое обсуждение на форуме F-Droid подсвечивает проблему, которая со стороны кажется небольшой, но критически важна для всех, кто полагается на open-source Android-приложения для privacy: новые release tags для Privacy Browser и Privacy Cell, как сообщается, были отправлены upstream, однако F-Droid их не обнаруживал. Практический итог прост: пользователи могут оставаться на старых builds, хотя новые releases уже существуют.

Это не драматичная история про zero-day. Это не breach. Это тот самый разлом в обслуживании инфраструктуры, который редко попадает в заголовки, но находится прямо внутри software supply chain. Для privacy-инструментов доставка обновлений — часть security model. Если приложение существует, fix существует и tag существует, но repository index не показывает update, то пользовательский опыт становится неотличим от «обновления нет».

Правило Cipher: если пользователи не могут получить update автоматически, update не был полностью доставлен. 🔐

Исходное обсуждение — это report на форуме F-Droid под названием “Update tags for Privacy Browser and Privacy Cell not being detected”, где описываются недавно добавленные tags, которые не были подхвачены примерно через одну-две недели. Вероятная проблема — несовпадение где-то между видимостью upstream repository, metadata F-Droid и build/index pipeline, который превращает source releases в installable updates.

Почему это важно: доставка обновлений — это trust chain#

F-Droid — не просто app store. Для многих пользователей это доверенный канал распространения Android-софта, который позволяет избегать зависимости от proprietary app stores. Он собирает приложения из source, отслеживает metadata в repository fdroiddata и публикует signed index, который F-Droid clients используют для обнаружения и установки updates.

Так формируется цепочка:

1. Upstream project публикует release.
2. Соответствующий Git tag становится видимым и доступным для fetch.
3. Metadata F-Droid указывает на этот tag и корректные version fields.
4. Build process может воспроизвести или скомпилировать ожидаемый APK.
5. Repository index генерируется заново.
6. Устройства пользователей видят update и устанавливают его.

Разорвите любое звено — и пользователи останутся позади.

Для обычных apps задержки обновлений раздражают. Для privacy и security tools задержки могут быть серьезнее. Browser может выпускать fixes для web compatibility, tracking protections, certificate handling, privacy defaults или поведения, связанного с security. Cellular privacy app может обновлять detection logic, совместимость с Android, permissions или поддержку устройств. Даже когда release не является security emergency, надежное распространение updates необходимо для доверия пользователей.

Важный урок не ограничивается Privacy Browser или Privacy Cell. Это паттерн, который должен понимать каждый open-source Android maintainer: release не завершен в момент push tag. Release завершен тогда, когда distribution channel видит его, собирает, публикует, а clients могут его установить.

Что может происходить между tags и F-Droid#

Со стороны симптом выглядит просто: tags были отправлены upstream, но F-Droid их не обнаружил. Root cause может быть одним из нескольких обыденных, но значимых несовпадений.

1. Metadata fdroiddata не совпадает с tag#

F-Droid опирается на metadata files, которые описывают, откуда получать source code, какой commit или tag собирать и какую version information ожидать. Если upstream tags существуют, но metadata все еще ссылается на старый tag, неожиданный naming pattern или другой version code, auto-detection может не сработать или пропустить update.

Для Android packages особенно важны два поля:

• versionName: человекочитаемая версия, например 4.1.2.
• versionCode: монотонно возрастающее integer-значение, которое Android использует, чтобы понять, является ли один build новее другого.

Release tag может выглядеть корректно, но при этом Android manifest или Gradle configuration все еще может выдавать version code, которого F-Droid не ожидает. Если version code не увеличивается, Android не будет считать APK upgrade. Если metadata ожидает одно значение, а build выдает другое, maintainers F-Droid могут быть вынуждены поправить recipe перед публикацией.

2. Tags отправлены, но не видны там, где pipeline делает fetch#

То, что tag был “pushed”, не всегда означает, что он виден каждой automated system в момент проверки. Repository mirroring, cached refs, branch protection, измененные remote URLs, переименованные repositories или особенности Git hosting — все это может создавать timing или visibility gaps.

Для human maintainer открыть repository в browser и увидеть tag может казаться окончательным доказательством. Для automated build pipeline важно другое: может ли настроенный Git remote получить именно этот tag во время build. Если metadata указывает на один source URL, а project был перенесен, зеркалирован или реструктурирован, tag может существовать в одном месте, пока F-Droid проверяет другое.