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


Re: [gentoo-dev] zoom concerns

2020-04-07 Thread Thomas Deutschmann
On 2020-04-07 12:35, Alessandro Barbieri wrote:
> What about moving all of these binary-only packages in an official overlay
> (made for the scope) or in GURU?

And which problem is that going to solve?

Do we want to tell world, "Look! Gentoo is the most secure distribution!
We have zero vulnerabilities*!"

*Because we move vulnerable packages to an overlay!

Please, don't get me wrong. But the whole thread looks like pure
activism to me. It looks like most people don't understand any details
but have the feeling "but we must do *anything*". This ignores the fact,
that most discussed issues in Zoom for example are found/caused by the
installer. Something we don't have in the Linux version. Or requires
write access into Zoom application directory which also doesn't affect
us (this is BTW a can Google opened years ago when they tried to get
market shares and were looking for a way to allow users to just install
their software without asking their IT department. Since then it became
'normal' to install software in user profile. The problem: This allows
any user process to modify these files, plant exploits to abuse
vulnerable loaders and stuff like that you don't have when you do proper
ACLs).

Regarding bin/non-bin: Software has bugs. Some software tends to have
more issues. Just because we have the source code and compile software
on user's system doesn't make the application itself more secure than
the provided binary package.


-- 
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] zoom concerns

2020-04-07 Thread Thomas Deutschmann
On 2020-04-07 10:48, Ulrich Mueller wrote:
> We could add a README.gentoo file with our caveats. It won't be perfect,
> but maybe better than nothing. (And certainly better than displaying a
> warning on every upgrade, which will eventually annoy people [1].)

I am strictly against something like this.

We have a lot of packages with *confirmed* *serious* problems. Zoom is
not special to warrant a special treatment in any way.

More important: Until today, not one single vulnerability discussed in
public recently got confirmed for the Linux version.

Sure, that could have banal reasons like "No one audited the Linux
version yet". But in security you don't issue warnings if you aren't
sure. Because if you make false statements people will no longer trust
you. But trust is everything.


-- 
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] zoom concerns

2020-04-02 Thread Thomas Deutschmann
Hi,

it's true that zoom is currently getting a lot of attention. It all
started with the iOS application using Facebook SDK to provide login
through Facebook and their TOS/privacy statement.

That triggered a lot of (security) researchers who are currently sitting
at home like most people in western world with a lot of time. If
upstream will address all problems this will become one of the best
(free-)audited conference software available ;-)

For this discussion please keep in mind that there are multiple versions
for different platforms. Not every platform is affected by all reported
problems.

Regarding zoom and Gentoo: net-im/zoom doesn't require any special
handling in Gentoo. Package is not even marked stable. We have a lot of
vulnerable packages...

If problems will get confirmed for the available Linux version and
upstream won't provide a fix within ~12 months (depends on severity of
reported vulnerabilities) we maybe decide to last-rite or apply a mask
to force user awareness through forced unmask action in case they need
that software. But again, this software isn't special and doesn't
require further discussion from our P.O.V.


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Thomas Deutschmann
On 2020-03-19 04:03, Kent Fredric wrote:
> Because that experiment basically failed.
> 
> Bugs with that flag, basically were treated (repeatedly) like that flag
> wasn't there.

Hehe, maybe because of missing tooling. Common tools like tatt don't
understand "ALLARCHES" :)


-- 
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: noarch keyword

2020-03-18 Thread Thomas Deutschmann
Hi,

please don't introduce another keyword.

Why can't we use "ALLARCHES" stabilization for that?

