On Friday, September 09, 2016 03:57:42 PM Adam Borowski wrote: > On Fri, Sep 09, 2016 at 09:39:09AM +0200, Emmanuel Bourg wrote: > > Le 9/09/2016 à 01:13, Henrique de Moraes Holschuh a écrit : > > > "must not change build behavior or build result depending on network > > > availability" is also needed somewhere, if it is not already in there. > > > > If some tests are automatically disabled when the network isn't > > available one could argue that the build behavior is changed though. > > Maybe the rule should focus on the part of the build generating the > > content of the binary packages. Something like this: > > > > "For packages in the main archive, no build step may attempt network > > access in a way that: > > - leaks sensitive data > > - changes the build result or the operations performed to produce it" > > > > (with the build result defined as the binary packages produced) > > As there's no way to distinguish such details automatically, and as > data/privacy leaks can be quite surprising, I'd strongly prefer the nice, > simple rule of "no attempt to access outside network, period". > > If _some_ network accesses are allowed, we can't easily spot the bad ones. > With the current wording of the policy, iptables ... -j LOG is all you need > for a QA check. > > I'd amend the policy to say explicitely "localhost doesn't count as network, > DNS lookup do". > > And DNS lookups do violate the Dissident Test. A request of a > package-specific hostname can be trivially logged by the target DNS server. > A request for a known-to-fail hostname can still be logged by the ISP, and > certain countries (possibly even the US) do log such traffic. Even one for > .invalid is no better, thanks to glibc violating the RFC. > > And if you query google.com? This looks innocuous but in a country that has > been blocking Google for years, no law(*spit*)-abiding citizen will have a > reason to do so, thus raising a miniscule flag that probably out of itself > won't be enough to investigate you but still gets logged. Such a request > is orders of magnitude less harmful than ones from the previous paragraph, > but as positive responses are easier to fake, I see no reason to make an > exception here if we can easily stay 100% safe.
That's not what the dissident test is about [1] [2]. Scott K [1] https://lists.debian.org/debian-legal/2002/08/msg00282.html [2] https://people.debian.org/~bap/dfsg-faq.html (9.b)
