Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust

2022-01-20 Thread Piotr Karbowski




On 18/01/2022 00.24, Georgy Yakovlev wrote:

Hi,

I've been approached multiple times with that request, and a lot of
time I see new users completely destroyed by rust build time and disk
space requirements.

WDYT about switching order of rusts in a virtual?

RDEPEND="|| (
 ~dev-lang/rust-${PV}
 ~dev-lang/rust-bin-${PV}
)"


becomes

RDEPEND="|| (
 ~dev-lang/rust-bin-${PV}
~dev-lang/rust-${PV}
)"


Existing installs should be unaffected ofc.
But portage may prefer to depclean rust and not rust-bin if both are
present.
Users who wish to use source version at all times can just add it to
world file.

I see both positives and negatives of doing that, but would like to
reach out to community first.


I would prefer to have source based one first.

Ideally we'd have some way to mark binary packages with new EAPI and 
have FEATURES flag like 'prefer-binary' and go with -bin in case there's 
|| ( ) dependencies list, regardless of the original order in virtual. 
This way everyone could be happy and not choose one workflow over another.


-- Piotr.



Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

2022-01-04 Thread Piotr Karbowski




On 04/01/2022 20.18, Michael Orlitzky wrote:

On Tue, 2022-01-04 at 19:26 +0100, Piotr Karbowski wrote:


And none of which happens unless you intentionally trigger it.

...

Sure, acl and how chmod manipulate mask on ACL-enabled entities is not
very simple, but nothing will break by itself just because you have acl
support enabled, you would need to try very hard to run into problems.




Even if you're right, and if no other tools invoke tar, and the user is
smart enough not to copy/paste commands from the web, and if no other
archivers can extract ACLs when invoked directly or indirectly...
you're still burdening the user to either have faith that this is all
true, or to verify it himself. Repeat the argument for other flags like
ipv6, and you wind up requiring either a lot of faith, or a lot of
diligence, both of which are antithetical to basic principles of
security.

You may not buy the argument, but it's why people disable this stuff,
and the ability to disable it is why a lot of our users user Gentoo to
begin with.


I was challenging here your opinion that most people should disable acl 
support.


And what I showed is that, by keeping it enabled, does not bring on you 
potential problems beside possible security issues in the code that you 
keep around and not want to have around.


Sure, there are valid reasons to strip things from kernel, I've seen 
some tor nodes running kernel without input devices all out of 
initramfs, such usecase do make sense.


However I am strongly against opinion that most people should not enable 
acl, unless you have 16 MB NOR flash storage and every kB of kernel 
image counts, but then it's unlikely that you'd use gentoo there in the 
first place, since bundling headers and whole toolchain would east a lot 
of storage.


I know there are people who love to disable things, there are even 
people who says that pam is bloatware and strip it, or people who, 
security reason as they claim, refuse to use logind provider (elogind or 
systemd) and instead choose to run Xorg as root.


-- Piotr.



Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

2022-01-04 Thread Piotr Karbowski

Hi,

On 04/01/2022 18.35, Michael Orlitzky wrote:

On Tue, 2022-01-04 at 12:03 -0500, Mike Gilbert wrote:


I disagree with the claim that "most people" should disable ACL
support at build time. That just gives you partially functional tools.
The ACL behavior can generally be controlled using runtime options.


I understand why people would disagree in this case, but isn't that a
an argument for having the flag?

There are plenty of great uses for ACLs, but unless you're extremely
knowledgeable, they also add a million new ways to compromise your
system. For example, if you untar a file with a default-ACL'd directory
in it and don't notice the little plus sign, you might wind up
unknowingly creating world-writable files. Even if you do notice the
ACL, you have to be an expert in the interaction between umask,
permission bits, the ACL mask, effective permissions, conflicting ACLs,
and all of the tools you're using to understand what will actually
happen or how to properly fix it. It's not something normal people can
handle.

And none of which happens unless you intentionally trigger it.

1. To have ACL break things on new (extracted) files you'd first need to 
have default ACL set on parent directory where you extract to -- 
otherwise they won't be carried and no problem


2. unless you add --acl to both create and extract, no acl will be added 
to tarball and/or extracted onto system


Running 'tar --acl ...' or 'setfacl -d ...' does not happen by accident 
and argument that you should disable acl to not run into issues with 
above does not make much sense.


Sure, acl and how chmod manipulate mask on ACL-enabled entities is not 
very simple, but nothing will break by itself just because you have acl 
support enabled, you would need to try very hard to run into problems.


-- Piotr.



Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

2022-01-04 Thread Piotr Karbowski

Hi,

On 04/01/2022 18.03, Mike Gilbert wrote:

On Tue, Jan 4, 2022 at 12:31 AM Michael Orlitzky  wrote:


On Tue, 2022-01-04 at 03:38 +, Sam James wrote:


ACL is kind of similar to what Ionen said for PAM, i.e. sometimes
people may want to turn it off and it makes sense to expose
this option for those who do, but we don't need to try support it.



This is another important one. It has security implications, is highly
confusing, requires kernel support, and is nonstandard as a USE flag
and as an implementation. Most people should have it off to avoid
surprises, but disabling it in the kernel can make the userland
software complain when explicitly built with ACL support.


I disagree with the claim that "most people" should disable ACL
support at build time. That just gives you partially functional tools.
The ACL behavior can generally be controlled using runtime options.