However, this will getting more complicated than it will help.
Any Python package which compiles something can fail. During my x86 work
I have seen a lot of problems when it comes to anything math related (no
SSE2, -mfpmath=387...). So as long as we want that a package keyworded
for x86 really works on old x86 hardware, we have to go the long route
an test 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] Last rites: dev-python/*, python-maintained, py3.6-only, no-revdep

2020-03-07 Thread Thomas Deutschmann
Hi,

www-apps/nikola was now moved away from python project and unmasked.

For reference, www-apps/nikola is heavily in use by the Gentoo e.V. in
Germany (surprising when you watch git log, not?). Gentoo e.V. is also
running Gentoo stable and Python 3.6 is the current stable version.
Python 3.7 will become the successor but isn't yet... so please calm
down regarding "But it doesn't support Py 3.7+ yet". We will add that
support in future when time permits.

The main problem is that Python project has decided to ignore common
rules and established a new disruptive way to tackle current problems.

I don't say that it isn't a problem that pyt...@gentoo.org became
maintainer of thousands of package the project never wanted. I don't
have a solution for that problem but I would suggest to start with a
honest mask like

> Packages mask for removal because Python project no longer
> wants to maintain these packages

This is without any judgment. It's just a fact. But please stop
spreading FUD that these packages are blocking, outdated or not well
maintained.

So if Python project has decided to go the disruptive road (yes, I am
aware that we don't have a better mechanism like setting a mask to get
attention), you have to deal with the fact that this is disruptive and
that not everyone like that.

But please, nobody is publicly shaming anyone. If you play that card,
don't wonder that people will stop talking.

Don't read too much into everything.


-- 
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] Changes made by acct-* ebuilds

2020-02-14 Thread Thomas Deutschmann
> # usermod -aG thomas postfix
> # id postfix
> uid=207(postfix) gid=207(postfix)
groups=207(postfix),12(mail),1004(thomas)
> # emerge -a1 acct-user/postfix
> [...]
>
> >>> Installing (1 of 1) acct-user/postfix-0::gentoo
>  * checking 0 files for package collisions
> >>> Merging acct-user/postfix-0 to /
> >>> Safely unmerging already-installed instance...
> No package files given... Grabbing a set.
> >>> Regenerating /etc/ld.so.cache...
> >>> Original instance of package unmerged safely.
>  * Updating groups for user 'postfix' ...
>  *  - Groups: postfix,mail
> >>> acct-user/postfix-0 merged.
> >>> Auto-cleaning packages...
>
> [...]
>
> # id postfix
> uid=207(postfix) gid=207(postfix) groups=207(postfix),12(mail)
>


...and if you read that council meeting log and even the mail discussion
before you will read that I always shared concerns about touching
existing user. I was only fine because I was told "We are aware, what
you described won't happen" and I didn't make a secret that I didn't had
the time to fully review and test myself at this time. Now I had the
time to 'play' with this and it looks like all my previous concerns are
true.


-- 
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] Changes made by acct-* ebuilds

2020-02-14 Thread Thomas Deutschmann
On 2020-02-14 16:38, Mike Gilbert wrote:
> Could you just explain please? I’m not inclined to read through the
> handbook and rebuild a system to guess what this horrible breakage might
> be.

My point is, that even the handbook tells user to modify groups. I.e.
you should add your user to group X for being able to do Y...

That's OK. That's normal.

But if everything in Gentoo has migrated to acct-* stuff, these changes
will get reverted once the user will re-emerge world including acct-*
package or such a package will get updated for some reason.

This is unexpected. Also, I hope nobody expects that every user using
sudo for example needs to maintain an own acct-*/sudo fork in his/her
overlay in future just because in Gentoo, you cannot use normal Linux
tools like usermod anymore because your changes might get resetted
during some upgrade.

That's what currently might happen with the current implementation which
tries to keep user/group state like described in package. Something you
will only see in Gentoo and no other distribution.


-- 
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] Changes made by acct-* ebuilds

2020-02-14 Thread Thomas Deutschmann
On 2020-02-13 17:17, Mike Gilbert wrote:
> I don't agree that this should be happen by default. I suspect the
> majority of users do not wish to manage system users/groups
> themselves.

Follow handbook to get a working system and rebuild entire world. You
will get surprised.

This is really a bad default and it's breaking with existing principles
you can find in most distributions: Don't touch stuff which were changed
by the user.


-- 
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] Changes made by acct-* ebuilds

2020-02-12 Thread Thomas Deutschmann
Hi,

thank you for bringing this to the list.

I have the same experience which is the reason why I haven't migrated
most of my packages yet (which is not a good move because I also didn't
post the problem to the list like I wanted *yet*, I only talked to
people via private mail, chat or at FOSDEM about that and was working on
a proposal I wanted to show next week when I am hopefully healthy again).

In short: It was a very bad decision that acct-* stuff is *changing*
existing stuff. This must be turned of *by default*. Maybe provide a
setting a user can put into make.conf to opt into current, still new,
behavior but by default, a package should never ever make changes to
*existing* user (unless it knows for sure it was the only source
creating that user and nothing was changed since creation which isn't
easy to track).

My example is a little bit different:

Please think about all the systems which are managed using some kind
configuration management tool (Puppet, Ansible, Salt, Chef...). It's
really common and there's is nothing wrong to make use of usermod for
example to alter users. All of the tools I mentioned have 'templates'
(=ready to use scripts to set up common software) which will make use of
things like usermod. The problem: You never expect that something in the
OS will get rid of your changes and will revert to something the package
manager believes should be the default.

In environments where you only have to deal with Gentoo, we maybe have
created something *new* which allows for new possibilities, see
https://wiki.gentoo.org/wiki/OpenDKIM#The_new_way

However, this is very bad: Configuration management tools are common
these days. While we also have systemd which helps at least to provide
some kind of interface allowing user to set timezone, time
sychonization, hostname and other general settings the same way across
different distribution, configuration management tools are also an
abstraction layer: You write 'recipes' or 'playbooks', describe 'states'
in a general language and the used cfm tool will know all the
implementation details. So in the end it doesn't matter if you apply
your configuration against Debian, Fedora, RHEL or Gentoo -- the system
you run your code against should be in the described state after all.
That's at least the idea ;-)

Thanks to the new way how we manage user in Gentoo that's no longer the
case: Suddenly you cannot use basic tools like usermod to make changes
to users anymore because you cannot be sure that these settings won't be
reverted.

Also, the idea to create *packages* to represent user configuration
doesn't scale. I already outlined that issue in [1]. Simple example:

You have two services (SerivceA and ServiceB) both using the same
package (say www-servers/nginx). We are talking about something like
'real application server'. While you can overwrite user/group via ebuild
once, you can't do it multiple times for *different* roles. Especially
when you have to deal with some kind of 'dynamic' stuff (see the
Jenkins' discussion). Creating your own acct-* repository *per role*
can't scale (aside the fact that it will be impossible to tell user,
"Yeah... for Gentoo you just cannot use 'append user X to group sudo'
syntax you use in your cfm tool. Instead you have to fork
acct-group/sudo and put user into that ebuild and ensure that this
version is installed). Also, don't forget about servers executing
multiple roles at the same time: It's easier to describe something like
"Make sure user X is in group Y" vs. making sure you have that single
acct-* ebuild creating user X or group Y with everything you ever need
right from the beginning.

tl;dr
We need to change current acct-* eclasses to not change things (i.e. not
changing home, groups...). At least if user/group were created/modified
outside of PM.


See also:
=
[1]
https://archives.gentoo.org/gentoo-dev/message/05c9b211eb18012d16302194a7bc37e6


-- 
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] New QA Policy Guide

2020-01-19 Thread Thomas Deutschmann
On 2020-01-19 12:46, Ulrich Mueller wrote:
>>>>>> On Sun, 19 Jan 2020, Michał Górny wrote:
> 
>> The sources are stored in proj/policy-guide.git [3].  If you wish to
>> submit your own changes, you can either use the 'Policy Guide' bugzilla
>> component [4] and/or GitHub mirror [5].
> 
> Please, no github for official policies. We should have a permanent
> paper trail for this kind of things, which isn't guaranteed if the
> discussion would happen entirely on github.
> 
> Besides, by the Social Contract we cannot rely on a non-free service
> for anything official.

I would second that but this would also apply to devmanual.

And at some point it will also affect contribution to Gentoo repository
at Github itself: Sure, eclass changes require ML review but sometimes
comments contain valuable information especially for the future when
someone wants to understand why an ebuild was changed that way.

That's why Debian created https://salsa.debian.org/, Fedora has
https://src.fedoraproject.org/ ...


-- 
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] Vanilla sources

2020-01-04 Thread Thomas Deutschmann
On 2020-01-04 12:01, Rich Freeman wrote:
> Packages without security support should be masked.  Really I don't
> see the point of even having this in the repo.

THIS! +infinite

And arches without security support in general can't have stable keywords.

But this is a dream. :-/


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Thomas Deutschmann
On 2020-01-04 14:08, Roy Bamford wrote:
> emerge -1 vanilla-sources
> eselect kernel ...
> genkernel all
> ...

Please tell user to do

genkernel --kernel-config=/proc/config.gz all

by default which will give them a better experience because new kernel
will be build based on kernel configuration from current running kernel.
Without providing a kernel config, user will probably fall back to
generic configuration which isn't intended for daily usage.


-- 
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] News Item: Genkernel 4 changed default kernel and initramfs filename

2019-12-30 Thread Thomas Deutschmann
Hi,

news item has been published:

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=b53539af13d77a7ad811327b677b9933e1dfb1b0


-- 
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] News Item: Genkernel 4 changed default kernel and initramfs filename

2019-12-27 Thread Thomas Deutschmann
On 2019-12-27 17:32, Ulrich Mueller wrote:
>> Title: Genkernel 4 changed default kernel and initramfs filename
> 
> Too long, GLEP 42 allows a maximum of 50 characters.

*sigh*

So maybe just

  Title: Genkernel 4 changed default filenames



PS: Where were you when

https://www.gentoo.org/support/news-items/2019-07-18-syncthing-update-incompatibility.html

and

https://www.gentoo.org/support/news-items/2019-11-25-rpi-firmware-dtb-files.html

were posted? :-)


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [RFC] News Item: Genkernel 4 changed default kernel and initramfs filename

2019-12-27 Thread Thomas Deutschmann
Title: Genkernel 4 changed default kernel and initramfs filename
Author: Thomas Deutschmann 
Posted: 2019-12-27
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: >=sys-kernel/genkernel-4

