From nobody Wed Jul 30 22:27:40 2025 X-Original-To: freebsd-pkgbase@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4bsn100jqFz635dW; Wed, 30 Jul 2025 22:28:20 +0000 (UTC) (envelope-from vimanuelt@fastmail.fm) Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4bsn0z5tr8z3jv3; Wed, 30 Jul 2025 22:28:19 +0000 (UTC) (envelope-from vimanuelt@fastmail.fm) Authentication-Results: mx1.freebsd.org; none Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfout.phl.internal (Postfix) with ESMTP id 4D914EC21A0; Wed, 30 Jul 2025 18:28:19 -0400 (EDT) Received: from phl-imap-01 ([10.202.2.91]) by phl-compute-01.internal (MEProxy); Wed, 30 Jul 2025 18:28:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1753914499; x=1754000899; bh=KcXLdpLoqXEmOLVhsQ87fdqAyC/5VhE1nt2z+T3rdG4=; b= Qv+RaB1g5sQdKmEwQrdfIeI7/UZR9PRaLPJZPaOTDalDg7Qec6AUozTChcrFtTlA 2j7pkrHohnkrS35gvDzKYwTeQTFfRttjZWTofuWdsReyrBJWnKMaB2ZSMuOaC/wC Qsej0ln+jswRUFl55KBMhnmjPo04BgJEG84/bzv3Y6T6H5MKujyHlmZB6mjCJUE5 mAkmni6lweRLg9cUjwu8qgb4Iz3zV0n9cT76STsfFN3e3Psgbw4xpHbG8gjark5i pBJjZKV9AUUjC0RtZDJb2OjXjgwl6Vd3ZlsBOWpcDOk1XOtArwISfAHzhK5EXIjy IHW7u35MjMJ/nLPkGqc2AQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1753914499; x= 1754000899; bh=KcXLdpLoqXEmOLVhsQ87fdqAyC/5VhE1nt2z+T3rdG4=; b=W 8oYUBag+kEaQ+HzeYj/HkQc6yXAlOTl2Rzgn5oTddV3lnw1IO9j+boJcFEoLP65U DJfQe1xsJ6sPKJYMmbjFSxggLZf7KB7Ojdmahg4OLyTjPM1cNmSsk46d+sFa6Rhs BFTjs+3up5gPfyTwbNzMHfPMQKK/AkDbjzEbYFYwlZY9MhvYfXukpjusFcvu0MrX Vv42xRDUbMXN43LukePlOF+SLSNmodFihqBjWNiwMi8e0q5yEHRQQL7w6Q/6kCul XvZVvbF2mq6arocaxGsyio2OdKQvWVSgWp3T3HqzWRjIHZsb7wxOGWffyFCPuLBc H9jb5N6He5edOcYiFSvSg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdelledufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefoggffhffvvefkjghfufgtgfesthhqredtredtjeenucfhrhhomhepvhhimhgrnhhu vghlthcuoehvihhmrghnuhgvlhhtsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtth gvrhhnpefhgeelhffgteeitdfhteekfeeggeegffegffetudejuddvudelteevuddtueef heenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhhrghruggvnhgvuggsshgurdhorh hgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhi mhgrnhhuvghlthesfhgrshhtmhgrihhlrdhfmhdpnhgspghrtghpthhtohepledpmhhoug gvpehsmhhtphhouhhtpdhrtghpthhtohepsggrphhtsehfrhgvvggsshgurdhorhhgpdhr tghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrghdprh gtphhtthhopehfrhgvvggsshguqdhpkhhgsehfrhgvvggsshgurdhorhhgpdhrtghpthht ohepfhhrvggvsghsugdqphhkghgsrghsvgesfhhrvggvsghsugdrohhrghdprhgtphhtth hopehfrhgvvggsshguqdhsthgrsghlvgesfhhrvggvsghsugdrohhrghdprhgtphhtthho pehshhgrfihnrdifvggssgeshhgrrhguvghnvggusghsugdrohhrghdprhgtphhtthhope hvvghrmhgruggvnhesihhnthgvrhhirgdrphhlpdhrtghpthhtohepphgvthgvsehnohhm rggulhhoghhitgdrohhrghdprhgtphhtthhopegsrghnvgesphhmfhdruhhnshdrrggtrd hrsh X-ME-Proxy: Feedback-ID: if8e14258:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 4A0AE18C0066; Wed, 30 Jul 2025 18:28:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface List-Id: Packaging the FreeBSD base system List-Archive: https://lists.freebsd.org/archives/freebsd-pkgbase List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkgbase@FreeBSD.org MIME-Version: 1.0 X-ThreadId: A0SBu-oedW3g Date: Thu, 31 Jul 2025 07:27:40 +0900 From: vimanuelt To: vermaden , "Shawn Webb" Cc: "freebsd-pkgbase@freebsd.org" , "freebsd-stable@freebsd.org" , "freebsd-pkg@freebsd.org" , "freebsd-current@freebsd.org" , pete@nomadlogic.org, bapt@freebsd.org, bane@pmf.uns.ac.rs Message-Id: In-Reply-To: References: Subject: Re: PKGBASE Removes FreeBSD Base System Feature Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4bsn0z5tr8z3jv3 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:151847, ipnet:103.168.172.0/24, country:AU] Building on Vermaden=E2=80=99s observations, it is worth reevaluating th= e current architectural assumptions underpinning FreeBSD=E2=80=99s packa= ge management model. The practice of overloading a single tool, namely p= kg, to manage both the base system and third-party software introduces s= emantic ambiguity, violates long-standing UNIX separation-of-concerns pr= inciples, and compromises system resilience. This unification, while exp= edient, creates a fragile interface that conflates operational layers wi= th 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 th= e FreeBSD filesystem hierarchy. At the foundation lies the base system, = encompassing the kernel, essential userland utilities, standard librarie= s, and canonical configuration. These components reside in /bin, /sbin, = /lib, and /etc, and collectively define the system=E2=80=99s identity, o= perability, and recoverability. Managing this layer through the same mec= hanisms used for optional software creates an unacceptable risk surface,= wherein routine administrative operations=E2=80=94such as invoking pkg = delete -af=E2=80=94may render the system unbootable. To address this, the base system should be managed independently by a sp= ecialised tool=E2=80=94basectl, for example=E2=80=94whose operational sc= ope is restricted to base components alone. This tool would support sign= ed, versioned manifests and enforce immutability policies by default, wh= ile permitting profile-based customisation where appropriate. Such a sys= tem would reduce coupling, restore system trust boundaries, and provide = formal recovery semantics. The second layer comprises third-party software drawn from the FreeBSD p= orts collection. This software, by convention, is isolated under /usr/lo= cal and is appropriately managed by the existing pkg tool. In this revis= ed model, pkg would remain responsible for software acquisition, depende= ncy resolution, and updates within its designated namespace, but would b= e explicitly barred from operating on core system components. This disti= nction not only aligns with historical UNIX design patterns but also imp= roves auditability and operational safety. The third layer consists of the user domain. Individual users often requ= ire localised environments to install and manage tools without elevated = privileges. For this, a dedicated user-scoped package manager=E2=80=94te= ntatively userpkg=E2=80=94could enable installations within $HOME, ideal= ly 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 overri= des, and declarative environment configurations. In effect, it would off= er FreeBSD users capabilities comparable to those found in systems like = Nix, Guix, or Flatpak, without compromising the integrity of the host sy= stem. The result of this layered design is a system whose components are gover= ned by coherent authority domains, each with appropriate tooling and lif= ecycle management. The risks associated with monolithic tooling=E2=80=94= such as destructive global operations, inconsistent state transitions, a= nd violated invariants=E2=80=94are mitigated by structural separation an= d role-specific semantics. Administrators gain clearer recovery paths, u= sers are granted autonomy, and the overall system becomes more predictab= le and maintainable. Importantly, this proposal is not a deviation from FreeBSD=E2=80=99s arc= hitectural tradition, but a principled refinement. It reasserts the boun= dary 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 delib= erate separation across the base, administrative, and user levels, FreeB= SD 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 too= l to ensure clarity and readability. I recognize that informal regional = dialects=E2=80=94particularly Southern American English=E2=80=94may 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=20 > /usr/local/etc/pkg and /var/db/pkg dirs for configuration. > > Use separate pkgbase(8) with /etc/pkgbase and /usr/local/etc/pkgbase=20 > and /var/db/pkgbase dirs for managing PKGBASE packages. By pkgbase(8) = I=20 > have the same pkg(8) project in mind - just renamed as pkgbase(8) and=20 > with */pkgbase dirs instead of */pkg. > > (2) > > My other idea is to 'mark' all FreeBSD Base System packages as 'vital'=20 > - so they are never removed automatically - but if someone wants to=20 > remove them with additional force option - then I assume he knows what=20 > 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=20 > have anything against such additional features or layers - its not=20 > related to the main topic IMHO - that with 'classic' FreeBSD the *pkg=20 > delete -af* removes only third party packages and with PKGBASE FreeBSD=20 > 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>;=20 > DW: freebsd-pkgbase@freebsd.org; freebsd-stable@freebsd.org;=20 > freebsd-pkg@freebsd.org; freebsd-current@freebsd.org;=20 > >>=20 >>> On Wed, Jul 30, 2025 at 02:28:35AM +0200, vermaden wrote: >>> Hi, >>>=20 >>> after short discussion here: >>> - https://github.com/freebsd/pkg/issues/2485 >>>=20 >>> I got REALLY concerned. >>>=20 >>> One of THE features and selling points of a FreeBSD UNIX system is > the 'untouchable' Base System. >>>=20 >>> Without PKGBASE all the features are preserved. >>>=20 >>> But when You convert to PKGBASE its ... GONE! >>>=20 >>> Consider this command: >>>=20 >>> # pkg delete -af >>>=20 >>> What it does? >>>=20 >>> It removes all third party packages on 'classic' FreeBSD system > without touching the FreeBSD Base System. >>>=20 >>> What the same "pkg delete -af" command does on a PKGBASE FreeBSD > system? >>>=20 >>> It kills/destroys almost all of the FreeBSD Base System and leaves > only two PKGBASE packages called: >>>=20 >>> - FreeBSD-clibs >>> - FreeBSD-runtime >>>=20 >>> All the rest of Base System is GONE. Destroyed. >>=20 >> Hey vermaden, >>=20 >> 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. >>=20 >> I suspect there could also be room for discussion on technical >> measures pkg could adopt to help mitigate issues like this. >>=20 >> 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. >>=20 >> Thanks, >>=20 >> --=20 >> Shawn Webb >> Cofounder / Security Engineer >> HardenedBSD >>=20 >> 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_Web= b/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc >>=20 >>