Also, you might be able to get away with disabling ACL support on a
server, but desktop users will want ACL support enabled to get
properly functioning udev rules.



I second this.

As far as Desktop is concerned acl is basic feature that should be there 
along with extended attributes, for example, I am pretty sure 
systemd-login will use acl to grant access to inputs in /dev for the 
logged user.


acl is as much needed as support for multiple users (CONFIG_MULTIUSER), 
and it also needs support on kernel level, because without this symbol 
hardly anything will work for you. What I mean here is that argument 
'needs support in kernel' is not a problem, because everything does need 
a support in kernel. Try to boot without CONFIG_FUTEX as example, it can 
be disabled so you could say that it needs support in kernel in a way to 
constitute that this is something bad and thus should be avoided.


-- Piotr.



Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

2022-01-03 Thread Piotr Karbowski

Hi,

On 03/01/2022 18.16, Alec Warner wrote:

I'm trying to understand your principles here. Like on what basis do
you remove or add flags (in general).


My principals is to end-user experience over exposing as much as 
possible as USE flags.


A real life example

media-sound/deadbeef

	The .mp3 support can either use libmad or libmpg123. The first one is 
dead upstream, while code work currently with it, because it is dead, I 
rather avoid some setups where users setup +mad instead of +mpg123 that 
are mutually exclusive and run into some issues, like crashes, that 
would waste a lot of time on debugging it, so I made it that mp3 depends 
on libmpg123 without option for libmad. Some overlay-provided ebuilds 
for it do have option for libmad, I decided to not include it.


If you'd decide to give user a choice, you would make it as USE flag, 
but from end-user perspective it does not provide any benefit, and from 
maintainer perspective it's better to reduce error surface.


Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam 
shared, does not make sense to be togglable.


-- Piotr



Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

2022-01-02 Thread Piotr Karbowski

Hi,

On 02/01/2022 01.03, Scott Ellis wrote:

Your `ipv6` USE flag hits home - I don't use IPv6, nor do I want to have
IPv6 support built into things (just another potential "thing" that I have
to secure, or errors/warnings I need to suppress since I run an IPv6-less
kernel).

If there needs to be a path to culling USE flags, perhaps looking to which
flags actually cause packages to pull in additional dependencies (vs solely
enable/disable a feature) would be a better place to start?


And here I am having a deja vu, an associate of mine who happens to use 
Gentoo also intentionally runs without IPv6. When we were traveling out 
of country he was unable to use WIFI hotspot that I was connected to, 
turns out, it was IPv6-only hotspot with NAT64 gateway. I had internet 
access, he had rant about why IPv6-only networks are abomination  and 
that he never seen a network like it.


He won nothing, and neither do you win anything running without IPv6 
support.


-- Piotr.



[gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

2022-01-01 Thread Piotr Karbowski

Hi,

I'd like to get some insight how others see the concept of narrowing the 
scope of USE flags in Gentoo.


Taking a quote from devmanual:

  > USE flags are to control optional dependencies and settings which 
the user may reasonably want to select.


I'd like to focus on the 'reasonably want' here. While it is commonly 
agreed on that we interface as USE flags only things that make sense to 
be togglable, it is not always the case. It is not uncommon to see 
packages that puts every possible option as USE flag which hardly 
benefit anyone in some cases.


It creates artificial choice of USE flag that makes as much sense as 
building and trying to use solar-powered night vision googles. Possible 
to be engineered, but makes absolute no sense to exist, yet, there will 
be someone who will go with it and then things will not work in desired 
way, bugs will be reported, effort will be wasted on investigation and 
patching things up.


As example I'd like to use 'ipv6' USE flag, at the moment of writing 
this email there's 351 ebuilds in tree that expose ipv6 as USE flag, 
allow it to be disabled.


The thing is, it's 2022, and it does not make any sense to *not* support 
IPv6, even if one does not connect to any network with IPv6, there's no 
harm to just have it there.


While I am all for choice, I am for choice on things that do make sense. 
For instance, Linux kernel can be built with CONFIG_MULTIUSER=n, someone 
could argue that since Linux kernel, that is user-configured in Gentoo, 
can be built without support for other than UID 0, then Gentoo should 
support it. One of the extreme examples of not supporting something that 
does not make sense to be supported.


Beside 'ipv6', there are other USE flags that I have on mind. 'pam' 
being another of them.


Whats your view on it?

-- Piotr.



[gentoo-dev] Last rites: dev-python/pytaglib

2021-12-19 Thread Piotr Karbowski

# Piotr Karbowski  (2021-12-19)
# No package depends on those bindings anymore.
# Removal in 30 days.
dev-python/pytaglib



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

2021-11-25 Thread Piotr Karbowski

https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/glibc-2.34-r2.ebuild#L643


Would you see something like this on more ebuilds, postgres, mysql, 
elasticsearch, or have proper FEATURE flag for it instead?


It's all cool and giggles until you realize that even such random 
variable is not even prefixed with PORTAGE_ or anything, meaning it 
could be taken out of shell and meant for entirely different thing.


-- Piotr.



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

2021-11-25 Thread Piotr Karbowski

Hi,

On 25/11/2021 16.50, Pacho Ramos wrote:

As a side note, maybe ebuild should add sanity checks (like those from glibc) to
prevent downgrades, otherwise people could still accidentally hit the issue


You might have valid use cases to downgrade mysql, if you are okay not 
preserving data. I'd assume it's a common knowledge that downgrade of 
any data store, be that database or likes like elasticsearch, will 
corrupt the data.


To make it actually useful I think we'd need new EAPI feature 
'downgrade-protection', that unless is explicit ignored like 
--ignore-downgrade-protection mysql, it would prevent it from happening.


-- Piotr.



Re: [gentoo-dev] Call for testing from toolchain team: glibc-2.34

2021-11-11 Thread Piotr Karbowski
Happy to report that everything works fine with sys-libs/glibc-2.34-r1, 
I have rebuilt whole @world (1300+ packages) without a single failure, 
thought I did it without FEATURES=test.


I can sign off this glibc as good enough to go into ~arch.

-- Piotr.



Re: [gentoo-dev] Re: johu's packages up for grabs

2021-10-10 Thread Piotr Karbowski



On 10/10/2021 15.54, Piotr Karbowski wrote:
> Hi,
> 
> 
> On 10/10/2021 09.23, Joonas Niilola wrote:
>> Hey,
>>
>> due to inactivity the following packages are now up for grabs:
>> app-admin/calamares
>> app-admin/profile-cleaner
>> app-crypt/zulucrypt
>> app-doc/zsh-lovers
>> app-misc/screenfetch
>> dev-cpp/websocketpp
>> dev-libs/qtkeychain
>> dev-vcs/gti
>> media-sound/lollypop
>> net-im/discord-bin
>> net-misc/sshpass
>> net-vpn/openfortivpn
>> sys-apps/daemonize
>> sys-fs/fuse-zip
>> x11-apps/luit
>> x11-misc/compton
>> x11-misc/fpm2
>> x11-misc/obconf
>> x11-misc/sxhkd
>> x11-terms/xterm
>> x11-wm/bspwm
> 
> Took compton under myself and added x11 project into xterm since it's
> kind of default/fallback terminal for xorg.
> 
> -- piotr.
> 

I was not aware compton is to be dropped from tree. Ignore my takeover
and drop it as you see fit.

-- piotr.



[gentoo-dev] Re: johu's packages up for grabs

2021-10-10 Thread Piotr Karbowski
Hi,


On 10/10/2021 09.23, Joonas Niilola wrote:
> Hey,
> 
> due to inactivity the following packages are now up for grabs:
> app-admin/calamares
> app-admin/profile-cleaner
> app-crypt/zulucrypt
> app-doc/zsh-lovers
> app-misc/screenfetch
> dev-cpp/websocketpp
> dev-libs/qtkeychain
> dev-vcs/gti
> media-sound/lollypop
> net-im/discord-bin
> net-misc/sshpass
> net-vpn/openfortivpn
> sys-apps/daemonize
> sys-fs/fuse-zip
> x11-apps/luit
> x11-misc/compton
> x11-misc/fpm2
> x11-misc/obconf
> x11-misc/sxhkd
> x11-terms/xterm
> x11-wm/bspwm

Took compton under myself and added x11 project into xterm since it's
kind of default/fallback terminal for xorg.

-- piotr.



Re: [gentoo-dev] Packages up to co-maintenance

2021-07-03 Thread Piotr Karbowski
Hi,

On 02/07/2021 11.15, Marek Szuba wrote:
> On 2021-07-02 10:12, Sergei Trofimovich wrote:
> 
>> app-misc/mc
>> dev-util/ltrace
>> media-fonts/terminus-font
>> media-libs/aalib
> 
> Will attach myself to these four.
> 

I will join you on the following:
net-ftp/proftpd
app-misc/mc
x11-misc/xclipmedia-fonts/terminus-font

-- Piotr.



Re: [gentoo-dev] Packages up for grabs: x11-misc/gmrun

2021-01-17 Thread Piotr Karbowski
Hi,

On 17/01/2021 16.57, Jonas Stein wrote:
> Dear all
> 
> the following packages are up for grabs after dropping
> desktop-misc:
> 
> x11-misc/gmrun
> https://packages.gentoo.org/packages/x11-misc/gmrun

I will grab the gmrun.

-- Piotr.



[gentoo-dev] sys-power/bbswitch up for grabs

2020-12-26 Thread Piotr Karbowski
Hi,

I've been maintaining sys-power/bbswitch in the recent times, however, I
no longer have any hardware where I can even test it. If anyone sees it
fit, feel free to grab it and join other maintainers there. I just
dropped myself out of metadata.xml.

Open bugs:
- https://bugs.gentoo.org/761370
- https://bugs.gentoo.org/613338

-- Piotr.



Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-25 Thread Piotr Karbowski
Hi,

On 25/11/2020 22.57, Georgy Yakovlev wrote:
> systemd-tmpfiles does not depend on any systemd-isms, does not need dbus,
> and is just a drop-in replacement, the only step needed is to emerge the
> package.
> it's a simple single binary + manpage, binary links to libacl and couple other
> system libs.

Can confirm that systemd-tmpfiles works fine on OpenRC systems. Been
using it since end of October.

Two things that are different in terms of interface to opentmpfiles is
that systemd-tmpfiles does not have --dry-run runtime option, and it
will complain if any /usr/lib/tmpfiles.d/*.conf uses /var/run instead of
/run, but that's just an warning.

Regardless, it's just a drop-in replacement, have not noticed any issues.

-- Piotr.



Re: [gentoo-dev] GNU Guix

2020-09-29 Thread Piotr Karbowski
On 29/09/2020 16.02, William Breathitt Gray wrote:
> Cuckoo is a spam bot. The bot assumes the first response will be a user
> pointing out that the link is dangerous. So the bot's response is to
> respond back automatically with an aggressive denial in the hopes that
> more users will continue to click the spam link.

So the day has come when a script has fooled me. Thanks for clarification.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] GNU Guix

2020-09-29 Thread Piotr Karbowski
On 29/09/2020 14.26, Cuckoo's Calling wrote:
> You are so naive and I couldn't stop laughing.

I would appreciate it If you'd refrain from sending such messages to
mailing list, either go into details when you disagree with people or
don't reply at all. Those low level flexing is not welcome here.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Stabilisation of app-admin/ansible-2.10.0

2020-09-15 Thread Piotr Karbowski
Hi,

The current state is that the Ansible in tree is not working due to fact
that it misses core modules.

I'd say 2.10.0 should be masked, as ~arch or stable arch, it does not
work, then revbump to use bundle package, not ansible-base. If
maintainer want to split it into ansible-base + separated ebuilds for
modules, then maintainer should prepare a news item, as the update
replaces working Ansible with something that cannot work by itself, and
there's no interfaces to take in rest of needed parts as by now.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages are up for grabs: zathura and co

2020-08-27 Thread Piotr Karbowski
On 24/08/2020 13.57, Mikle Kolyada wrote:
> dev-libs/girara
> app-text/zathura-ps
> app-text/zathura-pdf-poppler
> app-text/zathura-pdf-mupdf
> app-text/zathura-djvu
> app-text/zathura-cb
> app-text/zathura
> 
> 
> Are for grabs now, I do not use them daily anymore. A separate active
> maintainer needed.
> 
> 

I will take over zathura packages since I use it on daily basis.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-11 Thread Piotr Karbowski
On 11/08/2020 15.38, Joonas Niilola wrote:
> 
> On 8/11/20 11:36 AM, Jaco Kroon wrote:
>> And I've already provided you one use case where udev doesn't work well
>> but eudev does.  I've also mentioned some historic issues I believe
>> should already be fixed but which did bit me in systemd-udev which was
>> never a problem in eudev.
>>
> Your systems seem to diverge a lot from what I'd consider as 'default'.
> You must already make many changes to them.
> 
> Before this thread I didn't even know/remember I was using eudev. It
> works and there doesn't seem to be any global issues related to it.
> However after reading this thread I'm a bit considered about the
> maintenance state of it.
> 
> Switched to udev. Simple as 'emerge -1 sys-fs/udev'. It works, didn't
> notice any difference.
> 
> If musl is a problem, to my knowledge musl has its own stage images, so
> why can't those stages use eudev while other ones defaulting to udev?

For the sake of science, I've also moved one of my systems to
sys-fs/udev and noticed a single incompatibility. There are few ways how
to disable the systemd/udev predictable NIC names, one of them is to
boot with net.ifnames=0, another is to mask rule file that trigger the
rename, as described on wiki[1]

Long story short, on eudev it's 80-net-name-slot.rules, on udev it's
80-net-setup-link.rules

The result was that my system booted without working network, as connman
started to poke around Ethernet interfaces (this is ok, I had
blacklisted eth*, not enp*), which then resulted in switching routing to
Ethernet that failed to get IP from DHCP, even that WiFi had a fully
working Internet access, so more like connman bug. (And yes, I am aware
that net.ifnames=0 will work on both)

This however shows two things: eudev is (no longer) drop-in replacement,
as some interfaces changed in upstream udev, which leads to second
thing, we need to have migration path, because even if(!) Gentoo change
default (I am not a fan of this idea really), then it might lead to
people doing fresh installation or reinstallation, migrating their
configs resulting in not working systems/working in other way that
previous one.

[1] https://wiki.gentoo.org/wiki/Udev#Keep_classic_.27eth0.27_naming

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Piotr Karbowski
Hi,

To summarize

- There's no known bugs in eudev that are not in udev
- There's no bug that would be fixed by switch from eudev to udev
- There's no new feature that would change eudev to udev bring
- Currently musl and glibc profiles uses common eudev, after change we
whould have musl profile users use something that glibc users are not using
- You don't like the original decision to switch to eudev so you want
now to use uno reverse card.
- eudev have single maintainer, but so far it did not had negative
impact on Gentoo

I see no reason to switch to sys-fs/udev by default, up until there's
actually a technical reason behind it. The eudev is a thing because
systemd upstream made it clear that they have no intention into keeping
udev operational unless it runs under systemd, which is quite important
here.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Last-rites: net-p2p/nicotine+

2020-07-18 Thread Piotr Karbowski
Hi,

On 18/07/2020 15.09, Andreas Sturmlechner wrote:
> # Andreas Sturmlechner  (2020-07-18)
> # Stuck on Python 2, depends on deprecated dev-python/pygtk, bug #708162.
> # Needs a maintainer and >=2.0.1 version bump. Masked for removal in 30 days.
> net-p2p/nicotine+
> 

Will pick it up.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-dev-announce] Last rites: */* More Py2 only items

2020-06-29 Thread Piotr Karbowski
On 29/06/2020 02.35, Aaron Bauman wrote:
> [...]
> net-dns/maradns

There's single python script that can work with Python3 (at least in new
version) that does that can just use any Python version.