To be consistent with kernel's own naming which allows for easier
matching of kernel/initramfs with kernel files (/lib/modules),
genkernel 4 changed default kernel and initramfs filename:

kernel-genkernel-%%ARCH%%-%%KV%%  -> vmlinuz-%%KV%%
System.map-genkernel-%%ARCH%%-%%KV%%  -> System.map-%%KV%%
initramfs-genkernel-%%ARCH%%-%%KV%%   -> initramfs-%%KV%%.img

Note that in genkernel 4, filenames are fully customizable and that
$ARCH value is now part of $KV value by default.

All bootloaders and utilities like sys-apps/kexec-tools available in
Gentoo repository support the new naming schema.

However, due to lexical ordering, the default boot entry in your boot
manager could still point to last kernel built with genkernel before
that name change, resulting in booting old kernel when not paying
attention on boot.


-- 
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 2/4] acct-user/jenkins: Add jenkins user, UID 473

2019-12-26 Thread Thomas Deutschmann
Hi,

On 2019-12-26 16:28, Michael Orlitzky wrote:
>> And would I really have to create my own acct-*/nginx user+group
>> ebuild to mirror my myapp use case? In other words: Thanks to GLEP
>> 81, in Gentoo, you can no longer use known default Linux utilities
>> like usermod to maintain your system and make changes to
>> users/groups created by packages, instead you will always have to
>> 'fork' involved acct-*/ package and adjust for your needs?
> 
> That's right, but you're making it sound worse than it is. You also 
> cannot use known default tools like rm, mv, cp, and your text editor
> to change things installed by system packages, because those changes
> will get overwritten the next time that the package is upgraded or 
> reinstalled. Now user/group management works the same way.
> 
> If you want to change something that belongs to the system, you
> override and tweak the package that installs it. It's consistent, and
> you don't have to tell people to install puppet/salt/etc. as a
> special case just to make users work like everything else. Those were
> always band-aids for the lack of a better way to do it.

Why can't I use rm, mv, cp or text editor to change things?

System configuration management is abstraction. You don't care about
details like if you are using Debian, RHEL or Gentoo. This is
implemented in used tool. You only define "states":

- Make sure user X is present and member of group Y.

- Make sure directory /var/foo exists and is owned by x:y.

- Make sure service Z is installed.

- Make sure your configuration for service Z is installed.

- Make sure service Z is enabled and running.

*You* don't need to know if you have to use apt, yum or emerge to get Z
installed. This is something the tool (puppet, ansible, salt, chef...)
will know and take care of. You will probably manage a mapping of
package names on your own so that you can always say "Install Z" but on
Debian your configuration management tool will install openssh-server
and on Gentoo it will just be a package named net-misc/openssh.

You can deploy your own configuration (=replace /etc/ssh/sshd_config) or
you can say "Make sure /etc/ssh/sshd_config contains 'PermitRootLogin
without-password'" or that "/etc/php/fpm-php7.4/ext-active/foo.ini" is
absent on Gentoo which will translate to "[[ ! -f
/var/lib/php/modules/7.4/fpm/disabled_by_admin/foo]] && phpdismod -v 7.4
-s fpm foo ]]"
on Debian.


>> Things like
>> 
>> https://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html
>>
>> 
https://docs.ansible.com/ansible/latest/modules/user_module.html
>> 
>> which are commonly used to apply configurations can't be used
>> anymore?!
> 
> You don't need them any more, there's a better way to do it.

Ever deployed a custom Tomcat application for example? Sure, you have
dozen ways to do that. Like dev-util/jenkins-bin, you could create your
own package. But if you have to maintain various operating systems you
will write a role/state, see above. Or if this is your own in-house
application it could be easier that your CI pipline will just copy to
/srv/myapp/$buildid on each application server and to flip
/srv/myapp/current symlink so you can update/rollback in seconds and to
support staggered deployment.

My point is, it's pointless to say there are better ways. Making Gentoo
special because you can't use well established things which are working
on every other distribution and would require that everyone would
rewrite their states/roles and/or implement something new just to keep
Gentoo supported is not going to happen.


> I don't completely understand your example, but it doesn't sound
> like something that should be particularly hard. Can you elaborate
> before I stick my foot in my mouth?

Heh :)

In you example user would have to fork acct-*/ package in
his/her overlay to adjust for his/her needs. At the moment, all larger
Gentoo setups I am aware of are maintaining a company repository in
addition to the official Gentoo repository. So they would put
acct-user/nginx-0-r1 and acct-group/nginx-0-r1 in that repository with
their changes. But this doesn't work if you have multiple different
nginx instances for example. Sure, the forked acct-* packages would work
for all the application servers running this specific role/state. But
these adjusted packages would be wrong for the servers running grafana
role/state, i.e. running www-apps/grafana-bin behind www-servers/nginx
proxy. So you would end up with multiple acct-*/nginx ebuilds for each
configuration which can't be right. Whereas at the moment you will use
your configuration management tool to get things into describe state.


-- 
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 2/4] acct-user/jenkins: Add jenkins user, UID 473

2019-12-26 Thread Thomas Deutschmann
On 2019-12-26 14:42, Michael Orlitzky wrote:
> So before you push this, I would figure out what you want the Jenkins
> user to look like on your machine, and add an -r1 of acct-user/jenkins
> in a local overlay that configures it how you want. At that point, you
> can drop the usermod calls from your configuration management tools.
> 
> For the benefit of those other users, it would be extra nice if you
> could document how to do all that. I recently had to do the same thing
> for OpenDKIM, because the old instructions that were gave were being
> wiped out on upgrades and reinstalls:
> 
>   https://wiki.gentoo.org/wiki/OpenDKIM#The_new_way
> 
> Then if the home directory is only needed by people who are going to be
> overriding the acct-user ebuild anyway, you might as well leave
> ACCT_USER_HOME at the default and let people set it in their overlays.

Now, after reading the wiki for OpenDKIM I am more concerned than
before: We are also changing groups?!

Let me show you an example:
System has www-servers/nginx installed which created nginx user+group
via user eclass.

Now let's say I have a custom application for which I created user+group
"myapp".

I add nginx user to myapp group to allow nginx to access files from
myapp to serve application.

My current understanding is that during www-servers/nginx migration to
GLEP-81, i.e. when www-servers/nginx ebuild will pull in acct-user/nginx
and acct-group/nginx for the first time, the acct-* thing will do

  local groups=${ACCT_USER_GROUPS[*]}
  esetgroups "${ACCT_USER_NAME}" "${groups// /,}"

which would remove nginx from myapp group to match ACCT_USER_GROUPS set
in acct-*/nginx ebuild which would break my application server. Does
that really happen?

And would I really have to create my own acct-*/nginx user+group ebuild
to mirror my myapp use case? In other words: Thanks to GLEP 81, in
Gentoo, you can no longer use known default Linux utilities like usermod
to maintain your system and make changes to users/groups created by
packages, instead you will always have to 'fork' involved acct-*/
package and adjust for your needs?

Things like

https://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html
https://docs.ansible.com/ansible/latest/modules/user_module.html

which are commonly used to apply configurations can't be used anymore?!

Which will become funny if you are maintaining multiple systems: On one
system you have said "myapp", but on another system you would have a
second application named "myapp2". So you cannot even share repositories
between your systems anymore or would have to ensure somehow that system
A which acts as application server for "myapp" will only get
acct-*/- and system B which will
act as application server for "myapp2" will get
acct-*/- instead?! Not
to mention what will happen if you get a third system which will be able
to run multiple nginx instances, one for myapp and one for myapp2... ;]


-- 
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 2/4] acct-user/jenkins: Add jenkins user, UID 473

2019-12-26 Thread Thomas Deutschmann
On 2019-12-26 12:04, Michael Orlitzky wrote:
> On 12/25/19 10:11 AM, Thomas Deutschmann wrote:
>> +ACCT_USER_HOME=/var/lib/jenkins
> Needed?

I cannot answer that for sure. In *my* setups I need a valid home for
standard SSH setup (~/.ssh/authorized_keys). But there are dozen ways
how you can run and use Jenkins...

For myself I am probably not going to use Gentoo's acct-* stuff. While
*I* need valid HOME for jenkins' user to get working SSH setup without
any additional configuration I also store services in
/srv/ instead of /var/lib. I am still scared to death
that when I change HOME (usermod) which is part of my Salt state
(configuration management) that acct-* stuff will revert at some point
and break dozen of clusters ;]


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 4/4] dev-util/jenkins-bin: bump to v2.210

2019-12-25 Thread Thomas Deutschmann
Package-Manager: Portage-2.3.82, Repoman-2.3.20
Signed-off-by: Thomas Deutschmann 
---
 dev-util/jenkins-bin/Manifest |  1 +
 dev-util/jenkins-bin/jenkins-bin-2.210.ebuild | 47 +++
 2 files changed, 48 insertions(+)
 create mode 100644 dev-util/jenkins-bin/jenkins-bin-2.210.ebuild

