[gentoo-dev] [PATCHv3] 2021-11-23-mariadb-database-restore-maybe-required: add item
Bug: https://bugs.gentoo.org/825234 Signed-off-by: Thomas Deutschmann --- ...adb-database-restore-maybe-required.en.txt | 45 +++ 1 file changed, 45 insertions(+) create mode 100644 2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt diff --git a/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt new file mode 100644 index 000..c977ae7 --- /dev/null +++ b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt @@ -0,0 +1,45 @@ +Title: Full MariaDB database restore maybe required +Author: Thomas Deutschmann +Posted: 2021-11-23 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-db/mariadb +Display-If-Installed: sys-cluster/galera + +On 2021-11-21, keywords for dev-db/mariadb:10.6 were removed to +address a file collision with dev-db/mariadb-connector-c. This +unintentionally triggered a version downgrade for users who had +successfully upgraded to dev-db/mariadb:10.6 already. [Link 1]. + +However, downgrades are not supported in MySQL/MariaDB [Link 2]. + +In case you already fully upgraded to MariaDB 10.6 (which includes +executing mysql_upgrade command) and unintentionally downgraded your +MariaDB instance afterwards during the time window when keywords were +removed, you maybe experiencing different problems: + +At best, your unwanted downgraded MariaDB instance prevented startup +so all you have to do is upgrade to MariaDB 10.6 again to resume +services. + +In case previous MariaDB version was able to start, you are encouraged +to do a full backup as soon as possible using mysqldump command and +manually restore each database ("logical downgrade") to prevent any +data corruption. + +Depending on used feature set and from which version you upgraded, +it is maybe required to do a full restore from a previous backup before +MariaDB 10.6 upgrade to restore services and prevent any data loss or +future runtime errors. + +In case you are using MariaDB in a cluster and/or Galera setup you +probably have to rebuild the entire cluster in case the upgrade to +MariaDB 10.6 was already replicated (using pt-table-checksum from +dev-db/percona-toolkit can help you to validate your cluster). + +Keep in mind that due to the downgrade, point-in-time recovery may +not be available to the extent that you are used to. + +Link 1: https://bugs.gentoo.org/825234 + +Link 2: https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/ -- 2.34.0
[gentoo-dev] [PATCHv2] 2021-11-23-mariadb-database-restore-maybe-required: add item
Bug: https://bugs.gentoo.org/825234 Signed-off-by: Thomas Deutschmann --- ...adb-database-restore-maybe-required.en.txt | 45 +++ 1 file changed, 45 insertions(+) create mode 100644 2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt diff --git a/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt new file mode 100644 index 000..5d8afda --- /dev/null +++ b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt @@ -0,0 +1,45 @@ +Title: Full MariaDB database restore maybe required +Author: Thomas Deutschmann +Posted: 2021-11-23 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-db/mariadb +Display-If-Installed: sys-cluster/galera + +On 2021-11-21, keywords for dev-db/mariadb:10.6 were removed to +address a file collision with dev-db/mariadb-connector-c. This +unintentionally triggered a version downgrade for users who had +successfully upgraded to dev-db/mariadb:10.6 already. [Link 1]. + +However, downgrades are not supported in MySQL/MariaDB [Link 2]. + +In case you already fully upgraded to MariaDB 10.6 (which includes +executing mysql_upgrade command) and unintentionally downgraded your +MariaDB instance afterwards during the time window when keywords were +removed, you maybe experiencing different problems: + +At best, your unwanted downgraded MariaDB instance prevented startup +so all you have to do is upgrade to MariaDB 10.6 again to resume +services. + +In case previous MariaDB version was able to start, you are encouraged +to do a full backup as soon as possible using mysqldump command and +manually restore each database ("logical downgrade") to prevent any +data corruption. + +Depending on used feature set and from which version you upgraded, +it is maybe required to do a full restore from a previous backup before +MariaDB 10.6 upgrade to restore services and prevent any data loss or +future runtime errors. + +In case you are using MariaDB in a cluster and/or Galera setup you +probably have to rebuild the entire cluster in case the upgrade to +MariaDB 10.6 was already replicated (using pt-table-checksum from +dev-db/percona-toolkit can help you to validate your cluster). + +Keep in mind that due to the forced downgraded, point-in-time recovery +may not be available to the extent that you are used to. + +Link 1: https://bugs.gentoo.org/825234 + +Link 2: https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/ -- 2.34.0
Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item
On 2021-11-25 18:01, Piotr Karbowski wrote: https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/glibc-2.34-r2.ebuild#L643 Would you see something like this on more ebuilds, postgres, mysql, elasticsearch, or have proper FEATURE flag for it instead? It's all cool and giggles until you realize that even such random variable is not even prefixed with PORTAGE_ or anything, meaning it could be taken out of shell and meant for entirely different thing. Yeah, sounds like the I_KNOW_WHAT_I_AM_DOING thing which you end up having enabled globally for various reasons. But thank you Pacho. This is indeed a good suggestion and we will have a look how we can improve (there is also some work happening upstream: dev-db/mysql-8+ for example removed mysql_upgrade command and will take care of everything by itself and prevent startup when it detects a downgrade and there is some discussion for such a feature for 10.7 (probably too late) or 10.8). -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] profiles: mask sys-fs/eudev for removal
Hi, why do you want to drop the package? Since news item, upstream changed. There will be a new release soon. Was this just on your list to finish or is there another reason? I am currently watching upstream and would wait to see if they really do the release and keep up with the promise. We can still last-rite next quarter, not? -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item
Hi, On 2021-11-25 04:49, Mike Gilbert wrote: On 2021-11-21, keywords for dev-db/mariadb-10.6 were removed to address a file collision with dev-db/mariadb-connector-c. This unintentionally triggered a version downgrade for users who had successfully upgraded to dev-db/mariadb-10.6 already. Works for me. However, I would write dev-db/mariadb:10.6. Is that acceptable for you? I don't like the phrase "forcefully downgraded" here. This implies that something happened without the user's consent. emerge would have informed them of the downgrade before it happened. I would suggest removing the word "forcefully" from these paragraphs. If you do a normal world upgrade, this is the default portage behavior, not? I.e. package manager will downgrade if you don't stop. And especially on servers, people tend to use cronjobs/scripts to do that... And forcefully here refers to the undesirable result (at least that was my intention). Something the user doesn't want. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item
For the records: I hope that this news item won't get delayed by the recent ComRel bug someone filled against me regarding this news item. While we often rush with news items and don't wait the 72h listed in GLEP 42, this one should go out as soon as possible. Why? Because every minute we wait will increase the chance that someone affected by this will be unable to recover. This is (for those not familiar with database engines) because bin logs are about to expire (getting overwritten) in typical setups after 3-5 days. And in case someone will learn about this not before next week and has to do a full restore, that user will lose about one week of data... Just saying. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item
Bug: https://bugs.gentoo.org/825234 Signed-off-by: Thomas Deutschmann --- ...adb-database-restore-maybe-required.en.txt | 46 +++ 1 file changed, 46 insertions(+) create mode 100644 2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt diff --git a/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt new file mode 100644 index 000..c4a698e --- /dev/null +++ b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt @@ -0,0 +1,46 @@ +Title: Full MariaDB database restore maybe required +Author: Thomas Deutschmann +Posted: 2021-11-23 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-db/mariadb +Display-If-Installed: sys-cluster/galera + +On 2021-11-21, a member of the QA project accidentially de-keyworded +MariaDB 10.6 to address a file collision, users, who also had latest +dev-db/mariadb-connector-c installed, experienced (NOTE: The default +MySQL connector in Gentoo Linux is provided by +dev-db/mysql-connector-c) [Link 1]. + +However, downgrades are not supported in MySQL/MariaDB [Link 2]. + +In case you already fully upgraded to MariaDB 10.6 (which includes +executing mysql_upgrade command) and forcefully downgraded your +MariaDB instance afterwards during the time window when keywords were +removed, you maybe experiencing different problems: + +At best, your forcefully downgraded MariaDB instance prevented startup +so all you have to do is upgrade to MariaDB 10.6 again to resume +services. + +In case previous MariaDB version was able to start, you are encouraged +to do a full backup as soon as possible using mysqldump command and +manually restore each database ("logical downgrade") to prevent any +data corruption. + +Depending on used feature set and from which version you upgraded, +it is maybe required to do a full restore from a previous backup before +MariaDB 10.6 upgrade to restore services and prevent any data loss or +future runtime errors. + +In case you are using MariaDB in a cluster and/or Galera setup you +probably have to rebuild the entire cluster in case the upgrade to +MariaDB 10.6 was already replicated (using pt-table-checksum from +dev-db/percona-toolkit can help you to validate your cluster). + +Keep in mind that due to the forced downgraded, point-in-time recovery +may not be available to the extent that you are used to. + +Link 1: https://bugs.gentoo.org/825234#c8 + +Link 2: https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/ -- 2.34.0
Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval
On 2021-11-11 11:59, Ulrich Mueller wrote: We could: - Open some part of the range between 500 and 1000. For example, 500..799, which would leave 200 IDs for dynamic allocation. - Open part of the range 60001..65533. Not sure if all software will be happy with that. - Admit that the concept of static allocation has failed, and return to dynamic allocation. Only the third option is really possible. The first option (500-1000) would be technically possible but would clash with knowledge people gained in the past and would violate LPIC (=making Gentoo even more special and unusable for companies relying on certifications). In addition, it would just delay the problem we currently have and not solve/address it. Allowing ranges 60001+ is technically not an option. Expect that daemons using IDs >1000 will run into problems. Expect security problems because known system user range is hardcoded in many places so 60001+ is unexpected. This will really make Gentoo 'unique' in a really bad way and will break with everything which is/was being taught/documented in the world. Let's face it: The idea of static ID allocation didn't scale. Let's stop this experiment before it is too late. Like you know, I always ask why someone is proposing a change, i.e. asking for the motivation. The main driver behind static IDs was that when you are maintaining multiple systems, that if IDs are identical, it will make life a little bit easier because you could copy files from service A on system 1 to service A on system 2 without the need of adjusting permission afterwards. But is this really a problem? From my POV it isn't: 1) If this really was bothering you, you already had a solution in place. Keep in mind: Most setups don't just consist of Gentoo/Debian/RHEL-only... you usually have a mix of setups so you need a solution which works everywhere so you don't need that 'feature' Gentoo offered (not to mention that you probably have something like AD in place which will make things like that very easy). 2) Pay attention to the way how you do stuff today. You will not create systems manually anymore (and if you do, you would just clone so there isn't even a need for this). You will automate this in scripts and use tools like Ansible, Salt, Chef, Puppet and of course, Dockers (which is basically a script) and like mentioned, AD. From my POV I cannot imagine a single reason why we should stick to this idea and invest more time into it with the risk of making Gentoo more unique causing more _severe_ problems in future. Anyone who wants to keep this around and wants to extend UID ranges instead should answer the following questions: 1) How are you going to solve the mentioned problems? 2) Why do you believe this feature is worth all the trouble? 3) At the moment we can stop. But once we start altering systems to mark additional ranges for system users there is _no_ easy way back anymore. Any blow up will probably require user to reinstall their entire system... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
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"... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
f the --backtrack option, such as --backtrack=30, in order to see if that will solve this conflict automatically. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. !!! The following installed packages are masked: - sys-devel/binutils-2.35.2::gentoo (masked by: package.mask) /var/db/repos/gentoo/profiles/package.mask: # Andreas K. Hüttel (2017-05-21) # (and others, updated later) # These old versions of toolchain packages (binutils, gcc, glibc) are no # longer officially supported and are not suitable for general use. Using # these packages can result in build failures (and possible breakage) for # many packages, and may leave your system vulnerable to known security # exploits. # If you still use one of these old toolchain packages, please upgrade (and # switch the compiler / the binutils) ASAP. If you need them for a specific # (isolated) use case, feel free to unmask them on your system. - sys-libs/glibc-2.32-r7::gentoo (masked by: package.mask) - virtual/perl-Pod-Parser-1.630.0-r8::gentoo (masked by: package.mask) /var/db/repos/gentoo/profiles/package.mask: # Andreas K. Hüttel (2021-10-16) # Outdated virtual; the respective module was removed # from core Perl with Perl 5.32. Use dev-perl/Pod-Parser # instead. Removal in 30days. For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. Python: # grep -Fr TARGETS /etc/portage /etc/portage/make.d/PHP.conf:#PHP_TARGETS="php5-6 php7-0 php7-1 php7-2 php7-3" /etc/portage/make.d/RUBY.conf:#RUBY_TARGETS="ruby22 ruby23" /etc/portage/make.d/RUBY.conf:RUBY_TARGETS="ruby25 ruby26" /etc/portage/make.d/PYTHON.conf:#PYTHON_TARGETS="python2_7 python3_7" /etc/portage/make.d/PYTHON.conf:#PYTHON_TARGETS="python3_7 python3_8" # portageq envvar PYTHON_TARGETS python3_9 # portageq envvar PYTHON_SINGLE_TARGET python3_9 (no packages are manually set to a different Python version) 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. Situations like this will disqualify Gentoo for any professional environment like this will break automatic upgrades and you cannot roll individual fixes for each possible situation via CFM tools like Salt, Ansible, Puppet or Chef. It would be very appreciated if everyone will pay more attention to this in future. We can do better. In most cases we can avoid problems like this by keeping older ebuilds around much longer for certain key packages to help with upgrades. Thank you. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
On 2021-10-21 17:16, Mike Gilbert wrote: On Thu, Oct 21, 2021 at 4:05 AM Michał Górny wrote: 4. In the end, Security team isn't really respecting this policy. In the end, this leads to absurdities like GLSA being released before a package is stable on amd64, and confusing the users [4]. This is certainly an absurd mistake, but I think it is unrelated to the topic of your message. It looks like Whissi jumped the gun on releasing a GLSA, which could happen regardless of the policy. Am I missing some context? Yeah, #4 is bullshit. The security team was never happy with the situation to hold back GLSAs until last architecture was marked stable. Saying that we are not respecting our own own policy is absurd. The team discussed this in 2018 and we agreed that it is fine to already publish a GLSA in case a GLSA is ready and when at least one major architecture (amd64 or x86 at that time) was marked stable. That exception doesn't require a formal policy update. We even wanted to go one step further and release GLSA when no fixed version is available at all to inform users and give them a chance to take actions on their own (to be able to take actions on your own, i.e. you first need to be aware of a problem). However, this would be too complicated and would frustrate many users. The lived practice with releasing GLSA already when just one major architecture has set stable keyword (and in most cases we covered amd64 and x86 at release time) received good feedback and is accepted by users and didn't cause any problems (can't remember that we ever got GLSA feedback for other architectures than amd64 or x86). -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
On 2021-10-18 19:07, Michał Górny wrote: Security team arbitrarily deciding that an architecture is unsupported while otherwise it's supported in Gentoo doesn't change anything. Sure, you can close bugs and pretend that a problem doesn't exist... except that you can't if you can't remove the old version because of keywords. You won't see me defending the idea of allowing stable architectures without security support (this was before I joined Gentoo and I never liked it). But this is what we have for more than 10 years now. However, this was never an arbitrary decision. It was something between arch teams and security project but in the end it was always the arch team's decision because they are the ones doing the work (like "Sorry, we cannot keep up..." -"Well, that's bad but now we have to deal with that"). Anyway, I think we are losing focus on topic. I am still waiting for Marecki to answer the motivation behind this. And to quote you: Sure, you can close bugs and pretend that a problem doesn't exist Sadly, you can say the same for dropping stable keywords (and I think we are not that far away if I understand [1] correctly), not? That's why I asked for the motivation behind this and what people are expecting to become better/what problem will be solved after that change. We haven't yet talked about the risk of broken deptrees because some tooling will ignore non-stable architectures by default. [1] https://archives.gentoo.org/gentoo-dev/message/a3c7a6cb7596a5ff9102e4d819a52d9c -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
On 2021-10-18 03:08, John Helmert III wrote: 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. Excuse me? How is this possible? We have that Gentoo Vulnerability Treatment Policy and HPPA isn't listed in supported architectures. That problem was resolved in 2018 [1]. [1] https://archives.gentoo.org/gentoo-announce/message/196e45cde209d1ed25bd42e679739cf5 -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
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)? I am really curious what you are going to expect to change by this keyword change and why you want to change current status at all (motivation). -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On 2021-08-08 13:17, David Seifert wrote: So you've created a big commotion... because you didn't get the initial point? Honestly, this seems to be a recurring theme at this point. Someone suggests some improved check/some change, and nowadays you can bet 50 quid that Whissi will pop up and bikeshed it in some way. No? First of all, just because you disagree with something or believe a discussion is wrong and or not necessary and start to frame it as bikeshedding, it doesn't actually become bikeshedding. This is a very sad and transparent attempt to silence people through defamation. The draft contains an error. It's saying that "/etc/tmpfiles.d" became deprecated which is not true. Because this would imply that it was previously acceptable for packages in Gentoo repository to install to that location which is not correct. If a packages in ::gentoo installed to /etc/tmpfiles.d before, this was already wrong. And my point was and still is, that neither the commit message nor the eqawarn should use the wording "deprecated" because nothing has changed -- no location became deprecated. And this will also address parts of antarus' previous mail: Because this QA check should be only about ::gentoo repository, this shouldn't affect any other repository. I.e. in your own overlay, you are free to do whatever you want and can't be forced to stick to Gentoo QA rules. It's become a real problem at this point. In fact, we have proxy maintainers publicly refusing to work on packages somehow involving you (I'll mention no names, but check the #-desktop backlog), because your personality boils down to three attributes nowadays: I am not in that channel and never was. If you make such an allegation, include facts so that I can respond. If you look at my complete history at GitHub issues you will find that most people I worked with appreciated to work with me. Of course there are some bugs/PRs where I rejected a requested change but I am not sure what your point is. This is normal because not every PR is valid. 1. If I say the sky is blue, you'll say it's green. If I say it's green, you'll say it's blue. I've had at least 5 people tell me they see the exact same pattern in you (and no, mgorny is not part of that set, before you throw that point at me). You're the textbook contrarian of Gentoo ("Wutbürger") right now. 2. You'll tell people they are wrong, they aren't following protocols, they made a mistake, but you will never follow through with actually telling people what/why or how. By the time people ask you "why?", you've already disappeared. Given how frequently this happens in multiple channels, projects and at different time points, statistically, this can't be explained by coincidence any more. This happens practically on a daily basis, so you're not getting the benefit of the doubt any more. 3. You can't let go. The security elections disaster right now is the prime example (yes, it's public, just check the history of the Security Project). This captures you so well: it's all about **community** and stuff, until you lose, then you start invoking technicalities and procedural shenanigans to justify some ludicrous kind of "co-lead" crap. Frankly, it's embarrassing, and you're at the centre of it. Instead of accepting defeat (remember, community and democracy!), you just fudge the results. Interesting. You don't even now my view on this but you already have an opinion and are saying that I am the culprit. I think this is called "prejudiced". I am pretty sure that as a ComRel member you will abstain from this case as you seem to be superior. I mean you are publicly attacking me for 10+ months, rejected any attempt from my side when I tried to speak with you to get things sorted and now you showed how biased your are... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On 2021-08-04 04:56, Sam James wrote: Sure, thanks for the clarification. It's deprecated in the sense of ebuilds installing to it though, right? Well, it triggered me because saying it's deprecated implies two things for me: 1) It was OK for packages to do that in the past 2) Something has changed upstream Regarding 1) It was never OK for packages to install in that location. That will break the override mechanism systemd introduced. I.e. packages were and are still only allowed to install below /usr (/lib), to allow local system administrators to override installed unit/tmpfiles spec by placing a file with the same name in the corresponding directory in /etc. Regarding 2) Nothing has changed upstream regarding these locations. I personally hope that this QA check will never fire in hope we never added an ebuild doing something like that but in the end, that's the idea of having such a check: To notice something like that, just in case ;-) -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On 2021-08-01 01:56, Sam James wrote: 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which is a deprecated location; This location is _not_ deprecated. This is the location for the local system administrator to override tmpfiles.d specifications installed by packages which should install below /usr. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] 2021-08-01-tcpd-disabled: Remove USE=tcpd from make.defaults
On 2021-07-27 16:07, Ulrich Mueller wrote: +Display-If-Installed: net-analyzer/argus-clients IIUC this won't affect users who have already disabled the flag, so maybe add a [tcpd] use dependency here (and to all other Display-If-Installed lines below)? Looks like we cannot target USE flags in GLEP 42 news items: # equery uses mail-mta/postfix | grep cdb -cdb # eselect news list News items: [...] [20] 2021-07-23 migrating from glibc[crypt] to libxcrypt in ~arch # eselect news unread 20 Add Display-If-Installed: mail-mta/postfix[cdb] to /var/db/repos/gentoo/metadata/news/2021-07-23-libxcrypt-migration/2021-07-23-libxcrypt-migration.en.txt # emerge -p mail-mta/postfix [...] > * IMPORTANT: 1 news items need reading for repository 'gentoo'. > * Use eselect news read to view new items. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 2021-07-25 08:27, Michał Górny wrote: On Sun, 2021-07-25 at 01:12 +0200, Thomas Deutschmann wrote: I don't understand. Isn't it the same motion we put down just 2 months ago [1]? Or is this something new? If this isn't something new, what has changed since May [2]? Apparently it has not been 'put down' because it came back via open bugs. Open bugs? Could you please link them here? To remember: Currently we have two different hashes for every distfile. If we are going to throw this data away, we should really have good reasons to do that. Like said during that council meeting, BLAKE2B and SHA512 are competing hashes. What's wrong with having a backup plan even for a very unlikely scenario, that BLAKE2B will get broken? Define 'broken'. To quote from chapter 9 of the Handbook of Applied Cryptography, by Menezes, van Oorschot and Vanstone: If, for a given hash function, an attack is found, which, by exploiting special details of how the hash function operates, finds a preimage, a second preimage or a collision faster than the corresponding generic attack, then the hash function is said to be "broken". This happened publicly for SHA1 in 2017. Remember that verify-sig.eclass I criticized last year? Of course some scenarios I outlined were very unlikely and I never expected that I can run around in near future saying "I told you". But in January 2021, CVE-2021-3345 happened in libgcrypt... I don't see how this is relevant either. Are you admitting that you're criticizing all my ideas because I just happen to propose them? No, I am not criticizing ideas because *you* proposed them. I share my criticism when I have some concerns or believe the proposal has some flaws. You maybe have that impression because you are very active and most proposals are coming from you. In the end, we both are hopefully sharing the same goal to make Gentoo better... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
Hi, I don't understand. Isn't it the same motion we put down just 2 months ago [1]? Or is this something new? If this isn't something new, what has changed since May [2]? To remember: Currently we have two different hashes for every distfile. If we are going to throw this data away, we should really have good reasons to do that. Like said during that council meeting, BLAKE2B and SHA512 are competing hashes. What's wrong with having a backup plan even for a very unlikely scenario, that BLAKE2B will get broken? It's not like SHA512 is requiring any additional deps which are unmaintained or something like that. SHA has even hardware acceleration support in modern systems. In addition it is even more likely that you will find SHA checksum files with upstream release tarballs than BLAKE2B files. Remember that verify-sig.eclass I criticized last year? Of course some scenarios I outlined were very unlikely and I never expected that I can run around in near future saying "I told you". But in January 2021, CVE-2021-3345 happened in libgcrypt... So again: Why should we throw the data we currently have away and put Gentoo unnecessarily at risk that we will end up without hashes because the only hash algorithm we used became broken and given that we will be unable to re-hash every file in a timely manner (remember how long it took to get a BLAKE2B hash for every file)? See also: = [1] https://bugs.gentoo.org/784710 [2] https://projects.gentoo.org/council/meeting-logs/20210509.txt -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
Hi, it's not clear to me what will be the consequences of this change. I am expecting good faith and that nobody will add an ebuild with deprecated EAPI just for fun or because maintainer prefers retro stuff. So looking at the reasons to bump without touching EAPI: a) Because of a changing dep/add slot operator b) Because of a security vulnerability. c) Other critical fixes which should reach users ASAP. In addition, all of this could happen by non-primary maintainer of the package. In case such a change would force anyone who is touching the ebuild to also fix the ebuild itself and migrate to latest EAPI -- even non-primary maintainers -- this would be far away from any reality and would cause pain for users in the end because people wouldn't touch these packages anymore. Keep in mind: Even if you are the primary maintainer, if you have foo-1.2.3 (stable for a while but using deprecated EAPI) and upstream just released foo-2.0 (a complete rewrite after 10 years, not yet ready for stabilization but added with latest EAPI) and you would now need to fix something critical in v1.2.3, this would be impossible because adding a patch/change deps is one thing, making an EAPI change _will_ require more testing which will prevent fast stabilization (remember when trailing slash behavior changed when we had no QA/CI checks able to catch most (still not all!) problems caused by incomplete EAPI bumps which had real impact when those ebuilds were merged to disk). If the above will be still allowed (and I believe it *must* be still allowed), we cannot get rid of step 2 -- we will need exemptions. I would really like to understand why people in Gentoo believe we should eliminate step 2 and also start enforcing policy. I agree with the latter: If we create a rule which isn't enforceable, it's not a rule and we shouldn't create it as such. But in this case, like said, I believe we need the exemptions, which makes it impossible to enforce something, so we cannot create a (new) policy in first place. But is it really a problem? Is such a new policy really needed? Are people really pushing lots of ebuilds with EAPIs we already marked as deprecated? If it is a real problem, do we actually have information why maintainers are doing that? Trying to understand why someone keeps using deprecated EAPI could help more like a policy which is more likely to cause more stale packages/ignored bugs assuming these maintainer didn't do that for fun or wilful ignorance. At the moment, the whole idea of creating a policy for that problem sounds like shooting sparrows with cannons. But maybe I am missing something... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
Hi, TL;DR: Given that William said in the meanwhile, he sees no future for opentmpfiles [1] and that nobody else, including me, is interested in stepping up, things have changed. Please start with the normal last-rite process and please please please, rephrase the news item and do not tell world that opentmpfiles has been masked due to the reported vulnerability because this would be wrong. The package was masked due to a miscommunication with the Gentoo Security project. While it is true that the way opentmpfiles is currently implemented allows for certain races, from the security point of view, you always have to classify the vulnerability in context of your threat model because security depends on multiple layers (onion model). First, we have to take tmpfiles.d specifications into account: By default, opentmpfiles service is only reading from certain locations (for example /usr/lib/tmpfiles.d) – all of these locations are only writable for root user by default which makes it impossible for an attacker to create a controllable exploit. Furthermore, tmpfiles.d settings are only supposed for creation, deletion and cleaning of volatile and temporary files. Any package which will install tmpfiles.d settings which will create files in persistent locations should be treated like a bug in the package itself (for Gentoo packagers for example we have keepdir [3] function). Same is true for packages installing tmpfiles.d settings which will create volatile and temporary directories in user writable locations, which is usually treated like a weak file permission vulnerability in the package, similar to world-writable PID files, config files, log locations etc. Despite all the outlined pre-requirements, an attacker would still need to convince the system administrator to restart a boot service which is very uncommon and even OpenRC is warning against doing something like that. opentmpfiles specifically starts before any other services, so a compromised daemon is not capable of injecting a malicious symlink before startup: $ /lib/rc/bin/rc-depend opentmpfiles-setup sysfs devfs udev udev-trigger hwclock modules fsck root localmount opentmpfiles-setup Finally, in Gentoo Linux, like in many other distributions, from security point of view, we assume certain preconditions like running with "fs.protected_symlinks" and "fs.protected_hardlinks" enabled by default since baselayout-2.7 [4] which largely mitigates symlink attacks. (These sysctls don't affect CVE-2017-18925, but they do affect the other reported opentmpfiles CVEs, and it's worth mentioning them as examples of configuration we have to assume.) Therefore, Gentoo's security project does not believe that it is required to mask this package in Gentoo Linux for security reasons because our classification from 2017 has not changed and we usually do not mask any package with flaws which cannot be exploited in default configuration and would require discouraged settings like disabled fs.protected_symlink feature, or adjusting e.g. OpenRC's runlevels/configuration in an unsupported way. Thank you. See also: = [1] https://archives.gentoo.org/gentoo-dev/message/bce91b9d37db0b1e0980eb923a8607c9 [2] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html [3] https://devmanual.gentoo.org/function-reference/install-functions/ [4] https://bugs.gentoo.org/704914 -- Regards, Thomas Deutschmann / Gentoo Security Team fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] 'pax_kernel' USE flag
On 2021-07-07 05:05, Matt Turner wrote: On Tue, Jul 6, 2021 at 7:41 PM Thomas Deutschmann wrote: As you probably know, I am not a Linux desktop user (yet). My complete experience with that PaX stuff is limited to servers. Maybe I've misunderstood what you meant. You don't use Linux on the desktop? But, you maintain Firefox? I'm definitely confused :) No, I became Firefox maintainer by accident via security project when former devs weren't available and I started to help out. I actually bought a notebook a few years ago just to be able to do more testing (I have a lot of experience with Selenium where I am using the browser in headless mode but when you want to improve desktop integration...). This also enabled me to become a test user for leio's GNOME 3.30 work which was a great experience. My Gentoo desktop usage has increased a lot since then but Linux still isn't my *primary* desktop platform (yet). -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] 'pax_kernel' USE flag
On 2021-06-23 08:43, Matt Turner wrote: On Tue, Jun 22, 2021 at 3:19 PM Thomas Deutschmann wrote: The PaX community in Gentoo is still big and active. Many Gentoo users received free access to upstream sources or became paying customers. It's just not available for everyone for free/without registration anymore. But it is still a thing in Gentoo. Can you substantiate that claim? I am probably not the right person to answer that, given that I was never active in Gentoo's hardened/PaX project but let me try: When I got in touch with that stuff (via Debian) and was looking for help, I always run into a community full of helpful Gentoo users. The project itself always had a very good connection with the Gentoo project. Before they stopped providing unrestricted access, the Gentoo PaX/hardened community was around ~30 *active* people with additional ~40-60 changing people hanging around which I believe is a lot for such a niche. That's why upstream also mentioned Gentoo in https://grsecurity.net/passing_the_baton.php. Regarding numbers: I am not sure what you are expecting. All I can tell you is that people who were active, interested and probably known to upstream had the chance to get free access for their personal use (there was even an offer for Gentoo infrastructure...). I don't know how many are still using Gentoo. There was a pax-kernel USE flag on Mesa and I don't recall anyone saying a word when I removed it. As you probably know, I am not a Linux desktop user (yet). My complete experience with that PaX stuff is limited to servers. If there are paying customers that have PaX kernels, perhaps they'd be interested in providing some support for Gentoo if we're being asked to retain support for something we cannot test. Yeah, would be nice to hear something from Gentoo hardened project at all (I am looking at you, mschiff, zorry or blueness ;)). I think slashbeast could also provide more information. I still remember when I reworked firefox/thunderbird ebuild and broke PaX marking there (https://bugs.gentoo.org/756679). So yes, we have at least some users ;-) -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] 'pax_kernel' USE flag
FYI: The PaX community in Gentoo is still big and active. Many Gentoo users received free access to upstream sources or became paying customers. It's just not available for everyone for free/without registration anymore. But it is still a thing in Gentoo. So I wonder, how is the status of PaX support in the packages listed above? I can only speak for icedtea and nodejs which are working fine. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Should we switch IRC client defaults off Freenode?
On 2021-06-16 11:13, Michał Górny wrote: 1. Should we be proactively changing the default network in IRC clients (provided they have one) from Freenode to Libera.chat? 1a. If yes, then should we also make a change if clients default to network other than Freenode? Adding *our* network in case Libera.chat is missing, is one thing. Like adding branding for Gentoo. But imagine the project behind the IRC client is located on EFnet and therefore they are defaulting their client to EFnet, we shouldn't mess with that because of the Freenode drama. There should be a separate discussion if we should add Gentoo branding by default to *every* package where possible in which case we can think about it. 2. Should we be proactively *removing* Freenode from the network list in IRC clients (provided they have one)? No. Don't become part of a cancel culture where you disagree with someone and start to fight your enemy. We moved and are done with freenode. Gentoo is about choices. Our users should therefore be able to decide on their own. No need to make it harder to connect to a network we moved away from. And keep in mind: *Not* everyone has moved away from freenode, that's also part of the truth. And we shouldn't judge projects still located on freenode. 2a. Should we be adding Libera.chat to the list even if we do not remove Freenode? See 1. Quick recap for people that haven't been following the news or got confused in the lots of data: 1. Freenode was sold in 2017 to some guy who apparently wasn't supposed to interfere with its operations. 2. In 2021, the guy actively started to interfere, then formed a one-man Board and demanded full compliance. The problem with a summary like that is, that you only present one view. I.e. the view of the "winner" (history is written by the victors). But part of the drama is that freenode owner said he was forced to take actions for legal reasons (new owner is held liable for whatever his staff is doing) after former staff refused to cooperate. 5. New Freenode staff (including some disreputable types) went angry about this and started automated reclamation of channels that indicated move to another network (including some channels that didn't because they failed at grep). You could also have a different view on that: We (like many others) started to violate their TOS. It does not matter whether or not they created these TOS retrospectively: It's a proprietary/privately owned service. They can do whatever they like whenever they like. And they just did that. No question, an unpleasant move from our POV. But I know that many people don't like to hear or believe for some reasons that this could never happen to other services -- but this can happen at any time to our presence at Github and even what happened with freenode could happen with Libera.chat again. Both are proprietary and in the end privately owned. They can change rules without asking us and without even considering our interests. Just imagine unknowing Gentoo users having their systems compromised through advice from trolls pretending to be Gentoo developers. True. But this can happen wherever people talk about Gentoo. Even in our forums, mailing lists or official IRC channels. I would recommend everyone to relax a little bit. There will always be some imperfect situations like that we cannot control. We shouldn't start to overreact. Like we say, "Gentoo is about choice", have some faith in our users to deal with that. Gentoo is done with freenode, we migrated away. There is no need for us take additional actions against freenode. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Should we switch IRC client defaults off Freenode?
On 2021-06-16 13:28, Michal Prívozník wrote: Why should we mangle with packages this way? I mean, to me Gentoo was one of the few distros that allowed real choice for users (systemd vs openrc, selinux or !selinux, etc.). We shouldn't be making choices on behalf of users. The best we can do is to open issues for whatever IRC client we have in portage to switch from freenode to something different. BTW: not everybody is switching from freenode to libera.chat. I second that. Adding *our* network is one thing, like adding branding, but removing stuff we don't like is going to far. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-emulation/xen-pvgrub
# Tomáš Mózes (2021-06-10) # Based on unsupported grub-legacy, replaced by # pvgrub2. # Removal on 2021-07-08. Bug #790668. app-emulation/xen-pvgrub -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] News item: sys-libs/db old SLOT removal
On 2021-05-27 00:41, David Seifert wrote: Furthermore, the Gentoo Base System Team has decided to consider sys-libs/db a deprecated database backend. Uh? When did that happen? While there is no development happening anymore in old versions, 5.3 is feature complete, stable and a good choice for small setups like a postfix setup with the need for a few lookup tables. It's offering features you don't find anywhere else. As long as 5.3 keeps building... there shouldn't be any need to kill it. It's not even blocking anything because it has no deps. Other distros such as Fedora have started a gradual phase-out of Berkeley DB too, given Oracle's strong-armed approach to community input and their arguably hostile switch to the AGPLv3 (https://fedoraproject.org/wiki/Changes/Libdb_deprecated). Furthermore, Oracle is known to remove critical features from BDB in patch releases, such as the removal of the client-server architecture and the SQL API between 18.1.32 and 18.1.40. This paragraph doesn't belong into a news item. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
PS: Even Debian is mentioning "to follow systemd" when they updated their tzdata package end of 2015, https://bugs.debian.org/803144. OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On 2021-03-22 03:06, Mike Gilbert wrote: Based on that commit message, it looks systemd switched to looking at the symlink target instead of /etc/timezone well *after* some major distro started using a symlink for /etc/localtime. I suspect Kay Sievers noticed that the content of /etc/timezone and /etc/localtime were redundant on his development machine, and added a TODO entry to eliminate the redundant /etc/timezone file. In other words, this isn't a case of systemd forcing distros to symlink /etc/localtime; they were already doing that anyway. I just downloaded and tested some old distributions: Debian 9 was the first Debian release with systemd. Because of systemd, /etc/localtime became a symlink. In Debian 8 or when you install Debian 9 without systemd, it is a regular file. Ubuntu 12.04.5 is the same: No systemd, /etc/localtime is a regular file. Once they moved to systemd it became a symlink. In Fedora 17, which is already using systemd but a version before linked commit, /etc/localtime is also a regular file. But once Fedora upgraded to >=systemd-190 it became a symlink. That's why from my P.O.V. this is clearly caused by systemd. But does this matter? I doubt that systemd will even think about removing what I believe to be a false warning when systemd detects that /etc/localtime is a regular file. So let's focus on dealing with the fallout... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On 2021-03-20 16:37, Andreas K. Huettel wrote: 2) Most other distros seem to just do No, not most distros are doing that. systemd is forcing that downstream (the result is the same)! It was added via https://github.com/systemd/systemd/commit/92c4ef2d357baeef78b6f82f119b92f7ed12ac77 without mentioning a reason. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [News item review] V2 Chromium access to Google services
Hi, On 2021-03-08 20:01, Stephan Hartmann wrote: Starting March 15th, 2021 Google Chrome Team will restrict access to Google APIs and services that are reserved for Google use only. This means that users are no longer able to login into their Google Accounts which disables access to for example Chrome Sync. Maybe outline that this will only affect browser functions. You can still log in into your Google Account when accessing https://accounts.google.com/. As a consequence we have to remove Client ID and secret from all www-client/chromium ebuilds. This change has already been done for =www-client/chromium-89.0.4389.82. Other versions will be updated shortly. My first reaction was: WTF?! Why remove... maybe add a reference to [2] already or quote As explained in section above, signing in to Google web is rate limited if the developer has configured a client ID and client secret. To avoid hitting this limit in Chromium Derivatives, please remove the OAuth 2.0 client ID and client secret from your build configuration. directly in the news item. That said, I wonder if there's a use case to allow users to bake-in custom credentials. I know at least one large Gentoo setup distributing Firefox to its users with custom keys. This is possible via environment variables set at build time, see https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/firefox/firefox-86.0.ebuild?id=dfe26277ee7441d00d88da14691cfc48db85ac8a#n453 If you need one of the Google use only APIs, then you either have to switch to www-client/google-chrome{-beta,-unstable} or setup your own keys [1]. Should be www-client/google-chrome{,-beta,-unstable} ^^^ However, the latter is only intended for development. Documentation on how to generate and use own keys can be found in [2]. I wouldn't mention that at all. Either there is suitable way to keep status quo or there isn't. My suggestion: announcement> client_id or client_secret as explained in last paragraph of [2].> environment variable at runtime (and or build-time if you are going to support that) or add reference to [2] again.> -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [News item review v2] Python preference to follow PYTHON_TARGETS
Hi, I am hot happy with this change. Why must dev-lang/python become special? eselect is a known interface for most (all?) slotted packages. Configuration management tools expect that the appropriate module will be pulled in once you install a slotable package. You are now forcing everyone to either migrate to a new system (manage python-exec.conf directly) or ensure they update their world file and manually ensure that eselect-python is still installed which will make Python special. But because dev-lang/python does not call eselect-python anymore it looks like you cannot retain old, well established behavior across all slotable packages anymore. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs: dev-db/percona-xtrabackup
Hi, mysql project will take this package. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH v3] acct-user.eclass: allow opt-out of user modification
In some setups where users are changed/managed not only via ebuilds, for example through configuration management systems, it could be problematic if acct-user.eclass will restore user/group settings to values set in ebuild. Setting ACCT_USER_NO_MODIFY to a non-zero value will allow system administrator to disable modification of any existing user. Note: Lock/unlock when acct-* package will be installed/removed will still happen. Signed-off-by: Thomas Deutschmann --- v3: - Fixed eclass documentation - Honor 80 chars limit - Prefixed internal variable ACCT_USER_ALREADY_EXISTS eclass/acct-user.eclass | 27 +++ 1 file changed, 27 insertions(+) diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass index 47890e48409a..dcda661d39ea 100644 --- a/eclass/acct-user.eclass +++ b/eclass/acct-user.eclass @@ -72,6 +72,11 @@ readonly ACCT_USER_NAME # Overlays should set this to -1 to dynamically allocate UID. Using -1 # in ::gentoo is prohibited by policy. +# @ECLASS-VARIABLE: _ACCT_USER_ALREADY_EXISTS +# @INTERNAL +# @DESCRIPTION: +# Status variable which indicates if user already exists. + # @ECLASS-VARIABLE: ACCT_USER_ENFORCE_ID # @DESCRIPTION: # If set to a non-null value, the eclass will require the user to have @@ -79,6 +84,13 @@ readonly ACCT_USER_NAME # the UID is taken by another user, the install will fail. : ${ACCT_USER_ENFORCE_ID:=} +# @ECLASS-VARIABLE: ACCT_USER_NO_MODIFY +# @DEFAULT_UNSET +# @DESCRIPTION: +# If set to a non-null value, the eclass will not make any changes +# to an already existing user. +: ${ACCT_USER_NO_MODIFY:=} + # @ECLASS-VARIABLE: ACCT_USER_SHELL # @DESCRIPTION: # The shell to use for the user. If not specified, a 'nologin' variant @@ -344,6 +356,13 @@ acct-user_src_install() { acct-user_pkg_preinst() { debug-print-function ${FUNCNAME} "${@}" + # check if user already exists + _ACCT_USER_ALREADY_EXISTS= + if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then + _ACCT_USER_ALREADY_EXISTS=yes + fi + readonly _ACCT_USER_ALREADY_EXISTS + local groups=${ACCT_USER_GROUPS[*]} enewuser ${ACCT_USER_ENFORCE_ID:+-F} -M "${ACCT_USER_NAME}" \ "${ACCT_USER_ID}" "${ACCT_USER_SHELL}" "${ACCT_USER_HOME}" \ @@ -379,6 +398,14 @@ acct-user_pkg_postinst() { return 0 fi + if [[ -n ${ACCT_USER_NO_MODIFY} && -n ${_ACCT_USER_ALREADY_EXISTS} ]] ; then + eunlockuser "${ACCT_USER_NAME}" + + ewarn "User ${ACCT_USER_NAME} already exists; Not touching existing user" + ewarn "due to set ACCT_USER_NO_MODIFY." + return 0 + fi + # NB: eset* functions check current value esethome "${ACCT_USER_NAME}" "${ACCT_USER_HOME}" esetshell "${ACCT_USER_NAME}" "${ACCT_USER_SHELL}" -- 2.30.0
Re: [gentoo-dev] [PATCH v2] acct-user.eclass: allow opt-out of user modification
On 2021-01-08 21:58, Michał Górny wrote: +# @ECLASS-VARIABLE: ACCT_USER_ALREADY_EXISTS +# @INTERNAL +# @DESCRIPTION: +# Status variable which indicates if user already exists. Please prefix internal variables with an underscore. You mean renaming ACCT_USER_ALREADY_EXISTS to _ACCT_USER_ALREADY_EXISTS? Then _ACCT_USER_ALREADY_EXISTS would deviate from ACCT_USER_NAME which has no underscore prefix and is also marked as internal variable. Or should I fix both? -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH v2] acct-user.eclass: allow opt-out of user modification
In some setups where users are changed/managed not only via ebuilds, for example through configuration management systems, it could be problematic if acct-user.eclass will restore user/group settings to values set in ebuild. Setting ACCT_USER_NO_MODIFY to a non-zero value will allow system administrator to disable modification of any existing user. Note: Lock/unlock when acct-* package will be installed/removed will still happen. Signed-off-by: Thomas Deutschmann --- v2: Keep current behavior; Add opt-out eclass/acct-user.eclass | 25 + 1 file changed, 25 insertions(+) diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass index 47890e48409a..560ae6b0ac90 100644 --- a/eclass/acct-user.eclass +++ b/eclass/acct-user.eclass @@ -72,6 +72,11 @@ readonly ACCT_USER_NAME # Overlays should set this to -1 to dynamically allocate UID. Using -1 # in ::gentoo is prohibited by policy. +# @ECLASS-VARIABLE: ACCT_USER_ALREADY_EXISTS +# @INTERNAL +# @DESCRIPTION: +# Status variable which indicates if user already exists. + # @ECLASS-VARIABLE: ACCT_USER_ENFORCE_ID # @DESCRIPTION: # If set to a non-null value, the eclass will require the user to have @@ -79,6 +84,12 @@ readonly ACCT_USER_NAME # the UID is taken by another user, the install will fail. : ${ACCT_USER_ENFORCE_ID:=} +# @ECLASS-VARIABLE: ACCT_USER_NO_MODIFY +# @DESCRIPTION: +# If set to a non-null value, the eclass will not make any changes +# to an already existing user. +: ${ACCT_USER_NO_MODIFY:=} + # @ECLASS-VARIABLE: ACCT_USER_SHELL # @DESCRIPTION: # The shell to use for the user. If not specified, a 'nologin' variant @@ -344,6 +355,13 @@ acct-user_src_install() { acct-user_pkg_preinst() { debug-print-function ${FUNCNAME} "${@}" + # check if user already exists + ACCT_USER_ALREADY_EXISTS= + if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then + ACCT_USER_ALREADY_EXISTS=yes + fi + readonly ACCT_USER_ALREADY_EXISTS + local groups=${ACCT_USER_GROUPS[*]} enewuser ${ACCT_USER_ENFORCE_ID:+-F} -M "${ACCT_USER_NAME}" \ "${ACCT_USER_ID}" "${ACCT_USER_SHELL}" "${ACCT_USER_HOME}" \ @@ -379,6 +397,13 @@ acct-user_pkg_postinst() { return 0 fi + if [[ -n ${ACCT_USER_NO_MODIFY} && -n ${ACCT_USER_ALREADY_EXISTS} ]] ; then + eunlockuser "${ACCT_USER_NAME}" + + ewarn "User ${ACCT_USER_NAME} already exists; Not touching existing user due to set ACCT_USER_NO_MODIFY." + return 0 + fi + # NB: eset* functions check current value esethome "${ACCT_USER_NAME}" "${ACCT_USER_HOME}" esetshell "${ACCT_USER_NAME}" "${ACCT_USER_SHELL}" -- 2.30.0
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-08 19:14, Michał Górny wrote: The one floppym suggested, i.e. the same as sent patch but with the default staying on the current behavior. Do I understand correctly? You are willing to accept my patch but with > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED defaulting to a non-zero value to keep current behavior? This would be an acceptable compromise for me like it would allow users like me at least to opt-out. I would still try to convince Gentoo to change the default later because I believe this is a bad default but of course I would accept any voting results on this implementation detail. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-08 18:06, Mike Gilbert wrote: I disagree with your premise: I argue that the eclass is not "broken", and the code works as designed. You just don't like aspects of its design. Several people, not just me... *users*, other devs like robbat2 and antarus, all with experience in maintaining multiple systems not just as a hobby, have expressed that the current design has a flaw. I got feedback from other devs representing a large group in Gentoo and they all agree on the problem. They haven't spoken up yet because they don't care because the way how they use Gentoo is stateless. So why the hell is it acceptable for a small group (you and mgorny, Michael told me already last year that he will be fine with an opt-in change and I assume his opinion hasn't changed) to cause problems for another group just because you don't want to acknowledge the problem? Even soap, not sure if he has spoken for himself or as QA lead, has acknowledged in this thread that we need a mechanism to disable this behavior. Is it really not possible to solve this technical problem? Do we have to escalate and need a vote or something to replace entire GLEP 81 with something new just because a group believes there is no flaw and everyone else having problems are doing things wrong so this group is rejecting any attempts to address the problem? -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
Hi, please forget my previous mail. I was informed that I misread your mail, sorry about that! -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-08 17:03, Mike Gilbert wrote: I strongly object to you pushing this patch as-is. There have been plenty of non-technical objections, including from the eclass maintainer. The eclass maintainer has disqualified himself going into a technical debate with saying So, over my dead commit access. in his first posting. This is a technical mailing list. Currently, acct-* stuff is breaking stuff. Nobody has challenged this yet. Now I proposed a way how to unbreak stuff. Please tell me why we should keep broken stuff for non-technical reason and cause harm for those who are affected? It's not like we cannot address the other stuff later. It's about getting the fix down to users who are currently affected by this. So why take hostage when some user(s) ignore the problem for more than a year and show that they are not interested in collaboration to find a solution for a technical problem they created despite warnings before this went live? Of course, if you are not affected by this problem it is very easy to relax and sit back. You have all the time in the world... but when you are affected by this at large scale it is not that funny anymore. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
Hi, since nobody posted any technical objections, I am going to push the proposed patch on Saturday to address the current issue and allow any professional Gentoo user relying on usermod/configuration management tool to move on. If someone will spend time on further improvements like implementing the idea outlined by Robin or what Michael said about /etc/users.d and user-update tool, this is highly appreciated but will probably not happen anytime soon. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
Hi, I wonder how you composed this list. If you just checked if there is any revdep, the check was probably useless: For example, dev-libs/cyberjack is up-to-date, has an active dev as maintainer and is required for any ReinerSCT chipcard reader. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/2] acct-user.eclass: Support ACCT_USER_ID override
Hi, On 2021-01-06 20:05, Patrick McLean wrote: This is so ACCT_USER_$foo can be set in make.conf, and not have to be specified as an environment variable whenever portage is run. This helps when automated systems are building Gentoo images or systems. Please see my reply to Alec for more details. An additional argument I would like to add based on your reply: We already have package.env mechanism to override stuff. ACCT_USER_$foo would introduce an additional way. I wouldn't create an additional way for consistency. But don't get me wrong here. I am just asking and I am always for KISS. ACCT_USER_$foo support would create some additional headaches which we could avoid from my POV. But I am probably not going to use the override feature like I prefer doing stuff like that in configuration management tool which would create these users for me exactly the way I want it. And it doesn't matter if I apply the role to a Gentoo, Debian, Ubuntu or RHEL box... ;) So I am not blocking ACCT_USER_$foo if anyone really believe it would help them. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/2] acct-user.eclass: Support ACCT_USER_ID override
On 2021-01-06 20:12, Alec Warner wrote: Not sure I follow. Whether your automation sets a variable in /etc/portage/make.conf or /etc/portage/package.env; it's basically the same problem space; no? No. Assuming we will always stick to same variables, ACCT_USER_ID ACCT_USER_GROUPS ACCT_USER_SHELL ACCT_USER_HOME ACCT_USER_NAME ... You don't have to deal with variable names which could clash with other stuff. Instead you will only use values which are safe (no need to care about stuff like underscores)... Also, because we are always using same variable names, this will add some kind of consistency and makes documentation easier. Like you can referrer to same example (template) and just need to adjust values (it's actually really hard to get people understand that the example for let's say mail-filter/opendkim requires more than just copying and adjusting *values*; for instance, we have packages named acct-user/foo but *username* is actually food -- do they actually need to override via ACCT_USER__ or ACCT_USER__? Sticking to same variables names will avoid this confusion). Like said we will probably need to introduce an own namespace to override via environment variable and be able to detect the override to have them logged. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
Re: [gentoo-dev] [PATCH 1/2] acct-user.eclass: Support ACCT_USER_ID override
Hi, is there a specific reason why we want to support dynamic variables (ACCT_USER_$foo) at all? Isn't package.env support enough, i.e. use ACCT_USER_ID from environment if set (which we should detect and log, maybe this will require a different namespace for the variables at all to be able to differentiate between values set by acct-* ebuild and user override)? Of course this won't allow something like `ACCT_USER_ID=42 emerge ` but I am not sure if this is an implementation goal. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 19:27, Michael Orlitzky wrote: People like me could just ignore changed users if changes won't go live until you run said users-update command or make use of INSTALL_MASK. Changes wouldn't go live until you ran etc-update, and *then* users-update. This would address my concerns. But I still wonder if building such a system is worth it... I mean, it would be nice to have. Maybe we could build upon such a system to do same for (changed) file permissions... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [PATCH] acct-user.eclass: don't modify existing user by default
Hi, On 2021-01-04 19:07, Michael Orlitzky wrote: We could implement this with something like an /etc/users.d directory that would be populated with entries by either the admin or package manager with CONFIG_PROTECT enabled. Then the system database would be updated by running something like "users-update" (cf. env-update). The essential problem that we need to work around is that e.g. /etc/passwd is "owned" by multiple system packages. I think this would accomplish what you and Robin are talking about, but it wouldn't solve whissi's problem since it's still a Gentoo-specific solution. If you really want to spend so much time on this, feel free to implement something like this. From my point of view this is wasted time. I really have no words for anyone believing that there must be a way to deal with user config. This is a no go for me and most people in my bubble. Once you have created something, it's user data. If you want to make changes, tell the user about it but never ever mess with user configs. History is full of examples when messing with user configs caused real harm. For example there is a reason why we don't edit /etc files. Instead have CONFIG_PROTECT and are only providing helpers to update config. Do I really need to explain what can go wrong when you suddenly change /home? What will happen to your cron jobs for example? What will happen when you make changes to groups and reboot? But as said, if you want to spend so much time on this and create a complicated solution which will be adding a lot of complexity which I think isn't worth it, *I* could live with it. It's the same like dealing with CONFIG_PROTECT already. People like me could just ignore changed users if changes won't go live until you run said users-update command or make use of INSTALL_MASK. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: Support var overrides for user properties
On 2021-01-04 18:08, Michał Górny wrote: Introduce a few variables to allow easy overrides of common user account proprerties, that is: - ACCT_USER__SHELL - ACCT_USER__HOME - ACCT_USER__HOME_OWNER - ACCT_USER__HOME_PERMS - ACCT_USER__GROUPS - ACCT_USER__GROUPS_ADD The first five variables override the respective ACCT_USER_* variables, with ACCT_USER_*_GROUPS being a space-separated list. The *_GROUPS_ADD variable appends to groups present in the ebuild, as this seems a common necessity. We do realize that the original requirement of overriding ebuilds in a local repository was inconvenient. This new logic should permit easy updates via make.conf. Additionally, it has the advantage of clearly reporting the changes made in the build logs. This does not preclude other solutions to the problem. However, this is probably the best one and it should become the current recommendation. This will improve the overlay situation and can be seen as overall improvement but it doesn't address any shared concerns nor is it a replacement for the proposed 'acct-user.eclass: don't modify existing user by default' patch. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 17:38, Michał Górny wrote: You've actually added 'portage' to group 'thomas'. Yes, I know that. Well, I understand why this might be confusing for you. Like I was using portage as example for the described example when you give another service access to a socket like shown in my memcached/redis example. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 17:30, Thomas Deutschmann wrote: On 2021-01-04 17:28, Michał Górny wrote: It must be a bug in your version of the eclass. I've just reemerged acct-group/wheel and to*my great surprise* I'm still there. How unexpected! That's why I wrote > (luckily groups like wheel don't have users...) I meant that there is no acct-user/wheel because otherwise this group would get cleaned (reset), too. Best example is portage. Follow handbook. Add your user to portage's group: > usermod -aG portage Now re-emerge acct-user/portage... # usermod -aG thomas portage # id portage uid=250(portage) gid=250(portage) groups=250(portage),1000(thomas) # emerge -a1 acct-user/portage These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] acct-user/portage-0::gentoo 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] y Verifying ebuild manifests Running pre-merge checks for acct-user/portage-0 Emerging (1 of 1) acct-user/portage-0::gentoo Installing (1 of 1) acct-user/portage-0::gentoo Jobs: 1 of 1 complete Auto-cleaning packages... No outdated packages were found on your system. * GNU info directory index is up-to-date. # id portage uid=250(portage) gid=250(portage) groups=250(portage) -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 17:28, Michał Górny wrote: It must be a bug in your version of the eclass. I've just reemerged acct-group/wheel and to*my great surprise* I'm still there. How unexpected! That's why I wrote > (luckily groups like wheel don't have users...) I meant that there is no acct-user/wheel because otherwise this group would get cleaned (reset), too. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 17:14, Michał Górny wrote: as long as it spews a big fat ewarn that the user loses the right to support. Could you please elaborate this a little bit more? I cannot agree with the way I understand this at the moment but I might miss your point. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 16:55, David Seifert wrote: This is what we agree on. We need an escape hatch, and it needs to be off by default. Any sysadmin overriding it gets to keep the pieces, but they need to have that option. See Mike's example again. In last chapter of Gentoo's handbook (Finalization) we recommend user to call 'usermod' to put themselves into important groups like wheel or portage. Now guess what's happening? Whenever acct-user/portage will get remerged, PM will remove that user from portage group (luckily groups like wheel don't have users...). Do you really want to extend handbook and tell everyone, "OK, as last step, please create an overlay and fork acct-user/portage...". In case the answer will be yes, we now have successfully killed the idea of allowing maintainers to fix a user/group if this will ever be necessary which will add some kind of slap stick to the whole idea. That's why I am saying that we don't just need an opt-out option, that's why I am argue that all this stuff has to be opt-in by default. It's something special and unique in Gentoo. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
Hi, On 2021-01-04 04:18, Michael Orlitzky wrote: It would be nice if this was well-supported by the official way of modifying system users/groups; that is, by using an overlay with modified user/group ebuilds. No, this doesn't work: 1) It's conflicting with the goals other have. See Mike's first reply to my patch proposal: So the main problem I see with doing this is that it becomes impossible to reliably make changes to a user in later ebuild revisions. He is obviously looking for a way to allow maintainers to change users afterwards. But if we tell people, "If you need customization, fork the user/group ebuild in your overlay" we will disconnect these users from future changes. 2) Thank you for outlining the process how to make changes to users using the new acct-* way. It's a nice 'hack'. But it is an own, new way, which makes Gentoo special, unique. And this creates additional problems: This maybe work for your local system. In environments where everything is Gentoo and everyone knows Gentoo. But in today's world you are using configuration management tools like Ansible, Puppet, Saltstack, Chef... People who are not necessarily familiar with every implementation detail must be able to write configurations (recipes) and the used tool is supposed to take care of the differences. In the end, in the ideal world, you are just looking at your code describing a state the system should have. But this doesn't work if you make Gentoo so special that you will break most tools, will require adjustments or special Gentoo support just for stuff Gentoo is doing differently and like everyone else. Don't get me wrong here: Yes, these tools already have to implement USE flags for example which are unique for Gentoo. But stuff like user management isn't or should *not*. When you will get LPIC certification one can expect that you have some basic knowledge in Linux stuff allowing you to do common tasks on all different Linux systems. Now there comes Gentoo where you aren't allowed to use standard Linux tools like 'usermod' when deploying another service if you don't want to risk that your service will go down when following best practice and do regular world upgrades. Really? 3) More important, the idea of forking acct-* packages whenever you need to make modifications don't scale. Like I already outlined in February 2020, you cannot create overlays for each different user configuration: I.e. using memcached/redis: You grant permission to socket via group. So you put other services belonging to that application you are deploying into your user running the key value store. Do you really expect that one would create multiple overlays per application using one of these services? How would you maintain hundreds of overlays? How would you keep track that each box will use the correct overlay to get the specific customized acct-* package? How do you deal with scenarios where you don't just deploy single instances? Again, I understand the acct-* fork idea. But I think we have to admit that this will only work for the local system or small environments. For any professional environment this won't work nor scale. 4) Yet we have to talk about the idea in general that it is really not a good idea to automatically make changes to the user if you run the risk of overwriting changes explicitly made by the system administrator. It's one thing that multiple local users will get removed from portage group when you remerge acct-user/portage, but if you kill services because package maintainers are pushing their vision of how to run the package, it's not. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 10:23, Michał Górny wrote: Not modifying an existing user is a horrible default that has already bricked one system (by removing /dev/null). So, over my dead commit access. Have you seen how many user were hit caused by the recent rebuilt on 2020-12-28 and are already complaining/asking for help through various channels? It's like asking for service auto-restart support in PMS as requested as part of current OpenSSH upgrade because if you move from <8.3_p1 to >=8.3_p1 and don't restart OpenSSH in time, you can get locked out. However, an easily looking solution like Just add something like if [[ -d /run/systemd/system ]]; then systemctl try-restart sshd else rc-service -q --ifstarted sshd restart fi to pkg_postinst is wrong because even if it works for *some* users it won't work for all users but has the potential to cause major problems. That's why we have elog and newitem system. However, 8.3 is in repository for while and multiple people forgot about the newitem and didn't pay attention to elog messages. While I agree that it's a problem when you lose access to a remote box you don't have physical access to, this reached a level where I have to say, > We cannot rescue/protect everyone. Back to topic, acct-* stuff: Like already said in February 2020 when I joined a thread created by a user posting same concerns: There is a reason why *no* distribution on this planet is trying to mess with existing data/configurations: Every attempt trying to analyze given setup to apply required changes to fix/migrate something automatically has been prone to fail the long run. Please get some experience from real world. Preferable from running headless systems not just for yourself and where you are not the only person touching the system. When I worked on bug 605008 long time ago for example, I also ended up over-engineering. There is stuff you cannot fix. I am still thinking about creating everything the way it should look like in $D and report any difference like changed file permissions to user on merge to allow them to notice (an improvement, now user only have to pay attention and you need to solve the additional problem that the more information you present all the time, the more information will be ignored). But sometimes users are making changes we wouldn't do, not recommend or just don't understand at first. That all doesn't matter: We have to keep in mind that these aren't our systems and we have to respect whatever the user did on their system. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
[gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
Modifying an existing user is a bad default and makes Gentoo special because it is common for system administrators to make modifications to user (i.e. putting an user into another service's group to allow that user to access service in question) and it would be unexpected to see these changes reverted during normal world upgrade (which could break services). This commit will make Gentoo behave like any other Linux distribution by respecting any user modifications by default. However, we will retain the functionality to reset system user and groups and users interested in this feature can opt-in by setting ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in their make.conf. Signed-off-by: Thomas Deutschmann --- eclass/acct-user.eclass | 40 ++-- 1 file changed, 38 insertions(+), 2 deletions(-) diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass index 22b0038fbff7..d60b1e53b4bb 100644 --- a/eclass/acct-user.eclass +++ b/eclass/acct-user.eclass @@ -72,6 +72,11 @@ readonly ACCT_USER_NAME # Overlays should set this to -1 to dynamically allocate UID. Using -1 # in ::gentoo is prohibited by policy. +# @ECLASS-VARIABLE: ACCT_USER_ALREADY_EXISTS +# @INTERNAL +# @DESCRIPTION: +# Status variable which indicates if user already exists. + # @ECLASS-VARIABLE: ACCT_USER_ENFORCE_ID # @DESCRIPTION: # If set to a non-null value, the eclass will require the user to have @@ -79,6 +84,13 @@ readonly ACCT_USER_NAME # the UID is taken by another user, the install will fail. : ${ACCT_USER_ENFORCE_ID:=} +# @ECLASS-VARIABLE: ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED +# @DESCRIPTION: +# If set to a non-null value, the eclass is allowed to make changes +# to an already existing user which will include overriding any +# changes made by system administrator. +: ${ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED:=} + # @ECLASS-VARIABLE: ACCT_USER_SHELL # @DESCRIPTION: # The shell to use for the user. If not specified, a 'nologin' variant @@ -266,8 +278,8 @@ eunlockuser() { # << Phase functions >> -EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst pkg_postinst \ - pkg_prerm +EXPORT_FUNCTIONS pkg_pretend pkg_setup src_install pkg_preinst \ + pkg_postinst pkg_prerm # @FUNCTION: acct-user_pkg_pretend # @DESCRIPTION: @@ -309,6 +321,20 @@ acct-user_pkg_pretend() { fi } +# @FUNCTION: acct-user_pkg_setup +# @DESCRIPTION: +# Initialize internal environment variable(s). +acct-user_pkg_setup() { + debug-print-function ${FUNCNAME} "${@}" + + # check if user already exists + ACCT_USER_ALREADY_EXISTS= + if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then + ACCT_USER_ALREADY_EXISTS=yes + fi + readonly ACCT_USER_ALREADY_EXISTS +} + # @FUNCTION: acct-user_src_install # @DESCRIPTION: # Installs a keep-file into the user's home directory to ensure it is @@ -379,6 +405,16 @@ acct-user_pkg_postinst() { return 0 fi + if [[ -z ${ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED} && -n ${ACCT_USER_ALREADY_EXISTS} ]] ; then + eunlockuser "${ACCT_USER_NAME}" + + einfo "User ${ACCT_USER_NAME} already exists; Not touching existing user." + einfo "NOTE: If you want to allow package manager to reset user settings" + einfo " like home, shell, groups... set ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED" + einfo " to a non-null value in your make.conf." + return 0 + fi + # NB: eset* functions check current value esethome "${ACCT_USER_NAME}" "${ACCT_USER_HOME}" esetshell "${ACCT_USER_NAME}" "${ACCT_USER_SHELL}" -- 2.30.0
Re: [gentoo-dev] possible additional tag for GLEP66: Pending
Hi, Jaco Kroon wrote: Specifically, what I suggest is to flag the PR that fixes the issues (ie, ebuild bump) with the usual Bug: tag, but to then at the same time be able to pre-emptively file a PR removing the vulnerable versions, but only once the security bug has been handled (closed). Towards this end, I'd suggest a tag such as: Pending: https://bugs.gentoo.org/NN — to reference a bug; the bug needs to be closed before this PR will be considered for merging. No, this is not really needed and will make everything more complicated. Keep in mind that you never know what happens: - It's possible that the initial bump wasn't enough. - Maybe during stabilization process we will uncover the need for an additional patch. - It's possible that keywords will change during the process. - It's still possible that the ebuild(s) which will be cleaned up as part of the process changes before cleanup will happen. - It's possible that the process hasn't finished before a new security bug for same package was created (superseded). But if you have created the follow ups in advance, - this will clutter things up - you will have to adjust things all the time - and any additional fix up will create new notifications, comments... someone has to check - proxy-maintainer would have to spend time for review twice because something could have changed between creation of follow up PR and time when the PR will get merged And like you said, current CI would be unable to test these follow up PRs before new ebuild was marked stable or CI would report a lot of NonsolvableDepsInStable problems. Sure, you could delay or re-trigger check once stabilization has happened but I really see no benefits in doing anything of that in advance if the chance is high that you have to spend the same amount of time again before you can finally merge. -- Regards, Thomas Deutschmann / Gentoo Security Team fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
RE: [gentoo-dev] Packages up for grabs due to rafaelmartins' retirement
Hi, I took > app-backup/tarsnap -- Regards, Thomas openpgp-digital-signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On 2020-12-18 01:24, Mike Gilbert wrote: The GLEP already mentions the SKS keyserver pool, and the Gentoo LDAP directory. Are these not also "implementation details"? Hrm, I missed point 7. In this case how about replacing Upload your key to the SKS keyserver rotation before usage! with Upload your key to the keyservers [11] before usage! > > [...] > > References > > [...] > [11] Gentoo Wiki: Upload GLEP 63 based OpenPGP keys to keyservers (https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys#Submit_your_new_key_to_the_keyserver) That's all I would do to keep as many details out of the specs. But maybe I am the only one who is so strict about the spec... I am just saying and asking for comments. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
Hi, sorry to be a show stopper here but I have to admit I don't like this addition. If I remember correctly we were talking about this when we actively worked on this GLEP and decided to not put put anything like that into GLEP because this is a implementation detail which doesn't belong into 'specs'. We maybe can talk about adding just a reference link to the Wiki guide but I don't believe we should add this to GLEP. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
RE: [gentoo-dev] GPG key refresh
Hi, glad it's now working for you. In the meanwhile we are looking into issues with the European Gentoo server 😉 > And FWIW this sentence is a little misleading if the SKS refresh > frequency is zero =) > >The SKS keyserver pool can take much longer to replicate over the >keyserver network, while the Gentoo developer tooling explicitly >checks the Gentoo keyserver pool with a much higher frequency. What do you mean exactly? For Gentoo tooling, only Gentoo keyservers are important and Gentoo no longer synchronizes with any other pool. However, developers should still upload keys to public pools, like the SKS keyservers, so others can find the key in case they want to verify checksum or securely exchange encrypted/signed messages with Gentoo developers. -- Regards, Thomas openpgp-digital-signature.asc Description: PGP signature
RE: [gentoo-dev] GPG key refresh
Hi, what exactly did you do already? Did you uploaded to our internal key server? You can only upload through dev.gentoo.org, see https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys#Submit_your_new_key_to_the_keyserver However, you can pull from this server. I tried to test your key but I am currently getting a failure from our keyserver. Waiting for infra to check. -- Regards, Thomas openpgp-digital-signature.asc Description: PGP signature
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
On 2020-11-26 21:36, Michael Orlitzky wrote: Most of these security issues were fixed in systemd-tmpfiles years ago, and you can easily find upstream tmpfiles.d entries that contain e.g. "Z" entries. In that case, the upstream file is not in error, and root doesn't have to be actively tricked into installing anything -- it will just happen. I disagree here: Packages installing tmpfiles configs requiring recursive chown on each boot are doing something wrong from my P.O.V. like you can never safely do that (you can only take precaution like not following symlinks but in this case you don't do what you were asked to do so you shouldn't return 'Yup, I chowned everything like you asked me to do'). Opentmpfiles literally cannot fix this. There is no POSIX API to safely handle hardlinks. At best it can be reduced to the same race condition we have in checkpath, but the entire project would have to be rewritten in C to accomplish even that. Note that hardlinks aren't even fixed for systemd's tmpfiles provider. It will always rely on fs.protected_hardlinks for example. And checking for hardlinks like happened to address CVE-2017-18078 will create another TOCTOU race. Where is the follow-up report for this? In short: As long as it is possible for attacker to write to directory you are working on you can never do mentioned things in a safe way. You first have to revoke access for everyone except you and then you can start checking file per file... but *no* implementation is doing something like that. And keep in mind: We are talking about an attack vector where we already assume someone successfully compromised an application and can now do everything the application user can do for which we do the work in tmpfiles config. Saying that systemd's implementation is more secure than OpenTmpfiles' implementation when you are still able to escalate privileges is very misleading. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
Hi, I don't have any objections regarding the change of the default tmpfiles provider but I would like to classify the vulnerability: On 2020-11-25 22:57, Georgy Yakovlev wrote: In case you don't know, opentmpfiles has an open CVE CVE-2017-18925: root privilege escalation by symlink attack https://github.com/OpenRC/opentmpfiles/issues/4 It has been an issue for quite a while, reported 3 years ago, and not much changed since. Don't get scared by 'root privilege escalation': *Any* problem in *any* tmpfiles provider will *always* allow for root privilege escalation because this service is run by root early at boot. In theory you could create a user for this service but you would need CAP_DAC_OVERRIDE privileges which would again allow for root privilege escalation. Regarding CVE-2017-18925 itself: First you have to understand that anyone can request a CVE and that it isn't CNA's job to verify your report. That's it, having a CVE doesn't mean that a problem was confirmed. A CVE is just an identifier which should allow anyone who want to talk about the same problem to do that. For example when we file bug 123 in bugs.gentoo.org and Fedora would have the same package and experience the same issue they would file bug 456 in their bug tracker -- the goal of a CVE is just to connect information regarding the same issue -- in this example, the CVE would get references to Gentoo's bug 123 and Fedora's bug 456. The bug itself is about a race condition. This race condition is real. However, the impact is questionable: tmpfiles service will only process files from /etc/tmpfiles.d/*.conf /run/tmpfiles.d/*.conf /usr/lib/tmpfiles.d/*.conf Only root is allowed to write to these directories. In other words: To exploit this, a malicious local user (or a remote attacker who already gained user access) would have to trick root into creating specially crafted tmpfiles config allowing for race conditions first (according to the 10 immutable laws of security, if this is already possible, you are already lost). If root doesn't install any tmpfiles config which will create such a race condition and if package maintainer will take care that their packages won't do the same, you are fine. Rule of thumb: Just make sure that you only create top level directories. If something already exists, error out. Because whenever you try to work in a directory where any other user is able to write to at the same time, you are always vulnerable to such a race condition (that's why you should have a second level for actual user data and keep first level for ACL handling -- the service user must only be allowed to pass through this directory). PS: Just to avoid any misunderstandings: OpenTmpfiles should of course try to fix/avoid this problem if possible. Security is a layered process (like an onion) and having multiple safe-guards is always a good thing. -- Regards, Thomas Deutschmann / Gentoo Security Team fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Pushing to distfiles?
On 2020-11-14 23:12, James Le Cuirot wrote: I'm not claiming this has never actually happened but I use these GitHub tarballs*a lot* and I don't recall ever seeing it. Does anyone know for sure that it's happened in, say, the last 3 years? It's a lot of extra work for a problem that may no longer exist or is so rare that it's just not worth the effort. I am aware of three incidents: In 2011 but I cannot find details at the moment. In 2013, a bugfix in git (https://github.com/git/git/commit/22f0dcd9634a818a0c83f23ea1a48f2d620c0546) caused such a change. In second half of 2017, GitHub was rolling out a GZIP update across their fleet which caused such a change. It mostly hit rarely downloaded packages which were cleaned from CDN so tarball had to be re-generated. You can use GitHub Actions for example to automate this or include it in existing release workflows. But yes, you have to get upstream's attention to implement this. And it's not just GitHub, don't forget about GitLab and those self-hosted GitLab instances which often don't support to upload arbitrary assets... -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
Re: [gentoo-dev] A feedback about the CI bug reporting system
Hi, On 2020-11-07 12:30, Agostino Sarubbo wrote: On venerdì 6 novembre 2020 08:21:39 CET Agostino Sarubbo wrote: Hello all, 6 months have been passed after the CI system started to file bug reports. ~ 4700 bugs have been submitted We _know_ that atm is not possible to set a specific summary, instead a generic summary is used in case of compile failures and test failures. There are also some documented limitations. I have to second what other already said. Dropping bugs and forcing maintainer to review and spend time to check if there is a problem and what was the reported problem at all creates more work. And I consider anything creating more load for others which was not requested not as helpful. That said, I don't have these problems with toralf's reports. They are more complete and will show the problem in the report for most bugs. but the majority are fixed so in my opinion they were useful I do not agree with this conclusion. Just because developers didn't ignore you and spent additional time to understand and try to help like we normally do when we get reports from inexperienced users, doesn't mean it was a pleasure... -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] RE: anongit.gentoo.org/repo/sync/gentoo.git not syncing any more?
Hi, we are aware and are currently look into this. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 openpgp-digital-signature.asc Description: PGP signature
[gentoo-dev] Last-rites: dev-perl/ZMQ-LibZMQ3
# Thomas Deutschmann (2020-10-26) # Depends on net-libs/zeromq-3 which is scheduled for removal. # Removal in 30 days. Bug #741454. dev-perl/ZMQ-LibZMQ3 -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last-rites: dev-perl/ZMQ-LibZMQ2
# Thomas Deutschmann (2020-10-26) # Depends on net-libs/zeromq-2 which is scheduled for removal. # Removal in 30 days. Bug #741454. dev-perl/ZMQ-LibZMQ2 -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
On 2020-10-10 22:36, Michał Górny wrote: On Sat, 2020-10-10 at 22:10 +0200, Thomas Deutschmann wrote: Another example for something that was not thought to the end and which was rushed and pushed to our users. You start this mail with an insult to me. Why do you keep doing this? Do you feel that there is some special need for you to try to diminish me in order to reach your goal? You seem to be obsessed with the idea that I am your perfect enemy... I cannot help you with that. The whole idea started with assumption that not every developer will verify the distfile (an assumption I share). But why should we trust these developers that they will keep an eye on upstream’s used certificate instead? That does not make any sense for me. This sounds like 'perfect is the enemy of good'. If we can't get this done perfectly good, we should just lie down and do not put any effort into making things better. Sort of. Another point I just want to mention was patch 5 of 6 for net-libs/miniupnpc. Did you notice that the ebuild will fetch public key via HTTP instead of HTTPS? Is this question to me or to the public? Because if it's to me, then yes, I've noticed I couldn't use HTTPS there. I'm sorry, I'm not as incompetent as you'd repeatedly trying to prove, you won't win your argument this way. See the first paragraph. I really don't understand why you believe I want to show world how incompetent anyone is. I am very sure that people active in Gentoo know very well that you are *not* incompetent. I am just showing a design flaw without any judgement. This is a technical mailing list. It should be possible to focus on technical aspects. One way to respond to that would maybe a discussion how we can do that better (see robbat2 mail for example). I am fully aware that this is still a draft, which is also part of my problem but I will address that later. This will create a chicken-egg problem here: We will record key information metadata the same way we store information about distfiles which is temper proofed. But because this is happening in an automatic way there is not just a theoretical chance that we will store an attacker’s key in our metadata because who is going to verify they key? The same developer we distrust (or where we just want to avoid to trust) that he/she verified the distfile? What's the alternative? Ignoring upstream signatures entirely unless we can securely fetch the key? Shoving the problem under the carpet and assuming that the developer will have safely set up the key on his devbox while being totally incompetent at putting it in an ebuild? My point here is: You had the idea to improve something. Which is good. Improvement is always appreciated. But it must be an improvement. I expect that during the process, "Hey, I think we can do X better... what do you think about doing it that way... which will address problem Z..." we are all open minded. That means that if we come to the conclusion that something isn't really an improvement or so minor that the complexity and everything belongs to that isn't worth it, that we all realize, "OK, didn't work as expected. Withdraw the idea (maybe just until we find a better way) and move on". Theories are all nice but do you have any proof of that? Preferably one that involves developers who *actually carefully* checked distfiles. Because my theory says developers don't have infinite time to audit everything. I don't think I need a proof for that. I am just picking up your initial argument for this new eclass saying "I don't want to need to trust developer that distfile was checked carefully, if we would add automatism we wouldn't need to trust..." (something I share). I hoped I would have shown everyone that in the end we are only *moving* that trust we don't want to give developers that they carefully checked distfiles to keys. In other words: We haven't changed anything -- we gained nothing. We still have to trust developers that they carefully check something, now just keys instead of distfiles. The previous 'problem' this eclass wanted to improve (solve?) is still there. ...and from my POV we got an additional problem because we now have a system which will tell user, "No... distfile looks good, signature is fine" which weighs the user in a false sense of security (even Google had to learn that when they replaced padlock with "Secure" in browsers -- suddenly users stopped using their own brain because they trusted system too much which was telling them that the site which looks like their bank but wasn't their bank's site was secure). Not to mention when this system will force users to connect to arbitrary key servers... Are you arguing that we should remove commit signatures as well? Or d
Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
lowered security because more people will now stop paying attention: - Previous developers who carefully checked distfiles will stop doing that. - Nobody will question anything because there is a new passed check. In worst case scenario, we are now emerging a signed malicious package we could be aware of if some human would have checked upstream and noticed that release key was revoked. But this will not happen anymore because we rely that once we have recorded a key in the metadata that some system will tell us in case there is a problem. And what do you expect what will happen when after the download something will tell us “Oh, this file is not signed with currently known key”? Right, that developer who we do not want to trust that he/she verified the distfile will just add a reference to the new matching key which will silence any warning. No, sorry. Security required education. You need to understand where security is depending on so that you know when you need to take action. Every attempt to move this away from the user will actually add needless complexity, allow for new attack vectors and will not improve security. The purpose of this email is to get this addition removed ASAP. PS: I assume that the "Arch Linux is using something similar" argument will appear. I am not going to make an in depth statement about what Arch Linux is doing here. But they have a total different security model which you have to take into account. And please don't forget that we already have that working Manifest mechanism which isn't promising anything it cannot do. -- Regards, Thomas Deutschmann / Gentoo Security Team fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
Hi, TL;DR: jstein asked council [Bug 729062] for a motion that any service and software which is critical for Gentoo should be developed/run in Gentoo namespace. Because any request to council must be discussed I volunteered to bring this topic to the mailing list (sorry for the huge delay!). Problem === You maybe all remember what happened to stable-bot: Years ago, kensington created stable-bot on his own as PoC which revolutionized the way how we do package stabilization in bugzilla. The service run on his own infrastructure. Because of the benefit of the service the bot provided, arch team’s workflow became dependent on stable-bot. We were lucky that stable-bot just worked most of the time until the service was down for a while. Nobody was able to help here: Kensigton himself was unavailable, nobody had the sources… the end of the story: mgorny created nattka which replaced stable-bot. However, we are still facing the same problem: Only one person is involved in development and knows how to run it. In case something will break again and Michał will be unavailable, we can’t just push a fix and watch a CI pipeline picking up and deploying new nattka. Instead someone will have to fork repository from Michał’s private repository at GitHub, make the changes and hope that anyone within infrastructure team can help to deploy fixed nattka. This is what the motion is about: This is not about that Gentoo depends on single persons or things like that. It’s about the idea to *formalize* the requirement that any service and software which is critical for Gentoo (think about pkgcore) should live within Gentoo namespace (https://gitweb.gentoo.org/), i.e. be accessible for *any* Gentoo developer and deployments should be based on these repositories. Or in other words: Make sure that we adhere to social contract even for critical software and services Gentoo depends on. So that we will never ever face the situation that something we depend on doesn’t work anymore. Taking care of working pipelines before something is broken should also help us in case something stops working so we don’t have to figure out how to fix and re-deploy when house is already burning (like portage: In case Zac can't do a release for some reason, in theory, every Gentoo developer would be able to roll a new release). See also: = Bug 729062: https://bugs.gentoo.org/729062 -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev
On 2020-08-10 14:07, Michał Górny wrote: > ...or a revert of a change made for change's sake. That's a bold statement for an unambiguous 7-0 decision as seen in https://bugs.gentoo.org/575718. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev
On 2020-08-09 23:14, William Hubbs wrote: > Here is something else to consider. > > Blueness and any of the other eudev maintainers are doing good work > for alternative c library support such as musl. In fact, the musl > profiles hard mask sys-fs/udev, so they are covered no matter what > happens as a result of this thread. > > Eudev is supposed to be udev without systemd along with alternative c > library support, but it appears to be behind what eudev offers. > > The following commit appears to be the last time eudev synced with udev: > > https://github.com/gentoo/eudev/commit/2ab887ec67afd15eb9b0849467f1f9c036a2b6c8 > > There are roughly 100 commits in the udev master branch since the date of this > sync: > > https://github.com/systemd/systemd/commits/master/src/udev > > There are several new commits in libudev and udev rules since then as > well: > > https://github.com/systemd/systemd/commits/master/src/libudev > https://github.com/systemd/systemd/commits/master/rules.d > > I would like to publically thank Leio for providing me with the > information above. > > I asked the council for guidance and was told that they don't need to be > involved, so I guess the best thing to do now is call for testers. > > It would be helpful if people migrate their systems manually from eudev to > udev > and report issues. > > I'm not a valid test case because I have always run udev. This is not answering my questions. If anything from above would be valid (like others have asked you for bugs and already mentioned that commit count alone don't say anything) we wouldn't just be talking about switching default for *new* installations. Instead we would need to talk about ditching eudev in general... So for me it still looks like change for change's sake without a real reason. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev
On 2020-08-08 20:51, William Hubbs wrote: > What do people think? Like others already asked: What's the reason for this? What do you expect from this change? Is there a problem when new Gentoo installations will use EUDEV by default? Or is there a benefit if new installations would use sys-fs/udev? -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: Multiple root kernel command-line arguments
On 2020-08-06 21:50, Jaco Kroon wrote: > Can you detect in the runscript that this will trigger and issue a cold > reboot instead if this would trigger? > > Having never used kexec before ... I may well be missing the point. But > I'd rather have the system issue a cold reboot if kexec (which sounds > really cool in principle) stands any chance of failing. It's software. Of course you can do everything you can do in POSIX shell script :) But I doubt that something like this is practicable -- we also should avoid overengineering. Like I was thinking by myself if we should teach kexec runscript to return persistent name instead (utilizing lsblk for example) but this will raises question like what to do if tools aren't available and maybe user's start environment can't even handle root=UUID=... value :/ -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: Multiple root kernel command-line arguments
On 2020-08-06 19:20, Aaron Bauman wrote: > Wait, changes were made to genkernel to switch from mdev to (e)udev > which causes breakage, but it is *not* an issue with genkernel? Exactly. This failure can happen with genkernel version created 15 years ago, with new genkernel-4.1 which switched device manager or even with dracut -- the mistake is using non-permanent device names for things like root. I assume that most user don't do that. At least their default boot entry in /boot/extlinux/extlinux.cfg or via /etc/default/grub will have a permanent name -- but the problem are tools/scripts appending to that existing command-line. They will overwrite a good value... And it's even more a problem because even when you notice "Ah, something is appending root argument" you won't question that because the value you notice matches your expectation from POV of current running system. So you have to realize that this is a non-permanent value which could be different on next boot because you did X which caused and offset in numbering for example... > Aside from this, do we have any evidence or bugs validating that users > experience breakage with randomly named boot devices in kexec? > > It is great that you found an issue, but why try and be agnostic as to > which one caused the issue? It looks worse that we cannot simply say: > > "genkernel changed for the better and things *may* break now... please > read this!" > > Instead, we are pushing a news item to a lot of people simply because we > *assume* it may be an issue for others with no evidence. Well, the purpose of this is to educate and avoid problems for headless/server users. But if so many devs seem to care about pushing maybe unrelated information and believe that avoiding that has much more value than avoid a problem like an unbootable system for just a few people (and for headless/servers this is a major problem in case you cannot trigger remote reboot)... ¯\_(ツ)_/¯ -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: Multiple root kernel command-line arguments
On 2020-08-06 20:56, Rich Freeman wrote: > Has anything even changed with kexec? Or is this an issue that has > been an issue for many years in kexec, that will suddenly become an > issue in genkernel? In that case it is news from a genkernel > perspective, and something anybody with a correctly-booting system > fixed a long time ago if they're using kexec. Well, first it was an annoyance I became aware of myself when I noticed a system having dozen of root arguments in kernel command-line. I think we even talked about this in #gentoo-base a while ago: > # cat /proc/cmdline > domdadm dolvm dosshd crypt_root=UUID=a-b-c-d root=UUID=e-f-g-h rootfs=xfs > scandelay=3 root_trim=yes vga=0x317 gk.log.keep=/var/log/genkernel-boot.log > root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 > root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 > root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 > root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 > root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 > root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 root=/dev/dm-2 ...you can count how often the system was rebooted using kexec ;) This week I also received a bug report from a user who upgraded to genkernel-4.1 where first reboot failed but everything was working after a reset (cold boot). During my investigation I was able to trigger this by myself, for example when I close and re-open LVM volume and trigger new symlink for re-opened root volume (this sounds like a non-typical use case for some people but when dealing LVM backups/snapshots it's not that uncommon). So this became a bug for me in our kexec runscript which I fixed https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4860fce5434f46d90e913ff10515a9a256fc6c6a and already warn about https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=61c03ffab76740c0420e3c8a3185d047d461f7a7 But note: This is not even a kexec issue per-se. If you use kexec on your own with your scripts (which is also not that uncommon) you maybe also appending additional root argument which has the potential to cause boot failures in case you are using non-permanent device names and something will be different in start environment. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: Multiple root kernel command-line arguments
On 2020-08-06 17:44, Michał Górny wrote: > I'm not sure if you've noticed but there are people actively working > towards removing stale news items and trying not to dump everything > on once on a user freshly installing the system. Don't you consider > this a worthwhile goal? I don't see how this is conflicting. This news item can probably go away after 1-2 years. But for now, people who were just lucky will probably trigger this when upgrading to genkernel-4.1 on their first reboot due to switched device manager. But again: It's not a genkernel issue, so displaying that only for people who have genkernel installed would miss a bunch of users. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: Multiple root kernel command-line arguments
On 2020-08-06 14:22, Michał Górny wrote: >> - I am not 100% happy with the title but the 50 char limit >> doesn't allow any more details. > > Yes, the title doesn't say a thing why would anyone want to read this > news item or not. Maybe > Be aware of possible reboot problems instead? >> - No Display-If condition because it is neither a genkernel nor >> kexec-tools issue. We maybe even have additional packages >> which are appending to kernel command-line I am not aware of. > > Showing this news on all old and new Gentoo systems makes little sense. > Either someone is newly affected, then Display-if should determine it, > or someone is *not* newly affected, then you're either telling him > something he already knows or something that is of little value to him. > > News items should be precisely this -- news. Not random pieces of > information you've just discovered and want to share with everyone. > This is what documentation is about, and it should be in some kernel- > related piece of documentation (handbook?) and not scattered around > in news items. Sure, you are basically repeating what I wrote in my prolog. But the reason why I drafted that news item despite of this is the consideration that an unbootable system outweigh the risk to waste anyone's time to read something even if they are not affected. Note that news items will appear through multiple channels. So if this will help someone who didn't read documentation before or just didn't realize the obvious risk he/she is taking when using non-persistent names ("It worked that way for me past 15 years!") I believe it has served its purpose. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] News item v2: Multiple root kernel command-line arguments
Hi, here's v2 based on some IRC feedback (grammar- and punctuation-related) I am planning to add for tomorrow. --- Title: Multiple root kernel command-line arguments Author: Thomas Deutschmann Posted: 2020-08-05 Revision: 1 News-Item-Format: 2.0 Due to genkernel-4.1 development which is changing device manager from MDEV to (E)UDEV it was noticed that some tools like kexec append an additional root argument to kernel command-line. If these tools will set root to a non-persistent device name like root=/dev/dm-3, the next boot might fail if there is *no* root device named like that in start environment (i.e. initramfs). While kexec's runscript was changed in >=sys-apps/kexec-tools-2.0.20-r2 to no longer append root kernel command-line argument when an option like "--reuse-cmdline" (default) is used, a cold reboot *without* kexec may be needed to restore kernel command-line. NOTE: This issue is *not* specific to kexec or genkernel usage. Kernel will always use last set root kernel command-line argument. Any tool which might be appending root argument without a persistent device name might cause a boot failure if system cannot find that referenced root device during boot. To avoid boot problems, user should revise their current kernel command-line (/proc/cmdline) to ensure that only *one* root kernel command-line argument is set. The usage of persistent device names like root=UUID=<...> is highly recommended. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] News item: Multiple root kernel command-line arguments
Hi, please review the news item below: - I am not 100% happy with the title but the 50 char limit doesn't allow any more details. - No Display-If condition because it is neither a genkernel nor kexec-tools issue. We maybe even have additional packages which are appending to kernel command-line I am not aware of. - In theory this shouldn't be a news for anyone: If you don't use a persistent device name, you are basically asking for troubles like that. However, people just using kexec from kexec-tools package maybe unaware that auto-detection of ROOT device which is the default might cause trouble like that because it won't use persistent names. - Experiencing a boot failure is always bad -- especially for headless/remote systems so a warning shouldn't hurt. - Latest kexec-tools ebuild in repository now also warns user in pkg_postinst, see https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/kexec-tools/kexec-tools-2.0.20-r3.ebuild?id=61c03ffab76740c0420e3c8a3185d047d461f7a7#n111 --- Title: Multiple root kernel command-line arguments Author: Thomas Deutschmann Posted: 2020-08-05 Revision: 1 News-Item-Format: 2.0 Due to genkernel-4.1 development which is changing device manager from MDEV to (E)UDEV it was noticed that some tools like kexec append an additional root argument to kernel command-line. If these tools will set root to a non-persistent device name like root=/dev/dm-3, the next boot might fail if there is *no* root device named like that in start environment (i.e. initramfs). While kexec's runscript was changed in >=sys-apps/kexec-tools-2.0.20-r2 to no longer append root kernel command-line argument when an option like "--reuse-cmdline" (default) is used, a cold reboot *without* kexec maybe needed to restore kernel command-line. NOTE: This issue is *not* specific to kexec or genkernel usage. Kernel will always use last set root kernel command-line argument. Any tool which might be appending root argument without a persistent device name might cause a boot failure if system cannot find that referenced root device during boot. To avoid boot problems user should revise their current kernel command-line (/proc/cmdline) to ensure that only *one* root kernel command-line argument is set. The usage of persistent device names like root=UUID=<...> is highly recommended. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On 2020-07-29 16:07, Andreas Sturmlechner wrote: > Package is ~arch exclusively so everyone using it was already upgraded. > Masking <3.0.0_rc1 is perfectly fine if you want to keep old while not > blocking py2-masks of dependencies. While I even disagree with that, this is not even what happened. And yes, I probably wouldn't have notice this and wouldn't care if only <3 were masked. But again, that's not what has happened. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On 2020-07-29 15:46, Aaron Bauman wrote: > Yes, net-nntp/sabnzbd is valid as it still has an ebuild with only > py2.7. So fix it instead of bitching and being lazy about it. You > could have done that vice revert the commit. What are you talking about?! When upstream released first version supporting Py3, it was added to repository. So don't call me lazy! Like you can see, it's currently in RC state. No cleanup of previous stable version will happen before this version was declared stable. So no, your list was wrong. > I will revert your revert when I return to my laptop. Thanks for > nothing. ...and not just because of net-nntp/sabnzbd like this thread has shown. I followed Gentoo policy when I reverted a broken commit. If can only urge you to revise pkg list and pay more attention for your next commit. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On 2020-07-29 09:38, Aaron Bauman wrote: > This is exactly how it went before. No one is saying "it's your > fault". Fix whatever the issue is and remove it from the list. No. You can't drop the bomb and let other fix the damage you created. That's not how Gentoo is supposed to work. C'mon. You even added net-nntp/sabnzbd to that list again which created a lot of drama beginning of this year. Please don't try to say you reviewed anything... -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
FYI: I reverted the entire commit like this thread and bugs clearly show that this list wasn't even reviewed/checked: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b76ee2f3e20b55d268ec291a1a1328cc047f5a04 -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] */*: Mask Py2 only packages
On 2020-06-20 21:24, Aaron Bauman wrote: > Thomas, unfortunately, I am shocked at your choice of words here. I > think it is reasonable that any developer would understand a lack > of forward momentum in removing Py2 only packages only drives > stagnation. > > If you have a more effective method to doing so, I am open to > suggestions. Like I am shocked about your recent actions: Remember what you did in January. I thought it became clear that next time you will share your list before just masking stuff to avoid things which happened then. In the beginning of this month you just decided to disband graphics project. On your own. Please tell me what gave you the authority to just do that? You didn't even share your plan before executing it on any mailing list. Something that should be common sense, if not even necessary. The whole action was so destructive that you couldn't evenb just undo it because you also deleted stuff on Wiki. And now you did it again with Py2-only packages. And again for no good reason. Like multiple people have already shown you, many packages from that list are not even blocking Py3 transition. Let me tell you what a mask will cause: A mask is destructive and requires user interaction. Therefore a mask isn't something to play with, "Oh, let's test if someone will complain... it's just a mask, we can just unmask in case...". No, imagine there are people out there using Gentoo in production and not as playground. These people maybe have automated build systems which are creating systems/images (do you know Dockers for example?). Whenever you mask something and that package is referenced in configuration, you will break that build. That's not funny if this is happening for no real reason. > re: net-mail/offlineimap... there are alternatives. I think you don't really know that tool. It's an industry standard. Sure, there are already successors (however, not in Gentoo). But the package itself is still working and actively maintained and when you will use it in production you usually have extended/adjusted the tool for your environment using the plugin system the tool provides. That's not something you will be able to replace with something new in 5 minutes. And I repeat myself: Especially not when there is no need to do that because because the package itself is working fine and there is absolute no reason to get rid of it. Last but not least: Gentoo is about choices. It's not your job to decide what people should use. Sure, if you maintained a package and will stop using it so it will become maintainer-needed and masked for removal at some point because it's outdated, vulnerable and/or not working anymore, that's OK. But if someone else will pick up this package... and offlineimap in Gentoo is working and up-to-date. Heck, we could even talk about how rude it is to force a maintainer to drop its package. And yes, even p-m should be treated like real devs. So you can't just kill their packages because you want to. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] */*: Mask Py2 only packages
On 2020-06-20 12:07, Michał Górny wrote: >> Al least, python2 is not on your list. >> >> Be first into the future by masking this stuff and >> Last out of the past by leaving up to users to decide. >> It could stay in the tree, masked, as long as python2. >> > > Do you really think it'd be better to last rite a 1000 packages > simultaneously? What's the purpose of this at all? dev-lang/python:2.7 won't go away that soon. Removing perfectly working and up-to-date software which is in maintenance-only mode like net-mail/offlineimap is just not user-friendly. It doesn't even has deps on other Python packages blocking your cleanup delusion. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
RE: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests
Hi, is this really CI _vs_ Code Review? I.e. we can only have one? CI is nice and helpful. For example I usually don't start review until CI sets green light but CI alone wouldn't be enough. Thought that Gitlab will support same kind of hooks similar to how current CI is integrated into Github, not? Also, when I could wish something: The problem when doing review on Github for me is, that we usually create new revisions. Therefore we don't see what's changed in new revision versus previous revision. So the change to review looks like an entire new file was added (which is what basically happened). It would be cool if our solution would be aware of this and could handle this somehow. But I guess we would have to create our own solution for this... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 openpgp-digital-signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Should NATTkA reject keywordreqs for packages with -arch (-*) keywords?
On 2020-05-06 00:52, James Le Cuirot wrote: > On Tue, 05 May 2020 22:19:59 +0200 > Michał Górny wrote: >> >> WDYT? > > Play it safe. -* is frequently used for binary packages where an arch > will simply either work or it won't, with little likelihood of the > situation changing. -arch is so rare that I don't recall ever seeing > it. In either case, restoring an arch should be an explicit action. +1 -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
On 2020-04-26 15:46, Kent Fredric wrote: > On Sun, 26 Apr 2020 14:38:54 +0200 > Thomas Deutschmann wrote: > >> Let's assume we will get reports that app-misc/foo is only installed 20 >> times. If you are going to judge based on this data, "Obviously, nobody >> is using that package, it's stuck on ... safe to remove" your >> view is biased: > > I see this as more like what bloom filters get you, but in reverse: > > [...] > > - But now, instead of having "we don't know if anybody uses this", you > *can* have a "we know for sure somebody uses this". But how does that information really help us to decide anything in the end? Case A, stats are showing 0 users: Like said, we can't know if this is true or if this package is only used in setups where people don't report stats. Case B, stats are showing x users: Now what? Package from case A could have similar users -- we just don't know. Assume firefox has 1.000 users, chromium has 500 users and vivaldi doesn't show up in stats. How does that help us? Would this allow us to skip publishing GLSAs for vivalid because we assume nobody in Gentoo is using vivaldi? Does it allow Python project to go forward pushing a mask for removal in case vivaldi would depend on Python version, Python project want to get rid of? Would this allow Gentoo PR to make a public statement like "Firefox is the most popular browser in Gentoo, twice as users as chromium"? Yes it would be a signal but a useless signal, not? -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
On 2020-05-05 00:57, Andrey Utkin wrote: > I assume we have logs of distfiles downloads from Gentoo infrastructure, and > can negotiate access to relevant logs of our mirrors. That constitutes partial > data correlated with users' installation activity, as good as it gets. Even if we would have data for distfiles.gentoo.org this won't help us. See how Gentoo works: If you follow handbook you will pick a local/regional mirror. Now all these users are suddenly 'disconnected' from the download stats... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)
On 2020-05-02 22:30, Andreas K. Hüttel wrote: > * Legacy boot and MBR will get kicked out. * > > This is your chance to protest or support. *holdingupprotestsign* Why? There are still a lot of people out there who don't have (U)EFI or don't use GPT. Please keep this information or share why you believe this has to be removed. I assume you are talking about https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks and for me it's not a *mess*. Maybe move it to a 'legacy' sub page but it's too early for complete removal from my P.O.V. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
On 2020-04-26 10:08, Michał Górny wrote: > What do you think? Do you foresee other problems? Do you have > other needs? Can you think of better solutions? While I would really like to have data, I think it's impossible to get correct data and therefore we shouldn't collect any data at all because the invalid data we would collect would be misused/misinterpreted. Let's start with your first example already, > the primary goal of the project would be to gather statistics on > popularity of packages, in order to help us prioritize our attention > and make decisions on what to keep and what to remove Let's assume we will get reports that app-misc/foo is only installed 20 times. If you are going to judge based on this data, "Obviously, nobody is using that package, it's stuck on ... safe to remove" your view is biased: Because reporting will never be mandatory, we don't know if app-misc/foo is just unlucky because most of its user haven't opt-in into reporting, too (you can assume something like this for people with tor-related programs for example). Now think about large installations which are probably not allowed to "phone home", using their private local mirror and are even using build hosts. I am aware of *multiple* large Gentoo deployments -- for servers. You will never get data from these installations. Instead, stats will be drowned by several home users which are more likely to submit data. Not to mention the new containerized world... It's the problem you all should know from Mozilla, Google, Microsoft *duck*: They all do 'data-driven development'. The problem: *We* are power users. We are using several features most normal users don't even know. However, most of us are also aware about privacy and are disabling stats. The result: These companies are killing popular power user features just because their data indicates that nobody is using that feature. Please don't create pressure on users to opt-in to gentoostats to prevent something like this for Gentoo. My point is: I'll strongly object against *any* decision based on this project because the data will be *always wrong*. Therefore the data is useless and I wouldn't even consider collecting them in first place. Where there is a trough the pigs gather... and at one point people will start to ignore that the data is useless just to underline *their* point in their current situation. :/ -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH] rpm.eclass: use BDEPEND for EAPI 7
Hi, merged, thanks: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=606c745e611c216df15568bc8655e2781dc11095 -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Stabilizations and src_test
On 2020-04-12 11:21, Michał Górny wrote: > This is not a problem that can be solved by a binary flag. > > If package's test suite is entirely broken and unmaintained, the package > should use RESTRICT=test and not silently ask arch teams to ignore it. > > If package's test suite is only slightly broken, then I'd prefer saying > 'please report but ignore *these* test failures' because I can't fix > them right now but they don't seem major. Skipping the test suite > entirely is not a solution because it doesn't disambiguate between 'few > tests fail' and 'every single test explodes'. ACK. I also see no need for any new mechanism. > - There are people that rant if you open a test failure bug against their > packages and you block the stabilization. Maybe start ignoring those packages until people learn that stabilization is a lot of effort/work. Really, if you call for stabilization and haven't tested your own package you are offloading work to others which is not nice. I also dislike maintainers who simply restrict tests on first failure. But in the end it's at least a strong signal about package quality and state in Gentoo. :) -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords
On 2020-04-11 17:33, Michał Górny wrote: > 1. We kill both keywords, and just rely on components, or > > 2. I make NATTkA automatically add KEYWORDREQ or STABLEREQ where > appropriate. I think you cannot kill it. Yes, we have a component for stabilization/keywording, but we also do stabilization from security bugs which don't have such a component and some tools must be able to filter. Just checking CC list is not an option because in theory, you can CC architectures when you are just requesting some input from them. So I would tend to #2. It doesn't really hurt, does it? -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 00/10] GLEP 72 (arches.desc) revival
Hi, regarding "security supported architectures" a few words from security project: We don't like the differentiation. And in practice, it doesn't even matter nor does it work: In theory, "security supported architectures" would allow us to ignore bugs only affecting specific architectures. But examples are rare. I can only think about a vulnerability affecting just x86 (https://security.gentoo.org/glsa/202003-13) or arm (like some vulnerabilities in Xen hypervisor making use of specific hardware features) in the past 24 months. So this is not really important and in the end we don't really have the man power to differentiate. We just bump because if we would skip a bug fix just because we thought it doesn't affect us, this could have serious impact for no real reason. We also always have to cc all architectures which have stable keywords set on any affected ebuild which should be removed (cleaned up) after security stabilization or maintainers will be unable to do the cleanup. In the past, "security supported architecture" was also used to determine when security team was allowed to publish a GLSA. However, we changed this policy ~3 years ago: Some people don't do regular world upgrades. They only pull updates when they want a newer version or for security reasons via glsa-check tool. Not telling amd64 users that they are using a vulnerable package where we already have a fix for just because slacking architecture like hppa in these days didn't stabilize this package yet was just unacceptable. It wasn't an easy decision even in our small team because some members had the concern that users will get warned about a vulnerability without a solution yet available for their architecture, resulting in bug spam/nagging. However, this never happened and some members even believe that this is also an opportunity: Maybe some users not knowing that their arch team is slacking would step up and join their architecture team and help. For the future some members even want to go one step further and release GLSAs more often and not just for B2 or more severe vulnerabilities. Back to "security supported architectures: tl;dr Security project wants to remove "security supported architectures" for years. Any architecture in Gentoo which is carrying stable keywords must keep up with stabilization or keyword requests. Security stabilization shouldn't be treated special (Because new ebuilds often depend on recent libs. If an arch team would only focus on security bugs, calling for stabilization will become more difficult because we would have to add all the missing deps which are now required but already stable everywhere else and just ignored by this arch until today). If an architecture can no longer keep up with stabilization/keywording demand, the entire architecture must be dropped to ~arch. No exception. Stop pretending that this architecture is in good shape and that those users have the same stable experience like you have on more common architectures. Keep in mind: You would also need to explain a user, "Yeah, you are using something we name 'stable' but it doesn't mean what you are expecting and BTW, while we have said we have fixed vulnerability X in Gentoo you heard about in the media, don't forget to check on your own if this is also true for your architecture because in theory the maintainer could have decided to make use of arch-depending eapply for some reason..." => Keep it simple: Stable should mean the same across all architectures -- Regards, Thomas Deutschmann / Gentoo Security Team fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature