Temporary Storage Location for Repositories

Repomaker needs to maintain a local copy of each repository so it can be synced to remote storage locations. This is also required for fdroidserver, so it can perform tasks on the repository such as scanning APKs, extracting icons and creating the index.

In the original and current design of repomaker, this local copy is stored in a location that is not normally accessible via the webserver. The reason for this is that users might have apps or other data in their repository that they don't necessarily want to have exposed to the web (yet).

However, there are files such as the repository QR code, app icons and screenshots that need also to be accessible through the webserver, so they can be shown to the user. Due to this, we need to maintain two copies (or do a hardlink if supported) and keep them in sync (e.g. delete both when an app is deleted).

If all repository information would be considered public anyway, we could simplify the storage concept and the code behind that. This would have the added benefit that hosted repomaker instances would get their default storage location for free and don't need to do yet another copy of their potentially very large repository.

Users who need more private repositories, could still run repomaker locally or in an intranet instead.

What do people think? Can we consider repositories public and communicate this to users?

@eighthave @pserwylo @mvdan It would be great to have your opinion on this fundamental design decision

some discussion here https://botbot.me/freenode/fdroid-dev/msg/83711247/

Some more discussion happened in Jitsi. The outcome was that the local repository copy should only be accessed by authenticated users to be able to support private repositories.

There are however other possibilities that could enable us to reach the goal of only having to store one single copy of various files:

1. checking authentication before granting access to files
2. including a random token in the URL for the local repository copy

I'll look into these possibilities.

closed via commit 92a971b1c4afc76f2ca79a5fc141e18dd3ab22f3

changed milestone to %1.0