I see that it did not got update for over a year, will take it over now and push
update tomorrow, then drop your mask on this package.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

2020-06-22 Thread Piotr Karbowski
Hi,

On 21/06/2020 22.27, Michał Górny wrote:
> No offense but it sounds a little chaotic to me.

Which is the reasons we do those reviews. Appreciate the suggestions,
just sent revision 2 as the response to the very first email in this
thread, please check how it looks now.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: News item: xorg-server dropping default suid

2020-06-22 Thread Piotr Karbowski
Title: xorg-server dropping default suid
Author: Piotr Karbowski 
Posted: 2020-06-22
Revision: 2
News-Item-Format: 2.0
Display-If-Installed: x11-base/xorg-server

Starting 2020-07-15, x11-base/xorg-server will default to using the
logind interface instead of suid by default. resulting in better
security by default through running the server as a regular user instead
of root. However, this will require our users to use a logind provider
such as elogind or systemd. The systemd users and those who are not
using systemd but use desktop profiles can stop reading here, as they
already have a logind provider enabled.

Others, who have neither systemd or desktop profiles enabled will be
required to globally enable 'elogind' USE flag and update the system

    # emerge --newuse @world

Afterwards, one will need to re-login, so the PAM can assign a seat. One
can confirm that a seat has been assigned upon login by running:

    $ loginctl user-status

Users who do not wish to use logind interface or have rare hardware that
does not use KMS and because of that, require root privileges to
operate, can manually re-enable 'suid' and disable 'elogind' USE flags
in order to preserve the previous behavior. However, please note that
this is heavily discouraged to run X server as root due to security
reasons. The 'suid' USE flag will remain as optional opt-in for the need
of legacy hardware.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

2020-06-22 Thread Piotr Karbowski
Hi,

On 22/06/2020 06.03, Philip Webb wrote:
[...]
> I don't want to use 'systemd', as I want to run a traditional UNIX version
> of Linux + KDE (or Fluxbox) for a simple single-user desktop system.

Then... don't use systemd? I officially give you my approval for that.
Read what you quoted in your email, elogind is standalone package.

The elogind does work normally in the configuration with OpenRC and startx.

> So i ask again : Why is running 'xorg-server' as root "heavily discouraged" ?
It's common sense to run software with the least privileges they
require, so if new attack vector is discovered, perhaps there will be no
escalation surface to make use of it.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: News item: xorg-server dropping default suid

2020-06-21 Thread Piotr Karbowski
Hi,

Re-sending news item inline.

###

Title: xorg-server dropping default suid
Author: Piotr Karbowski 
Posted: 2020-06-22
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: x11-base/xorg-server

The Gentoo X11 Team is announcing that starting with 15th of July,
the x11-base/xorg-server will no longer default to suid and will default
to using logind interface instead. This change makes xorg-server run as
regular user rather than root by default, however, those who do not have
any logind interface provider (either systemd or elogind) will need to
enable either to make it possible to run X session as unprivileged user.

No action is required from systemd and desktop profile users, since
systemd provides logind interface, and desktop profile already enables
'elogind' USE flag globally.

Rest of the non-systemd users is required to globally enable 'elogind'
USE flag and apply it by 'emerge --newuse @world', after which, re-login
is required so that PAM can allocate seat.

One can confirm that a seat has been assigned upon login by running:

$ loginctl user-status

Those who for whatever reason want to preserve current state, while
heavily discourage, can still use x11-base/xorg-server with 'suid -elogind'.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] News item: xorg-server dropping default suid

2020-06-21 Thread Piotr Karbowski
Hi,

Please find news item attached.

-- Piotr.
Title: xorg-server dropping default suid
Author: Piotr Karbowski 
Posted: 2020-06-22
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: x11-base/xorg-server

The Gentoo X11 Team is announcing that starting with 15th of July,
the x11-base/xorg-server will no longer default to suid and will default
to using logind interface instead. This change makes xorg-server run as
regular user rather than root by default, however, those who do not have
any logind interface provider (either systemd or elogind) will need to
enable either to make it possible to run X session as unprivileged user.

No action is required from systemd and desktop profile users, since 
systemd provides logind interface, and desktop profile already enables
'elogind' USE flag globally.

Rest of the non-systemd users is required to globally enable 'elogind'
USE flag and apply it by 'emerge --newuse @world', after which, re-login
is required so that PAM can allocate seat.

One can confirm that a seat has been assigned upon login by running:

$ loginctl user-status

Those who for whatever reason want to preserve current state, while
heavily discourage, can still use x11-base/xorg-server with 'suid -elogind'.


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2020-05-27 Thread Piotr Karbowski
Hi,

On 27/05/2020 01.31, Brian Dolbec wrote:
> * dev-python/boto3
> * dev-python/botocore

Do you mind if I join you on those? I use them a lot, and I planned to
comaintain awscli since Patrick is the only one current maintainer of
those, boto3 is vital part of it too.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.

2020-05-26 Thread Piotr Karbowski
Hi,

On 26/05/2020 09.23, Philip Webb wrote:
> 200526 Piotr Karbowski wrote:
>> On 26/05/2020 00.34, Philip Webb wrote:
>>> I'ld rather you didn't.
>> You didn't provided any rationale for that.
> 
> I thought I did (smile).
> 
>> Running X as root is anti-pattern, especially nowadays
>> when so little effort is required to not have to run it as root.
> 
> I've never run X as root : it's not the UNIX way.

