Wolf Gallery is proposed for inclusion in F-Droid as an offline, encrypted media vault built around a strict no-network security model. The request highlights a recurring gap in open-source Android ecosystems: software can be cryptographically strong and fully FOSS, yet still depend on volunteer packaging before it becomes widely accessible through trusted distribution channels like F-Droid.
The core tension here is not the application design, but operational onboarding into a curated repository. Wolf Gallery already declares a complete build recipe, GPL-3.0-only licensing, and a fully offline architecture. What remains is integration work: verifying metadata, reproducing builds, and ensuring it complies with F-Droid’s reproducibility and anti-tracking standards.
What Wolf Gallery is and why it is being proposed for F-Droid#
Wolf Gallery is an Android application described as a fully offline encrypted photo and video vault. It uses AES-256-GCM for encryption and Argon2id for key derivation, with keys stored in the Android Keystore. The stated design removes network access entirely and avoids telemetry, trackers, and Google Play Services dependencies.
The app is licensed under GPL-3.0-only and is published with source code on GitHub under the Wolf Project organization. Native components such as cryptographic primitives are built from source rather than shipped as precompiled binaries, aligning with F-Droid’s expectations for verifiable builds.
The current request is not about feature validation. It is about packaging: a contributor is asking for help opening a merge request in GitLab due to phone or credit card verification barriers. This is a structural dependency in the ecosystem, not a technical flaw in the application itself.
Why does packaging matter for F-Droid users?#
F-Droid acts as a trust filter, not just an app store. It enforces reproducible builds, source availability, and removal of anti-features such as trackers or proprietary dependencies. Applications like Wolf Gallery already align with these constraints on paper, but they still require a packaging layer to become installable through the repository.
Without packaging, users are forced back to direct APK downloads or third-party builds. That shifts trust from a controlled reproducible pipeline to ad-hoc distribution, even when the software itself is well designed.
Wolf Gallery’s request exposes a bottleneck: security properties at the code level do not automatically translate into distribution-level availability. This gap is where many privacy-focused applications stall.
Internal reference context:
- https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
- https://gigatap.top/en/articles/open-source-security-needs-more-than-code
Security model: offline encryption and local trust boundary#
Definition capsule: Wolf Gallery is a local-first encrypted media vault for Android that stores and protects photos and videos using on-device cryptography without network exposure.
The design is straightforward: data is encrypted locally, keys are derived using Argon2id, and encryption uses AES-256-GCM. The Android Keystore is used to hold cryptographic material where possible. The application explicitly disables network access, which reduces remote attack surface but increases reliance on device security posture.
A fully offline model changes the threat landscape. There is no server-side compromise path, no telemetry leakage, and no cloud sync dependency. The security boundary becomes the device itself.
Comparison layer:
| Model | Trust boundary | Attack surface | Failure mode |
|---|---|---|---|
| Cloud gallery apps | Device + remote server | Network + backend APIs | Server compromise or account takeover |
| Wolf Gallery (offline) | Device only | Local storage + OS integrity | Physical access or device compromise |
This shift is not automatically superior in all contexts. It reduces remote risk but concentrates risk locally. If the device is compromised, encryption guarantees depend entirely on implementation correctness and key handling.
What maintainers and users should check#
The F-Droid relevance of Wolf Gallery depends on verifiable build integrity, not only stated properties. Key checks typically include:
- Reproducible build pipeline consistency with declared metadata
- Absence of hidden network calls or runtime telemetry paths
- Correct handling of native components compiled from source
- Dependency audit for any indirect proprietary linkage
The request explicitly states that native components are built from source under core-native/src/main/cpp/vendor/, which aligns with F-Droid requirements, but still requires verification in the packaging process.
Operationally, this is where most delays occur. The bottleneck is not ideology or licensing, but repeatable build verification and metadata integration into the repository.
Related framing:
What not to overclaim#
The presence of AES-256-GCM and Argon2id does not guarantee overall system security. These are strong primitives, but security depends on implementation details: key lifecycle, entropy sources, memory handling, and OS-level isolation.
“No network access” is also not a complete guarantee of privacy. On Android, permissions, inter-process communication, and system-level logging paths still define possible leakage vectors.
The correct interpretation is narrower: Wolf Gallery reduces external dependency risk and simplifies the attack surface. It does not eliminate compromise scenarios.
FAQ#
Is Wolf Gallery automatically safe because it is offline?#
No. Offline status removes remote attack paths but increases reliance on local device security and correct cryptographic implementation.
Why does F-Droid need a packaging volunteer for such apps?#
F-Droid requires reproducible builds and verified metadata integration. Even fully open-source apps need manual onboarding into its build system.
Does encryption alone define the security of a gallery vault app?#
No. Encryption is one layer. Key management, OS integrity, and build transparency determine real-world security outcomes.