Simon McVittie writes ("Bug#813471: network access to the loopback device
should be allowed"):
> On Wed, 04 Oct 2017 at 14:09:53 +0200, Bill Allombert wrote:
> > I want to clarify that I never intended the prohibition of network access
> > to apply to the loopback device, and I expect the other seconders to
> > think the same, given the rationale for the change.
> >
> > To my mind, using the loop backdevice is not performing network access.
My preferred answers to your questions:
> An interesting question related to this: Is it legitimate for a package
> to resolve the reserved name "localhost" during build, and assume that
> it will get 127.0.0.1 and/or ::1 back? Possible answers include:
>
> - yes, always
Yes, assuming that it uses gethostbyname() from the libc.
> - yes, but only if it Build-Depends on libnss-myhostname and/or netbase
I don't know what these things are but I think an system being used
for builds ought to contain an /etc/hosts giving an IP address for
`localhost' and enough libc to read it via gethostbyname().
> - no, and it must not attempt to resolve that name because that might
> be network access in corner cases
Any such corner case is a bug. Hosts should not contact the network
to resolve `localhost'. if they do it is an information leak.
> Similarly, can it assume it can resolve $(hostname) always, or only if
> it B-D on libnss-myhostname, or never?
I think `resolve $(hostname)' is a bit ambiguous.
I think any build script is entitled to call
gethostbyname(`hostname`), because that is the only way to get an FQDN
for the current host. The canonical name returned by the libc must be
a value containing at least some dots. My expectation is that this
will be implememted with an appropriate entry in /etc/hosts as
documented in `THE FQDN' in hostname(1).
It is not ok for the build process to assume that any of the resulting
addresses are useable for any purpose. The build MUST NOT try to
connect to them. And it MUST NOT fail if there are only IPv4 address;
or only IPv6 .addresses.
Of course reproducible builds mean that the build hostname should not
be baked into binaries.
> At the moment, schroot/sbuild is very likely to make both localhost and
> $(hostname) resolvable (/etc/hosts from the host system is copied into
> the chroot, and that file is not strictly guaranteed to make localhost or
> $(hostname) resolvable but probably does), but pbuilder with its default
> USENETWORK=no configuration does not necessarily have a hosts file or a
> working resolv.conf. dbus currently FTBFS on reproducible-builds (#897662)
> because one of its automated tests assumes localhost is resolvable.
I think this is a bug in pbuiler.
> I started to implement a feature in pbuilder to make it create a trivial
> /etc/hosts that can resolve localhost and friends (the same as is created
> by netbase.postinst) whenever it locks down resolv.conf, but then realised
> that netbase isn't Essential, so it isn't completely clear whether the
> resolvability of localhost is part of the basic "API" of a Debian system.
I think it must be part of the basic API for a build environment. I'm
a bit surprised that netbase isn't build-essential. Certainly IMO an
/etc/hosts with the entries you describe above should be implied by
build-essential, one way or another.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
