From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B59E11581EE for ; Sun, 30 Mar 2025 14:38:39 +0000 (UTC) Received: from lists.gentoo.org (bobolink.gentoo.org [140.211.166.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id 9779D343250 for ; Sun, 30 Mar 2025 14:38:39 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id EC6D01104B9; Sun, 30 Mar 2025 14:37:55 +0000 (UTC) Received: from flump.de (flump.de [185.163.118.210]) (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) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id 0F7FB1104B0 for ; Sun, 30 Mar 2025 14:37:54 +0000 (UTC) Received: from falbala.localnet (ip4d172419.dynamic.kabel-deutschland.de [77.23.36.25]) by flump.de (Postfix) with ESMTPSA id 54D6B2242528 for ; Sun, 30 Mar 2025 16:37:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=flump.de; s=mail; t=1743345469; bh=Py340Gczjg/BB0l8ZmGCRxgfxntxLAsldYV21gRQjqw=; h=From:To:Subject:Date:In-Reply-To:References; b=y2R1CdMBv0ERVuw1/y51ntFOhr5ciz0Kv8nij19OgZLozktmDodHFCOC7UO2heDlO GrxRIJ0y00cfbpc51hWRt+9NDtwmUWIWw4eYMGMk4Lb85WJwY1jw0rFJv1YS42nmlb dOqvYOy0ZWFRcxM5zcC9nseN94n5zDGH8MOUHPTg= From: Gerion Entrup To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: The meaning of attributes in repositories.xml? Date: Sun, 30 Mar 2025 16:37:45 +0200 Message-ID: <5357043.31r3eYUQgx@falbala> In-Reply-To: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4998341.LvFx2qVVIh"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Archives-Salt: 5d043c6e-f0e1-49d5-aa51-8d15ab7d880c X-Archives-Hash: ba5d578724fe7892c3f45d9afd1c57fb --nextPart4998341.LvFx2qVVIh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Gerion Entrup To: gentoo-dev@lists.gentoo.org Date: Sun, 30 Mar 2025 16:37:45 +0200 Message-ID: <5357043.31r3eYUQgx@falbala> In-Reply-To: MIME-Version: 1.0 Am Freitag, 28. M=C3=A4rz 2025, 09:23:42 Mitteleurop=C3=A4ische Sommerzeit = schrieb Duncan: > Micha=C5=82 G=C3=B3rny posted on Fri, 28 Mar 2025 05:27:40 +0100 as excer= pted: >=20 > > Hello, > >=20 > > I've looked at our repositories.xml and the quality/status attributes > > don't seem to be used very meaningfully. > >=20 > > That is, by quality: > >=20 > > core: gentoo [official] > > stable: opentransactions (?) [official (?!)] > > testing: hyprland-overlay, moexiami [both unofficial] > > experimental: everything else graveyard: unused > >=20 > > By status: > >=20 > > official: ago, alexxy, anarchy, andrey_utkin, cj-overlay, dilfridge, > > emacs, EmilienMottet, fordfrog, gentoo, gnome, gnustep, graaff, guru, > > haskell, java, jmbsvicetto, kde, libressl, maekke, masterlay, mschiff, > > multilib-portage, musl, mysql, opentransactions, pentoo, pinkbyte, > > qemu-init, qt, R_Overlay, rich0, riscv, rnp, ruby, science, sping, > > swegener, tex-overlay, toolchain, ukui, ulm, vGist, voyageur, x11 > >=20 > > unofficial: everything else > >=20 > >=20 > > Which brings the significant question: are these attributes in any way > > meaningful? Is there a point in keeping them at all? Should we set > > some ground rules and make them used consistently? > >=20 > > Of them all, only "core" makes sense right now. "stable" and "testing" > > are used only by random user overlays, with no apparent features. > > Similarly, "official" is used by a mix of developer and ex-developer > > repositories, developer and user project repositories, and a bunch of > > user repositories with no clearly distinct features. >=20 > So what you didn't mention but I assume knew, thus making your question=20 > more one of: "This seems to have changed, do we get stricter again or los= e=20 > the attributes which don't seem to mean anything any more"... >=20 > My (user) understanding from "back in the day" when overlays were fairly= =20 > new and I first merged and configured layman (reading its config docs=20 > where IIRC this came from to do so), keeping in mind that back then=20 > overlays were a new concept and a major point from the detractors was fea= r=20 > that actually providing official overlays management and documentation=20 > would somehow implicate Gentoo if a user took advantage to distribute=20 > overt malware: >=20 > Status: >=20 > * "Official" status meant managed by an official Gentoo project or=20 > developer (who had gone thru the usual vetting process), thereby implying= =20 > the same security-trust level as the main Gentoo tree. That is,=20 > regardless of quality (experimental, testing, etc), the contents should b= e=20 > relatively trustworthy at minimum not to include deliberate ebuild/eclass= =20 > level malware. >=20 > The implication of "official" was that any deliberate or "they went=20 > through the vetting process and should have known better" security=20 > violation (as opposed to quality/QA violation) in any "official" overlay= =20 > would be treated as if it had occurred in the main overlay, and would not= =20 > only trigger ejection of the dev in question but a reexamination of what= =20 > could be done to improve vetting to avoid it happening again in the=20 > future, as well as possible prosecution as appropriate. >=20 > * "Unofficial" status had rather less security-trust and was intended for= =20 > "ordinary users". Unvetted, "caveat emptor", "here be dragons" and "if i= t=20 > breaks you get to keep the pieces". Security violations would of course= =20 > result in removal of the overlay from the list... after the fact. >=20 > The implication was "If it's from an unofficial overlay, be sure you=20 > either trust the author with effective root on your system or explicitly= =20 > examine the code before running it, because effective root on your system= =20 > is what you're giving them." >=20 > ... >=20 > I thus find it ... "unsettling"... to read that various user overlays hav= e=20 > apparently been marked "official" with no regard to that original policy.= =20 > While the original distinction may have arguably had alarmist motivations= ,=20 > I definitely still find it useful, within a somewhat more limited context= ,=20 > and consider "official" status among other factors when I consider adding= =20 > an overlay. >=20 > Guru specifically, given its purpose and that I personally have it active= =20 > (but ATM unused), I wonder about having official status. I only "sort of= "=20 > use one ebuild from there, net-nntp/pan -- "sort of" because I used it as= =20 > a basis for my personal overlay's pan-9999 live-git ebuild, when upstream= =20 > switched autotools -> cmake. (FWIW I've been "going to" contact and=20 > coordinate with the primary author and perhaps add the -9999 version to=20 > guru as well once we do, but that's yet to happen...) Obviously I did th= e=20 > appropriate "unofficial status level" security evaluation in the process= =20 > of converting it to live-git -9999. >=20 > Quality: >=20 > I /think/ the quality attribute /may/ have been introduced later as IDR=20 > reading about it in the original layman docs, as I think back then the=20 > /assumption/ was that "if it's only in an overlay, it's not up to main- > tree quality", thus "experimental" and possibly incomplete/under- > development, below ~arch-level quality. Either that or perhaps IDR it=20 > simply because it didn't strike me as important enough to "underline in m= y=20 > memory" like the status did (with the experimental assumption then being= =20 > on my part as seeming obvious). >=20 > Graveyard would have been the sunset overlay, which I guess has fallen by= =20 > the wayside? (Of course I'm personally much more toward the live-git sid= e=20 > than sunset/graveyard, so I'd have never noticed sunset's disappearance.) >=20 >=20 > FWIW kde's the only overlay I'm currently actively using (for -9999s, set= s=20 > and package.accept_keywords), and it's (correctly) official status,=20 > experimental quality. (Tho I only just removed qt days ago, after readin= g=20 > that qt*-9999s are officially in-tree now -- kde of course having require= d=20 > it at times for the -9999s in the :5 era due to upstream kde's sometime = =20 > dependency on unreleased qt.) I directly use(d) it for my package mask: gentoo and official overlays are unmasked (default behavior) Every other overlay gets an entry in my package.mask: `*/*::obscure-overlay` I unmask packages from non official overlays only giving their specific ver= sion and try to look at the ebuild code before merging them. AFAIK, portage has no other functionality to prevent updates from overlays = (e.g. a `sys-libs/glibc` package marked stable in a newer version than in t= he gentoo tree would be merged by portage without a further hint). OpenSUSE= /zypper for example remembers the source/"overlay" of the currently install= ed package and perform an update only when its provided by the same source/= "overlay". Best Gerion --nextPart4998341.LvFx2qVVIh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEM/tVN9WpYYHnPZHxloeAdSYJHeoFAmfpVzkACgkQloeAdSYJ HeoaWQv/ckZTpZXUwI6FUDhyDIN2f5FeC4DghtXOtrXqgVIa6UvWAS9itvahlZNS SZs59QGHPpRwY+7MhR+DXlMr0Ml6FyrS9b6Ir2iWk8Mp6pPqAF7NTAUF9eCU+JsP mHXgNKzekIu30Z3XiPqMcXdhQlXIgXOGawlbGjiGXYLjayfuM/jr0WTSXwCcAF36 FLICFyGzX01KcX5vn7WYy/uZkcdzk0eENdLQ7tBbo/BsRidjDKWT4w3TnWwMVxhF 1F027tmqSbIzjBWqVp1hmkiynLXYAsApZrM7VhifEc9+t9FXv7LhWPgEy0ycDhjJ jpNpGUr+kfWzvStLETSDqUj0CVqnXXDDoYBqXgRU+GSBiPdracHVzEKME5CKOVlR /KZFcCg7SUFQCvtXawEp3OoD2MiQHPlHsexU08sc+3+mB3+kKu9Dbahh8c/Dm1wb 3EPVpLJvswFIgGgxJLdi1LWJ8WMBTWz38S+RjK5FA8Ff2UiTH9DE83+T5gTGzWd+ tw0SHB0Y =wLoE -----END PGP SIGNATURE----- --nextPart4998341.LvFx2qVVIh--