I am not sure if you're trolling me here, or you genuinely not
understand that regardless of what user you execute `startx` on, if Xorg
have suid, it will start as root.

>> You can either enable elogind
> 
> Why would anyone want to abandon the long-successful UNIX method
> & adopt some complex replacement ?

I wouldn't call running X as root to be long successful UNIX method.
Back in the days there was no way to ran X without root, now there is.

>> or you can enable suid if you want to preserve your status quo,
>> we're talking here about defaults
>> that user can change if he has a reason to do so.
> 
> Yes, this is a regular problem which is unavoidable :
> what should the default be ? -- I want the default to be
> what it's always been & what matches basic UNIX principles.
> I can add 'suid' to 'xorg-server' in  package.use ,
> but why should I have to ? -- over to you for a rationale (smile).

I am not sure what kind of UNIX principles you're speaking about, the
default should be reasonable, running X as root is not, if someone want
to go against common sense and run X as root, he can do so, with
defaults to not run it as root.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.

2020-05-26 Thread Piotr Karbowski
Hi,

On 26/05/2020 00.34, Philip Webb wrote:
> I'ld rather you didn't.

You didn't provided any rationale for that. Running X as root is anti
pattern, especially nowadays when so little effort is required to not
have to run it as root.

You can either enable elogind, or you can enable suid if you want to
preserve your status quo, we're talking here about defaults that user
can change if he has a reason to do so.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.

2020-05-25 Thread Piotr Karbowski
Hi,

For years the xorg-server in Gentoo was defaulting to be running with
suid, even those that does not really require it, like systemd users and
those who runs elogind still end up with X as uid 0 because of +suid
default.

Times has changed, we now have +elogind in desktop profile, xorg-server
can no longer work without udev (due to input drivers), so there's no
real benefit for defaulting to suid.

There are 3 common ways the xorg-server is started:

- via XDM of some sort, usually forked as root, does not require suid,
systemd or elogind.
- via better XDM that can into logind interface, started as regular user
thanks to logind interface provided by either systemd or elogind.
- via `startx`, if systemd or elogind are present, can work without
suid, without them, suid is required.

Flipping current '+suid (-)elogind' as *default* USE flags on ebuild
level into '+elogind (-)suid' will not affect first two use cases, and
affect only 3rd one if neither systemd is used, or elogind is enabled.

What I'd like to go with is to enable elogind and disable suid on ebuild
level. The systemd profiles have use.mask for elogind, meaning it's not
a problem for them. and those who do not want to use any logind provider
can still opt-out out of it and go back to use suid. It shouldn't really
affect most of the users in any negative way, if anything, it will make
more users to not run Xorg as root, which is a positive aspect.

The alternative way would be to enable elogind on default profile,
however it would also affect those who run headless Gentoo, of which a
lot refuse to use any login manager.

So, dear people of Gentoo, what do you think about turning the current
possible opt-out of Xorg as root into possible opt-in for running Xorg
as root? People still will have a choice, just the defaults will be more
sane.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: x11-drivers/xf86-input-{keyboard,mouse}

2020-05-03 Thread Piotr Karbowski
# Piotr Karbowski  (2020-05-03)
# Obsolete input drivers, use x11-drivers/xf86-input-libinput
# or x11-drivers/xf86-input-evdev instead.
# Removal in 30 days.
x11-drivers/xf86-input-keyboard
x11-drivers/xf86-input-mouse

For more information see
https://gitweb.gentoo.org/data/gentoo-news.git/tree/2020-04-03-deprecation-of-legacy-x11-input-drivers/2020-04-03-deprecation-of-legacy-x11-input-drivers.en.txt

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: News item: Deprecation and removal of legacy X11 input drivers.

2020-04-02 Thread Piotr Karbowski
Hi,

On 02/04/2020 17.26, Piotr Karbowski wrote:
> Hi,
> 
> Updated with what Ulm and Soup pointed out, while keeping the long
> sentence, that even it's long, is still beneficial to have. Revision
> bumped to 2, date bumped to tomorrow's.

My apology, s/Soup/Soap/.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: News item: Deprecation and removal of legacy X11 input drivers.

2020-04-02 Thread Piotr Karbowski
Hi,

Updated with what Ulm and Soup pointed out, while keeping the long
sentence, that even it's long, is still beneficial to have. Revision
bumped to 2, date bumped to tomorrow's.

--- news item below ---

Title: Deprecation of legacy X11 input drivers
Author: Piotr Karbowski 
Posted: 2020-04-03
Revision: 2
News-Item-Format: 2.0
Display-If-Installed: x11-drivers/xf86-input-mouse
Display-If-Installed: x11-drivers/xf86-input-keyboard

The Gentoo X11 Team is announcing the deprecation and future removal of
the legacy X11 input drivers x11-drivers/xf86-input-mouse and
x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers
will be masked for removal.

These drivers have been deprecated for many years, first by
xf86-input-evdev and then by xf86-input-libinput.

The only use for those drivers remain in deployments which intentionally
opt-out of using udev, as both evdev and libinput require udev during
runtime, however given that upstream has already removed the Linux
support from xf86-input-keyboard, future X11 releases will no longer
support xf86-input-keyboard on Linux rendering those installation
infeasible to use without udev.

In order to ensure frictionless upgrade path for future X11 releases, we
have decided to deprecate those drivers that are not in active use by
pretty much any installation of Gentoo.

No action is required from end-users who are already using libinput (or
evdev). To check which driver is in use, one can use

$ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log

for the systems running xorg-server as regular user (-suid
+elogind/+systemd) or by running

# grep 'Using input driver' /var/log/Xorg.0.log

for those running xorg-server as root.

If however neither libinput or evdev is in use, one should append
'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf
while removing 'keyboard' and 'mouse' if present, then update @world
with new USE flags

# emerge -N @world

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] News item: Deprecation and removal of legacy X11 input drivers.

2020-04-01 Thread Piotr Karbowski
Title: Deprecation and removal of legacy X11 input drivers.
Author: Piotr Karbowski 
Posted: 2020-04-02
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: x11-drivers/xf86-input-mouse
Display-If-Installed: x11-drivers/xf86-input-keyboard

The Gentoo X11 Team is announcing the deprecation and future removal of
the legacy X11 input drivers x11-drivers/xf86-input-mouse and
x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers
will be masked for removal.

These drivers have been deprecated for many years, first by
xf86-input-evdev and
then by xf86-input-libinput.

The only use for those drivers remain in deployments which intentionally
opt-out of using udev, as both evdev and libinput require udev during
runtime, however given that upstream has already removed the Linux
support from xf86-input-keyboard, future X11 releases will no longer
support xf86-input-keyboard on Linux rendering those installation
infeasible to use without udev.

In order to ensure fraction-less upgrade path for future X11 releases,
we have decided to deprecate those drivers that are not in active use by
pretty much any installation of Gentoo.

No action is required from end-users who are already using libinput (or
evdev). To check which driver is in use, one can use

$ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log

For the systems running xorg-server as regular user (-suid
+elogind/+systemd) or by running

# grep 'Using input driver' /var/log/Xorg.0.log

for those that still runs xorg-server as root.

If however neither libinput or evdev is in use, one should append
'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf
and update @world with new USE flags

# emerge -N @world




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

2019-12-18 Thread Piotr Karbowski
Hi,

On 18/12/2019 22.08, Michał Górny wrote:
> I know that's an unhappy idea but maybe it's time to include CMake
> in stage3.  Then it would be just a matter of temporarily enabling
> bundled libs for stage builds, I guess.

Not sure what's unhappy about it, but I like the idea, it will be
painless for new users with rather limited cost of ownership on Gentoo side.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers

2019-10-21 Thread Piotr Karbowski
Hi,

I'd like to bring the topic of defining default policy to do changes to
packages within ::gentoo that one does not maintain.

This topic goes back from time to time on #gentoo-dev, and as I was
told, it was originally sent to gentoo-dev mailing list by robbat2 (I
failed to find this in archive, so if anyone have copy of it, please share).

Current policy is to never touch ebuild that one did not claim as
maintainer unless maintainer of said package allowed you to do so.

This is a bit unhealthy, especially when some developers that maintain
packages are out of reach, or the patches to update ebuild just rot on
the bugzilla and are not taken in by maintainers.

What I'd like to end with would be to set a policy that allows any
developer with write access to ebuilds tree do changes that are small in
scope, like a minor bug fixes, adding missing flags, version bumps,
anything, that does not require complete overhaul of ebuild, with the
option to set in metadata.xml that policy for specified package is to
deny anyone but maintainers from doing changes.

The packages that would require a flag to prohibit non-maintainers from
doing changes would of course be those of toolchain, or other big in
user base packages that are in very good shape, as in gnome packages,
kde packages, X11 packages and so on.

Of course, the policy would also define, that if there are any bug
introduced by changes that non-maintainer made, it's responsibility of
those who did the change in first place to fix it and clean any mess
that it has created.

I personally am fine with others doing changes to packages I own, as
long as they won't break anything and I do know from the discussion on
#gentoo-dev, that there are others who have similar opinion about it.

Those who feel territorial and those who believe only maintainers should
maintain specified packages can just set the flag in metadata.xml and
continue with the current state of things for their packages.

The reason why I would like to get default policy to allow-all is that I
do not believe most of developers would want to go around all the
packages they own and set it manually to allow others doing changes even
if they're fine with others touching those packages.

What do you think folks?

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

2019-09-29 Thread Piotr Karbowski
Hi,

On 29/09/2019 11.56, Michał Górny wrote:
> WDYT?

You mean using HTTPS-only mirrors in 3rdparty mirrors? I am on board
with that.

Ideally, we would switch all of Gentoo resources to HTTPS too. I had a
short discussion about it in #-infra where I was looking for distfiles
and stage3 snapshots mirror roundrobin that is https enabled, this of
course require a huge changes and it unlikely come anytime soon, but for
what's it worth, I think no official Gentoo resource should default to
non encrypted HTTP, and the only http enabled traffic should be a 301
HTTP redirect to https address.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] dev-python/fabric up for grabs

2019-05-11 Thread Piotr Karbowski
On 11/05/2019 18.00, Virgil Dupras wrote:
> Although I don't use it anymore because I find it too heavy for my
> needs, Ansible is generally seen as a good replacement.

FWIW Ansible does not seems that heavy when you realize that you can put
a exec bit on a playbook, set shebang to ansible-playbook, set it to
being a locally executed and define tasks within playbook itself, like:

#!/usr/bin/env -S ansible-playbook -i localhost,

- name: playbook
  gather_facts: false
  connection: local
  hosts: localhost
  tasks:
- name: foo
  debug:
msg: 'blah'

Gets the job done really well.

-- Piotr.



Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

2019-03-22 Thread Piotr Karbowski
Hi,

For time being the IUSE has been reverted to the old +suid, elogind is
now opt-in and not enabled by default. This preserves the old,
working-for-everyone-everywhere default flags.

-- Piotr.


pEpkey.asc
Description: application/pgp-keys


Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

2019-03-22 Thread Piotr Karbowski
Hi,

On 22/03/2019 21.47, Andreas Sturmlechner wrote:
> Therefore, not one single package, unless it hard-depends on exactly-one-of ( 
> elogind systemd ) should enable elogind by default at this time. Doing so now 
> only makes people switch it off globally either before or after they are 
> facing 
> runtime issues.
> 
> Let's fix the remaining bugs, create a proper news item in advance, and then 
> switch over desktop profiles to elogind as the new default.

So, what you propose is to go IUSE="+suid elogind" on xorg-server for
now, until elogind has full blown support, and then enabling +elogind in
desktop profile?

I am not a big fan of that, but for sure, that would address the issues,
however I am really worried about what to do later with xorg-server. I
*really* do not want suid to be enabled there by default permanently, if
we go the following route, do you think it's feasible to then still
default to +elogind -suid on xorg-server? I understood now that
consolekit clash with elogind, but maybe it's something to handle on
consolekit level, to block elogind from being installed?

This way the users of default profile would defaults to elogind on
xorg-server, and if they desire to use consolekit, they will need to add
-elogind for xorg-server, and adding +suid if they do not use DM that
starts X for them as root.

-- Piotr.


pEpkey.asc
Description: application/pgp-keys


Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

2019-03-22 Thread Piotr Karbowski
Hi,

On 22/03/2019 21.43, Brian Evans wrote:
> What are the implications, if any, of using DMs which are not aware of
> {,e}logind?  Do they work without modification?

My understanding is that such DMs, like lightdm, fork X as root anyway,
so there's no implication here, regardless if you have -elogind or
+elogind on xorg-server. Even more, you can have -suid -elogind -systemd
on xorg-server for lightdm and it will work, as again, it starts as root.

The relation between xorg-server and elogind is that pam_elogind.so
provides user upon login with variables like $XDG_VTNR, that Xorg then
uses, when you start X as user, to start X on the very same virtual
terminal that one logged in, and then, elogind (started via dbus or
manually) pass the SETMASTER ioctl.

-- Piotr.


pEpkey.asc
Description: application/pgp-keys


[gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

2019-03-22 Thread Piotr Karbowski
Hi,

I'd like to discuss here the current state of elogind integration as a
whole, and the follow-up work that is now required, after I've put a
default on local USE flag +elogind on xorg-server while dropping default
suid flag in my commit yesterday.

The motivation on the changes was to follow up the removal of default
+suid that happened in November last years, that sadly had to be
reverted. Now with elogind integration, non-systemd users got all that
they need to run Xorg as a unprivileged user.

The status of xorg-server at this very moment is that it no longer
defaults to be merged with suid, however, now it defaults to +elogind.
This have the following implications:

- User will be prompted that pambase requires +elogind, which is not
enabled by default -- meaning that simple `emerge xorg-server` will
prompt user to add package.use entry. This could be solved by always
having the elogind bits enabled, the same way a gnome-keyring is, so the
pam_elogind.so is used if present. This shouldn't have any negative
effect on for instance systemd users, as systemd cannot be installed at
the same time as elogind.

- systemd users that does not use systemd profiles will be required to
alter package.use or make.conf USE flags definition to drop -elogind
there, as otherwise xorg-server will refuse to be merged due to
at-most-one-of ( elogind systemd ) condition there. However those
systemd users that do use systemd profiles will not run into any things
to do, as systemd's use.mask have elogind there.

- The desktop profiles enables +consolekit, which conflicts with elogind
-- the users of those profiles will need to adjust USE flags.

- OpenRC/non-systemd users are now able to run X without suid, as
elogind is the entity that wraps the SETMASTER, no more "ioctl
permission denied" on starting X as unprivileged user.

After speaking with some of you on #-dev and #-desktop I know that the
opinions on that vary, arguably enabling elogind local USE flag on
xorg-server was somewhat ahead of time, leaving some users in
unfavorable position where the xorg-server installation will require
them to manually modify package.use/make.conf.

Some of the ideas that were pointed on IRC (forgive me if I missed some):

- We should go back to +suid -elogind default.
- We should actually NOT put suid on Xorg if USE="suid elogind" but put
suid bit with USE="suid -elogind".
- We should only ever enable elogind in desktop profiles.

Personally I'd like to stay without enabling suid by default on
xorg-server, as otherwise hardly anyone will ever drop the suid from it,
which would be a big step back. Gentoo tried to drop suid from
xorg-server a handful of times, let's make the current one a final one :)

I'd like to propose doing the following:

- Keywording elogind on missing archs
- Making elogind a global USE flag
- Switching desktop profiles to elogind from consolekit while still
preserving -suid +elogind on xorg-server for those that does not use
desktop profiles (systemd profiles users not affected)
- Making pambase always install the configuration for pam_elogind.so,
the same way it does for pam_gnome_keyring.so at this very moment,
effectively removing elogind USE flag from it.

What do you all think about?

-- Piotr.


pEpkey.asc
Description: application/pgp-keys