[gentoo-dev] [PATCHv3] 2021-11-23-mariadb-database-restore-maybe-required: add item

2021-11-25 Thread Thomas Deutschmann
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

2021-11-25 Thread Thomas Deutschmann
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

2021-11-25 Thread Thomas Deutschmann

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

2021-11-25 Thread Thomas Deutschmann

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

2021-11-25 Thread Thomas Deutschmann

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

2021-11-25 Thread Thomas Deutschmann

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

2021-11-24 Thread Thomas Deutschmann
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

2021-11-14 Thread Thomas Deutschmann

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

2021-11-03 Thread Thomas Deutschmann

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

2021-11-03 Thread Thomas Deutschmann
track=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

2021-10-22 Thread Thomas Deutschmann

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

2021-10-19 Thread Thomas Deutschmann

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

2021-10-18 Thread Thomas Deutschmann

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

2021-10-17 Thread Thomas Deutschmann

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

2021-08-09 Thread Thomas Deutschmann

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

2021-08-04 Thread Thomas Deutschmann

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

2021-08-03 Thread Thomas Deutschmann

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

2021-07-28 Thread Thomas Deutschmann

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

2021-07-26 Thread Thomas Deutschmann

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

2021-07-24 Thread Thomas Deutschmann

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

2021-07-12 Thread Thomas Deutschmann

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

2021-07-11 Thread Thomas Deutschmann

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

2021-07-07 Thread Thomas Deutschmann

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

2021-07-06 Thread Thomas Deutschmann

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

2021-06-22 Thread Thomas Deutschmann

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?

2021-06-16 Thread Thomas Deutschmann

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?

2021-06-16 Thread Thomas Deutschmann

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

2021-06-11 Thread Thomas Deutschmann

# 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

2021-05-28 Thread Thomas Deutschmann

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 ?

2021-03-21 Thread Thomas Deutschmann
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 ?

2021-03-21 Thread Thomas Deutschmann

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 ?

2021-03-21 Thread Thomas Deutschmann

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

2021-03-08 Thread Thomas Deutschmann

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

2021-01-24 Thread Thomas Deutschmann

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

2021-01-20 Thread Thomas Deutschmann

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

2021-01-08 Thread Thomas Deutschmann
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

2021-01-08 Thread Thomas Deutschmann

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

2021-01-08 Thread Thomas Deutschmann
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

2021-01-08 Thread Thomas Deutschmann

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

2021-01-08 Thread Thomas Deutschmann

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?

2021-01-08 Thread Thomas Deutschmann

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

2021-01-08 Thread Thomas Deutschmann

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

2021-01-08 Thread Thomas Deutschmann

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?

2021-01-08 Thread Thomas Deutschmann

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

2021-01-06 Thread Thomas Deutschmann

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

2021-01-06 Thread Thomas Deutschmann

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

2021-01-06 Thread Thomas Deutschmann

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

2021-01-04 Thread Thomas Deutschmann

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

2021-01-04 Thread Thomas Deutschmann

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

2021-01-04 Thread Thomas Deutschmann

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

2021-01-04 Thread Thomas Deutschmann

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

2021-01-04 Thread Thomas Deutschmann

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

2021-01-04 Thread Thomas Deutschmann

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

2021-01-04 Thread Thomas Deutschmann

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

2021-01-04 Thread Thomas Deutschmann

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

2021-01-04 Thread Thomas Deutschmann

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

2021-01-04 Thread Thomas Deutschmann

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

2021-01-03 Thread Thomas Deutschmann
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

2020-12-23 Thread Thomas Deutschmann

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

2020-12-21 Thread Thomas Deutschmann
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

2020-12-17 Thread Thomas Deutschmann

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

2020-12-17 Thread Thomas Deutschmann

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

2020-12-15 Thread Thomas Deutschmann
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

2020-12-15 Thread Thomas Deutschmann
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

2020-11-26 Thread Thomas Deutschmann

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

2020-11-26 Thread Thomas Deutschmann

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?

2020-11-14 Thread Thomas Deutschmann

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

2020-11-07 Thread Thomas Deutschmann

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?

2020-10-28 Thread Thomas Deutschmann
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

2020-10-25 Thread Thomas Deutschmann

# 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

2020-10-25 Thread Thomas Deutschmann

# 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

2020-10-11 Thread Thomas Deutschmann

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 
does it happen that with roughly the same technology and the same 
people, one layer is secure and another similar layer is to

Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

2020-10-10 Thread Thomas Deutschmann
 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

2020-09-13 Thread Thomas Deutschmann
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

2020-08-10 Thread Thomas Deutschmann
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

2020-08-10 Thread Thomas Deutschmann
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

2020-08-09 Thread Thomas Deutschmann
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

2020-08-06 Thread Thomas Deutschmann
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

2020-08-06 Thread Thomas Deutschmann
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

2020-08-06 Thread Thomas Deutschmann
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

2020-08-06 Thread Thomas Deutschmann
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

2020-08-06 Thread Thomas Deutschmann
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

2020-08-06 Thread Thomas Deutschmann
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

2020-08-05 Thread Thomas Deutschmann
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

2020-07-29 Thread Thomas Deutschmann
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

2020-07-29 Thread Thomas Deutschmann
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

2020-07-29 Thread Thomas Deutschmann
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

2020-07-29 Thread Thomas Deutschmann
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

2020-06-24 Thread Thomas Deutschmann
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

2020-06-20 Thread Thomas Deutschmann
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

2020-05-27 Thread Thomas Deutschmann
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?

2020-05-05 Thread Thomas Deutschmann
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

2020-05-04 Thread Thomas Deutschmann
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

2020-05-04 Thread Thomas Deutschmann
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 / ...)

2020-05-03 Thread Thomas Deutschmann
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

2020-04-26 Thread Thomas Deutschmann
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

2020-04-20 Thread Thomas Deutschmann
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

2020-04-12 Thread Thomas Deutschmann
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

2020-04-11 Thread Thomas Deutschmann
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

2020-04-11 Thread Thomas Deutschmann
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


  1   2   3   >