Re: Snapshot behind Fastly; roles and responsibilities
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
Reply to: