The nanobsd script is relying on behaviour that has been patched in the next release of libarchive (https://github.com/libarchive/libarchive/commit/5935715). Excerpt from /usr/obj/nanobsd.soekris/_.di Populating s1a from /usr/obj/nanobsd.soekris/_.w /usr/obj/nanobsd.soekris/_.mnt/.cpio: .: Path is absolute: Unknown error: -1 /usr/obj/nanobsd.soekris/_.mnt/./varcpio: ./var: Path is absolute: Unknown error: -1 This prevents building a good image. I haven't dug into a suggested fix as of yet. See also: - https://github.com/libarchive/libarchive/pull/110 - http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2304
Left as impacts only me. The commit in question that would cause this issue is part of bug 206386 and the libarchive 3.2.0 release is only in the alpha stages at this time (https://github.com/libarchive/libarchive/releases/tag/v3.1.900a). I'll revisit when I get the time.
Created attachment 170272 [details] add --insecure to cpio calls Use --insecure to on cpio(1) calls As of libarchive-3.2.0, extraction to absolute paths is considered an insecure behavior to address CVE-2015-2304. The --insecure flag must to used to allow extraction to absolute paths.
Turns out we relied on absolute path extraction in multiple places as it broke ports as well after the 3.2.0 update [1] and the commit was reverted shortly after [2]. [1] https://svnweb.freebsd.org/base?view=revision&revision=299529 [2] https://svnweb.freebsd.org/base?view=revision&revision=299576 As per the new cpio(1) manual, --insecure is needed for: "This allows extraction via symbolic links, absolute paths, and path names containing .. in the name." On r299575 before the revert, the image builds are broken with the "Path is absolute" failure before applying this change and fixed afterwards. There is also no change to building a good image by using --insecure on r299278 before the update.
This was fixed after https://svnweb.FreeBSD.org/changeset/base/299896 which imported the upstream commit to fix behaviour of the -p/--pass-through flag. This PR is now overcome by events with that fixed in upstream libarchive.