>This can lead to a replay attack where an attacker substitutes an archive with an earlier—unmodified—version of the archive. This would prevent APT from noticing new security updates which they could then exploit.
>To mitigate this problem, APT archives includes a timestamp after which all the files are considered stale[4].
> The Valid-Until field may specify at which time the Release file should be considered expired by the client. Client behaviour on expired Release files is unspecified.
Well, of course the client behavior is under-specified -- sometimes the client is a human constructing a URL to download a .deb in a web browser over a corp-approved proxy, and then hand-installing the package with `deb -i`, bypassing all the security checks. Or sometimes there's a caching proxy (or three) between the client and the server. Or maybe IT has modified apt to only connect to repositories maintained by the IT department, and rejects sources from other domains.
At the first place I worked at: Zip Files. $customername-YYYYMMDD.zip. "Branches"? Easy. Just create a new folder. Merging? WinMerge is your friend :-D Deployment was sending a Zip File with DLLs to the customer. Obviously no build system, but built on the dev's local system.
Thank god I could convince the team to move to SVN.
>To mitigate this problem, APT archives includes a timestamp after which all the files are considered stale[4].
Let's take a look at the repo spec then:
https://wiki.debian.org/DebianRepository/Format#Date.2C_Vali...
> The Valid-Until field may specify at which time the Release file should be considered expired by the client. Client behaviour on expired Release files is unspecified.
“Should”, “may”, and unspecified behaviour.