pfSense Community Edition source build reproducibility and XML config package constraints

Question

A repeatable development environment for pfSense Community Edition is being considered using the public source build and XML configuration restore.

Feature context and constraints

The Community Edition source is built from FreeBSD with build scripts in the public repository. Builds pull packages and ports from public repositories at build time, so output depends on the exact ports tree and package versions available during each run. No officially supported version-pinned container or build image is documented.

pfSense XML configuration backups preserve firewall rules and settings but do not include installed packages or their dependencies. Restoring an XML backup on a clean install requires manual package reinstallation, and package versions are not pinned in the configuration file.

What is the documented expectation for build reproducibility across separate runs for a given release tag? Is there a supported mechanism to capture installed packages alongside an XML config for repeatable restore? What permission boundary or configuration option controls package handling during XML config restore?

Tasadduq Burney · Answer

Direct answer
pfSense Community Edition builds from a public release tag are not expected to be bit-for-bit reproducible across separate runs. The XML configuration backup does not capture installed packages, and no supported pfSense permission boundary or configuration option controls package handling during an XML restore.

Assumptions and uncertainty
Assumption: This applies to pfSense Community Edition, not pfSense Plus, which may have different build artifacts and repository access. Because the research brief flags current verification requirements, treat package-version drift and restore behavior as items to confirm against the live pfsense/pfsense repository and Netgate Docs before production use.

Confirmed behavior

Build scripts retrieve FreeBSD ports and package repositories at build time. A release tag pins the source tree, but not the package versions resolved during that build.
config.xml stores core pfSense configuration: interfaces, firewall rules, NAT, VPN, users, certificates, and related system settings. It does not store the installed package list, package configuration, or package dependencies.
XML restore replaces the configuration file only. The pkg(8) database and installed package files are untouched, so there is no GUI checkbox, CLI flag, or permission boundary that changes package behavior during restore.
Restoring config.xml to a different pfSense major or minor version is unsupported and may break because of configuration schema changes.

Steps for this case

Install the same pfSense CE release on the target system.
Restore config.xml through Diagnostics > Backup & Restore.
Reinstall required packages manually using System > Package Manager or the pkg CLI.
If exact package versions are required, script post-restore installation against a pinned or mirrored package repository.

Verification
Export config.xml from a running system, add a package, export again, and compare the files. No installed-packages section should appear. Before assuming two builds from the same tag are identical, inspect the ports tree snapshot and package repository state used by the build script.

Missing diagnostic detail: Are you restoring to the same pfSense CE major and minor version? Cross-version restore is unsupported and changes the recommended procedure.

pfSense Community Edition source build reproducibility and XML config package constraints

Feature context and constraints

1 answer

Direct answer

Assumptions and uncertainty

Confirmed behavior

Steps for this case

Verification

Your perspective belongs here.

0 question comments