Re: Network access during build
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.
--
Second "wet cat laying down on a powered-on box-less SoC on the desk" close
shave in a week. Protect your ARMs, folks!
Reply to: