Date: Thu, 31 Jul 2025 07:27:40 +0900 From: vimanuelt <vimanuelt@fastmail.fm> To: vermaden <vermaden@interia.pl>, "Shawn Webb" <shawn.webb@hardenedbsd.org> Cc: "freebsd-pkgbase@freebsd.org" <freebsd-pkgbase@freebsd.org>, "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org>, "freebsd-pkg@freebsd.org" <freebsd-pkg@freebsd.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>, pete@nomadlogic.org, bapt@freebsd.org, bane@pmf.uns.ac.rs Subject: Re: PKGBASE Removes FreeBSD Base System Feature Message-ID: <c547347a-9e22-45ef-a11d-0441000a9905@app.fastmail.com> In-Reply-To: <fozdqxvxzylwxyvzfrmt@fobq> References: <gblzvammhkzqxmwduyap@vpbk> <na7zou5skn2rcvyoigjgnnlzaomqsx23aj7dq3epq5ds65cu4y@ukgxp5zsj7j7> <fozdqxvxzylwxyvzfrmt@fobq>
index | next in thread | previous in thread | raw e-mail
Building on Vermaden’s observations, it is worth reevaluating the current architectural assumptions underpinning FreeBSD’s package management model. The practice of overloading a single tool, namely pkg, to manage both the base system and third-party software introduces semantic ambiguity, violates long-standing UNIX separation-of-concerns principles, and compromises system resilience. This unification, while expedient, creates a fragile interface that conflates operational layers with distinct trust, mutability, and lifecycle characteristics. A more coherent model would partition the system into three well-defined strata, each governed by its own tooling and aligned explicitly with the FreeBSD filesystem hierarchy. At the foundation lies the base system, encompassing the kernel, essential userland utilities, standard libraries, and canonical configuration. These components reside in /bin, /sbin, /lib, and /etc, and collectively define the system’s identity, operability, and recoverability. Managing this layer through the same mechanisms used for optional software creates an unacceptable risk surface, wherein routine administrative operations—such as invoking pkg delete -af—may render the system unbootable. To address this, the base system should be managed independently by a specialised tool—basectl, for example—whose operational scope is restricted to base components alone. This tool would support signed, versioned manifests and enforce immutability policies by default, while permitting profile-based customisation where appropriate. Such a system would reduce coupling, restore system trust boundaries, and provide formal recovery semantics. The second layer comprises third-party software drawn from the FreeBSD ports collection. This software, by convention, is isolated under /usr/local and is appropriately managed by the existing pkg tool. In this revised model, pkg would remain responsible for software acquisition, dependency resolution, and updates within its designated namespace, but would be explicitly barred from operating on core system components. This distinction not only aligns with historical UNIX design patterns but also improves auditability and operational safety. The third layer consists of the user domain. Individual users often require localised environments to install and manage tools without elevated privileges. For this, a dedicated user-scoped package manager—tentatively userpkg—could enable installations within $HOME, ideally under a directory conforming to the XDG Base Directory Specification such as ~/.local. This tool would function independently of system-wide package databases and would support multiple versions, user-level overrides, and declarative environment configurations. In effect, it would offer FreeBSD users capabilities comparable to those found in systems like Nix, Guix, or Flatpak, without compromising the integrity of the host system. The result of this layered design is a system whose components are governed by coherent authority domains, each with appropriate tooling and lifecycle management. The risks associated with monolithic tooling—such as destructive global operations, inconsistent state transitions, and violated invariants—are mitigated by structural separation and role-specific semantics. Administrators gain clearer recovery paths, users are granted autonomy, and the overall system becomes more predictable and maintainable. Importantly, this proposal is not a deviation from FreeBSD’s architectural tradition, but a principled refinement. It reasserts the boundary between system and application, elevates the role of policy in tool design, and brings FreeBSD in line with contemporary best practices in operating system modularity and user space isolation. By embracing deliberate separation across the base, administrative, and user levels, FreeBSD can strengthen its reliability and clarity while remaining responsive to evolving user needs. - Vic P.S. This proposal reflects my own thinking, though I used a grammar tool to ensure clarity and readability. I recognize that informal regional dialects—particularly Southern American English—may not serve this audience well, and I have taken care to present the ideas in a more neutral and accessible register. On Thu, Jul 31, 2025, at 03:30, vermaden wrote: > Hi. > > I have only two proposals that seem sensible. > > (1) > > Keep pkg(8) for third party packages with /etc/pkg and > /usr/local/etc/pkg and /var/db/pkg dirs for configuration. > > Use separate pkgbase(8) with /etc/pkgbase and /usr/local/etc/pkgbase > and /var/db/pkgbase dirs for managing PKGBASE packages. By pkgbase(8) I > have the same pkg(8) project in mind - just renamed as pkgbase(8) and > with */pkgbase dirs instead of */pkg. > > (2) > > My other idea is to 'mark' all FreeBSD Base System packages as 'vital' > - so they are never removed automatically - but if someone wants to > remove them with additional force option - then I assume he knows what > he is doing. > > I would prefer (1) over (2) if you ask me. > > As for additional groups like base-minimal or base-standard - I do not > have anything against such additional features or layers - its not > related to the main topic IMHO - that with 'classic' FreeBSD the *pkg > delete -af* removes only third party packages and with PKGBASE FreeBSD > it removes almost all system rendering it unbootable/unusable. > > Hope that helps. > > Regards, > vermaden > > > > Temat: Re: PKGBASE Removes FreeBSD Base System Feature > Data: 2025-07-30 4:18 > Nadawca: "Shawn Webb" <shawn.webb@hardenedbsd.org> > Adresat: "vermaden" <vermaden@interia.pl>; > DW: freebsd-pkgbase@freebsd.org; freebsd-stable@freebsd.org; > freebsd-pkg@freebsd.org; freebsd-current@freebsd.org; > >> >>> On Wed, Jul 30, 2025 at 02:28:35AM +0200, vermaden wrote: >>> Hi, >>> >>> after short discussion here: >>> - https://github.com/freebsd/pkg/issues/2485 >>> >>> I got REALLY concerned. >>> >>> One of THE features and selling points of a FreeBSD UNIX system is > the 'untouchable' Base System. >>> >>> Without PKGBASE all the features are preserved. >>> >>> But when You convert to PKGBASE its ... GONE! >>> >>> Consider this command: >>> >>> # pkg delete -af >>> >>> What it does? >>> >>> It removes all third party packages on 'classic' FreeBSD system > without touching the FreeBSD Base System. >>> >>> What the same "pkg delete -af" command does on a PKGBASE FreeBSD > system? >>> >>> It kills/destroys almost all of the FreeBSD Base System and leaves > only two PKGBASE packages called: >>> >>> - FreeBSD-clibs >>> - FreeBSD-runtime >>> >>> All the rest of Base System is GONE. Destroyed. >> >> Hey vermaden, >> >> As mentioned in the GitHub ticket, it appears there might be some room >> for discussion on which base packages ought to be marked vital and if >> the current list (of two) should be expanded. >> >> I suspect there could also be room for discussion on technical >> measures pkg could adopt to help mitigate issues like this. >> >> I myself don't have much in the way of suggestions on either topic of >> discussion. I'm simply hoping this email moves the needle forward in a >> positive direction. >> >> Thanks, >> >> -- >> Shawn Webb >> Cofounder / Security Engineer >> HardenedBSD >> >> Signal Username: shawn_webb.74 >> Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 >> > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc >> >>help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c547347a-9e22-45ef-a11d-0441000a9905>