From nobody Thu Jul 31 02:41:00 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 4bstgG2m87z63LG9; Thu, 31 Jul 2025 02:43:22 +0000 (UTC) (envelope-from vimanuelt@fastmail.fm) Received: from fout-b5-smtp.messagingengine.com (fout-b5-smtp.messagingengine.com [202.12.124.148]) (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 4bstgG0L3Tz474d; Thu, 31 Jul 2025 02:43:22 +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.stl.internal (Postfix) with ESMTP id C86D11D00163; Wed, 30 Jul 2025 22:43:20 -0400 (EDT) Received: from phl-imap-01 ([10.202.2.91]) by phl-compute-01.internal (MEProxy); Wed, 30 Jul 2025 22:43:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= 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=1753929800; x=1754016200; bh=0Cj/myqQ20wI9QZFop+IqQWyYd9d8YfOQwk54Z7kY/U=; b= azVVzZt3nENhwka7Ce+e17q7wXpR+RSGHinFMzqGFS+u0qpCUVHDRc8hBARf1cBS IfPR3nxDZ0ZibDovWiOPjPveJSsEt6pBlUXNh2F3rOcU4sbUrvwvimaBpRyED1IN /lPAezMTErcpo+6hFtqlZyNDgUBarvgWhWIfag1ANbwRUt40gGt6JickE+zJCt5/ dDeBbPIQIE1tv0wdYu/EKiQyfOZZDGaGXfCnh+HhF2L3R40DqpefVi78Ryo7/+M3 t/7j6M23bVnZbUEGnMPBpjVQA9e8rmo4kkldk813bjjhvSuGZDITz0BlkUfQS4jK WZR3tq2kVwr5p/d/pywVaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=1753929800; x=1754016200; bh=0 Cj/myqQ20wI9QZFop+IqQWyYd9d8YfOQwk54Z7kY/U=; b=f/b9D9yxu8D7ExHy8 WUN3Sllya6xG+ASXlx0YoSXInP2b+WqLPxH5uAZHCHSq9htXd1BG/S17lSApTBhm q6D6VMstKzAiloBxQPPZW7fJyJrVSEIN6mMA8kzG6GbL5y5HIw6fLwhyTQJfdvhU Yd0AcjpkpN21D+5yTzH6uLEPkCzOqAjmvdSW0TSJnGHESZKWlx/2+86pPrpNA3dJ WMH203fODjRxwGteAw1bsNieqCIAG9VafFxHPJMn+jft/QH/N1TMlfFZC1KoaWxw H5ml5g/laomjkN8NeSDzFEK5SGwrjKlNg4cdO1eus+wu2LZzGaYuXkx6MJslnVEv 5dz8g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdelleeigecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefoggffhffvkfgjfhfutgfgsehtqhertdertdejnecuhfhrohhmpehvihhmrghnuhgv lhhtuceovhhimhgrnhhuvghlthesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvg hrnheptedtgeffkeefvdeikeeutedvffdvtdefkeehueegjefhteelvdfhgfdukeekfeek necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhimh grnhhuvghlthesfhgrshhtmhgrihhlrdhfmhdpnhgspghrtghpthhtohephedpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvg gvsghsugdrohhrghdprhgtphhtthhopehfrhgvvggsshguqdhpkhhgsehfrhgvvggsshgu rdhorhhgpdhrtghpthhtohepfhhrvggvsghsugdqphhkghgsrghsvgesfhhrvggvsghsug drohhrghdprhgtphhtthhopehfrhgvvggsshguqdhsthgrsghlvgesfhhrvggvsghsugdr ohhrghdprhgtphhtthhopehmrghrqhhuihhssehrohgslhgvrdgtohhm X-ME-Proxy: Feedback-ID: if8e14258:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 7C0A918C0067; Wed, 30 Jul 2025 22:43:20 -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 11:41:00 +0900 From: vimanuelt To: "Roger Marquis" , "freebsd-pkgbase@freebsd.org" , "freebsd-stable@freebsd.org" , "freebsd-pkg@freebsd.org" , "freebsd-current@freebsd.org" 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: 4bstgG0L3Tz474d 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:202.12.124.0/24, country:AU] Yes, I see your point. While both involve system administration, managin= g a server is fundamentally different from managing a laptop. The requir= ements, usage patterns, and priorities vary considerably. Since my persp= ective is shaped by laptop use, I will respectfully step back from the c= onversation. I'll leave you with an aside. Note: This is a tangential aside and not essential to the main argument.= Feel free to skip it.=20 Changing the service model would necessarily require adjustments elsewhe= re in the system. One area that would demand particular attention is the= init framework. This, it must be made clear. What was not stated explic= itly is that revamping bsdrc would almost certainly be necessary in orde= r to support and reinforce the proposed layered service model. At presen= t, the FreeBSD init system depends on a loosely ordered sequence of shel= l scripts. It provides limited support for formal dependency tracking. T= here are no enforced boundaries separating system-level, administrator-m= anaged, and user-defined services. To support a layered startup structur= e with well-defined privilege separation and reliable ordering, the init= system itself would need to be restructured. A strict hierarchy, it wou= ld be required. Vendors too might welcome such a model, since it offers = cleaner integration points and more predictable behaviour during system = bring-up. In the revised model, each service is assigned to a specific layer accor= ding to its role and scope. The base layer includes services delivered w= ith the FreeBSD base system and resides in /etc/rc.d. These services are= maintained by the operating system and form the foundation on which eve= rything else depends. The local layer includes services installed by the= system administrator or vendor, usually from the ports collection or pa= ckage repository, and are located in /usr/local/etc/rc.d. The user layer= consists of session-specific services, owned and configured by the indi= vidual user, and stored in writable locations such as ~/.config/rc.d or = ~/.rc.d. The init system, under this model, brings up each layer in sequence. The= base services are initialised first, then local services, and finally u= ser services. This order, it enforces trust boundaries. It ensures that = core functionality is established before anything optional or user-scope= d is allowed to execute. It makes the startup process not only more pred= ictable, but also more defensible. To support this structure, each service would include a corresponding me= tadata file. This file, conventionally named service.rcmeta, is not a re= placement for the shell script itself but a declarative descriptor of th= e service=E2=80=99s role, requirements, and constraints. It specifies th= e layer the service belongs to. It defines which user or group the servi= ce should run under. It indicates whether the service is one-shot or sup= ervised, and under what conditions it should be started, such as on boot= , on login, or in response to a network event. It includes startup and s= hutdown timeouts. It may require the service to run inside a jail, a chr= oot environment, or a sandbox. It declares whether the service is restar= table or idempotent. It defines where logs should be written. It can als= o specify environment variables or dependency values to be injected at r= untime. The purpose of this metadata is to allow the system to construct and val= idate a complete service graph before execution begins. It gives adminis= trators the ability to verify dependencies and detect misconfigurations = early. For package maintainers, it offers a portable and self-documentin= g way to describe service behaviour. For users, it provides safety and c= ontrol without compromising the rest of the system. This structure also introduces meaningful improvements to system securit= y. By clearly separating layers and responsibilities, the system can def= ine and enforce trust boundaries. User services are unable to interfere = with administrator-managed services. Local services cannot override or d= isrupt base system components. Each layer is constrained to its scope, w= hich makes the system more resilient against misconfiguration and harder= to compromise through privilege escalation. Metadata enforcement further strengthens this boundary. If a user-level = service attempts to launch before its dependencies are met=E2=80=94for e= xample, before the network stack is ready=E2=80=94it is deferred. If a l= ocal service depends on a daemon in the base layer, that dependency must= be explicitly declared. Cyclical dependencies are detected and rejected= at compile time. The service tree, it becomes deterministic. For desktop users, this structure enables a long-requested feature: reli= able and supervised per-user services. Background processes such as encr= yption agents, file sync daemons, and session services can be declared a= nd managed by the user without any need for elevated privileges. If a se= rvice crashes, it can be restarted. If it misbehaves, it can be isolated= , killed, and logged. The configuration lives entirely in the user=E2=80= =99s home directory. There is no need to modify global paths like /usr/l= ocal/etc to install or manage something that only one user needs. Support for graphical environments becomes smoother and more robust. Way= land compositors, notification daemons, user message buses, and related = components can be started automatically, in correct order, with clean bo= undaries. It reduces friction during login, and it opens the door to mor= e complete desktop session management. Administrators benefit as well. Services are consistent in structure and= purpose. Startup semantics become understandable and predictable. Logs = can be tied directly to service state. For vendors, the environment beco= mes safer to extend and easier to debug. For users, the system becomes m= ore usable, more resilient, and more responsive to their needs. In this model, FreeBSD remains true to itself. It does not sacrifice its= clarity or simplicity. Instead, it evolves with intention, refining the= architecture where necessary while preserving the principles that defin= e it. The system becomes structured rather than ad hoc, layered rather t= han flat, and secure without becoming restrictive. This direction builds= on what FreeBSD has always done well, though it may reflect the priorit= ies of someone approaching it from a laptop user's point of view. - Vic On Thu, Jul 31, 2025, at 10:24, Roger Marquis wrote: > On Thu, 31 Jul 2025, vimanuelt wrote: >> ... the current architectural assumptions underpinning FreeBSD?s pack= age >> management model. The practice of overloading a single tool, namely p= kg, to >> manage both the base system and third-party software introduces seman= tic >> ambiguity, violates long-standing UNIX separation-of-concerns princip= les, > > A single pkg command for both base and third-party packages would not = be > a problem so much as a feature for 3 reasons: 1) it has a long track > record of working in Linux, 2) it facilitates 'distroless' and 'minima= l' > base and jails which, like Linux containers, are much desired as they > reduce the attack surface and minimize pkg update overhead, and 3) yet > another package command would be confusing and create unnecessary > maintenance overhead. > > For those worried about recursive deletes, removing essential base > packages with a '-F' flag (force base too) and/or '-RR' (recurse base > too) could potentially limit unintentional dangerous actions. Either > way it would IMO be simpler and more intuitive if all pkg flags were > base-aware rather than requiring a different command with a slightly > different set of flags. > > Bottom line: FreeBSD's current inability to create a minimal base, much > less minimal jails, is a HUGE USABILITY GAP that makes the OS > problematic to spec in appliances and IoT much less jails. Facilitati= ng > security updates and enabling minimal distributions are critical to > FreeBSD staying viable as an OS. I say this as a security analyst who > spends a large portion of every working day trying to help engineering > and operations patch tens of thousands of unnecessarily > vulnerability-ridden systems. > > Roger Marquis