diff --git a/dev-util/jenkins-bin/Manifest b/dev-util/jenkins-bin/Manifest
index 854cbb4f581..678e7c5e3a5 100644
--- a/dev-util/jenkins-bin/Manifest
+++ b/dev-util/jenkins-bin/Manifest
@@ -4,3 +4,4 @@ DIST jenkins-bin-2.190.3.war 78247363 BLAKE2B 
99d4c13236b4b4f7308c7993033d1e5f9d
 DIST jenkins-bin-2.197.war 78309466 BLAKE2B 
c3d34c6fc40a82148eafa978c8787375ece6522d0d936b42f0296ee13cd084669bfa31975c0ad27816bdd4c1266cb066c0909774199a1373661a7ec524c06e91
 SHA512 
3b6a00dee5aeb8a94c8f75323c2469b54fe96d90bf8371898e41dc5bdecaa472f112bff1466481c66c9c7a07b22cbe799a08e45ac486d68fd5bdc7c20d43d722
 DIST jenkins-bin-2.204.1.war 63433755 BLAKE2B 
53cb254ddf3b59e083b564adf8d5696c61012e6d0d26b622eac7023268d5ba3d43082d07cae5654e032169cd144a5338f2553d4ee39c851c4126fe0be5378f1e
 SHA512 
2ebf1ff7792a2ba80d8cf6f8675864580533b62659346e9ef3334ff988899d735d5d72cb3a89308cd9287bcaa74c42306cbf80a716d03658ad748688f94f394b
 DIST jenkins-bin-2.205.war 62738246 BLAKE2B 
de350469e3a6e0d93f6d05c38f7669ce630f01a0284db83a0ba002e15ef712b4dddca6dcac804ab45c898f5c73cdac99bfe9b9bb99f6534c1446d8f4545660ec
 SHA512 
1c0b12cdf7dadaba8d81ede769f76b059c7869732610353658cc928dd8c4943f8cf8beb15498a0dd4e064688cfdb7f88faaa9165c6da97c20d5e99080a12f413
+DIST jenkins-bin-2.210.war 62752366 BLAKE2B 
02124970276a8c0edf8946413bd109a9835e047fd7e96bd05dfdb3454e3603720d6f6a630fb9f2a26a6431c30ed560116a3f40aabfaa5bb2667d80ef5909cd35
 SHA512 
fc4f64c0c2e7b4269b8b9e67332d7749ab8bd415b8fa1dc6df26529fc3164b57de49a71390f335b728ac2faeb3a1dfa148fd9bf3fc814e897efb484c1e226d8e
diff --git a/dev-util/jenkins-bin/jenkins-bin-2.210.ebuild 
b/dev-util/jenkins-bin/jenkins-bin-2.210.ebuild
new file mode 100644
index 000..45f7e332969
--- /dev/null
+++ b/dev-util/jenkins-bin/jenkins-bin-2.210.ebuild
@@ -0,0 +1,47 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit systemd
+
+DESCRIPTION="Extensible continuous integration server"
+HOMEPAGE="https://jenkins.io/;
+LICENSE="MIT"
+SRC_URI="http://mirrors.jenkins-ci.org/war/${PV}/${PN/-bin/}.war -> ${P}.war"
+RESTRICT="mirror"
+SLOT="0"
+KEYWORDS="~amd64 ~x86 ~amd64-linux"
+IUSE=""
+
+COMMON_DEPS="acct-user/jenkins
+   acct-group/jenkins"
+
+DEPEND="${COMMON_DEPS}"
+
+RDEPEND="${COMMON_DEPS}
+   media-fonts/dejavu
+   media-libs/freetype
+   !dev-util/jenkins-bin:lts
+   >=virtual/jre-1.8.0"
+
+S=${WORKDIR}
+
+JENKINS_DIR=/var/lib/jenkins
+
+src_install() {
+   keepdir /var/log/jenkins ${JENKINS_DIR}/backup ${JENKINS_DIR}/home
+
+   insinto /opt/jenkins
+   newins "${DISTDIR}"/${P}.war ${PN/-bin/}.war
+
+   insinto /etc/logrotate.d
+   newins "${FILESDIR}"/${PN}-r1.logrotate ${PN/-bin/}
+
+   newinitd "${FILESDIR}"/${PN}.init2 jenkins
+   newconfd "${FILESDIR}"/${PN}.confd jenkins
+
+   systemd_newunit "${FILESDIR}"/${PN}.service2 jenkins.service
+
+   fowners jenkins:jenkins /var/log/jenkins ${JENKINS_DIR}/home 
${JENKINS_DIR}/backup
+}
-- 
2.24.1




[gentoo-dev] [PATCH 3/4] dev-util/jenkins-bin: bump to v2.204.1

2019-12-25 Thread Thomas Deutschmann
Package-Manager: Portage-2.3.82, Repoman-2.3.20
Signed-off-by: Thomas Deutschmann 
---
 dev-util/jenkins-bin/Manifest |  1 +
 .../jenkins-bin/jenkins-bin-2.204.1.ebuild| 47 +++
 2 files changed, 48 insertions(+)
 create mode 100644 dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild

diff --git a/dev-util/jenkins-bin/Manifest b/dev-util/jenkins-bin/Manifest
index 39d97b60d3e..854cbb4f581 100644
--- a/dev-util/jenkins-bin/Manifest
+++ b/dev-util/jenkins-bin/Manifest
@@ -2,4 +2,5 @@ DIST jenkins-bin-2.190.1.war 78245883 BLAKE2B 
6c80eaebc6fe34e2c889c78a34dfc3e105
 DIST jenkins-bin-2.190.2.war 78243424 BLAKE2B 
7a6bd4cf1c070ce3a09fb84b3dbe7e87f474f4254dd4b4fcffdd7dedf7d4c2ba91d8783e727321439bfeb02da721e4d539cba76312c21b523a9bf336a964
 SHA512 
b1f59ef10dfdfda06bedbf9a40a9e83e159b44b2b5574cba4d62547294386224f64d856490fd4477fb3300a4119d17fc284819719218dfcf32d3dc20ce468847
 DIST jenkins-bin-2.190.3.war 78247363 BLAKE2B 
99d4c13236b4b4f7308c7993033d1e5f9dd2fd9926febf52ffdacea595fecaba0d0eb8962761d8a6f983eaf9738f8be1ba4df785bb2fe6b613ac8cadcc618e23
 SHA512 
4ffa2ce3be4d55f0df8021026115d9ce8f1d0f4faa16eaf9f327ce17105f61731730c2a0124fb9af5d8c16c8fee9200f9b785b23856896e292a19f5404a9d2c2
 DIST jenkins-bin-2.197.war 78309466 BLAKE2B 
c3d34c6fc40a82148eafa978c8787375ece6522d0d936b42f0296ee13cd084669bfa31975c0ad27816bdd4c1266cb066c0909774199a1373661a7ec524c06e91
 SHA512 
3b6a00dee5aeb8a94c8f75323c2469b54fe96d90bf8371898e41dc5bdecaa472f112bff1466481c66c9c7a07b22cbe799a08e45ac486d68fd5bdc7c20d43d722
+DIST jenkins-bin-2.204.1.war 63433755 BLAKE2B 
53cb254ddf3b59e083b564adf8d5696c61012e6d0d26b622eac7023268d5ba3d43082d07cae5654e032169cd144a5338f2553d4ee39c851c4126fe0be5378f1e
 SHA512 
2ebf1ff7792a2ba80d8cf6f8675864580533b62659346e9ef3334ff988899d735d5d72cb3a89308cd9287bcaa74c42306cbf80a716d03658ad748688f94f394b
 DIST jenkins-bin-2.205.war 62738246 BLAKE2B 
de350469e3a6e0d93f6d05c38f7669ce630f01a0284db83a0ba002e15ef712b4dddca6dcac804ab45c898f5c73cdac99bfe9b9bb99f6534c1446d8f4545660ec
 SHA512 
1c0b12cdf7dadaba8d81ede769f76b059c7869732610353658cc928dd8c4943f8cf8beb15498a0dd4e064688cfdb7f88faaa9165c6da97c20d5e99080a12f413
diff --git a/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild 
b/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
new file mode 100644
index 000..f29b83b491f
--- /dev/null
+++ b/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
@@ -0,0 +1,47 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit systemd
+
+DESCRIPTION="Extensible continuous integration server"
+HOMEPAGE="https://jenkins.io/;
+LICENSE="MIT"
+SRC_URI="http://mirrors.jenkins-ci.org/war-stable/${PV}/${PN/-bin/}.war -> 
${P}.war"
+RESTRICT="mirror"
+SLOT="lts"
+KEYWORDS="~amd64 ~x86 ~amd64-linux"
+IUSE=""
+
+COMMON_DEPS="acct-user/jenkins
+   acct-group/jenkins"
+
+DEPEND="${COMMON_DEPS}"
+
+RDEPEND="${COMMON_DEPS}
+   media-fonts/dejavu
+   media-libs/freetype
+   !dev-util/jenkins-bin:0
+   >=virtual/jre-1.8.0"
+
+S=${WORKDIR}
+
+JENKINS_DIR=/var/lib/jenkins
+
+src_install() {
+   keepdir /var/log/jenkins ${JENKINS_DIR}/backup ${JENKINS_DIR}/home
+
+   insinto /opt/jenkins
+   newins "${DISTDIR}"/${P}.war ${PN/-bin/}.war
+
+   insinto /etc/logrotate.d
+   newins "${FILESDIR}"/${PN}-r1.logrotate ${PN/-bin/}
+
+   newinitd "${FILESDIR}"/${PN}.init2 jenkins
+   newconfd "${FILESDIR}"/${PN}.confd jenkins
+
+   systemd_newunit "${FILESDIR}"/${PN}.service2 jenkins.service
+
+   fowners jenkins:jenkins /var/log/jenkins ${JENKINS_DIR}/home 
${JENKINS_DIR}/backup
+}
-- 
2.24.1




