On 11/19/24 9:11 AM, Simon Josefsson wrote: > snapshot-real.debian.org -> goes it Debian-maintained HTTPS server > > Of course replace with your own preference for "-real".
Tencent sent abusive traffic to snapshot-master, which pointed to (and was designed to be) a real machine. It is also much harder to provide a reliable server unless it is a rotation. This implies that we need to keep doing the same[1] abuse fighting ourselves. > I believe that the usage and privacy policy of most CDN's are generally > incompatible with Debian's goals, and one reason this hasn't hit the fan > is because the usage and privacy policy's are not documented properly. But are the policies incompatible/inconsistent with Debian's own privacy policy[2]? > So nobody even knows what usage and privacy policy they are using when > accessing for example https://archive.debian.org/ I'm not sure that's true, per the above. > Presumably the usage policy is something along the line of "we'll > happily substitute libcrypto3-udeb_3.0.14-1~deb12u2_arm64.udeb with a > compromised version for some particular IP/User-Agent's if someone calls > us and asks nicely and offers an invoicing opportunity". I don't want to throw mirror operators under the bus, but it is unclear to me if we have guarantees against that for the country-specific serving under cc.debian.org either. Similarly I don't know if the Debian policy applies to them and what kind of logging they do. With Fastly we at least have some contractual relationship AIUI. Coming from a European perspective the privacy policy already mentioned seems kind of sufficient to me, but companies would have data processing contracts with all of the DCs and services (external companies) they are using. And I consider this particular example a bit of a red herring, though: We should make sure that the archive signing infrastructure is safe and sensible and we always (for all of the mirror infrastructure) assumed that users have to do their own verification through apt and the signed indices we ship. Or they would need to pin hashes for the files. We never trusted the mirrors not to substitute but for substitution attempts to throw errors. Kind regards Philipp Kern [1] I pondered doing this kind of system myself. But it's work and it does not look like there's [2] https://www.debian.org/legal/privacy
