Development

Network access by Debian package builds

The Debian project is known for strictly adhering to its various internal rules and guidelines; a package that some developers feel is in violation of the Debian Free Software Guidelines, for example, is sure to spawn considerable debate, regardless of its popularity or its origin. Recently, a Debian package maintainer realized that a particular package violated a guideline prohibiting network access during the build process, thus sparking a discussion about that guideline and what its ultimate purpose is.

On September 7, Vincent Bernat wrote to the debian-devel list, noting that the python-asyncssh package, when building, runs a unit test that attempts a DNS lookup. That would seem to violate section 4.9 of the Debian packaging policy, which states "For packages in the main archive, no required targets may attempt network access."

The issue was reported by Chris Lamb in a bug tagged as "serious." Fixing that violation, Bernat said, is simple enough—just disable the test in question—but Bernat wondered whether or not the policy rule is genuinely useful. Since the test originates in the upstream project, Debian would have to carry the patch indefinitely, adding what might be deemed considerable overhead for little real gain.

Furthermore, the test in question performs a lookup for a host named fail, which is expected not to succeed, and the purpose of the test is to ensure that the package handles the lookup failure gracefully. The build, Bernat said, works in an isolated network namespace and the package builds reproducibly with or without network access. Consequently, he asked for feedback on ignoring the violation in this case:

Various responses to Bernat's question suggested alternatives to removing the test, but much of the discussion focused on the purpose of the no-network-access rule. Christian Seiler, among others, said the rule was intended to prevent information leaks, which a DNS lookup would certainly cause.

Paul Wise, however, felt that the rule was intended to ensure that nothing outside of the local build environment had any impact on the result of the build process. Steve Langasek concurred with that viewpoint, noting that:

It would appear that there are more than a few packages in the archive that do violate the no-network-access rule. Christoph Biedl said "a certain package (name withheld) did a *lot* of DNS traffic in the test suite, so far nobody has shown concerns". And the test in python-asyncssh, as written, is problematic: if there is a host named fail in the local DNS zone, the lookup will succeed. While unlikely, this is possible; a better test would be to look up a hostname that is guaranteed to be nonexistant by IANA rules (such as .invalid). In addition to being a better test of lookup-failure handling, that change would avoid the risk of an information leak through the lookup request (or, at least, reduce the risk, depending on the behavior of the nameserver).

Russ Allbery contended, though, that there is no genuinely important information leak anyway. He made that comment in reply to Thomas Goirand, who suggested that the issue of attempting network access was valid, but questioned whether "serious" was an appropriate severity level:

Others on the list, starting with Gregor Hermann, suggested revising the wording of the rule itself. Allbery proposed two rules, one saying that the package build "must not fail when it doesn't have network access" and another that warns against leaking privacy-related information; several similar variations arose from other participants in the thread. But Adam Borowski replied that attempts to distinguish between different types of network usage are, ultimately, doomed to fail, making such an effort pointless:

Borowski reiterated the privacy-leak angle, saying that even innocent-looking DNS lookups violate "the Dissident Test"—that is, a user performing the build in some location where state-sponsored surveillance is a threat could put themselves at risk of investigation.

But not everyone found the "Dissident Test" argument persuasive. Allbery, in particular, contended that the lookup of a well-known hostname did not reveal significant personally identifiable data, saying:

Moreover, Allbery continued, the entire issue is somewhat overblown:

Goirand concurred with that sentiment, noting that Debian already has a contentious relationship with some upstream projects. Zlatan Todoric also agreed, saying "I also feel that we are losing too much energy on this and this is not sustainable long term, nor fun."

The discussion eventually tapered off without a firm conclusion as to whether or not Debian policy should be amended and with no guidelines for a broad approach to assessing future network accesses that occur during package builds. It seems that the status quo will remain in place, then. Each package maintainer will have to individually assess any problematic network-access attempts in build targets, and some of those access attempts may survive for some time if they are determined to pose neither a serious privacy risk nor to impact the result of the build.

On the surface, it might seem like the Debian project has decided to let a minor rules violation slip through the cracks. Bernat had closed the bug as wontfix prior to raising the issue on the discussion list and has not revisited it. But, at another level, the project could be said to have taken the underlying issues—privacy and reproducible builds—seriously and determined that those principles were being upheld. And that would surely be considered Debian behaving as it usually does, with a strict attention to detail.

Comments (14 posted)

Quotes of the week

Comments (2 posted)

Vim 8.0 released

Comments (16 posted)

python-can 1.5 released

Version 1.5 of python-can, the CAN (Controller Area Network) Bus support package for Python, has been released. "This has been cooking in a development branch for a few months with plenty of changes and bug fixes. Documentation has been updated quite substantially, a virtual interface has been added and a consistent filtering api has been added. " Also noteworthy is that the next release, 1.6, is slated to drop support for the J1939 automotive message protocol.

Full Story (comments: none)

Kügler: LTS releases align neatly for Plasma 5.8

Comments (37 posted)

U-Boot v2016.09 is available

U-Boot version 2016.9 is now available. The announcement notes that "lots and lots" of new architecture, SoC, and platform updates are included in the release. The update also adds support for device tree overlays and for Secure Boot on ARM and PowerPC.

Full Story (comments: none)

Development newsletters from the past week

• What's cooking in git.git (September 8)
• What's cooking in git.git (September 9)
• Git Rev News (September 14)
• This Week in GTK+ (September 12)
• OCaml Weekly News (September 13)
• Perl Weekly (September 12)
• PostgreSQL Weekly News (September 11)
• This Week in Rust (September 13)
• Wikimedia Tech News (September 12)

Comments (none posted)

Apache NetBeans Incubator Proposal

Comments (27 posted)

Abbott: Success with Interns

Laura Abbott marks the end of the latest round of open-source internships at Outreachy with a blog post reflecting on "what makes an internship successful", especially as seen in the kernel team's internships. Among Abbott's lessons: "Choose your tasks carefully. Tasks with a specific goal but multiple ways to solve are best. Too open ended tasks can be frustrating for all involved but there should be some chance for decision making. Just giving a list of tasks and exactly how they should be completed isn't good for learning. Give your intern a chance to propose a solution and then review it together." Also: "Speaking of review, code review is a skill. Model how to respond to code review comments. Encourage interns to practice reviewing others code and ask questions as well." That is just a sampling; in total, Abbott lists well over a dozen take-aways from the experience, all worth reading.

Comments (2 posted)