[gentoo-dev] dev-util/jenkins-bin GLEP-81 migration

2019-12-25 Thread Thomas Deutschmann
Hi,

please see my first package migration to GLEP 81.

Complete change set can be found at https://github.com/gentoo/gentoo/pull/14121.

Previous ebuilds using user eclass called

  fowners jenkins:jenkins /var/log/jenkins ${JENKINS_DIR} ${JENKINS_DIR}/home 
${JENKINS_DIR}/backup

which I changed to

  fowners jenkins:jenkins /var/log/jenkins ${JENKINS_DIR}/home 
${JENKINS_DIR}/backup

in assumption that $JENKINS_DIR is now maintained through acct-* package.

I changed chmod for $HOME to 0750 which should be a safer default.

Thanks.





[gentoo-dev] [PATCH 1/4] acct-group/jenkins: Add jenkins group, GID 473

2019-12-25 Thread Thomas Deutschmann
Package-Manager: Portage-2.3.82, Repoman-2.3.20
Signed-off-by: Thomas Deutschmann 
---
 acct-group/jenkins/jenkins-0.ebuild |  9 +
 acct-group/jenkins/metadata.xml | 12 
 2 files changed, 21 insertions(+)
 create mode 100644 acct-group/jenkins/jenkins-0.ebuild
 create mode 100644 acct-group/jenkins/metadata.xml

diff --git a/acct-group/jenkins/jenkins-0.ebuild 
b/acct-group/jenkins/jenkins-0.ebuild
new file mode 100644
index 000..0786846c589
--- /dev/null
+++ b/acct-group/jenkins/jenkins-0.ebuild
@@ -0,0 +1,9 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-group
+
+DESCRIPTION="Jenkins program group"
+ACCT_GROUP_ID=473
diff --git a/acct-group/jenkins/metadata.xml b/acct-group/jenkins/metadata.xml
new file mode 100644
index 000..de8ce22b371
--- /dev/null
+++ b/acct-group/jenkins/metadata.xml
@@ -0,0 +1,12 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   patr...@gentoo.org
+   Patrick Lauer
+   
+   
+   gra...@gentoo.org
+   Hans de Graaff
+   
+
-- 
2.24.1




[gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

2019-12-25 Thread Thomas Deutschmann
Package-Manager: Portage-2.3.82, Repoman-2.3.20
Signed-off-by: Thomas Deutschmann 
---
 acct-user/jenkins/jenkins-0.ebuild | 13 +
 acct-user/jenkins/metadata.xml | 12 
 2 files changed, 25 insertions(+)
 create mode 100644 acct-user/jenkins/jenkins-0.ebuild
 create mode 100644 acct-user/jenkins/metadata.xml

diff --git a/acct-user/jenkins/jenkins-0.ebuild 
b/acct-user/jenkins/jenkins-0.ebuild
new file mode 100644
index 000..b3f9a003cd6
--- /dev/null
+++ b/acct-user/jenkins/jenkins-0.ebuild
@@ -0,0 +1,13 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="Jenkins program user"
+ACCT_USER_ID=473
+ACCT_USER_HOME=/var/lib/jenkins
+ACCT_USER_HOME_PERMS=0750
+ACCT_USER_GROUPS=( jenkins )
+acct-user_add_deps
diff --git a/acct-user/jenkins/metadata.xml b/acct-user/jenkins/metadata.xml
new file mode 100644
index 000..de8ce22b371
--- /dev/null
+++ b/acct-user/jenkins/metadata.xml
@@ -0,0 +1,12 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   patr...@gentoo.org
+   Patrick Lauer
+   
+   
+   gra...@gentoo.org
+   Hans de Graaff
+   
+
-- 
2.24.1




Re: [gentoo-dev] RFC: acct-user/... modifies existing user sometimes

2019-12-14 Thread Thomas Deutschmann
On 2019-12-14 21:47, The Bit Pit wrote:
> acct-user/mythtv modifies the existing user if that user is not logged
> in. Mythtv has been around for years and users have created specialized
> configurations for the mythtv user. They do not like changes to the
> mythtv user when upgrading.

Could you please be a little bit more precise what's changing?

acct-* shouldn't mess with already *existing* users. So upgrade
experience shouldn't be affected...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


  1   2   3   >