Re: Network access during build
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)
Reply to: