Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs
On Sat, Feb 10, 2024 at 05:57:08PM +0100, Daniel Simionato wrote: > Hello, > I'd like to start a discussion regarding setting HOME_MODE by default in > the /etc/login.defs file (owned by sys-apps/shadow package). > > Upstream keeps HOME_MODE commented: > https://github.com/shadow-maint/shadow/blob/3e59e9613ec40c51c19c7bb5c28468e33a4529d5/etc/login.defs#L207 > > HOME_MODE affects only useradd and newuser commands: if HOME_MODE is set, > they will use the specified permission when creating a user home directory, > otherwise the default UMASK will be used. > Since the default umask is 022, keeping HOME_MODE unset will result in home > readable home directories created by useradd, which goes against security > best practices. > > The proposal is to set HOME_MODE to 0700, or at least 0750: RedHat and RH > based distros, OpenSuse, ArchLinux all set it to 0700, Ubuntu has it at > 0750. Debian and Gentoo are two exceptions, keeping the upstream value of > HOME_MODE (although login.defs is changed in other ways). > > I previously made a PR on github where you can find more details ( > https://github.com/gentoo/gentoo/pull/35231), but as pointed in the > comments this probably warrants some discussion beforehand. > > I can understand the argument against the change, which is keeping in sync > with upstream and don't risk changing the historic default behaviour of > tools some users might rely upon. > > I do believe though there's merit in providing safer and secure defaults, > so I would like HOME_MODE to have a safe default value for Gentoo and > Gentoo based distros. Setting it to 0700 makes good sense to me, unless someone has some good example of this breaking anything. Deviating from upstream defaults in following other distributions isn't exactly treading new ground for us. And it's easy for the administrator to change to suit their liking anyway (hopefully covering the "keep the status quo" class of objections). > Have a nice day, > Daniel signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-dns/totd
# John Helmert III (2024-01-06) # Unmaintained in Gentoo, outdated, and vulnerable # Removal on 2024-02-06. Bugs #856466, #865253 net-dns/totd signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-nds/tac_plus
# John Helmert III (2024-01-06) # Unmaintained in Gentoo, outdated, vulnerable # Removal on 2024-02-06. Bug #918536 net-nds/tac_plus signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-text/gocr, media-video/subtitleripper
Sorry, the subject should've included gocr. On Sat, Nov 25, 2023 at 07:12:40AM -0800, John Helmert III wrote: > # John Helmert III (2023-11-24) > # Multiple vulnerabilities, unmaintained upstream and in Gentoo. > # subtitleripper included as sole reverse dependency, similarly > # unmaintained, and with no other reverse dependencies. > # Removal on 2023-12-24, bug #824290. > app-text/gocr > media-video/subtitleripper signature.asc Description: PGP signature
[gentoo-dev] Last rites: media-video/subtitleripper
# John Helmert III (2023-11-24) # Multiple vulnerabilities, unmaintained upstream and in Gentoo. # subtitleripper included as sole reverse dependency, similarly # unmaintained, and with no other reverse dependencies. # Removal on 2023-12-24, bug #824290. app-text/gocr media-video/subtitleripper signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-fs/minio
# John Helmert III (2023-03-22) # Multiple vulnerabilities, unmaintained and broken in Gentoo, removal # on 2023-04-22. Bug #782037, #850547. net-fs/minio signature.asc Description: PGP signature
Re: [gentoo-dev] Java issue with a proprietary game
On Mon, Jan 30, 2023 at 08:43:55AM +0100, Hoël Bézier wrote: > Hi, > > Recently I’ve run into an issue with a proprietary java game called The Count > Lucanor. It is distributed on GOG.com with a bundled Java 8 binary. Since > bundled libraries are evil™, I’ve tried getting rid of it in favor of my > system > java binary. > > If the latter is Java 8, everything works as expected. However, using Java 17 > the game crashes on start with the following error: > > Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion > `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' > failed! > > This happened with dev-java/openjdk:17 but to my surprise didn’t with > dev-java/openjdk-bin:17. I figured Eclipse Temurin had to build OpenJDK with > different flags than I did, which fixed the issue. > > After running a bunch of tests, I managed to build a working java binary by > removing -Wl,--as-needed from my LDFLAGS (or adding -Wl,--no-as-needed). This > flag is set by my profile — default/linux/amd64/17.1 — so I expect mostly > everyone to have it. > > Should I propose a patch to dev-java/openjdk:17 in order to filter out > -Wl,--as-needed? I have no idea what this flag is for nor if removing it > might > result in other issues, which is why I’m asking on this mailing-list before > doing so. Moreover, that would be in order to fix an issue with a proprietary > game, and I don’t know what is Gentoo policy regarding that kind of bug. > > If I am to propose a patch, should I do so using filter-flag from > flag-o-matic.eclass, or no-as-needed which is provided by the same eclass and > is a no-op on clang? (My C compiler is gcc and I haven’t tested building > OpenJDK17 with clang.) > > If I should propose a patch, should I first open a bug in gentoo bugtracker > so > that it may be referenced in the ebuild? > > Thanks > Hoël > > PS: Using dev-java/openjdk:11 to run the game also fails, but with a > different > error which I did not try to fix. So this discussion is only about > dev-java/openjdk:17. Seems reasonable to open a bug, at least for posterity. signature.asc Description: PGP signature
Re: [gentoo-dev] dev-python/ package naming policy?
On Sun, Jan 29, 2023 at 02:15:19AM +0300, Torokhov Sergey wrote:
> The similar names in PyPi is a real problem for users when trying to
> find associated packages. It's also could be a security issue for them with
> malicious packages named like popular packages. />So in ::guru I try to save package naming even if it's too
> CamelCase.As for replacing dot (".") with hyphen
> ("-") I have PyPi package "FoBiS.py" that is packaged in ::guru just as
> "FoBiS" as I wasn't sure is it worth to store ".py" suffix while github repo
> of this project is just "FoBiS". So there could be a problem if package named
> "fobis" will appear in PyPi.28.01.2023, 19:38,
> "Michał Górny" mgo...@gentoo.org:Hi,
> everyone.TL;DR: I'd like to propose naming dev-python/* packages
> following PyPInames whenever possible, case-preserving, with
> modifications only whennecessary to match PN rules.So
> far the naming in dev-python/* hasn't been exactly consistent. Myself
> I've been mostly following "whatever's the easiest" policy which />generally meant following GitHub project names whenever we fetched from />there.This mostly made sense so far, as I've been thinking of
> dev-python/primarily in terms of dependencies of other packages.
> However, it'sbeen pointed out that this makes it hard for people to
> find packagesthey're looking for.The vast majority of
> packages in dev-python/ are also published on PyPI[1]. They can
> afterwards be installed using tools such as pip, orspecified as
> dependencies of other projects — using their PyPI namesin every
> case.On top of that, it is not unknown for multiple packages with
> verysimilar names to coexis, say "foo", "pyfoo" and "python-foo". When
> GHproject names come into the picture, this can get even more
> ambiguous. Don't even get me started about developers pushing duplicate
> packagesbecause they didn't find the existing instance. />To improve consistency and make packages easier to find, I'd like to />propose going forward that when packages are published on PyPI, we use />their official PyPI names. This also means preserving the case for />the few packages that use CamelCase names and similar.Some
> modifications will be necessary. For example, it is legal for PyPI />package names to include dot (".") — we normally translate that to a />hyphen ("-"). We may also have use cases for creating multiple Gentoo />packages from the same PyPI package (see e.g. dev-python/ensurepip-*). />Then, there are of course Python packages that aren't published on PyPI. />Still, I think as a general rule of thumb this would make sense.
> WDYT?[1] https://pypi.org/;
> target="_blank">https://pypi.org/ class="f55bbb4eeef208e8wmi-sign">-- Best regards,Michał Górny />
Can you send plaintext mail to gentoo-dev? HTML makes it very hard to read your
mails in certain clients.
signature.asc
Description: PGP signature
Re: [gentoo-dev] dev-python/ package naming policy?
On Sat, Jan 28, 2023 at 10:23:45PM +0100, Ulrich Mueller wrote: > > On Sat, 28 Jan 2023, Andrew Ammerlaan wrote: > > > Each of these is a different package. The package you usually want is > > GitPython, but if we would name it gitpython or git-python, things > > would get very confusing very quickly. In fact, this package was > > renamed precisely to avoid this confusion in [1]. This is not the only > > case where there are very similarly named packages on pypi. By having > > a 1 to 1 mapping between names in pypi and names in ::gentoo we avoid > > this confusion. > > Looking at mgorny's list, you cannot have an 1 to 1 mapping anyway, > because that would result in invalid PN names. Should imperfection get in the way of bettering the mapping? signature.asc Description: PGP signature
Re: [gentoo-dev] dev-python/ package naming policy?
On Sat, Jan 28, 2023 at 10:15:02PM +0500, Anna (cybertailor) Vyalkova wrote:
> I'd prefer if PyPI names are guidelines, not a strict policy. I don't
> like CamelCase and separators other than dash ("-") :P
>
> Also I don't like when packages are named "dev-python/python-foo"
> instead of just "dev-python/foo".
So, two simply aesthetic opinions. I'm not sure it's appropriate to
suggest one's aesthetic preference as default when there's no further
benefit.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites:
On Mon, Jan 23, 2023 at 05:35:50PM +, Marco Scardovi wrote: > id="protonmail_mobile_signature_block">Sent from Proton Mail for > iOS Il lun, gen 23, 2023 alle > 18:22, Tomas Mozes mailto:hydrapo...@gmail.com; > class="">hydrapo...@gmail.com ha scritto: class="protonmail_quote" type="cite"> On Monday, January 23, 2023, > David Seifert mailto:s...@gentoo.org;>s...@gentoo.org > wrote: # David Seifert href="mailto:s...@gentoo.org;>s...@gentoo.org (2023-01-23) # > EOL branch, switch to mariadb-10.4/galera-26.4, removal on > 2023-02-22. dev-db/mariadb-10.4 > sys-cluster/galera-26.4Mariadb 10.3 will be > supported until May 2023, any reason to drop it now?Because it > requires galera-25, which is masked too Please send plaintext mail. signature.asc Description: PGP signature
Re: [gentoo-dev] Packages of zlogene up for grabs
On Fri, Jan 13, 2023 at 02:35:45PM +0100, Michał Górny wrote: > Friends, > > Our dear friend zlogene has been inactive recently, and for this reason > the packages listed below are looking for new maintainers. Please take > a look and see if you're interested in a few of them. > > app-admin/git-credential-gopass > app-admin/gopass > app-admin/gopass-hibp > app-admin/gopass-jsonapi > app-admin/gopass-summon-provider I've just bumped and simplified these a bit, but only took maintainership of gopass itself. May add myself to others later, but don't really have any use for them. More hands welcome. signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-util/artifactory-bin
# John Helmert III (2023-01-08) # Multiple vulnerabilities include remote code execution, maintainer # needed, removal in 30 days. Bug #834501 dev-util/artifactory-bin signature.asc Description: PGP signature
[gentoo-dev] Packages up for grabs: patool, mkstage4, dev-python/{prov,pydotplus,ratelimit}
The following packages are up for grabs due to the retirement of their proxied maintainer: app-arch/patool app-backup/mkstage4 dev-python/prov dev-python/pydotplus dev-python/ratelimit signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-portage/flaggie
On Sun, Dec 25, 2022 at 06:02:11PM +, m1027 wrote: > mgorny: > > > # Michał Górny (2022-12-25) > > # make.conf writing is broken and package.use support incomplete. > > # Last release in 2013. Attempted unsuccessfully fixing it in 2017. > > # Use an editor instead. > > # Removal on 2023-01-24. Bug #888423. > > app-portage/flaggie > > So I will deeply miss flaggie! Despite some issues it is a very > helpful thing once you know it, e.g. for automated USE flag changes > over ssh in a server farm. If you're doing configuration management over ssh, you might want a proper configuration management solution anyway, like ansible or puppet. > I am rather in C than in python so I cannot really help advancing > flaggie. But I wonder whether there is a full specification for USE > in make.conf as well as for package.use/* so there was a chance to > think about a reimplementation somehow. > > signature.asc Description: PGP signature
Re: [gentoo-dev-announce] Re: [gentoo-dev] Last rites: dev-python/* using nose, with no revdeps
On Fri, Dec 23, 2022 at 11:11:46PM +0300, Alexey 'Alexxy' Shvetsov wrote: > Hi! Please make discussion on gentoo-dev rather than gentoo-dev-announce. > Whats the reason to lastrite packages that use nose as dep for tests? > e.g dev-python/pika (which is a usefull py lib)? nose has been deprecated for several months: ~/gentoo/gentoo/dev-python/pika $ pkgcheck scan dev-python/pika UnstableOnly: for arches: [ amd64, arm64, x86 ], all versions are unstable: [ 1.3.0 ] DeprecatedDep: version 1.3.0: BDEPEND: deprecated dependency: dev-python/nose[python_targets_python3_10(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?] PythonCompatUpdate: version 1.3.0: PYTHON_COMPAT update available: python3_11 And in package.deprecated: # Michał Górny (2022-10-17) # Nosetests are no longer maintained (since 2015!), are completely # broken with Python 3.11, and we were already patching it to make it # work with prior Python versions. If your package still needs it # (sic!), then either port it to use a maintained test framework (pytest # preferably) or last rite it. # # Case is also unmaintained (since 2018). Nose-random has had last # commit in 2016 and was not even released to pypi! dev-python/nose dev-python/nose-random > В письме от пятница, 23 декабря 2022 г. 17:35:59 MSK пользователь Michał > Górny > написал: > > # Michał Górny (2022-12-23) > > # Packages that still use dev-python/nose and have no revdeps. > > # > > # dev-python/blessings: EAPI 7, last rel. in 2018, git act. in 2020 > > # dev-python/errorhandler: EAPI 7, last rel. in 2016, git act. in 2018 > > # dev-python/flask-restful: EAPI 7, last rel. in 2021, git act. in Mar > > # dev-python/imread: non-PEP517, last rel. in 2020, uses pytest in git > > # dev-python/influxdb: EAPI 7, last rel. 2020, archived on GitHub > > # dev-python/nose-random: nose plugin > > # dev-python/pika: active, uses nose + nose2 (sic!) > > # dev-python/pilkit: EAPI 7, last rel. in 2017, uses pytest in git > > # dev-python/PyContracts: EAPI 7, last rel. in 2019, git act. in 2020 > > # dev-python/python-redmine: EAPI 7, last rel. in 2020, git may be good > > # dev-python/python-zipstream: EAPI 7, last rel. in 2016, git in 2018 > > # dev-python/PyUtilib: EAPI 7, last rel. and git act. in 2020 > > # dev-python/socketio-client: EAPI 7, last rel. in 2016, git in 2017 > > # dev-python/www-authenticate: EAPI 7, last rel. in 2015, git in 2019 > > # > > # Removal on 2023-01-22. Bug #888087. > > dev-python/blessings > > dev-python/errorhandler > > dev-python/flask-restful > > dev-python/imread > > dev-python/influxdb > > dev-python/nose-random > > dev-python/pika > > dev-python/pilkit > > dev-python/PyContracts > > dev-python/python-redmine > > dev-python/python-zipstream > > dev-python/PyUtilib > > dev-python/socketio-client > > dev-python/www-authenticate > > > -- > Best regards, > Alexey 'Alexxy' Shvetsov signature.asc Description: PGP signature
Re: [gentoo-dev] Current portage will now truncate your repo's git history to 1
On Sat, Dec 17, 2022 at 05:42:43AM +, Sam James wrote: > > > > On 15 Dec 2022, at 19:22, Florian Schmaus wrote: > > > > This is a public service announcement that the recently stabilized portage > > version will truncate you repo's git history to 1. > > I wish you'd shown us in #gentoo-portage before sending this, as it's a bit > misleading / alarmist. We were actively all speaking > at the time. > > Not only to reconsider the phrasing and include some important details, but > also to mention the rationale, which I describe > below. > > If you felt the Portage team should've written a news item for it, you were > (and still are) free to say so, and we'd > do it. > > > > > While this is a good thing for the majority of Gentoo users, it affects > > developers that develop in a git known to portage (like me). If I > > understand the portage maintainers vision correctly, then future portage > > will assume full control over its configured repositories and potentially > > perform destructive operations on them, for example "git clean" [1]. > > > ... only for repositories of sync-type=git & auto-sync=yes. > > The rationale for this is that most people who use sync-type=git are doing so > because they want > a quicker sync (to complete), a more reliable one (no Manifest race condition > issues), and to > get changes from Gentoo faster. > > Whenever Portage is syncing something, our view was that we should prioritise > successful > completion of syncs, especially given it may be performed unattended. > > If git is pulling from a CDN, Portage may on one sync receive state X, but > on a subsequent sync receive state X-1. This can cause an odd state > where git wants to resolve conflicts and manual intervention is required. > > This situation was often worse with sync-depth=1 and would lead > to orphaned files, hence the 'git clean' PR referenced. > > The motivation behind the sync depth part was because of > disk space growing unbounded otherwise. Just to make this more abundantly explicit: it repeatedly happened to me (but others, too) that on a system using git to sync a shallow ::gentoo clone, during unattended syncs, the repository attempted a merge with the upstream, yielding a repo in a merging state, with a huge list of dirtied files in the working tree, plus untracked files. > > I personally would prefer portage simply adjusting its behavior based on > > the owner of the repository. That is, if it's the 'portage' user then > > assume full control, and if it is a different user, then fall back to a > > preserving, conservative mode of operation. Unfortunately, for me, this > > idea was received skeptically at best in a recent discussion in > > #gentoo-portage. > > This wouldn't work for Prefix and also FEATURES="-usersync". > > -- > > Now, looking forward in a constructive manner, I think we can > make both camps happy here with an option to indicate > If Portage can assume the repository will be touched by something > other than Portage. > > I propose a configuration option called 'volatile' (thanks > Arsen for the name suggestion) which indicates that the > repository may be changed outside of Portage by any time, > and hence no destructive operations should be carried out. > > If the option is on, it also prohibits some optimisations > which require assuming the integrity of the repository. > > I have a draft of these changes at https://github.com/gentoo/portage/pull/961. > > (https://github.com/gentoo/portage/pull/961.patch if want to view as a raw > patch series.0 > > I am undecided on whether volatile should be default on or not. In the PR > as it is, it defaults to off, which would require a news item. I may just > turn it > on given the tone of this thread, as none of it has been very encouraging > for further work on Portage. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Current portage will now truncate your repo's git history to 1
On Fri, Dec 16, 2022 at 11:01:13PM -0500, Brian Evans wrote: > On 12/15/22 20:08, Duncan wrote: > > Florian Schmaus posted on Thu, 15 Dec 2022 21:40:19 +0100 as excerpted: > > > >> On 15/12/2022 21.10, Toralf Förster wrote: > >>> On 12/15/22 20:22, Florian Schmaus wrote: > o use PORTDIR_OVERLAY and multiple repositories on their system: a > system-wide, managed by portage, and a dev repository (in your HOME), > scoped in via PORTDIR_OVERLAY. > >>> > >>> Isn't this covered by /etc/portage/repos.conf/* > >> > >> Absolutely, but this requires a manual intervention from the user. And, > >> of course, you can totally opt-out from portage managing (syncing) the > >> repository, but then you have to take care of syncing yourself. > >> > >> The point is that with the new portage release, portage's behavior > >> changes. And I would argue that portage should not, in its effort to > >> become more user friendly, disregard ebuild-developer friendliness. > >> Assuming it is achievable with a reasonable amount of additional code > >> complexity. > > > > This bit me too, and making things worse, the truncate killed the git > > history that presumably had the answer I needed to fix it up. > > =:^( Fortunately I had a bit of a clue due to preemptively following the > > portage changelog where I had seen a hint, so I was able to dig it up > > again without the git log help that's definitely now my first instinct. > > > > Thankfully, if anyone does accidentally gets shallowed, just executing > 'git fetch --unshallow' will revert the default '--depth 1' > > I really don't care for that 'git clean' patch. If that makes it in > without a way to opt-out, it will be patched out for me personally. > > Brian By "that 'git clean'" patch, do you mean [1]? Why are you speaking as if you're talking about a 3rd party and not people that are also on the gentoo-dev mailing list? It seems like the more productive thing to do would be to at least offer substantive criticism about a specific PR, maybe even in the PR itself. While I'm at it: you used to be reachable on IRC, but you never migrated away from Freenode. Why? It seems like every few days someone is looking for you only to be surprised that you're not in Gentoo's IRC community anymore. [1] https://github.com/gentoo/portage/pull/939 signature.asc Description: PGP signature
Re: [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with
On Mon, Dec 12, 2022 at 11:26:32PM +0100, Piotr Karbowski wrote: > On 12/12/2022 23.06, Sam James wrote: > > It's unusual to have discussion about a single package on the mailing > > lists. I tend to keep an eye on PAM > > bugs because I maintained pambase. > > > > Bugs are the primary method of discussing changes to packages. > > You really came strong on this one. I did explain why it went to mailing > list, that very few people would notice bug on undeclared > maintainer-needed package, unlike mailing list, assigning it to zlogene > and hoping for few people to catch it up, yet you still zealously > challenge it. You did explain, somebody else still disagreed, I don't think that should be taken personally? > I feel really burnt out from this exchange and I see that you already > base-system'd the sys-libs/pam tactically preventing me joining and > introducing changes, last time I wanted join base-system there was push > back and I was informed that only invited members can join. Do your > thing Sam, I will step back now and will take note to throw ideas into > void of bugzilla next time. pam is a package which is pretty obviously in-scope for the Base System project, even from a third party perspective. Based on Sam's most recent reply, that doesn't like it was a mechanism to prevent you from contributing? And since you seem to have taken it that way, why? If that were the case, I'd think the Base lead (sam) would've told you, and he hasn't (quite the opposite!). > -- Piotr. > signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: www-servers/boa
On Fri, Dec 02, 2022 at 08:30:03PM +, Peter Stuge wrote: > John Helmert III wrote: > > > > There are multiple CVEs for it, is it really on us to discriminate > > > > between which CVEs are valid and which are not? > > > > > > Yes. > .. > > > > We can't possibly hope to do that accurately in all cases. > > > > > > Some times it will be easy, other times less easy. > .. > > > Maybe the accurate bigger picture is that no (current) Gentoo developer > > > knows enough about the package and thus can't be expected to action > > > such bogus CVEs correctly without a couple of minutes of investigation, > > > which would be too long, then I guess maintainer-needed is the most > > > honest? > > > > No, when a package is believed to be vulnerable, it is not responsible > > for us to just leave it as maintainer-needed, that's not an accurate > > reflection of the situation. > > Do you continue to believe that boa has vulnerabilites involving files > and functionality (as mentioned by the maintainer mgorny in #882773#c1) > which do not exist in the package? Just like it isn't your responsibility to "cleanup NVD", it's not my responsibility to authoritatively verify every CVE that Gentoo Security acts upon. Even if I did make such a judgement, I will *not* risk my being wrong and exposing Gentoo users to vulnerabilities unecessarily, even when prompted to by users on mailing lists. > I wanted my mail to change that belief. If I've failed so far can you > tell me how I can accomplish it, ie. what it would take for you to > please revert the lastrite commit? I (or smoeone else) will drop the last rites message when the package is removed. > > > If you think the CVEs are invalid, maybe talk to upstream? Or MITRE? > > The CVEs are obviously invalid and yes someone could contribute time > to clean up NVD but I honestly don't think that either upstream or > myself can reasonably be made responsible for invalid CVEs submitted > by third parties. Again, we're not making judgements about "obviously invalid". The time you've spent arguing with us on gentoo-dev could've been easily spent asking upstream about the issue. > > Or anybody that isn't only a CVE downstream? > > I expect every downstream of everything to apply themselves in order to > improve quality of what they consume, not reduce it. To be clear: It's > also not your job to improve NVD but at least don't lastrite in Gentoo > because of invalid CVEs. > > > > I also note that very few distributions package Boa: > > > > https://repology.org/project/boa/versions > > > > This is a good way to measure how many people care about the package > > (and thus, its security health). > > I disagree, that's only a good way to measure how many distributions care. Which is *precisely* the point I'm making. If distributions with many times the resources of Gentoo don't care to package it, that's a bad indicator of how well the package is taken care of. > Each distribution has its own dynamic (but actually distributions also > tend to herd behavior) and especially commercial distributions are more > often than not bound by law to be driven only by profit, with *everything* > else secondary. This includes software quality and/or "security health". > > > > If the commercial distributions don't carry a package, nobody cares for > > it, and thus security issues are unlikely to be tracked and handled well. > > This seems based on an assumption that only commercial software has > high value? I could not disagree more with that. Nope, not the point I was making. See above. > But if we play out the argument then CVEs for packages not in many > distributions would more likely be invalid than others. While true > in this case I don't find it convincing as a general conclusion. > > These things can all be true at once: > > 1. a package is secure > 2. the package is not popular > 3. a CVE for the package is invalid but not (yet) rejected > 4. another CVE for the package is valid (low severity; still secure) > > Only 1. says something about "security health" (whatever that means). > > I think it's both irresponsible and wrong to indiscriminately give > authority to CVEs. People are wrong on the internet all the time, > some even intentionally, it's not correct to blindly believe CVEs > any more than tweets. > > > > > The mere existance of CVEs can not be reason enough for any change, > > > that would mean resignation to fear instead of encouraging rational > > > behavior as required to actually improve technology. > > > > That'
Re: [gentoo-dev] Last rites: www-servers/boa
On Fri, Dec 02, 2022 at 06:29:28PM +, Peter Stuge wrote: > John Helmert III wrote: > > So much yapping on the mailing lists, and no response in the bug which > > triggered the last rites... > > Apologies if I responed in the wrong forum. I thought on list would > be good, why are those mails on the list if not? > > > > So, Peter, do you use Boa? > > Not right now, but I have before and I might again. > > > > If you do, what niche does it fill that isn't filled by anything else? > > That's a strange question. Why should I agree with or even > reconfigure because of something that is in fact an error? > > I ask you to revert the lastrite not because it would break a use > case of mine but because the CVEs do not apply to boa itself but to > some unknown appliance that uses boa to serve unknown buggy CGI scripts. > > > > There are multiple CVEs for it, is it really on us to discriminate > > between which CVEs are valid and which are not? > > Yes. > > You are obviously /not/ responsible for what bogus CVEs people may > report, but we're all responsible for the commits we create. > > I assume that everyone wants to improve the overall state with each > commit - that we want to make things more correct since that's what > enables reliability, hence yes: it really is on every one of us to > verify our inputs before taking action on them. > > > > We can't possibly hope to do that accurately in all cases. > > Some times it will be easy, other times less easy. > > In this case the CVEs could be dismissed by searching the source code > for the file names in the CVEs. Or by having experience with what the > package provides, in particular that it doesn't include any CGI scripts. > > Maybe the accurate bigger picture is that no (current) Gentoo developer > knows enough about the package and thus can't be expected to action > such bogus CVEs correctly without a couple of minutes of investigation, > which would be too long, then I guess maintainer-needed is the most honest? No, when a package is believed to be vulnerable, it is not responsible for us to just leave it as maintainer-needed, that's not an accurate reflection of the situation. If you think the CVEs are invalid, maybe talk to upstream? Or MITRE? Or anybody that isn't only a CVE downstream? I also note that very few distributions package Boa: https://repology.org/project/boa/versions This is a good way to measure how many people care about the package (and thus, its security health). If the commercial distributions don't carry a package, nobody cares for it, and thus security issues are unlikely to be tracked and handled well. > The mere existance of CVEs can not be reason enough for any change, > that would mean resignation to fear instead of encouraging rational > behavior as required to actually improve technology. It would also > create incentive for permanent denial-of-service attacks by way of > bogus CVEs manipulating people into incorrect lastrites and other > changes. I don't want that to become common. That's not a real concern. We're not going to last rite something like nginx simply because there's a CVE against it. In the case of Boa, which doesn't seem to have been touched in approaching 20 years, the impact of last rites is minimal. > My question about the lastriting process was not an attack but a > genuine inquiry. The answer I receive so far is something like > "it can't work better because we react indiscriminately to CVEs", > that's an honest answer (thank you!) but not great quality. Does > everyone mostly agree with that policy? It generally can't work better with MITRE being useless in many cases. Yes, the CVEs seem garbage, but I can't say that authoritatively, so I don't. > > Thanks > > //Peter > signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: www-servers/boa
So much yapping on the mailing lists, and no response in the bug which triggered the last rites... So, Peter, do you use Boa? If you do, what niche does it fill that isn't filled by anything else? There are multiple CVEs for it, is it really on us to discriminate between which CVEs are valid and which are not? We can't possibly hope to do that accurately in all cases. On Fri, Dec 02, 2022 at 05:20:40PM +, Peter Stuge wrote: > Michał Górny wrote: > > > Shouldn't this process work a lot better? > > > > Processes tend to work better when people are contributing towards > > making the processes work better rather than complaining from their > > comfy armchairs that they tend to confuse with thrones. > > LOL! > > Are you honestly arguing that the Gentoo lastriting process relies on > third party contributions to work or improve? That would amount to > declaring Gentoo (developers) incapable of self-improvement, something > that would be absolutely unacceptable to say about any one or any group > of people. > > If you feel that Gentoo is unsustainable like that then please think > about how you should react to it. > > > Instead of writing a passive aggressive response to my demonstration > of this process failure I wish that you would have drawn on your > knowledge of the process and the learnings in my mail to 1. educate > us on what gaps you see, if any, that caused this particular error, > and maybe even 2. suggest some improvements. > > Expecting and/or demanding that from me because I dared describe a > symptom and question the process is neither reasonable nor fair nor > useful. Shooting the messenger reveals that you can't deal with the > message, but that's a you problem, it's not okay to project that onto > the messenger or anyone else. > > > If you wanted to encourage me to become a Gentoo developer and (among > other things) improve the lastriting process then you missed the mark, > in fact your behavior consistently remains one strong reason for me > to *not* become a Gentoo developer. > > > Kind regards > > //Peter > signature.asc Description: PGP signature
[gentoo-dev] Last rites: sys-aps/ucspi-ssl
Resending to correct subject line. On Tue, Nov 29, 2022 at 08:56:34PM -0600, John Helmert III wrote: > # John Helmert III (2022-11-29) > # Unmaintained and outdated in Gentoo, compatibility issues with > # openssl-1.1. Removal in 30 days. Bug #696936. > sys-apps/ucspi-ssl signature.asc Description: PGP signature
[gentoo-dev] Last rites: # days. Bug #883637.
# John Helmert III (2022-11-29) # Unmaintained and outdated in Gentoo, compatibility issues with # openssl-1.1. Removal in 30 days. Bug #696936. sys-apps/ucspi-ssl signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-metrics/prometheus-bin
# John Helmert III (2022-11-29) # Authentication bypass vulnerability, unmaintained in Gentoo, source # package available. Use app-metrics/prometheus instead. Removal in 30 # days. Bug ##883637. app-metrics/prometheus-bin signature.asc Description: PGP signature
[gentoo-dev] Last rites: www-servers/boa
# John Helmert III (2022-11-27) # Unmaintained upstream, several unresolved public vulnerabilities, # Removal in 30 days. Bug #882773. www-servers/boa signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] add apache to metadata.dtd
Could you resend this in plaintext? On Thu, Nov 24, 2022 at 05:46:45PM +0100, vaukai wrote: > > > > > > > > > Michał Górny href="mailto:mgo...@gentoo.org;>mgo...@gentoo.org hat am 24.11.2022 > 15:03 CET geschrieben: > > > > > > > > > On Thu, 2022-11-24 at 13:29 +0100, Volkmar W. Pogatzki wrote: > > > > There are many packages hosted on package.apache.org like e.g. > > > > > > dev-java/log4j-core - href="https://logging.apache.org/log4j/2.x/; target="_blank" > rel="noopener">https://logging.apache.org/log4j/2.x/ > > > dev-java/pdfbox - https://pdfbox.apache.org/; > target="_blank" rel="noopener">https://pdfbox.apache.org/ > > > net-libs/serf - https://serf.apache.org/; target="_blank" > rel="noopener">https://serf.apache.org/ > > > > > > > This doesn't seem consistent. How is it supposed to work? > > > > > > Please don't forget to include a patch for the XML Schema and pkgcheck. > > > > > > > href="https://882351.bugs.gentoo.org/attachment.cgi?id=835371;>https://882351.bugs.gentoo.org/attachment.cgi?id=835371 > > > href="https://882351.bugs.gentoo.org/attachment.cgi?id=835437;>https://882351.bugs.gentoo.org/attachment.cgi?id=835437 > > > > > >Wiki says "DTD (needs gentoo-dev ML review, do this before any other step)" > > >-- > > >Best > > >Volkmar W. Pogatzki > > > > > > > signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-db/percona-xtrabackup-bin
# John Helmert III (2022-11-24) # Binary package several releases behind the source-based package, # multiple vulnerabilities, unmaintained for several years. Removal in # 30 days. Bugs #849389, #882783. dev-db/percona-xtrabackup-bin signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-misc/cfengine
# John Helmert III (2022-11-24) # Compatibility issues with openssl-1.1*, numerous build issues, version # in tree is EOL upstream. Removal in 30 days. Bug #882759. net-misc/cfengine signature.asc Description: PGP signature
[gentoo-dev] Gitolite ACL Pruning
I've pruned a bunch of users (non-devs) from Gitolite ACLs who haven't committed in many years (and more than a decade in many cases). Let me know if you've lost access to something you think you shouldn't have. signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: net-mail/vchkuser
On Mon, Nov 14, 2022 at 09:53:43PM +, Peter Stuge wrote: > John Helmert III wrote: > > > Jonas Stein wrote: > > > > # Dead upstream > > > > # Removal after 2023-01-01. Bug #881249. > > > > net-mail/vchkuser > > > > > > Was there an actual issue with the package that prompted you to do > > > this - something that a package maintainer should have resolved? > > > > > > I think it's a bad idea to remove a package if "Upstream Homepage and > > > SRC_URI is gone" and "Gentoo is the last distro with this package" > > > are the only reasons... > > > > Do you use it? Is it still functional? > > I don't use it, I use something else for the same task. > > Looking up the GitHub user that person seems present, just that > particular repo is no longer there. > > Searching for the repo name on GitHub finds this however: > > https://github.com/bdrewery/vchkuser > > ..which seems to be a 2010 version of the code. I did a test, it works > fine. Maybe just change the SRC_URI. Can you produce a guarantee that the code there is equal to the code which the ebuild currently refers to? Or maybe that it's equivalent to the now-removed repository? > > //Peter > signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: net-mail/vchkuser
On Mon, Nov 14, 2022 at 04:43:51PM +, Peter Stuge wrote: > Jonas Stein wrote: > > # Dead upstream > > # Removal after 2023-01-01. Bug #881249. > > net-mail/vchkuser > > Was there an actual issue with the package that prompted you to do > this - something that a package maintainer should have resolved? > > I think it's a bad idea to remove a package if "Upstream Homepage and > SRC_URI is gone" and "Gentoo is the last distro with this package" > are the only reasons... Do you use it? Is it still functional? > > Thanks > > //Peter > signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] A new GLSA schema
On Thu, Nov 10, 2022 at 09:49:27PM +0100, Jonas Stein wrote: > On 10/11/2022 03:27, John Helmert III wrote: > > The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of > > October 2003. It used roughly the same format of the GLSAs we release > > today, in 2022, making that format almost as old as me. > > IFF we change the format, we should not invent a new standard [1] but > use existing one like CSAF [2] > > [1] https://imgs.xkcd.com/comics/standards.png > [2] https://oasis-open.github.io/csaf-documentation/ We're not inventing a new "standard", we're upgrading the format we use to distribute GLSAs. Besides, what would this actually mean for us? Are you volunteering to help implement a transition? > -- > Best, > Jonas > > signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] A new GLSA schema
On Thu, Nov 10, 2022 at 10:55:03PM +0200, Mart Raudsepp wrote: > Ühel kenal päeval, N, 10.11.2022 kell 22:07, kirjutas Jaco Kroon: > > > Like glsa-check? > > We currently use that, but it really just says which GLSAs are > > applicable to the system, it doesn't tell me net-misc/asterisk- > > 16.0.1:16 > > - we've got ways of working from the glsa-check output to that. Of > > particular annoyance if a GLSA lists multiple packages, of which you > > have one installed, and one not. Given net-misc/asterisk-16.0.1:16 I > > can > > quite quickly determine that emerge -1av net-misc/asterisk:16 will > > resolve the problem with the lowest possible risk of breakage to > > other > > components on the system, and without having to perform a full > > update. > > emerge -vpO @security > > but to get something like it to only showing which installed asterisk > SLOT is vulnerable would be some extra coding with portage API I think. Yeah, to implement this, working on glsa-check is already necessary. I'm willing to look into ensuring the @security set works properly as well. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] A new GLSA schema
On Thu, Nov 10, 2022 at 10:43:55AM +0200, Jaco Kroon wrote: > Hi, > > On 2022/11/10 06:13, John Helmert III wrote: > >>> - Drop synopsis and description fields. These fields contain the same > >>> information and will be superceded by the existing impact field. > >> Well, I'm not saying "no" but it feels a bit weird reading a GLSA that > >> doesn't say a word what the problem is but specifies impact. > > You're right, but with 19 CVEs (for example), is anyone really > > interested in hearing about the problem that caused each of the 19 > > issues? In the current format we've resorted to writing descriptions > > like... > Actually yes! Also a way to check whether my specific configuration is > vulnerable for this specific CVE, something like "If you're setting > foo=bar in /etc/pkg.conf your system is vulnerable, if you've got > foo=phew you're most likely fine". Obviously we could rely a bit more > on package maintainers (myself included) to provide these. That would greatly increase the care necessary for us to release a GLSA. It's already a big pain (even with the new GLSAMaker being a huge improvement over the old one), and I'd like to make it less of a pain. Maybe a proxy for this information for you would be the "type" field of the impact? > I don't think I've seen a single "workaround" and usually the text here > just says "No known workaround", where the reality is that for something > like asterisk just not using the affected module is good enough. So > workaround: "Don't use chan_sip, use chan_pjsip instead" would be > perfectly fine here. > > One could thus also link GLSA issues to specific USE flags, taking > asterisk again, let's say the problem is with the http web server having > a buffer overflow in the http basic authenticator, then if that embedded > server isn't even compiled in, how can the package be vulnerable? So > here vulnerable would be something like > which then also indicates the "fixed" versions, as has been pointed out > "affected" and "not affected" are inverses. The "atom" attribute of each constraint is using atom syntax, so along with that we get the ability to specify USE exactly like "asterisk-16.X.Y:16[http]". > A mechanism to QUERY which installed packages are affected by known > GLSA's would also be tremendously helpful. Like glsa-check? > > > > Multiple vulnerabilities have been discovered in $PACKAGE. Please > > review the CVE identifiers referenced below for details. > > > > ... simply because it's infeasible (and in my opinion, not really > > necessary) for us to enumerate the issues in this way. Also, I note > > that the section being called "impact" doesn't preclude us from > > incorporating text that we would currently put in the "description" or > > "synopsis" fields. > > Of course giving the full details in the GLSA is a pain in the backside, > is there a way to retrieve this information automatically from the CVE > database? In other words, just get the blurp from there and include it > here. It won't give full details, but at least it will give some extra > details not currently available. Effectively we choose to ignore > certain GLSAs if we consider their impact to be low. We could import CVE descriptions, but then we'd end up with a huge wall of mostly useless text, such as CVE-2021-35648's: Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: FTS). Supported versions that are affected are 8.0.26 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). MySQL bugs usually have dozens of CVEs associated with them. Would it really be useful to have dozens of those paragraphs in GLSAs? Would it be useful to have that text included in a GLSA for MariaDB or PostgreSQL if they're affected by the same issue? On the other end of the spectrum (CVE-2022-41035): Microsoft Edge (Chromium-based) Spoofing Vulnerability. Does that tell anyone anything about the vulnerability? Not really, I think. It'd just be added noise in a GLSA. > It would also help a great deal to automate that if the CVE scores and > the "inputs" into that could be made available, eg, CVE score 7.0, > remote=yes/no, (And I'm fairly certain importing this from the CVE > database should be possible). It
Re: [gentoo-dev] [RFC] A new GLSA schema
On Thu, Nov 10, 2022 at 02:10:09PM +1000, Marc Schiffbauer wrote: > * Sam James schrieb am 10.11.22 um 13:58 Uhr: > > > > I think we'd rename impact -> description but description would now > > be "description of the problem" and not "description of the package". > > > +1, but additionally having the short description of the package sounds > still useful to me, as not always everybody knows what any package is > exactly for and the description will help a lot in telling the > impact/danger of your own infra that might be caused by that package. > > -Marc Are you saying you rely on the background field, which is generally just the package's DESCRIPTION? Maybe glsa-check should just spit out the package's DESCRIPTION then too. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] A new GLSA schema
On Thu, Nov 10, 2022 at 04:43:01AM +0100, Michał Górny wrote: > On Wed, 2022-11-09 at 20:27 -0600, John Helmert III wrote: > > The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of > > October 2003. It used roughly the same format of the GLSAs we release > > today, in 2022, making that format almost as old as me. > > > > Somewhere along the way, it started to become necessary to target > > multiple version ranges within the same package. The GLSA format > > isn't capable of expressing this. Thus, I propose a new format (an > > example of which I've attached inline below), with the following > > changes from the old format: > > > > - Rework affected to use XML-ified logical operators to specify the > > affected versions, and *don't* use different fields to specify > > vulnerable and unaffected versions. Instead, only list vulnerable > > versions, unaffected versions are implicit. > > Does that imply op="" will now be limited to the standard ebuild > operators? Perhaps it'd be cleaner to take a step further and remove > the attribute in favor of going 100% ebuild syntax (yeah, escaping is > gonna suck there). The added complexity of escaping is exactly what I wanted to avoid! These are already enumerated in the old glsa.dtd [1] for usage in a similar way: https://gitweb.gentoo.org/data/dtd.git/tree/glsa.dtd#n126 > > > > - Drop synopsis and description fields. These fields contain the same > > information and will be superceded by the existing impact field. > > Well, I'm not saying "no" but it feels a bit weird reading a GLSA that > doesn't say a word what the problem is but specifies impact. You're right, but with 19 CVEs (for example), is anyone really interested in hearing about the problem that caused each of the 19 issues? In the current format we've resorted to writing descriptions like... Multiple vulnerabilities have been discovered in $PACKAGE. Please review the CVE identifiers referenced below for details. ... simply because it's infeasible (and in my opinion, not really necessary) for us to enumerate the issues in this way. Also, I note that the section being called "impact" doesn't preclude us from incorporating text that we would currently put in the "description" or "synopsis" fields. > BTW have you considered switching to JSON or TOML? ;-) Definitely! But that adds significantly more complexity to implementing this, and given I'm likely to be the only one working on it, I decided against trying it. If I were inventing GLSAs for the first time I'd definitely avoid XML, of course. > > -- > Best regards, > Michał Górny > > signature.asc Description: PGP signature
[gentoo-dev] [RFC] A new GLSA schema
The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of October 2003. It used roughly the same format of the GLSAs we release today, in 2022, making that format almost as old as me. Somewhere along the way, it started to become necessary to target multiple version ranges within the same package. The GLSA format isn't capable of expressing this. Thus, I propose a new format (an example of which I've attached inline below), with the following changes from the old format: - Rework affected to use XML-ified logical operators to specify the affected versions, and *don't* use different fields to specify vulnerable and unaffected versions. Instead, only list vulnerable versions, unaffected versions are implicit. - Drop synopsis and description fields. These fields contain the same information and will be superceded by the existing impact field. - Drop background field. This is usually just the package's description, or some similar text. No reason to reproduce it in GLSAs. What does everyone think? https://www.gentoo.org/dtd/glsa-2.dtd;> Nvidia Drivers: Multiple Vulnerabilities 2022-13-00 2022-13-00 764512 784596 803389 832867 845063 866527 These vulnerabilities could allow a local user with low privileges to gain root privileges. There is no known workaround at this time. All Nvidia drivers 390 users should upgrade to the latest version: # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-390.154" All Nvidia drivers 470 users should upgrade to the latest version: # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-470.141.03" All Nvidia drivers 510 users should upgrade to the latest version: # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-510.85.02" All Nvidia drivers 515.65.01 users should upgrade to the latest version: # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-515.65.01" https://nvd.nist.gov/vuln/detail/CVE-2021-1052;>CVE-2021-1052 https://nvd.nist.gov/vuln/detail/CVE-2021-1053;>CVE-2021-1053 https://nvd.nist.gov/vuln/detail/CVE-2021-1056;>CVE-2021-1056 https://nvd.nist.gov/vuln/detail/CVE‑2021‑1076;>CVE‑2021‑1076 https://nvd.nist.gov/vuln/detail/CVE‑2021‑1077;>CVE‑2021‑1077 https://nvd.nist.gov/vuln/detail/CVE-2021-1090;>CVE-2021-1090 https://nvd.nist.gov/vuln/detail/CVE-2021-1093;>CVE-2021-1093 https://nvd.nist.gov/vuln/detail/CVE-2021-1094;>CVE-2021-1094 https://nvd.nist.gov/vuln/detail/CVE-2021-1095;>CVE-2021-1095 https://nvd.nist.gov/vuln/detail/CVE‑2022‑21813;>CVE‑2022‑21813 https://nvd.nist.gov/vuln/detail/CVE‑2022‑21814;>CVE‑2022‑21814 https://nvd.nist.gov/vuln/detail/CVE-2022-28181;>CVE-2022-28181 https://nvd.nist.gov/vuln/detail/CVE-2022-28183;>CVE-2022-28183 https://nvd.nist.gov/vuln/detail/CVE-2022-28184;>CVE-2022-28184 https://nvd.nist.gov/vuln/detail/CVE-2022-28185;>CVE-2022-28185 https://nvd.nist.gov/vuln/detail/CVE-2022-31607;>CVE-2022-31607 https://nvd.nist.gov/vuln/detail/CVE-2022-31608;>CVE-2022-31608 https://nvd.nist.gov/vuln/detail/CVE-2022-31615;>CVE-2022-31615 larry notlarry larry signature.asc Description: PGP signature
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On Tue, Nov 08, 2022 at 09:43:19AM +0100, Agostino Sarubbo wrote: > Hi, > > Whatever outside the arch testing (like tinderbox) is off topic here since it > is a completely different argument. > > To make John Helmert III happy, I just switched to tatt; so my actual > workflow is tatt + nattka and there is nothing more. > > If there are unanswered questions about the arch testing, please let me > know. > > Agostino Great, thanks! signature.asc Description: PGP signature
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On Mon, Nov 07, 2022 at 07:23:33PM -0500, Rich Freeman wrote: > On Mon, Nov 7, 2022 at 6:16 PM Sam James wrote: > > > > > On 7 Nov 2022, at 06:07, Oskari Pirhonen wrote: > > > > > > On Sun, Nov 06, 2022 at 11:37:24 +0100, Piotr Karbowski wrote: > > >> I would be in favour of stepping up the social contract and actually > > >> prohibiting this kind of things, we had that before too, the nattka you > > >> mgorny wrote is replacement for old bugzilla bot that was ... > > >> closedsource and perished, though nattka now have way more features than > > >> the old thing ever had. > > > > > > As a user, I think it would be really cool if there was a requirement > > > that all infra and infra-adjacent stuff was free software. > > > > > > I feel like I've read that Debian already has something like this. While > > > doing some quick searches I didn't find a full-on requirement, but all > > > their infra bits I did find were powered by free software. The most > > > relevant ones being buildd [1] and debci [2]. Additionally, the debci > > > docs has inctructions on reproducing tests yourself [3] which is a nice > > > extra IMO. > > > > Gentoo has > > https://www.gentoo.org/get-started/philosophy/social-contract.html. > > I feel like something like a dev-run tinderbox is a bit out of the > scope of that. > > Suppose I file a bug against a package, pointing out some issue in it. > How do you know I didn't use some proprietary static code analysis > tool to discover that error? Does it even really matter? The bug > speaks for itself. It is like worrying about whether somebody who > filed a bug was running Windows or another proprietary OS or browser > on their desktop. > > Well, a tinderbox is just an automated process for doing just that. > We don't require any dev to use a proprietary tinderbox before > committing. It is something that individual devs choose to use for > themselves, automating the testing workflow and possibly the > submission of bugs. > > I think the key is something that was brought up earlier in the > thread: is this causing problems? If somebody is running some tool > against the repository and automatically filing bugs, and those bugs > are not useful/actionable and waste the time of volunteers, then that > is a problem. Proprietary tools do contribute to this since they can > generate results that are harder to reproduce, but if they are clear > and accurate and actionable it could still be a net-positive. In some cases, yes, this is exactly the problem. This was one of the bugs reported in the now-deleted issue tracking repository on Github. > Of course if somebody wants to contribute to 100% FOSS tinderbox > efforts that would be even better. Perhaps if our 100% FOSS tinderbox > efforts addressed our needs very well, then nobody would want to > bother with the proprietary reports, or generating them. IMO it would > be better to create the FOSS solution before abandoning the > proprietary one. Doing otherwise is basically burning bridges - it > can be motivating in a sense but not really ideal. I'd love to have a > 100% FOSS solution around all of this, but I appreciate what has been > created and can hardly criticize volunteers for failing to make it > happen, especially since I haven't contributed to that myself. > > -- > Rich > signature.asc Description: PGP signature
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On Mon, Nov 07, 2022 at 08:26:15AM +0200, Joonas Niilola wrote: > On 7.11.2022 8.07, Oskari Pirhonen wrote: > > On Sun, Nov 06, 2022 at 11:37:24 +0100, Piotr Karbowski wrote: > >> I would be in favour of stepping up the social contract and actually > >> prohibiting this kind of things, we had that before too, the nattka you > >> mgorny wrote is replacement for old bugzilla bot that was ... > >> closedsource and perished, though nattka now have way more features than > >> the old thing ever had. > > > > As a user, I think it would be really cool if there was a requirement > > that all infra and infra-adjacent stuff was free software. > > > > I feel like I've read that Debian already has something like this. While > > doing some quick searches I didn't find a full-on requirement, but all > > their infra bits I did find were powered by free software. The most > > relevant ones being buildd [1] and debci [2]. Additionally, the debci > > docs has inctructions on reproducing tests yourself [3] which is a nice > > extra IMO. > > > > [1] https://buildd.debian.org > > [2] https://ci.debian.net > > [3] https://ci.debian.net/doc/file.MAINTAINERS.html > > > > - Oskari > > I _believe_ ago's tinderbox isn't being paid by the GF _anymore_ due to > this reason, but he keeps it running with his own expenses. I don't mind > this as long as the results are desirable and not phony. I still see a > lot of value in most of ago's work. He's not using infra's AWS resources anymore, but he's still using the devbox.amd64.dev.gentoo.org VM. > It is unfortunate we don't get to see the engine behind and copy it, > since I'd be really interested in using his automated bug search / > report tool. Even tattoo (https://github.com/arthurzam/tattoo) lacks > that at the moment. > > -- juippis signature.asc Description: PGP signature
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On Sun, Nov 06, 2022 at 08:03:16PM +0100, Agostino Sarubbo wrote: > On domenica 6 novembre 2022 14:27:40 CET John Helmert III wrote: > > As far as I can tell, there's ONE person relying completely on a > > proprietary arch testing system. > > > > Ago, could you comment on this? What's blocking you from open sourcing > > your software? > > Hi, > > I already answered in the previous post: > > "I still use getatoms.py to fetch 'doable' stablereqs (it is on my todo > to switch to nattka). And I have a script the **simply** does emerge over the > list of > the packages. There is nothing obscure in it." > > I'm working in arch testing since 2009. In the past I relied on scripts done > by someone else > and every time there was an issue I got no response. And so you force that frustration on everyone else? Why? > At a certain point I decided to make my own script in language I know so I > can edit it when > is needed. None of this blocks you from open sourcing it. Is your reason for not open-sourcing your automation really that "There is nothing obscure in it"? You also ignored my other question: "I'll also point out that you removed the Github repository that you used to tell people to report issues with your CI at, while there were several outstanding issues. Why?" > Since few years we allow self stabilization from maintainer. Do we know how > and with > what they test? No because it is not required. > The requirement for test is that the package you are testing works as > expected. > > https://wiki.gentoo.org/wiki/Project:AMD64_Arch_Testers#Arch_tester.27s_policy[1] > > Agostino > > > [1] > https://wiki.gentoo.org/wiki/Project:AMD64_Arch_Testers#Arch_tester.27s_policy signature.asc Description: PGP signature
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On Sun, Nov 06, 2022 at 09:15:40AM +0100, Michał Górny wrote: > Hi, everyone. > > Arch testing's relying on automation a lot these days. Not saying > that's bad, if it improves the state of affairs. However, I have some > concerns, based on what I've seen lately. > > On top of that, it seems that most of it still relies on proprietary > software and we have no clue how *exactly* it works, and it's really, > really hard to get a straight answer. As far as I can tell, there's ONE person relying completely on a proprietary arch testing system. Ago, could you comment on this? What's blocking you from open sourcing your software? I'll also point out that you removed the Github repository that you used to tell people to report issues with your CI at, while there were several outstanding issues. Why? I have two (of three) issue titles in my browser history, but as I recall you never touched them: 2. Release source code 3. More information on the bug [1] https://github.com/asarubbo/ci > So, my questions are: > > 1. Is "runtime testing required" field being respected? Obviously not > every package can be (sufficiently) tested via FEATURES=test, so we've > added that fields. However, if arch testers just ignore it and push > things stable based on pure build testing... > > 2. How are kernels being tested? Given the speed with which new gentoo- > sources stablereqs are handled, I really feel like "arch testing" there > means "checking if sources install", and have little to do with working > kernels. > > 3. How does the automation handle packages that aren't trivially > installable? I recall that in the past stablereqs were stalled for > months without a single comment because automation couldn't figure out > how to proceed, and nobody bothered reporting a problem. > > -- > Best regards, > Michał Górny > > signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Last rites: user.eclass
On Wed, Oct 19, 2022 at 07:08:44PM -, Martin Vaeth wrote:
> Mike Gilbert wrote:
> > user.eclass has been deprecated for two years. In the gentoo repo, it
> > is currently only used by acct-group.eclass and acct-user.eclass
>
> It is needed for ebuilds in non-gentoo repositories which cannot
> reserve a fixed number for users and groups.
Can't you import it into any overlay that needs it? Why not use
acct-{user,group} anyway?
signature.asc
Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Wed, Sep 28, 2022 at 05:28:00PM +0200, Florian Schmaus wrote: > I would like to continue discussing whether we should entirely deprecate > EGO_SUM without the desire to offend anyone. > > We now have a pending GitHub PR that bumps restic to 0.14 [1]. Restic is > a very popular backup software written in Go. The PR drops EGO_SUM in > favor of a vendor tarball created by the proxied maintainer. However, I > am unaware of any tool that lets you practically audit the 35 MiB source > contained in the tarball. And even if such a tool exists, this would > mean another manual step is required, which is, potentially, skipped > most of the time, weakening our user's security. This is because I > believe neither our tooling, e.g., go-mod.eclass, nor any Golang > tooling, does authenticate the contents of the vendor tarball against > upstream's go.sum. But please correct me if I am wrong. > > I wonder if we can reach consensus around un-depreacting EGO_SUM, but > discouraging its usage in certain situations. That is, provide EGO_SUM > as option but disallow its use if > 1.) *upstream* provides a vendor tarball > 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer > maintains the package > 3.) the number of EGO_SUM entries exceeds 1500 and a proxied maintainer > maintains the package I'm not sure I agree on these limits, given the authenticity problem exists regardless of how many dependencies there are. > In case of 3, I would encourage proxy maintainers to create and provide > the vendor tarball. > > The suggested EGO_SUM limits result from a histogram that I created > analyzing ::gentoo at 2022-01-01, i.e., a few months before EGO_SUM was > deprecated. > > - Flow > > 1: https://github.com/gentoo/gentoo/pull/27050 > signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 06/15] unpacker.eclass: Use lowercase in unpacker_src_uri_depends
On Sun, Sep 25, 2022 at 04:04:07PM -0500, John Helmert III wrote:
> On Sun, Sep 25, 2022 at 08:23:08PM +0200, Michał Górny wrote:
> > Transform the URIs to lowercase in unpacker_src_uri_depends() for
> > consistency with the behavior of _unpacker().
> >
> > Signed-off-by: Michał Górny
> > ---
> > eclass/unpacker.eclass | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/eclass/unpacker.eclass b/eclass/unpacker.eclass
> > index 482cf141ee1d..e07c25d0ffa9 100644
> > --- a/eclass/unpacker.eclass
> > +++ b/eclass/unpacker.eclass
> > @@ -509,7 +509,8 @@ unpacker_src_uri_depends() {
> > fi
> >
> > for uri in "$@" ; do
> > - case ${uri} in
> > + local m=${uri,,}
> > + case ${m} in
> > *.cpio.*|*.cpio)
> > d="app-arch/cpio" ;;
> > *.rar|*.RAR)
>
> If m is always lowercased, no need to check for uppercased extensions?
Sorry, this was done in the next patch
>
> > --
> > 2.37.3
> >
> >
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 06/15] unpacker.eclass: Use lowercase in unpacker_src_uri_depends
On Sun, Sep 25, 2022 at 08:23:08PM +0200, Michał Górny wrote:
> Transform the URIs to lowercase in unpacker_src_uri_depends() for
> consistency with the behavior of _unpacker().
>
> Signed-off-by: Michał Górny
> ---
> eclass/unpacker.eclass | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/unpacker.eclass b/eclass/unpacker.eclass
> index 482cf141ee1d..e07c25d0ffa9 100644
> --- a/eclass/unpacker.eclass
> +++ b/eclass/unpacker.eclass
> @@ -509,7 +509,8 @@ unpacker_src_uri_depends() {
> fi
>
> for uri in "$@" ; do
> - case ${uri} in
> + local m=${uri,,}
> + case ${m} in
> *.cpio.*|*.cpio)
> d="app-arch/cpio" ;;
> *.rar|*.RAR)
If m is always lowercased, no need to check for uppercased extensions?
> --
> 2.37.3
>
>
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 2/3] glep-0074: Specify the format of size and checksum fields
On Fri, Sep 23, 2022 at 04:03:54PM +0200, Michał Górny wrote: > Signed-off-by: Michał Górny > --- > glep-0074.rst | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/glep-0074.rst b/glep-0074.rst > index 54bf216..bfbe092 100644 > --- a/glep-0074.rst > +++ b/glep-0074.rst > @@ -191,6 +191,19 @@ The encoding can be used for other characters as well. > In particular, > escaping non-printable characters might be desirable. > > > +Size and checksum fields > + > + > +The Manifest entries used to describe files list the file size and one > +or more checksums. The size is expressed as an unsigned decimal integer. "an unsigned decimal integer" representing the file's size in bytes (rather than bits, or nibbles, or $UNIT), right? > +The checksums are expressed using pairs of fields, with the first field > +in every pair specifying the hash name and the second field its value. > +The names of hashes and the encoding of their values are specified > +in the `checksum algorithms`_ section. > + > +It is invalid to specify a hash name without a value. > + > + > File verification > - > > -- > 2.37.3 > > signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: virtual/dbus
On Wed, Sep 07, 2022 at 04:56:37PM +0100, Marek Szuba wrote: > Dear everyone, > > I wonder if we should create a virtual package to allow our users - or > at least those who run systemd anyway - to choose between sys-apps/dbus > and sys-apps/dbus-broken as D-Bus implementation for their systems. The > usual "Gentoo is about choice" thing aside, there is now at least one, > security-related, problem with the former which can be worked around by > switching to the latter: https://github.com/systemd/systemd/issues/22737 If you find a security issue, please file a security bug. I'm not really sure what the security impact of this is, though. > WDYT? > > PS. Cc'ing maintainers of both packages to see what they might have got > to say about this. > > -- > Marecki signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units
On Mon, Aug 22, 2022 at 02:10:47PM -0400, Kenton Groombridge wrote: > Hi everyone, > > I noticed that there are many systemd units which are shipped by various > packages which could be hardened, some further than they are currently and > some > that could use some hardening in general. > > For those who are unaware, systemd units support many options which can be > used > to restrict privileges of the processes run by the service. Some of these > options include things like making specified paths inaccessible or read-only, > setting the no_new_privs flag, protecting kernel sysctls, preventing the > loading > of kernel modules, applying a seccomp filter to restrict syscalls, and more. I > frequently reference systemd.exec(5)[1] and this page[2] for reference. > > Many of these options are fairly easy to apply from a user perspective - a > user > only needs to harden something like miniflux.service by overriding/settings > via > 'systemctl edit miniflux.service' (or manually editing > /etc/systemd/system/miniflux.service.d/override.conf). But, I want to propose > an > initiative to set some of these options by default for systemd units shipped > in > ::gentoo. > > Care must be taken though, as some of these options may end up breaking some > functionality that could be expected by users. An example of this may be if > the > package maintainer made the root filesystem read-only for a service except for > its private /var/lib, but a user was using an entirely different directory for > the service's read-writable data. Something like this may need to be > communicated via post-installation messages or simply left out by default, > depending on the circumstances. On the other hand, there are many options like > restricting syscalls via SystemCallFilter=@system-service or restricting > privilege escalation via NoNewPrivileges=true that I think are generally safe > to > apply, but each service is different and needs to be handled and tested > accordingly. > > As for getting units updated, I think a good place to start would be to > create a > new tracker bug for identifying packages providing systemd units that could be > improved in this regard, and each bug filed could include recommendations for > some of the more common options like ProtectSystem=, ProtectHome=, > ProtectDevices=, and others. > > What do you think? This would be a great improvement! systemd users can also see some of this via `systemd-analyze security`. > [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html > [2] https://docs.arbitrary.ch/security/systemd.html signature.asc Description: PGP signature
[gentoo-dev] Last rites: media-gfx/gif2apng
# John Helmert III (2022-08-16) # Multiple vulnerabilities, unmaintained upstream, EAPI 6. Removal in 30 # days, bug #830138 media-gfx/gif2apng signature.asc Description: PGP signature
[gentoo-dev] Last rites: www-servers/thttpd
# John Helmert III (2022-08-16) # Vulnerable, unmaintained upstream, maintainer says it's time for it to # go. Removal in 30 days, bug #769758 www-servers/thttpd signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-crypt/keybase
# John Helmert III (2022-08-14) # Vulnerable, unmaintained in Gentoo, EAPI6. Removal in 30 days, # bug #772209 app-crypt/keybase signature.asc Description: PGP signature
[gentoo-dev] Up for grabs: app-shells/thefuck
app-shells/thefuck is up for grabs after the inactivity retirement of its proxied maintainer. I've gone ahead and cleaned up its many duplicate/obsolete bugs and cleaned up for a security bug, so it has one test failure bug open. signature.asc Description: PGP signature
[gentoo-dev] Last rites: x11-terms/mrxvt
# John Helmert III (2022-08-14) # Remote code execution vulnerability, dead upstream. Removal in 30 # days, bug #791004. x11-terms/mrxvt signature.asc Description: PGP signature
[gentoo-dev] Last rites: media-libs/libaacplus
# John Helmert III (2022-08-14) # Dead upstream, vulnerable, no revdeps except a usedep. Removal in 30 # days, bug #618000 media-libs/libaacplus signature.asc Description: PGP signature
[gentoo-dev] Last rites: sys-cluster/slurm
# John Helmert III (2022-08-14) # Many vulnerabilities (including code execution and root privilege # escalation), effectively unmaintained. Removal in 30 days, bugs # #631552, #790296, #842789 sys-cluster/slurm signature.asc Description: PGP signature
[gentoo-dev] Last rites: calico-cni-plugin, calicoctl
# John Helmert III (2022-08-14) # Vulnerable and unmaintained for years, many open bugs, no revdeps, # EAPI 6. Removal in 30 days, bug 733354 net-misc/calico-cni-plugin net-misc/calicoctl signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-analyzer/smokeping
# John Helmert III signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: net-analyzer/sguil-sensors
On Wed, Aug 10, 2022 at 11:01:27PM -0500, John Helmert III wrote: > # John Helmert III (2022-08-10) > # Root privilege escalation vulnerability, many open bugs. Removal in 30 > # days, bug 630752 > net-analyzer/sguil-sensors Sorry, that's net-analyzer/sguil-sensor, without a trailing 's'. signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-analyzer/sguil-sensors
# John Helmert III (2022-08-10) # Root privilege escalation vulnerability, many open bugs. Removal in 30 # days, bug 630752 net-analyzer/sguil-sensors signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-admin/logcheck
# John Helmert III (2022-08-10) # Root privilege escalation vulnerability, unmaintained since the git # transition, multiple open bugs. Removal in 30 days, bug 630752 app-admin/logcheck signature.asc Description: PGP signature
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On Mon, Jul 25, 2022 at 03:59:59PM -0400, Joshua Kinard wrote: > On 7/25/2022 15:30, Joshua Kinard wrote: > [snip] > > > > > Some really quick looking around, I'm not finding any substantive > > discussions on why yescrypt is better than argon2. It so far seems that it > > just got implemented in libxcrypt sooner than argon2 did, so that's why > > there is this sudden push for it. > > > > E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend > > yescrypt instead. Anyway, it has to be implemented in libcrypt.", but > > provides no justification for why they recommend yescrypt. Since we're > > dealing with a fairly important function for system security, I kinda want > > something with much more context that presents pros and cons for this > > algorithm over others, especially argon2. > > So there is this question and three answers on Crypto StackExchange. It is > about five years-old, but it's got more detail on why argon2 won the PHC > instead of one of the other contenders. It is still subjective information, > but more thorough: > https://crypto.stackexchange.com/questions/48933/why-did-argon2-win-the-phc > > There's some more info if one continues to deep-dive on CSE, but I am > noticing a lot of the info is several years old. Some more recent things > make references to a newer algo called Balloon, but that seems to be going > off into side-tangents. > > Anyways, I guess I am just being paranoid. If a change to hashing algos is > made, it should be based on facts and not popularity contests or feelings. I'm not sure it's fair to suggest this change is based on "popularity contests or feelings". The facts were given in the original mail, just because one finds them unconvincing doesn't mean those facts aren't real and convincing to others. > -- > Joshua Kinard > Gentoo/MIPS > ku...@gentoo.org > rsa6144/5C63F4E3F5C6C943 2015-04-27 > 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 > > "The past tempts us, the present confuses us, the future frightens us. And > our lives slip away, moment by moment, lost in that vast, terrible > in-between." > > --Emperor Turhan, Centauri Republic > signature.asc Description: PGP signature
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On Mon, Jul 25, 2022 at 03:30:08PM -0400, Joshua Kinard wrote: > On 7/25/2022 14:44, Sam James wrote: > > > > > >> On 22 Jul 2022, at 20:10, Mikhail Koliada wrote: > >> > >> Hello! > >> > >> This idea has been fluctuating in my head for quite a while given that the > >> migration had happened > >> a while ago [0] and some other major distributions have already adopted > >> yescrypt as their default algo > >> by now [1]. For us switching is as easy as changing the default use flag > >> in pambase and rehashing the password > >> with the ‘passwd’ call (a news item will be required). > >> > >> What do you think? > >> > >> P.S. surely, I am only speaking about the local auth method based on > >> shadow and also about the pam-based systems as the change is going > >> to mainly impact the pam_unix.so calls in the pam’s stack. > >> Pamless or the systems with an alternative auth methods is a different > >> story. > >> > >> [0] - > >> https://www.gentoo.org/support/news-items/2021-10-18-libxcrypt-migration-stable.html > >> [1] - > >> https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow > > > > It's fine with me although I guess I'm a bit reluctant when the libxcrypt > > stuff is still biting > > some users. > > > > My preference would be to wait a few more months, but I don't feel strongly > > about it, > > and won't object if we want to move forward sooner. > > > > Overall though, it's a good idea, although I'd welcome Jason's input > > on alternatives first. CC'd. > > > > Best, > > sam > > "yescrypt" is an odd name for a hashing algorithm. I looked it up on > Wikipedia, and it just redirects to the 2013 Password Hashing Competition > (PHC)[1], in which yescrypt was just a runner-up (along w/ catena, makwa, > and lyra2). The winner was argon2. So unless something has changed in the > last nine years or there is more recent information, wouldn't it make more > sense to go with the winner of such a competition (argon2) instead of a > runner-up? I know marecki said Fedora was waiting for an official RFC for > argon2, but the wait for that ended almost a year ago in Sept 2021 when > RFC9106[2] was released. > > Some really quick looking around, I'm not finding any substantive > discussions on why yescrypt is better than argon2. It so far seems that it > just got implemented in libxcrypt sooner than argon2 did, so that's why > there is this sudden push for it. > > E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend > yescrypt instead. Anyway, it has to be implemented in libcrypt.", but > provides no justification for why they recommend yescrypt. Since we're > dealing with a fairly important function for system security, I kinda want > something with much more context that presents pros and cons for this > algorithm over others, especially argon2. > > That said, there does appear to be an open pull request on libxcrypt for > argon2[4], so maybe that is something to follow to see where it goes? > > 1. https://en.wikipedia.org/wiki/Password_Hashing_Competition > 2. https://datatracker.ietf.org/doc/html/rfc9106 > 3. https://github.com/linux-pam/linux-pam/issues/45 > 4. https://github.com/besser82/libxcrypt/pull/150 > > tl;dr, I'm just a bit uncomfortable adopting a new hashing algo just because > it seems popular. I would prefer something that's been thoroughly tested. > The scant info I've found thus far, that points to argon2, not yescrypt. There's justification for this in one of the references in zlogene's original mail: https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow#Detailed_Description > -- > Joshua Kinard > Gentoo/MIPS > ku...@gentoo.org > rsa6144/5C63F4E3F5C6C943 2015-04-27 > 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 > > "The past tempts us, the present confuses us, the future frightens us. And > our lives slip away, moment by moment, lost in that vast, terrible > in-between." > > --Emperor Turhan, Centauri Republic > signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: large amount of unmaintained dev-haskell/* package
On Sat, Jul 23, 2022 at 08:34:26AM -0400, Michael Orlitzky wrote: > On Sat, 2022-07-23 at 02:49 +0100, Sam James wrote: > > # Sam James (2022-07-22) > > # Monolithic mask for dev-haskell/* packages which have no reverse > > dependencies, > > # are broken, or severely out of date. The aim is to have the Haskell > > overlay > > # (::haskell) be the place for development packages and only have packages > > # needed for end-user applications in ::gentoo, as the status who has > > # proven to be unsustainable. More up-to-date versions of these packages > > # are available in ::haskell. > > # Removal on 2022-08-22. > > ... > > dev-haskell/hakyll > > ... > > sci-mathematics/agda > > > > Those two are (relatively) popular end-user applications. > > I'm sure this came up already, but just in case it didn't: we largely > have two non-developers maintaining the ::haskell overlay, and they've > been doing so since slyfox's retirement. Since there's an ongoing > thread about recruitment... has anyone thought about letting them do > their work in ::gentoo instead? Yes, I (and others) have encouraged them to do the quiz and offered mentoring them. signature.asc Description: PGP signature
Re: [gentoo-dev] Create an index for all qa notices
On Sat, Jul 16, 2022 at 08:42:39PM +0200, Agostino Sarubbo wrote: > Hello all, > > I noticed that we have many people that, after received a bug report, ask for > what the > reported 'qa notice' means. > > Sometimes there is a tracker and people can take an hint from the resolved > bugs but > when there aren't a lot of info I feel they are a bit lost. Somewhat orthogonally, it would be a great help to include common causes, solutions, and reproduction instructions directly in the bug reports and/or trackers. > Today, by pure chance, I stumbled upon the "Rust Compiler Error Index" and I > thought: > why we don't do the same thing with our qa notices? > > I think that devmanual could be the right place and each QA notice should > have an > 'identification code'. > In that way we can link the error in the qa notice like: > > https://devmanual.gentoo.org/appendices/qa-notices/qa0001[1] > https://devmanual.gentoo.org/appendices/qa-notices/qa0002[2] > > and so on. > > > Reference: https://doc.rust-lang.org/error-index.html[3] > > What do you think? > > Agostino > > > [1] https://devmanual.gentoo.org/appendices/qa-notices/qa0001 > [2] https://devmanual.gentoo.org/appendices/qa-notices/qa0002 > [3] https://doc.rust-lang.org/error-index.html signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] glep-0076: Require real name instead of legal name
On Tue, Jul 12, 2022 at 05:28:36AM +0500, Anna Vyalkova wrote: > This patch uses more friendly language towards potential transgender > and plural contributors. > > No other projects require to use a legal name, e.g. Linux says to use > your real name[0]. I'm not sure there are *none*, but nevertheless I think this is a useful change. Thanks for doing this! > Government issued documents are really a bad example since in some > countries it's really hard to get your name changed there. > > [0]: > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin > > Closes: https://bugs.gentoo.org/805575 > Signed-off-by: Anna Vyalkova > --- > glep-0076.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/glep-0076.rst b/glep-0076.rst > index 2216483..27db00a 100644 > --- a/glep-0076.rst > +++ b/glep-0076.rst > @@ -137,8 +137,8 @@ the Certificate of Origin by adding :: > Signed-off-by: Name > > to the commit message as a separate line. The sign-off must contain > -the committer's legal name as a natural person, i.e., the name that > -would appear in a government issued document. > +the committer's real name as a natural person, i.e., the name that > +you would use to present yourself to your colleagues. > > The following is the current Gentoo Certificate of Origin, revision 1: > > -- > 2.35.1 > > signature.asc Description: PGP signature
Re: [gentoo-dev] Looking for co-maintainers for number of packages
On Sun, Jul 03, 2022 at 09:03:04PM -0700, Georgy Yakovlev wrote: > I've been rather busy lately and can't keep up with all of my packages. > There are pending bumps, some bugs, but nothing too crazy or hard. > So I'm looking for someone to co-maintain (or even take over if you > insist) the following packages: > > * net-mail/notmuch > pseudo-autoconf NIH build system that can be PITA to work with, > responsive upstream. High profile package. > proxied maintainer in metadata has not been active lately and probably > should be dropped. > > * net-irc/weechat > Regular but not very frequent releases, responsive upstream, cmake, > pretty sane and very popular. > > * dev-cpp/abseil-cpp > Googleware, it's usually bundled into source, like gnulib, but some > projects use system copy. > Hardcoded flags, broken abi every other bump, may require slotting in > the future, some revdeps rely on older versions. Not hard to maintain, > but has more that usual blast radius. > > * net-libs/grpc > * dev-python/grpcio > * dev-python/grpcio-tools > * dev-python/grpcio-testing > grpc stack, googleware again. rather frequent releases, lack of > portage-able tests, as tests insist on downloading gtest stack git > master in src_test phase. > Technically it's already co-maintained, but I't be beneficial if we > have more hands and eyes on this one. > python project has been helping with python packages, but lack of tests > makes the package somewhat risky. > bonus points if you can test it with tensorflow. > > * dev-util/bear > Responsive upstream. Tests work but require disabling sandboxing (check > ebuild on how to run it). Not too hard, pretty popular. > > * app-arch/dpkg > debian upstream, easy to maintain. just need extra eyeballs. > > * app-shells/fish > Responsive upstream, not very frequent releases, cmake. Requires some > attention on non-x86 as arch bugs are rather frequent. But nothing too > crazy. > > * sys-process/glances > Responsive upstream, easy package. Just need extra pair of eyes/hands. Joined you here! > * dev-util/google-perftools > Another google package, very arch-specific, big blast radius if broken. > Not hard to maintain, but need to be extra careful with revdeps, > requires alt-arch testing. > > * app-admin/sysstat > pretty easy but important package. I will also offer base-system to > take it, as it's kinda important one. > > * app-admin/tmpreaper > debian upstream, easy. > > * x11-misc/xwallpaper > sane upstream, easy package. just need extra hands. probably most > secure wallpaper setter out there ;-) > > > Thanks, Georgy. > > PS. Huge bonus if you can test packages not only on x86_64. > Ofc I can help with some gotchas in packages and have no plans on > abandoning those completely, but realistically I'm not doing enough to > keep those properly maintained at the moment. > signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-libs/libvterm-neovim
# John Helmert III (2022-06-19) # Untouched by maintainer since Git transition. No reverse dependencies, # unused by upstream, vulnerable. Removal in 30 days. Bug #678705 dev-libs/libvterm-neovim signature.asc Description: PGP signature
[gentoo-dev] Package up for grabs (gui-apps/wf-recorder)
gui-apps/wf-recorder has been dropped to maintainer-needed due to its proxied maintainer being retired. I've gone ahead and bumped it to 0.3.0, fixing the only open bug against it. signature.asc Description: PGP signature
[gentoo-dev] Last rites: sys-cluster/csync2
# John Helmert III (2022-06-15) # Open security bug with patches for years. Upstream seems dead since # 2020. Removal on 2022-07-15. Bug #718550. sys-cluster/csync2 signature.asc Description: PGP signature
Re: [gentoo-dev] About EGO_SUM
On Thu, Jun 09, 2022 at 07:49:04PM +0200, Sebastian Pipping wrote: > On 08.06.22 22:42, Robin H. Johnson wrote: > > EGO_SUM vs dependency tarballs: > > [..] > > - EGO_SUM is verifiable/reproducible from Upstream Go systems > > Let's be explicit, there is a _security_ threat here: as a user of an > ebuild, dependency tarballs now take effort in manual review just to > confirm that the content full matches its supposed list of ingredients. > They are the perfect place to hide malicious code in plain sight. Now > with dependency tarballs, there is a new layer that by design will > likely be chronically under-audited. It gives me shivers, frankly. > Previously with a manifest and upstream-only URLs, only upstream can add > malicious code, not downstream in Gentoo. There are many packages in ::gentoo that use tarballs of patches written and hosted by Gentoo developers, or tarballs of source code generated by developers themselves. A (very) rough grep shows this is very prevalent: ~/gentoo/gentoo $ grep -r SRC_URI.*dev.gentoo.org | wc -l 2845 So this problem isn't really new. Users are required to trust Gentoo packagers that we don't do naughty things to the source code, more or less just like any other distribution. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Security Bug Assignment Change
On Sat, Apr 23, 2022 at 03:49:32PM +0300, Joonas Niilola wrote: > On 15.4.2022 4.38, John Helmert III wrote: > > Hi all! Currently all security bugs are assigned to security@g.o, > > always. This can easily lead to some confusion about who needs to do > > something about a given bug; right now this is generally tracked by > > whiteboard magic strings that probably not many people outside of the > > Security Project understand [1] and this has been a source of > > confusion around security bugs for a long time. > > Is there a specific group that has this problem? E.g. inactive > developers, proxied maintainers, (dead) projects? Like is this actually > a wide-spread problem? No, I don't think so. But currently the one who is expected to act on a bug is only discernable via whiteboard, which is somewhat unique in security bugs. Removing some of that 'magic' would seem to be a good thing in any case. > > > > To make it abundantly clear who needs to take action for a given bug, > > I propose we move away from the dogma of security@ always being > > assigned to security bugs, and instead assign bugs to whoever needs to > > take action for the bug. For example, on security bugs that need a > > package bumped or cleaned up, the package maintainer would be > > assigned. For bugs needing a GLSA, security@ would be assigned. > > > > As a nice side effect, this would be a step towards making security > > bug state discernable outside of the human-maintained and oft-stale > > whiteboard. In the long term, a maintainer's security bugs could be > > more easily tracked via things like packages.g.o. > > p.g.o already has a "security" tab for maintainers, but the bug listing > is pretty ineffective already as-is. Right, because there's not a trivial way to identify who needs to do something for a security bug. Under this new scheme, a bug would only be under a maintainer's security bug tab if they were assigned (i.e., the package needs a bump), and then removed when security@ is assigned. > > > > As far as bug handling goes, I see two obvious (though rathor minor) > > sticky points: > > > > - Who do we assign bugs to when a bug is in stabilization > > state? The stabilization bug will always be assigned to the > > maintainer, but the security bug will be neither actionable by the > > maintainer nor security@ until the stabilization is finished. > > > > - Rarely, we have a security bug that affects multiple packages with > > different maintainers (e.g. a package and its -bin variant). Under > > this scheme, we would have to always separate bugs by package > > maintainer. > > > > I'm not proposing any change to the Bugzilla product or component, so > > security bugs will still be able to be exhaustively enumerated this > > way, but any tooling that relies on security bugs always being > > assigned to security@ would have to be changed. > > > > What do you all think? > > > > [1] > > https://www.gentoo.org/support/security/vulnerability-treatment-policy.html > > "Severity Level" section > > I don't mind either way as long as it's really fixing a problem. Just > got familiar with the new workflow after most recent change... I didn't think it was that invasive or disruptive of a change. > Anyway hope things have gotten better since sending this e-mail, but I > fear (assume) people who had these problems aren't actively reading the > mailing list either. I don't think this is really relevant to my proposal. If we decide to implement this and people get it wrong, oh well. The situation will still gradually get better. > -- juippis signature.asc Description: PGP signature
[gentoo-dev] [RFC] Security Bug Assignment Change
Hi all! Currently all security bugs are assigned to security@g.o, always. This can easily lead to some confusion about who needs to do something about a given bug; right now this is generally tracked by whiteboard magic strings that probably not many people outside of the Security Project understand [1] and this has been a source of confusion around security bugs for a long time. To make it abundantly clear who needs to take action for a given bug, I propose we move away from the dogma of security@ always being assigned to security bugs, and instead assign bugs to whoever needs to take action for the bug. For example, on security bugs that need a package bumped or cleaned up, the package maintainer would be assigned. For bugs needing a GLSA, security@ would be assigned. As a nice side effect, this would be a step towards making security bug state discernable outside of the human-maintained and oft-stale whiteboard. In the long term, a maintainer's security bugs could be more easily tracked via things like packages.g.o. As far as bug handling goes, I see two obvious (though rathor minor) sticky points: - Who do we assign bugs to when a bug is in stabilization state? The stabilization bug will always be assigned to the maintainer, but the security bug will be neither actionable by the maintainer nor security@ until the stabilization is finished. - Rarely, we have a security bug that affects multiple packages with different maintainers (e.g. a package and its -bin variant). Under this scheme, we would have to always separate bugs by package maintainer. I'm not proposing any change to the Bugzilla product or component, so security bugs will still be able to be exhaustively enumerated this way, but any tooling that relies on security bugs always being assigned to security@ would have to be changed. What do you all think? [1] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html "Severity Level" section signature.asc Description: PGP signature
Re: [gentoo-dev] proposal: use only one hash function in manifest files
I don't really have any strong opinion, but I'll note this was discussed here last year, too: https://archives.gentoo.org/gentoo-dev/message/a51ef62765b577dccfde67d5d2d727ae On Tue, Apr 05, 2022 at 01:41:50AM +0200, Jason A. Donenfeld wrote: > Hi, > > I'd like to propose the following for portage: > > - Only support one "secure" hash function (such as sha2, sha3, blake2, etc) > - Only generate and parse one hash function in Manifest files > - Remove support for multiple hash functions > > In other words, what are we actually getting by having _both_ SHA2-512 > and BLAKE2b for every file in every Manifest? It's not about file > integrity, since certainly a single hash handles that use case fine. > And it's not about security either, since for that we use gpg > signatures, and gpg signatures are carried out over a _single_ hash of > the plain text being hashed, so the security of the system reduces to > breaking SHA2-512 anyway. So, if it's not about file integrity and > it's not about security, what is it about? > > I don't really care which one we use, so long as it's not already > broken or too obscure/new. So in other words, any one of SHA2-256, > SHA2-512, SHA3, BLAKE2b, BLAKE2s would be fine with me. Can we just > pick one and roll with it? > > Jason > > PS: there _is_ a good reason for recording the file size in Manifest > files as we do now: it's quicker to compare sizes on large files than > it is to read and hash the whole thing, so this gives us a "free" way > of noticing quick corruption. > signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating repoman
On Thu, Mar 10, 2022 at 04:53:10PM -0500, Joshua Kinard wrote: > On 3/10/2022 14:44, Andreas K. Huettel wrote: > >>> > >>> I wouldn't block anyone from doing this, but it's not something I'm > >>> personally interested in pursuing. I see very little value here. > >> > >> First, you're trying to justify replacing repoman on an entirely subjective > >> opinion of "I think is superior" ... > > > > Well, if you've ever tried it you'll notice that for != repoman > > actually finishes the checks within a finite amount of time. Kind of, the > > most blatant argument for ditching repoman, actually. > > If this is a concern for some, has anyone looked into whether repoman can be > fixed to be more efficient? If so, how was the determination made that it > cannot be fixed and instead, needs to be replaced? It's been around for 20+ > years. Surely someone has gotten annoyed enough to look at any issues it > has and attempt to fix them? It's slow enough that Gentoo CI [1] uses pkgcheck to be remotely useful. [1] https://qa-reports.gentoo.org/output/gentoo-ci/output.html > That said, I'm not terribly bothered by it. It is slow, don't get me wrong, > but it's not slow enough that my workflow is significantly impacted. It > catches most of the mistakes I've ever made before I make them so that I can > fix them. For me, that's job well done. > > -- > Joshua Kinard > Gentoo/MIPS > ku...@gentoo.org > rsa6144/5C63F4E3F5C6C943 2015-04-27 > 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 > > "The past tempts us, the present confuses us, the future frightens us. And > our lives slip away, moment by moment, lost in that vast, terrible > in-between." > > --Emperor Turhan, Centauri Republic > signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating repoman
On Thu, Mar 10, 2022 at 12:07:40PM -0600, William Hubbs wrote: > On Thu, Mar 10, 2022 at 09:29:59AM -0800, Matt Turner wrote: > > On Wed, Mar 9, 2022 at 11:09 PM Joonas Niilola wrote: > > > > > > On 9.3.2022 23.00, Matt Turner wrote: > > > > I'd like to deprecate and ultimately remove repoman. I believe that > > > > dev-util/pkgcheck and pkgcommit (from app-portage/mgorny-dev-scripts) > > > > are far superior replacements, and it makes sense to have people using > > > > the same tool and seeing the same warnings as in the CI. > > > > > > > > Are there any useful checks or behaviors of repoman that are missing > > > > from pkgcheck and pkgcommit? > > > > > > > > Thanks, > > > > Matt > > > > > > > > > > I still fail to see the "why" in here. Repoman is better than pure 'git > > > commit' that I know some people still like to use, and as long as it's > > > kept maintained. > > > > repoman is inferior to other tooling mentioned. The other tooling is > > actually run in CI. Developers should get the same warnings locally as > > in CI. Restated another way: I'm tired of telling people to stop using > > repoman or "pkgcheck would have caught that". > > I am going to nit-pick here, but pkgcheck pulls in pkgcore still. As far > asI know, pkgcore was meant to be a portage-like package manager, but it > isn't maintained. So, can we break that dependency before we make > pkgcheck the official tool for qa checks? I would rather not have > pkgcore landing on everyone's systems unless it is usable. If I am wrong > about pkgcore, please correct me and I'll be quiet, but if not let's > make pkgcheck independent from it before we deprecate repoman. Yes, pkgcheck pulls in pkgcore, and yes, pkgcore wants to function as a package manager, but it doesn't conflict with Portage, so there's no concern in pulling it in. As long as you don't call the executables it installs (notably pmerge, maybe others), it won't cause any problems. pkgcheck can also already be considered our official CI tool, since it's what does our CI. signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: sys-apps/hwids
On Sat, Dec 25, 2021 at 01:51:36AM -0500, Philip Webb wrote:
> 211224 Mike Gilbert wrote:
> > # Mike Gilbert (2021-12-24)
> > # Replaced by sys-apps/hwdata. Removal on 2021-01-23.
> > sys-apps/hwids
>
> It seems to be a requirement for my system :
>
> root:515 ~> emerge -cpv hwids
> Calculating dependencies... done!
> sys-apps/hwids-20210613-r1 pulled in by:
> sys-apps/pciutils-3.7.0 requires sys-apps/hwids
> sys-apps/usbutils-014 requires sys-apps/hwids
> sys-fs/udev-249.6 requires >=sys-apps/hwids-20140304[udev]
> x11-libs/libpciaccess-0.16 requires sys-apps/hwids
>
> root:512 ~> eix hwids
> [U] sys-apps/hwids
> Available versions: 20210613-r2 ***l {+net +pci systemd +udev
> +usb}
> Installed versions: 20210613-r1([2021-09-25 15:57:37])(udev usb -net -pci
> -systemd)
>
> root:513 ~> eix hwdata
> [I] sys-apps/hwdata
> Available versions: 0.353^t ~0.354^t
> Installed versions: 0.353^t([2021-12-11 22:30:38])
>
> Am I missing something ?
Yes, you seem to be missing the (perhaps not so) recent commits to the
tree which prepared the tree for the removal of sys-apps/hwids. Please
try syncing and doing a world update then checking again.
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH] mount-boot.eclass: support EAPI 8
Signed-off-by: John Helmert III
---
eclass/mount-boot.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/mount-boot.eclass b/eclass/mount-boot.eclass
index 2b07160231a6..3111d9dcb9b5 100644
--- a/eclass/mount-boot.eclass
+++ b/eclass/mount-boot.eclass
@@ -4,7 +4,7 @@
# @ECLASS: mount-boot.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
-# @SUPPORTED_EAPIS: 6 7
+# @SUPPORTED_EAPIS: 6 7 8
# @BLURB: functions for packages that install files into /boot
# @DESCRIPTION:
# This eclass is really only useful for bootloaders.
@@ -14,7 +14,7 @@
# error if it can't. It does nothing if /boot isn't a separate partition.
case ${EAPI:-0} in
- 6|7) ;;
+ 6|7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
--
2.34.1
[gentoo-dev] Re: Aisha's packages up for grabs
On Sun, Nov 21, 2021 at 08:59:57AM +0200, Joonas Niilola wrote: > Hey, > > the following are up for grabs: > > acct-group/greetd > acct-user/greetd > gui-libs/greetd I'll take these. Very happy to comaintain if anyone else is interested, of course. signature.asc Description: PGP signature
[gentoo-dev] Last rites: mail-client/cone
# John Helmert III (2021-11-13) # Unmaintained in Gentoo, open security bug, many unfixed otther # bugs. Removal on 2021-12-13, bug #764719. mail-client/cone signature.asc Description: PGP signature
[gentoo-dev] Last rites: www-apps/websvn
# John Helmert III (2021-11-12) # Unfixed code execution bug, unmaintained in Gentoo. # Removal on 2021-11-11, bugs #672352, #794511. www-apps/websvn signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-emulation/firecracker
# John Helmert III (2021-11-11) # Unmaintained and vulnerable. # Removal on 2021-12-11. Bugs #735978, #794907 app-emulation/firecracker signature.asc Description: PGP signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Thu, Nov 04, 2021 at 12:09:28AM +, Sam James wrote: > On 4 Nov 2021, at 00:02, Sam James wrote: > >> On 3 Nov 2021, at 23:53, Aaron Bauman wrote: > >> Is that where the policy belongs? > >> If so, shouldn't the council update it based on their decisions? > >> "patches are welcome" doesn't fit every scenario. > > Got to agree here. If there's a gap in the documentation, > > let's file a bug -- irrespective of if someone is going to give > > a patch. > > Just commenting this on the ML means it'll get lost > > and we'll forget about it... > > Filed https://bugs.gentoo.org/821553. Please > feel free to clarify it. Thank you! Many of us apparently have differing interpretations of the policy (and it's somewhat hidden), so a clear policy in an obvious place will be a huge improvement! signature.asc Description: PGP signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Wed, Nov 03, 2021 at 05:51:49PM +0100, Thomas Deutschmann wrote: > On 2021-11-03 17:44, John Helmert III wrote: > >> | Upgrade path for old systems > >> | > >> | Vote (unanimous): The ebuild tree must provide an upgrade path to a > >> | stable system that hasn't been updated for one year. > > Does "upgrade path" imply a simple world upgrade is all that should be > > necessary to upgrade the system? I wouldn't interpret it this way. > > Could you please share your interpretation? I wonder how you can agree > on an upgrade path but still require manually hacking to get a system > up-to-date. That is basically the definition of "upgrade path"... Sure. An "upgrade path" to me sounds like not just a world update, but also includes other stuff that might be necessary to get a system fully updated, like temporarily setting PYTHON_TARGETS to upgrade a package. A system without an upgrade path would seem to be a system where there is no way to upgrade it without reinstalling, which you seem to be asserting is the case for this system. 13:36 <@Whissi> Nice. Due to some people rushing to EAPI8 and remove old ebuilds they broke the guarantee to update systems at least once a year again. Congratulations! http://dpaste.com/AD87YKY62 13:36 <+sam_> your issue is to do with python targets changing: PYTHON_TARGETS="python3_8" emerge -v1 portage should work 13:37 <@Whissi> As you can see, it doesn't work. 13:37 <+sam_> that's not what you ran though? 13:37 <+sam_> see https://wiki.gentoo.org/wiki/User:Sam/Portage_help/Upgrading_Portage#Solution 13:37 <@Whissi> http://dpaste.com/7RYRJD72H 13:38 <+sam_> you're not forcing the old PYTHON_TARGETS? 13:39 <@Whissi> No, http://dpaste.com/7V727USW4 13:39 <+sam_> but i'm saying you should 13:39 <+sam_> (not that you should _have_ to) 13:39 <+sam_> temporarily do it once on the command line 13:39 <+sam_> it is enough to get portage upgraded 13:39 <+sam_> we do it often in #gentoo Based on this snippet from #gentoo-mozilla, it does seem like there is a way forward for this system. signature.asc Description: PGP signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Wed, Nov 03, 2021 at 05:34:16PM +0100, Ulrich Mueller wrote: > > On Wed, 03 Nov 2021, Rich Freeman wrote: > > > On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann > > wrote: > >> > >> This is not about finding solution to upgrade the system (in this case > >> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is > >> about raising awareness that Gentoo is a rolling distribution and that > >> we guarantee users to be able to upgrade their system when they do world > >> upgrades just once a year (remember: in my case the last world upgrade > >> is just 4 months old!). If they cannot upgrade their system without > >> manual intervention, we failed to do our job. > > > Do we have this "guarantee" documented somewhere? I thought I've > > heard six months tossed around. You say one year. It seems > > reasonable to have some sort of guideline like this and try to stick > > with it, at least for @system. > > We do. Summary of 2009-11-09 Council meeting: > > | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt > | > | Upgrade path for old systems > | > | Vote (unanimous): The ebuild tree must provide an upgrade path to a > | stable system that hasn't been updated for one year. Does "upgrade path" imply a simple world upgrade is all that should be necessary to upgrade the system? I wouldn't interpret it this way. > | Action: leio will start a discussion on gentoo-dev on if and how to > | support upgrading systems that are outdated more than a year. signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-10-27-upgrade-to-net-news_rssguard-4_0: add news item
On Wed, Oct 27, 2021 at 10:53:10AM +0500, Anna Vyalkova wrote: > Signed-off-by: Anna Vyalkova > --- > Related to this version bump and unmask: > https://archives.gentoo.org/gentoo-proxy-maint/message/d86352b4ebad8c4ddd14fcd8ce37162f > > ...27-upgrade-to-net-news_rssguard-4_0.en.txt | 29 +++ > 1 file changed, 29 insertions(+) > create mode 100644 > 2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt > > diff --git > a/2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt > > b/2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt > new file mode 100644 > index 000..35971f0 > --- /dev/null > +++ > b/2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt > @@ -0,0 +1,29 @@ > +Title: net-news/rssguard-4.0 upgrade > +Author: Anna Vyalkova > +Posted: 2021-10-27 > +Revision: 1 > +News-Item-Format: 2.0 > +Display-If-Installed: =rssguard-4.0 due to when they sync. > + > +RSS Guard database files created by RSS Guard version 3.9.x are > +incompatible with RSS Guard version 4.0 or later [0]. > + > +Configuration file (config.ini) is fully backwards compatible according > +to the upstream. You can save it (File -> Backup settings) before an > +upgrade and restore it later (File -> Restore settings). > + > +There is no reliable way to automate the database format conversion, so > +action from the user is required before an upgrade can take place. > + > +The first option would be to export your feeds as an OMPL file > +(Accounts -> Export feeds) before an upgrade and import them later > +(Account -> Import feeds). > + > +The second option would be to manually update your database.db file to > +4.x.x format following a guide by the upstream developer [1]. > + > +Keep in mind that application data directory has been renamed from > +"~/.config/RSS Guard" to "~/.config/RSS Guard 4". > + > +[0] https://github.com/martinrotter/rssguard/releases/tag/4.0.0 > +[1] > https://github.com/martinrotter/rssguard/blob/master/resources/docs/Documentation.md#migratt > -- > 2.33.1 > > signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
On Thu, Oct 21, 2021 at 10:05:20AM +0200, Michał Górny wrote: > Hello, > > Splitting from the discussion in [1] (moving more arhitectures to > ~arch), I'd like to propose that we remove the "security supported" > architecture list from [2] and instead level security support with > the general architecture support in Gentoo, e.g. by having all > architectures with stable profiles be "security supported". This will better align the written policy with what actually happens in reality, so I'm all for it! Thanks for bringing this up. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
On Mon, Oct 18, 2021 at 02:25:47AM +0200, Thomas Deutschmann wrote: > On 2021-10-14 15:40, Marek Szuba wrote: > > WDYT? > > Could you please elaborate what you are expecting from this change? > > I.e. will this solve any problem (please name it)? Will it allow us to > move forward where we are blocked at the moment (please name it)? A security bug, for example, is currently blocked for almost a month waiting for hppa stabilization [1], and this isn't the first time we've had to wait for a "slower" arch on a security bug. [1] https://bugs.gentoo.org/795480 signature.asc Description: PGP signature
Re: [gentoo-dev] Stabilization Detached from Security Bugs
On Fri, Aug 27, 2021 at 08:58:35AM +0200, Michał Górny wrote: > On Thu, 2021-08-26 at 19:11 -0500, John Helmert III wrote: > > In the past, stabilization for security bugs would be handled directly > > in that security bug. After some discussion on the gentoo-dev mailing > > list [1], there was some consensus on modifying this workflow to > > separate stabilization from security bugs. Going forward, separate bugs > > should be filed for security stabilizations and then the security bug > > will have a dependency on its stabilization bug. > > Great! I can make the field invisible on security bugs when you've > confirmed that all pending stabilizations are finished. Or without > that, if you prefer ;-). Sure! But let's at least wait until we're done with the pending security bugs which have CC-ARCHES [1], just to keep churn (and work for us) a bit lower. [1] https://bugs.gentoo.org/buglist.cgi?email1=security%40gentoo.org_to1=1=substring=keywords_id=5758333=substring_format=advanced=---=CC-ARCHES signature.asc Description: PGP signature
[gentoo-dev] Stabilization Detached from Security Bugs
Hi all, In the past, stabilization for security bugs would be handled directly in that security bug. After some discussion on the gentoo-dev mailing list [1], there was some consensus on modifying this workflow to separate stabilization from security bugs. Going forward, separate bugs should be filed for security stabilizations and then the security bug will have a dependency on its stabilization bug. Thanks! [1] https://archives.gentoo.org/gentoo-dev/message/72d1747bb087c0317e492177c9653cc3 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Add cpio dependency
On Mon, Aug 23, 2021 at 06:55:57PM -0400, Mike wrote:
> Add cpio dependency to kernel-2.eclass
>
> Bug: https://bugs.gentoo.org/731666
>
> Signed-off-by: Mike Pagano
> ---
> eclass/kernel-2.eclass | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index e3d556f2b..83d173d77 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -586,6 +586,7 @@ if [[ ${ETYPE} == sources ]]; then
> dev-lang/perl
> sys-devel/bc
> sys-devel/bison
> + app-arch/cpio
Any reason to not keep the dependencies sorted?
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
The benefits definitely seem to outweigh the added work here, sounds good to me! signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-portage/{deltup,getdelta}
# John Helmert III (2021-07-26) # Open security bug, service backing it seems to be dead, making these # packages useless. Old EAPIs. Removal on 2021-08-26. Bug #630814 app-portage/getdelta app-portage/deltup signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-text/lout
# John Helmert III (2021-07-26) # Maintained needed, open security bug, uninterested upstream. # No revdeps. Removal on 2021-08-26. Bug #752408. app-text/lout signature.asc Description: PGP signature
Re: [gentoo-dev] Package up for grabs: dev-python/imread
On Fri, Jul 23, 2021 at 07:42:48PM +0200, Dennis Lamm wrote: > Hello, > > Package up for grabs due to to no consumer in 3dprint project and other > portage package: > dev-python/imread > > It has 1 open bug and a version bump pending according to Repology. > > IMHO: this should be removed from portage. Why? If you think so, why not do it? signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] bash-completion-r1.eclass: Add EAPI 8 support
On Fri, Jul 16, 2021 at 05:33:24PM +0200, Michał Górny wrote:
> Signed-off-by: Michał Górny
> ---
> eclass/bash-completion-r1.eclass | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/eclass/bash-completion-r1.eclass
> b/eclass/bash-completion-r1.eclass
> index 80f2d5fcd32a..783ba5a85bd2 100644
> --- a/eclass/bash-completion-r1.eclass
> +++ b/eclass/bash-completion-r1.eclass
> @@ -1,138 +1,143 @@
> # Copyright 1999-2021 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: bash-completion-r1.eclass
> # @MAINTAINER:
> # mgo...@gentoo.org
> -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
> +# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7 8
> # @BLURB: A few quick functions to install bash-completion files
> # @EXAMPLE:
> #
> # @CODE
> -# EAPI=5
> +# EAPI=8
> #
> # src_configure() {
> #econf \
> #--with-bash-completion-dir="$(get_bashcompdir)"
> # }
> #
> # src_install() {
> #default
> #
> #newbashcomp contrib/${PN}.bash-completion ${PN}
> # }
> # @CODE
>
> +if [[ ! ${_BASH_COMPLETION_R1_ECLASS} ]]; then
> +
> inherit toolchain-funcs
>
> case ${EAPI:-0} in
> - 0|1|2|3|4|5|6|7) ;;
> - *) die "EAPI ${EAPI} unsupported (yet)."
> + 5|6|7|8) ;;
> + *) die "EAPI ${EAPI} unsupported."
> esac
SUPPORTED_EAPIS has 0-8, but die on EAPI<5?
>
> # @FUNCTION: _bash-completion-r1_get_bashdir
> # @INTERNAL
> # @DESCRIPTION:
> # First argument is name of the string in bash-completion.pc
> # Second argument is the fallback directory if the string is not found
> # @EXAMPLE:
> # _bash-completion-r1_get_bashdir completionsdir /usr/share/bash-completion
> _bash-completion-r1_get_bashdir() {
> debug-print-function ${FUNCNAME} "${@}"
>
> if $(tc-getPKG_CONFIG) --exists bash-completion &>/dev/null; then
> local path
> path=$($(tc-getPKG_CONFIG) --variable="${1}" bash-completion)
> || die
> # we need to return unprefixed, so strip from what pkg-config
> returns
> # to us, bug #477692
> echo "${path#${EPREFIX}}"
> else
> echo "${2}"
> fi
> }
>
> # @FUNCTION: _bash-completion-r1_get_bashcompdir
> # @INTERNAL
> # @DESCRIPTION:
> # Get unprefixed bash-completion completions directory.
> _bash-completion-r1_get_bashcompdir() {
> debug-print-function ${FUNCNAME} "${@}"
>
> _bash-completion-r1_get_bashdir completionsdir
> /usr/share/bash-completion/completions
> }
>
> # @FUNCTION: _bash-completion-r1_get_helpersdir
> # @INTERNAL
> # @DESCRIPTION:
> # Get unprefixed bash-completion helpers directory.
> _bash-completion-r1_get_bashhelpersdir() {
> debug-print-function ${FUNCNAME} "${@}"
>
> _bash-completion-r1_get_bashdir helpersdir
> /usr/share/bash-completion/helpers
> }
>
> # @FUNCTION: get_bashcompdir
> # @DESCRIPTION:
> # Get the bash-completion completions directory.
> get_bashcompdir() {
> debug-print-function ${FUNCNAME} "${@}"
>
> echo "${EPREFIX}$(_bash-completion-r1_get_bashcompdir)"
> }
>
> # @FUNCTION: get_bashhelpersdir
> # @INTERNAL
> # @DESCRIPTION:
> # Get the bash-completion helpers directory.
> get_bashhelpersdir() {
> debug-print-function ${FUNCNAME} "${@}"
>
> echo "${EPREFIX}$(_bash-completion-r1_get_bashhelpersdir)"
> }
>
> # @FUNCTION: dobashcomp
> # @USAGE: [...]
> # @DESCRIPTION:
> # Install bash-completion files passed as args. Has EAPI-dependent failure
> # behavior (like doins).
> dobashcomp() {
> debug-print-function ${FUNCNAME} "${@}"
>
> (
> insopts -m 0644
> insinto "$(_bash-completion-r1_get_bashcompdir)"
> doins "${@}"
> )
> }
>
> # @FUNCTION: newbashcomp
> # @USAGE:
> # @DESCRIPTION:
> # Install bash-completion file under a new name. Has EAPI-dependent failure
> # behavior (like newins).
> newbashcomp() {
> debug-print-function ${FUNCNAME} "${@}"
>
> (
> insopts -m 0644
> insinto "$(_bash-completion-r1_get_bashcompdir)"
> newins "${@}"
> )
> }
>
> # @FUNCTION: bashcomp_alias
> # @USAGE: ...
> # @DESCRIPTION:
> # Alias completion to one or more commands (es).
> bashcomp_alias() {
> debug-print-function ${FUNCNAME} "${@}"
>
> [[ ${#} -lt 2 ]] && die "Usage: ${FUNCNAME} ..."
> local base=${1} f
> shift
>
> for f; do
> dosym "${base}" "$(_bash-completion-r1_get_bashcompdir)/${f}" \
> || return
> done
> }
> +
> +_BASH_COMPLETION_R1_ECLASS=1
> +fi
> --
> 2.32.0
>
>
signature.asc
Description: PGP signature
[gentoo-dev] Last rites: net-proxy/polipo
# John Helmert III (2021-07-14) # Dead upstream, unfixed security issue. # Removal on 2021-08-13. Bugs #755896, #781467. net-proxy/polipo signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-misc/netkit-rsh
# John Helmert III (2021-06-19) # Unmaintained, open security bug. # Removal on 2021-07-19. Bug #717794. net-misc/netkit-rsh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Repository configuration file (layout.conf)
On Wed, May 19, 2021 at 02:32:27PM +0200, Michał Górny wrote: > Hi, > > Please review the pre-GLEP inlined below. Its purpose is to formally > define the format of layout.conf. It's pretty much inevitable these > days, so we should specify it. However, it doesn't really fit into PMS, > and other formats (Manifests, metadata.xml) are already defined > in GLEPs, so this just follows suit. > > Pre-GLEP follows. > > --- > GLEP: > Title: Repository configuration file (layout.conf) > Author: Michał Górny > Type: Standards Track > Status: Draft > Version: 1.0 > Created: 2021-05-19 > Last-Modified: 2021-05-19 > Post-History: 2021-05-19 > Content-Type: text/x-rst > --- > > Abstract > > > The ``metadata/layout.conf`` file format is specified as used by Portage > and PkgCore. A standard set of configuration keys is described I can't speak for pkgcore but I can't find anywhere this capitalization scheme is used. Internally and in its docs it seems 'Pkgcore' is used at the beginning of sentences, but generally 'pkgcore' is used. > including the keys currently used in the Gentoo repository. > > > Motivation > == > > The ``metadata/layout.conf`` file was first added to the Gentoo > repository in Oct 2011, to facilitate setting of hashes used > in Manifest2 files. In Mar 2012, it was used to indicate the transition > to the new ``md5-dict`` cache format. In Jul 2013, it started being > used to indicate the repository's masters and effectively became > obligatory for all repositories. > > Today, ``layout.conf`` is used for various repository configuration > knobs that can be expressed as simple values and therefore > do not justify adding new files to the repository. This primarily > involves the configuration of development tools but also includes a few > keys relevant to the behavior of the package manager. > > However, ``layout.conf`` is currently not covered by any formal > specification. The PMS neglects its existence entirely, and the keys > used are roughly defined by their first use of Portage or PkgCore. > This GLEP aims to overcome this by providing a formal specification > for the file, as well as an up-to-date list of permitted configuration > keys. > > > Specification > = > > layout.conf file format > --- > > Every ebuild repository must contain a ``metadata/layout.conf`` file. > The file uses a line-oriented text format. Lines starting with ``#`` > represent comments and are ignored, as are lines consisting entirely > of whitespace. The remaining lines must contain a key followed > by equals sign (``=``), followed by a (possibly empty) value. Each of "...followed by zero or more space separated values" would be better I think. Currently it reads like only one value is allowed. > these elements can be surrounded by additional whitespace that > is stripped. > > > Configuration keys > -- > > The ``layout.conf`` file must contain the ``masters`` key. Other keys > listed in this specification are entirely optional. The package > managers may choose to implement a subset of listed keys. Unknown keys > must be ignored. > > The following keys are currently defined: > > masters = > Specifies the master repositories of this repository. For stand-alone > repositories, this must be set to an empty value. Otherwise, it can > list one or more repositories, separated by spaces. This key must > be specified. > > manifest-hashes = > Specifies the list of hashes that should be used for new distfiles > in the Manifest files. The development tools may create a subset > of the specified hashes if it is not updating the checksums for > the specified distfile, or does not support the hash in question. > The hash names are specified in GLEP 74. [#GLEP74]_ The default > set of hashes is implementation-defined. > > manifest-required-hashes = > Specifies the list of hashes that must be used in Manifest files. > The development tools must support all the hashes listed there, > and update distfile checksums to use these hashes (refetching > if necessary). This must be a subset of manifest-hashes. If not > specified, all hashes from manifest-hashes (or the default set) > are considered required. > > use-manifests = ``strict``, ``true`` or ``false`` > Indicates the policy for creating and using Manifest files. If set > to ``strict``, Manifest files are created and files are required to > match digests found in Manifests. If set to ``true``, Manifests > are created but digest mismatches are ignored. If set to ``false``, > Manifests are not used at all. The default is ``strict``. > > update-changelog = ``true`` or ``false`` > Indicates whether the development tools should write ChangeLog files. > The default is ``false``. > > cache-formats = > Specifies one or more cache formats used by the repository. > The currently defined values are ``pms`` for the original
