8:23 a.m.
Hi!
I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
the PATH.
Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
where the old system-installed executable written in Python (from
/usr/bin) is launched, but it finds new Python sources (installed into
$HOME) which it doesn't work with and crashes.
[bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
I believe the current configuration breaks the intuitive expectation
that things installed closer to the user should take priority. That's
for example how it works with Python.
Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
PATH (though Ubuntu has ~/bin) so we can't take guidance there.
Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
Regards,
Tomas
8:30 a.m.
On Wed, May 2, 2018 at 6:24 AM Tomas Orsava <torsava(a)redhat.com> wrote:
Hi!
I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
the PATH.
Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
where the old system-installed executable written in Python (from
/usr/bin) is launched, but it finds new Python sources (installed into
$HOME) which it doesn't work with and crashes.
[bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
I believe the current configuration breaks the intuitive expectation
that things installed closer to the user should take priority. That's
for example how it works with Python.
Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
PATH (though Ubuntu has ~/bin) so we can't take guidance there.
Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
Yes, if a user's account is compromised (or any service running as them),
it's REALLY easy to drop faked tools into a user-private directory and
override critical system tools (like replacing 'bash' with a keylogger).
8:33 a.m.
On 05/02/2018 03:30 PM, Stephen Gallagher wrote:
On Wed, May 2, 2018 at 6:24 AM Tomas Orsava <torsava(a)redhat.com
<mailto:torsava@redhat.com>> wrote:
Hi!
I'd like to propose putting the ~/.local/bin in front of the
/usr/bin on
the PATH.
Currently /usr/bin has priority over ~/.local/bin, which causes a
[bug]
where the old system-installed executable written in Python (from
/usr/bin) is launched, but it finds new Python sources (installed
into
$HOME) which it doesn't work with and crashes.
[bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
I believe the current configuration breaks the intuitive expectation
that things installed closer to the user should take priority. That's
for example how it works with Python.
Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
PATH (though Ubuntu has ~/bin) so we can't take guidance there.
Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
Yes, if a user's account is compromised (or any service running as
them), it's REALLY easy to drop faked tools into a user-private
directory and override critical system tools (like replacing 'bash'
with a keylogger).
However, if the user's account is compromised, it's just as easy to
change the definition of PATH.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
8:44 a.m.
On 2.5.2018 15:30, Stephen Gallagher wrote:
Does anyone see a reason not to prioritize ~/.local/bin over
/usr/bin?
Yes, if a user's account is compromised (or any service running as
them), it's REALLY easy to drop faked tools into a user-private
directory and override critical system tools (like replacing 'bash' with
a keylogger).
If user's account is compromised, user's PATH can be changed. IMHO the
provided argument is not valid.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:46 a.m.
On Wed, May 2, 2018 at 6:44 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 2.5.2018 15:30, Stephen Gallagher wrote:
> Does anyone see a reason not to prioritize ~/.local/bin over
/usr/bin?
>
>
> Yes, if a user's account is compromised (or any service running as
> them), it's REALLY easy to drop faked tools into a user-private
> directory and override critical system tools (like replacing 'bash' with
> a keylogger).
If user's account is compromised, user's PATH can be changed. IMHO the
provided argument is not valid.
There are a lot of ways where their account can be compromised without
having complete session access. If they're running a web-connected
application as their user, that application could be compromised to write a
file to disk. If that file can now supersede the system copy, they have now
escalated the degree of the compromise.
8:53 a.m.
On Wed, May 02, 2018 at 01:46:34PM +0000, Stephen Gallagher wrote:
On Wed, May 2, 2018 at 6:44 AM Miro Hrončok
<mhroncok(a)redhat.com> wrote:
> On 2.5.2018 15:30, Stephen Gallagher wrote:
> > Does anyone see a reason not to prioritize ~/.local/bin over
> /usr/bin?
> >
> >
> > Yes, if a user's account is compromised (or any service running as
> > them), it's REALLY easy to drop faked tools into a user-private
> > directory and override critical system tools (like replacing 'bash'
with
> > a keylogger).
>
> If user's account is compromised, user's PATH can be changed. IMHO the
> provided argument is not valid.
>
>
There are a lot of ways where their account can be compromised without
having complete session access. If they're running a web-connected
application as their user, that application could be compromised to write a
file to disk. If that file can now supersede the system copy, they have now
escalated the degree of the compromise.
If they can write a file to disk, they can just replace $HOME/.bashrc to
set $PATH or any number of other things that can escalate to the same
degree. You either need MAC or some kind of ocontainer based solution for
the user's apps to prevent a compromised app escalating to own the entire
session. $PATH ordering offers no meaningful protection.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
9:08 a.m.
On Wednesday, May 2, 2018 3:46:34 PM CEST Stephen Gallagher wrote:
On Wed, May 2, 2018 at 6:44 AM Miro Hrončok
<mhroncok(a)redhat.com> wrote:
> On 2.5.2018 15:30, Stephen Gallagher wrote:
> > Does anyone see a reason not to prioritize ~/.local/bin over
>
> /usr/bin?
>
> > Yes, if a user's account is compromised (or any service running as
> > them), it's REALLY easy to drop faked tools into a user-private
> > directory and override critical system tools (like replacing 'bash'
with
> > a keylogger).
>
> If user's account is compromised, user's PATH can be changed. IMHO the
> provided argument is not valid.
There are a lot of ways where their account can be compromised without
having complete session access. If they're running a web-connected
application as their user, that application could be compromised to write a
file to disk. If that file can now supersede the system copy, they have now
escalated the degree of the compromise.
You have two choices:
1. Either you allow users to easily install software to their home directory.
If their user account is compromised, an attacker can install some software
they do not want to install, but it still affects their user account only.
2. You do not allow users to easily install software to their home directory.
In that case, they will install questionable software using sudo, which
gives it root privileges and affects all other users on the system (and
possibly other systems reachable through a trusted network).
Which of those choices is more secure?
Kamil
9:25 a.m.
On Wed, 2 May 2018, Kamil Dudka wrote:
On Wednesday, May 2, 2018 3:46:34 PM CEST Stephen Gallagher wrote:
> On Wed, May 2, 2018 at 6:44 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> On 2.5.2018 15:30, Stephen Gallagher wrote:
>>> Does anyone see a reason not to prioritize ~/.local/bin over
<snip>
You have two choices:
1. Either you allow users to easily install software to their home directory.
If their user account is compromised, an attacker can install some software
they do not want to install, but it still affects their user account only.
2. You do not allow users to easily install software to their home directory.
In that case, they will install questionable software using sudo, which
gives it root privileges and affects all other users on the system (and
possibly other systems reachable through a trusted network).
Which of those choices is more secure?
if they've got sudo privs to install software in the system area as root
then any malicious program is going to emulate su/sudo in which case
you're rooted in both scenarios.
Is there any reason the OP can't use alias to override the system command
with the local one? that's what we used to do back in the '90s
Kamil
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Iain Rae - Computing Officer | iainr @ inf. ed. ac. uk
School of Informatics, Univ of Edinburgh | Tel: +44 131 6505202
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
11:50 a.m.
On Wednesday, May 2, 2018 4:25:58 PM CEST Iain Rae wrote:
if they've got sudo privs to install software in the system area
as root
then any malicious program is going to emulate su/sudo in which case
you're rooted in both scenarios.
In order to emulate su/sudo, the binary needs to have special permissions.
Programs downloaded by web browsers do not get them and non-privileged users
cannot grant such permissions.
I just wanted to say that many users would not need sudo access at all if they
were able to install software to their home directory in a way that it works
out of the box.
Kamil
4:57 p.m.
On 02/05/18 17:50, Kamil Dudka wrote:
On Wednesday, May 2, 2018 4:25:58 PM CEST Iain Rae wrote:
> if they've got sudo privs to install software in the system area as root
> then any malicious program is going to emulate su/sudo in which case
> you're rooted in both scenarios.
In order to emulate su/sudo, the binary needs to have special permissions.
Programs downloaded by web browsers do not get them and non-privileged users
cannot grant such permissions.
ah so something like :
#!/bin/bash
ME=`whoami`
echo [sudo] password for $ME
read -s PASSWD
echo $PASSWD >> /tmp/.stash
echo $PASSWD |sudo -S $* > /dev/null
probably wouldn't work then ;)
I just wanted to say that many users would not need sudo access at all if they
were able to install software to their home directory in a way that it works
out of the box.
oh yes, that would be the ideal situation, and if ~/.login/bin is
so
standard you'd think that things like pip would check to see if there
was a more up to date version of themselves in there and run it rather
than the system installation.
Kamil
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
3:39 a.m.
On 05/02/2018 11:57 PM, Iain Rae wrote:
On 02/05/18 17:50, Kamil Dudka wrote:
> On Wednesday, May 2, 2018 4:25:58 PM CEST Iain Rae wrote:
>> if they've got sudo privs to install software in the system area as root
>> then any malicious program is going to emulate su/sudo in which case
>> you're rooted in both scenarios.
> In order to emulate su/sudo, the binary needs to have special permissions.
> Programs downloaded by web browsers do not get them and non-privileged users
> cannot grant such permissions.
ah so something like :
#!/bin/bash
ME=`whoami`
echo [sudo] password for $ME
read -s PASSWD
echo $PASSWD >> /tmp/.stash
echo $PASSWD |sudo -S $* > /dev/null
probably wouldn't work then ;)
> I just wanted to say that many users would not need sudo access at all if they
> were able to install software to their home directory in a way that it works
> out of the box.
oh yes, that would be the ideal situation, and if ~/.login/bin is so
standard you'd think that things like pip would check to see if there
was a more up to date version of themselves in there and run it rather
than the system installation.
pip actually checks if ~/.local/bin is on the PATH and prints a warning
if it isn't. But nobody predicted that ~/.local/bin might be on the PATH
but only behind /usr/bin. That breaks the intuitive expectation that
things installed closer to the user should take priority. Python works
like that.
Tomas
> Kamil
>
>
>
4:42 a.m.
On 03/05/18 09:39, Tomas Orsava wrote:
>
<snip>
>> I just wanted to say that many users would not need sudo
access at
>> all if they
>> were able to install software to their home directory in a way that
>> it works
>> out of the box.
> oh yes, that would be the ideal situation, and if ~/.login/bin is so
> standard you'd think that things like pip would check to see if there
> was a more up to date version of themselves in there and run it rather
> than the system installation.
pip actually checks if ~/.local/bin is on the PATH and prints a
warning if it isn't. But nobody predicted that ~/.local/bin might be
on the PATH but only behind /usr/bin. That breaks the intuitive
expectation that things installed closer to the user should take
priority. Python works like that.
Oh I suspect someone predicted it I or else noone reads the fish book
any more. The standard advice I've heard/read since the year dot is to
append rather than prepend ~ or $HOME paths, I guess that makes me old
fashioned
At the very least it seems like a fairly obvious thing to check for or
at least pop up a warning for. If your software breaks because your
users don't do what you expect then you're going to have fragile
software, I've found that life tends to work like that.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
11:23 a.m.
On Thu, 3 May 2018, Tomas Orsava wrote:
pip actually checks if ~/.local/bin is on the PATH and prints a
warning if it
isn't. But nobody predicted that ~/.local/bin might be on the PATH but only
behind /usr/bin. That breaks the intuitive expectation that things installed
closer to the user should take priority. Python works like that.
It is easy to get into a bike-shed painting contest about what
is and is not 'intuitive'
But there is also the expectation of 'least surprise' in a
Unix (tm) culture, and I think it is rather without question
that:
PATH is initially set by conscious design at
deployment, and have NOT included per user
variations as a default as a matter of 'how we got here'
By convention additions to the path come LAST in priority,
because of well known privilege escalation attack approaches
(the incautious admin sits down at a 'trapped' nominally sick
workstation, and fails to use a fully qualified path to 'su'
or 'sudo' , or omits to add the '-' to cause PATH cleansing).
Incautious admins do this do this once, git bitten, and learn
their lesson to use fully qualified paths on workstations, on
in accounts, they do not control. I _understand_ that there
are lots of ways to seek escalated privileges in *nix ...
But do we really need to be adding MORE, and hidden ones with:
a. 'breaks expectation' early in the PATH precedence?
b. 'invisible' directories in the PATH
Local convention here is a ~/bin/ directory, and I think this
is a widely observed one
I understand the assertion that 'the next new thing' may well
have lurked unread and unimplemented, and not been widely
implemented until recently, adding:
~/.local/
- or -
~/local/
But defaulting to this needs to be generally accepted,
detailed in Release Notes, well communicated, and easy to
revert out. It is NOT something that one user asking for it,
and an XKCD cartoon should drive
I would suggest this is a major change, and needs
Fedoraproject Council 'buy in' as to a plan for change, rather
than simply being imposed by fiat
-- Russ herrold
3:50 a.m.
On 03/05/18 12:23 -0400, R P Herrold wrote:
By convention additions to the path come LAST in priority,
because of well known privilege escalation attack approaches
(the incautious admin sits down at a 'trapped' nominally sick
workstation, and fails to use a fully qualified path to 'su'
or 'sudo' , or omits to add the '-' to cause PATH cleansing).
Either the admin does one of those things, or they're screwed anyway
because a user (or attacker with access to the user's account) who
wants to escalate their privileges can edit the user's PATH. The user
can always do that, whether Fedora puts ~/.local/bin early in the PATH
by default or not.
I don't think I like the idea of putting it early in the PATH by
default, but I don't have a solid argument for why I don't like it.
None of the "security" arguments presented are convincing though.
4:31 a.m.
On 4.5.2018 10:50, Jonathan Wakely wrote:
I don't think I like the idea of putting it early in the PATH by
default, but I don't have a solid argument for why I don't like it.
Thanks. Honestly, that's the feeling I get form this discussion. People
don't like it, so they try to explain the reasons why it's bad and so
far they fail IMHO.
None of the "security" arguments presented are convincing
though.
Exactly.
I think that Debian/Ubuntu doing this, is also a strong argument (I
mean, we are not doing it because of them, but we know it's not untested
waters).
Somebody said this probably needs a Fedora Change. Should we prep one?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:33 a.m.
On 4 May 2018 at 05:31, Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 4.5.2018 10:50, Jonathan Wakely wrote:
>
> I don't think I like the idea of putting it early in the PATH by
> default, but I don't have a solid argument for why I don't like it.
Thanks. Honestly, that's the feeling I get form this discussion. People
don't like it, so they try to explain the reasons why it's bad and so far
they fail IMHO.
> None of the "security" arguments presented are convincing though.
Exactly.
I think that Debian/Ubuntu doing this, is also a strong argument (I mean, we
are not doing it because of them, but we know it's not untested waters).
Somebody said this probably needs a Fedora Change. Should we prep one?
I would do so for the following reasons:
1. Even though the security arguments are weak, they are going to be
checkmarks on audits which can't be changed for years.
2. When someone gets a "remove this and find out why the OS did this"
it helps if they can point to an "official" change versus an email.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
8:42 a.m.
On 2018-05-04 09:33, Stephen John Smoogen wrote:
I would do so for the following reasons:
1. Even though the security arguments are weak, they are going to be
checkmarks on audits which can't be changed for years.
2. When someone gets a "remove this and find out why the OS did this"
it helps if they can point to an "official" change versus an email.
This is an excellent point. Chasing the history of such changes through
myriad email is always frustrating, especially since it's often
inconclusive of what actually did happen.
Just checking my own PATH, I see some surprising things at the front:
$ echo $PATH
/usr/libexec/python3-sphinx:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
I love Sphinx and Qt, but what are they doing there ... at the front?
If nothing else, that seems an inefficient search order. Yeah, caching
will alleviate most of that, so why are they there at all?
11:25 a.m.
On 05/04/2018 09:42 AM, John Florian wrote:
On 2018-05-04 09:33, Stephen John Smoogen wrote:
> I would do so for the following reasons:
> 1. Even though the security arguments are weak, they are going to be
> checkmarks on audits which can't be changed for years.
> 2. When someone gets a "remove this and find out why the OS did this"
> it helps if they can point to an "official" change versus an email.
This is an excellent point. Chasing the history of such changes
through myriad email is always frustrating, especially since it's
often inconclusive of what actually did happen.
Just checking my own PATH, I see some surprising things at the front:
$ echo $PATH
/usr/libexec/python3-sphinx:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
I love Sphinx and Qt, but what are they doing there ... at the front?
If nothing else, that seems an inefficient search order. Yeah, caching
will alleviate most of that, so why are they there at all?
Yeah, I don't like
it either. Even if there are reasons for those two,
it's a bad precedent---if every package did that, $PATH would become
unmanageable, and impossible to audit. Furthermore, the way these two
insert stuff into my $PATH is quirky/hacky: they drop files into
/etc/profile.d that cover csh and sh
* python-sphinx runs 'module load python-sphinx' from
/usr/share/modulefiles/python-sphinx/python2-sphinx which does
'prepend-path'
* qt just executes a shell script that manipulates $QT* and $PATH
Since the main reason to mess with $PATH ordering is to override
same-named commands, I think we should have a guideline that packages do
not mess with path, or at least don't prepend to it.
BTW, on my system, ktechlab also messes with $PATH but at least it
_appends_ /usr/libexec/sdcc to it. Still, I think sdcc should just go to
/bin...
1:35 p.m.
On 2018-05-04 12:25, Przemek Klosowski wrote:
On 05/04/2018 09:42 AM, John Florian wrote:
>
> On 2018-05-04 09:33, Stephen John Smoogen wrote:
>> I would do so for the following reasons:
>> 1. Even though the security arguments are weak, they are going to be
>> checkmarks on audits which can't be changed for years.
>> 2. When someone gets a "remove this and find out why the OS did this"
>> it helps if they can point to an "official" change versus an email.
>
> This is an excellent point. Chasing the history of such changes
> through myriad email is always frustrating, especially since it's
> often inconclusive of what actually did happen.
>
> Just checking my own PATH, I see some surprising things at the front:
>
> $ echo $PATH
>
/usr/libexec/python3-sphinx:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
>
>
> I love Sphinx and Qt, but what are they doing there ... at the
> front? If nothing else, that seems an inefficient search order.
> Yeah, caching will alleviate most of that, so why are they there at all?
Yeah, I don't like it either. Even if there are reasons for those two,
it's a bad precedent---if every package did that, $PATH would become
unmanageable, and impossible to audit. Furthermore, the way these two
insert stuff into my $PATH is quirky/hacky: they drop files into
/etc/profile.d that cover csh and sh
* python-sphinx runs 'module load python-sphinx' from
/usr/share/modulefiles/python-sphinx/python2-sphinx which does
'prepend-path'
* qt just executes a shell script that manipulates $QT* and $PATH
Since the main reason to mess with $PATH ordering is to override
same-named commands, I think we should have a guideline that packages
do not mess with path, or at least don't prepend to it.
Such a guideline makes sense, if there's not already one. This
definitely violates the principle of least surprise. If someone is
using an alternative shell or they force set PATH rather than modifying
it, that could lead to abnormal behavior that doesn't help anyone. I
really appreciate that rpm won't let us overwrite files of another
package, but ought there be protection (probably not via rpm) against
displacing executables due to PATH hackery too? Wouldn't same-named
commands be better dealt with via the alternatives system?
BTW, on my system, ktechlab also messes with $PATH but at least it
_appends_ /usr/libexec/sdcc to it. Still, I think sdcc should just go
to /bin...
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
3:17 a.m.
On 05/04/2018 04:42 PM, John Florian wrote:
On 2018-05-04 09:33, Stephen John Smoogen wrote:
> I would do so for the following reasons:
> 1. Even though the security arguments are weak, they are going to be
> checkmarks on audits which can't be changed for years.
> 2. When someone gets a "remove this and find out why the OS did this"
> it helps if they can point to an "official" change versus an email.
This is an excellent point. Chasing the history of such changes through
myriad email is always frustrating, especially since it's often
inconclusive of what actually did happen.
Just checking my own PATH, I see some surprising things at the front:
$ echo $PATH
/usr/libexec/python3-sphinx:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
I love Sphinx and Qt, but what are they doing there ... at the front?
Ditto. And *libexec* at that. libexec by definition is "internal
binaries that are not intended to be executed directly by users or shell
scripts", so it really does not belong in anybodys PATH.
- Panu -
5:39 a.m.
Panu Matilainen wrote:
On 05/04/2018 04:42 PM, John Florian wrote:
> Just checking my own PATH, I see some surprising things at the front:
>
> $ echo $PATH
>
/usr/libexec/python3-sphinx:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
>
> I love Sphinx and Qt, but what are they doing there ... at the front?
Ditto. And *libexec* at that. libexec by definition is "internal
binaries that are not intended to be executed directly by users or shell
scripts", so it really does not belong in anybodys PATH.
It looks like a kludge to make python2-sphinx and python3-sphinx
parallel-installable and allow individual users to choose one or the
other, without breaking things that invoke the commands by their
unversioned names. It's yet another consequence of not designing a
programming language with enough forethought to make future versions
backward-compatible. I suppose we'll get rid of it some day when all
Sphinx plugins have been ported to Python 3.
Björn Persson
6:34 a.m.
On 04/05/18 09:50, Jonathan Wakely wrote:
On 03/05/18 12:23 -0400, R P Herrold wrote:
> By convention additions to the path come LAST in priority,
> because of well known privilege escalation attack approaches
> (the incautious admin sits down at a 'trapped' nominally sick
> workstation, and fails to use a fully qualified path to 'su'
> or 'sudo' , or omits to add the '-' to cause PATH cleansing).
Either the admin does one of those things, or they're screwed anyway
because a user (or attacker with access to the user's account) who
wants to escalate their privileges can edit the user's PATH. The user
can always do that, whether Fedora puts ~/.local/bin early in the PATH
by default or not.
I don't think I like the idea of putting it early in the PATH by
default, but I don't have a solid argument for why I don't like it.
You're probably in the same boat as me which is you've been brought up
putting things like that late. Looking at the various unixy accounts I
have only one that has any mention of ~/.login/bin in $PATH and they put
it late, all of them have ~/bin or some version of that last. I suspect
that there's a whole mishmash of positioning of stuff like this and
various sites/people/applications are going to have their own opinions
on what should go where.
None of the "security" arguments presented are convincing
though.
No, you're probably right, although I'm not entirely convinced that
"it
has to be first because otherwise app X will break" is a convincing
argument either. A convention either way is sensible, changing
conventions will cause pain, but I suspect that horse has left the building.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
9:34 a.m.
On 2 May 2018 at 10:08, Kamil Dudka <kdudka(a)redhat.com> wrote:
On Wednesday, May 2, 2018 3:46:34 PM CEST Stephen Gallagher wrote:
> On Wed, May 2, 2018 at 6:44 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
> > On 2.5.2018 15:30, Stephen Gallagher wrote:
> > > Does anyone see a reason not to prioritize ~/.local/bin over
> >
> > /usr/bin?
> >
> > > Yes, if a user's account is compromised (or any service running as
> > > them), it's REALLY easy to drop faked tools into a user-private
> > > directory and override critical system tools (like replacing 'bash'
with
> > > a keylogger).
> >
> > If user's account is compromised, user's PATH can be changed. IMHO the
> > provided argument is not valid.
>
> There are a lot of ways where their account can be compromised without
> having complete session access. If they're running a web-connected
> application as their user, that application could be compromised to write a
> file to disk. If that file can now supersede the system copy, they have now
> escalated the degree of the compromise.
You have two choices:
1. Either you allow users to easily install software to their home directory.
If their user account is compromised, an attacker can install some software
they do not want to install, but it still affects their user account only.
The issue is where they do not know they have installed software to
their home directory. This leads to the problem outlined in
https://xkcd.com/1200/ where the user account is more precious than
having root.
2. You do not allow users to easily install software to their home
directory.
In that case, they will install questionable software using sudo, which
gives it root privileges and affects all other users on the system (and
possibly other systems reachable through a trusted network).
Which most users will do anyway because every stackoverflow and
software install says you have to do a 'curl | su -' or a 'sudo
pip/gem/etc install'
3. You do not allow users to easily install software to their home
directory. You do not allow them to get sudo access either. They have
limited access on that box because they may need to do certain tasks
which are audited and controlled. [This is the usual case for server
systems because you have to follow rules which are dictated outside of
either the system admin, user or OS manufacturer.]
What happens then is that users do not want to be on that system and
will set up their own system.
Which of those choices is more secure?
None of them is more secure because security is an overloaded template
versus a single term. Each of those has its own threat analysis and
may have reasons to be done in one place or another. Most of those may
be dictated by outside forces. Trying to say if one is more secure is
like saying "Which one is more colour? Red, blue or green?"
Kamil
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
12:05 p.m.
On Wednesday, May 2, 2018 4:34:51 PM CEST Stephen John Smoogen wrote:
The issue is where they do not know they have installed software to
their home directory.
Sure but still better than if they did not know they had installed software
outside of their home directory, at least from perspective of other users
sharing the same system.
This leads to the problem outlined in
https://xkcd.com/1200/ where the user account is more precious than
having root.
Wait. If you have full root access, you have automatically access to data
(and running sessions) of all users on that system.
I think you are misreading the xkcd. It says that stealing a user sessions
is _almost_ as serious as having root access on that system. Still as root
you can do a superset of things compared to having a user session only.
> 2. You do not allow users to easily install software to their
home
> directory.
> In that case, they will install questionable software using sudo,
> which
> gives it root privileges and affects all other users on the system
> (and
> possibly other systems reachable through a trusted network).
>
>
Which most users will do anyway because every stackoverflow and
software install says you have to do a 'curl | su -' or a 'sudo
pip/gem/etc install'
Because that is currently the only way that works reliably. If you find out
a more secure way that works for the users equally well, it will find its way
to stackoverflow some day.
Kamil
5:10 p.m.
On 02/05/18 18:05, Kamil Dudka wrote:
On Wednesday, May 2, 2018 4:34:51 PM CEST Stephen John Smoogen
wrote:
<snip>
> This leads to the problem outlined in
> https://xkcd.com/1200/ where the user account is more precious than
> having root.
Wait. If you have full root access, you have automatically access to data
(and running sessions) of all users on that system.
I think you are misreading the xkcd. It says that stealing a user sessions
is _almost_ as serious as having root access on that system. Still as root
you can do a superset of things compared to having a user session only.
no, I'm afraid you're misunderstanding. if someone steals a laptop the
live user session can be more valuable than the root password. with
the live session you have access to everything the owner of the sesion
is logged into. with the root password you have access to everything on
the laptop. But you can't for example access his banking account .you
need the banking account login details.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
5:01 a.m.
On Thursday, May 3, 2018 12:10:25 AM CEST Iain Rae wrote:
no, I'm afraid you're misunderstanding. if someone steals a
laptop the
live user session can be more valuable than the root password. with
the live session you have access to everything the owner of the sesion
is logged into. with the root password you have access to everything on
the laptop. But you can't for example access his banking account .you
need the banking account login details.
If you have full root access while the session is running, you can access the
login details, too. You can read memory or attach debugger to any process of
your choice. Obviously, there cannot be any login details that are available
to the regular user but that cannot be accessed by root at the same time.
When you install programs from untrusted sources using sudo, you usually have
a user session running. So the mentioned xkcd does not really apply here.
Kamil
8:35 a.m.
On 05/02/2018 03:23 PM, Tomas Orsava wrote:
Hi!
I'd like to propose putting the ~/.local/bin in front of the /usr/bin
on the PATH.
Currently /usr/bin has priority over ~/.local/bin, which causes a
[bug] where the old system-installed executable written in Python
(from /usr/bin) is launched, but it finds new Python sources
(installed into $HOME) which it doesn't work with and crashes.
[bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
I believe the current configuration breaks the intuitive expectation
that things installed closer to the user should take priority. That's
for example how it works with Python.
Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
PATH (though Ubuntu has ~/bin) so we can't take guidance there.
Speaking of ~/bin, Ubuntu *does* prioritize it over /usr/bin. This is in
their default ~/.profile (Ubuntu 14.04.5 LTS):
https://paste.fedoraproject.org/paste/jQGGxejCAxRXZ7whdHYZjw
Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
Regards,
Tomas
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
8:39 a.m.
On 05/02/2018 04:23 PM, Tomas Orsava wrote:
Hi!
I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
the PATH.
Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
where the old system-installed executable written in Python (from
/usr/bin) is launched, but it finds new Python sources (installed into
$HOME) which it doesn't work with and crashes.
[bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
I believe the current configuration breaks the intuitive expectation
that things installed closer to the user should take priority. That's
for example how it works with Python.
Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
PATH (though Ubuntu has ~/bin) so we can't take guidance there.
Not quite what you're asking, but actually not having a hidden directory
as a part of default PATH in the first place seems like a rather good
idea to me...
- Panu -
8:45 a.m.
On 2.5.2018 15:39, Panu Matilainen wrote> Not quite what you're asking,
but actually not having a hidden directory
as a part of default PATH in the first place seems like a rather good
idea to me...
It's already there. And it is XDG complaint. The question here is about
order (what takes priority).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:53 a.m.
----- Original Message -----
From: "Miro Hrončok" <mhroncok(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>, "Panu Matilainen"
<pmatilai(a)redhat.com>
Sent: Wednesday, May 2, 2018 3:45:55 PM
Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On 2.5.2018 15:39, Panu Matilainen wrote> Not quite what you're asking,
but actually not having a hidden directory
> as a part of default PATH in the first place seems like a rather good
> idea to me...
It's already there. And it is XDG complaint. The question here is about
order (what takes priority).
Can you point me to the XDG specification that requires it ? It was mentioned by Lenart on
the bug, but he later clarified his comment[1].
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
[1] https://lists.fedoraproject.org/pipermail/devel/2011-July/154902.html
--
--
Siteshwar Vashisht
8:56 a.m.
On 2.5.2018 15:53, Siteshwar Vashisht wrote:
----- Original Message -----
> From: "Miro Hrončok" <mhroncok(a)redhat.com>
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>, "Panu Matilainen"
> <pmatilai(a)redhat.com>
> Sent: Wednesday, May 2, 2018 3:45:55 PM
> Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
>
> On 2.5.2018 15:39, Panu Matilainen wrote> Not quite what you're asking,
> but actually not having a hidden directory
>> as a part of default PATH in the first place seems like a rather good
>> idea to me...
>
> It's already there. And it is XDG complaint. The question here is about
> order (what takes priority).
Can you point me to the XDG specification that requires it ? It was mentioned by Lenart
on the bug, but he later clarified his comment[1].
You are absolutely right, sorry about that.
Hover I still think it is de facto a standard. At least it makes tools
like pip --user work out of the box. And it worked like this for logn
time for users to expect it to work.
The fact that it is in hidden directory just doesn't feel relevant to me.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:59 a.m.
On Wed, May 02, 2018 at 09:53:48AM -0400, Siteshwar Vashisht wrote:
----- Original Message -----
> From: "Miro Hrončok" <mhroncok(a)redhat.com>
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>, "Panu Matilainen"
> <pmatilai(a)redhat.com>
> Sent: Wednesday, May 2, 2018 3:45:55 PM
> Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
>
> On 2.5.2018 15:39, Panu Matilainen wrote> Not quite what you're asking,
> but actually not having a hidden directory
> > as a part of default PATH in the first place seems like a rather good
> > idea to me...
>
> It's already there. And it is XDG complaint. The question here is about
> order (what takes priority).
Can you point me to the XDG specification that requires it ? It was
mentioned by Lenart on the bug, but he later clarified his comment[1].
It isn't part of the XDG spec AFAIK, rather it is something that systemd
has documented as an extension to XDG, but not sure if systemd actually
invented that or just documented existing practice that was around before:
https://www.freedesktop.org/software/systemd/man/file-hierarchy.html
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
9:28 a.m.
On Mi, 02.05.18 09:53, Siteshwar Vashisht (svashisht(a)redhat.com) wrote:
> On 2.5.2018 15:39, Panu Matilainen wrote> Not quite what
you're asking,
> but actually not having a hidden directory
> > as a part of default PATH in the first place seems like a rather good
> > idea to me...
>
> It's already there. And it is XDG complaint. The question here is about
> order (what takes priority).
Can you point me to the XDG specification that requires it ? It was mentioned by Lenart
on the bug, but he later clarified his comment[1].
So this came up again recently here:
https://lists.freedesktop.org/archives/xdg/2017-August/013938.html
(see the full thread)
And I even promised to merge the proposed spec addition there, but
never actually did that. Maybe I really should now...
Lennart
--
Lennart Poettering, Red Hat
9:47 a.m.
On Wed, 2 May 2018, Lennart Poettering wrote:
>> It's already there. And it is XDG complaint. The question
here is about
>> order (what takes priority).
>
> Can you point me to the XDG specification that requires it ? It was mentioned by
Lenart on the bug, but he later clarified his comment[1].
So this came up again recently here:
https://lists.freedesktop.org/archives/xdg/2017-August/013938.html
(see the full thread)
And I even promised to merge the proposed spec addition there, but
never actually did that. Maybe I really should now...
Adding invisible directories to a user's PATH is putting esthetics over
security and is the wrong thing to do.
I have no problem with ~/bin/ but feel a bit reserved about ~/local/bin/
as ~/local might not be obvious to the user as an added binary containing
directory.
Paul
9:54 a.m.
On 2 May 2018 at 10:47, Paul Wouters <paul(a)nohats.ca> wrote:
On Wed, 2 May 2018, Lennart Poettering wrote:
>>> It's already there. And it is XDG complaint. The question here is about
>>> order (what takes priority).
>>
>>
>> Can you point me to the XDG specification that requires it ? It was
>> mentioned by Lenart on the bug, but he later clarified his comment[1].
>
>
> So this came up again recently here:
>
> https://lists.freedesktop.org/archives/xdg/2017-August/013938.html
>
> (see the full thread)
>
> And I even promised to merge the proposed spec addition there, but
> never actually did that. Maybe I really should now...
Adding invisible directories to a user's PATH is putting esthetics over
security and is the wrong thing to do.
I have no problem with ~/bin/ but feel a bit reserved about ~/local/bin/
as ~/local might not be obvious to the user as an added binary containing
directory.
I guess this is to allow more than binaries. The ~/local seems to
allow for {lib, share, man} etc which would pollute a home directory
much more. [I dislike the hidden . part as I wasn't aware it was in my
path at all.]
Paul
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
10:24 a.m.
On Mi, 02.05.18 10:47, Paul Wouters (paul(a)nohats.ca) wrote:
On Wed, 2 May 2018, Lennart Poettering wrote:
> > > It's already there. And it is XDG complaint. The question here is
about
> > > order (what takes priority).
> >
> > Can you point me to the XDG specification that requires it ? It was mentioned
by Lenart on the bug, but he later clarified his comment[1].
>
> So this came up again recently here:
>
> https://lists.freedesktop.org/archives/xdg/2017-August/013938.html
>
> (see the full thread)
>
> And I even promised to merge the proposed spec addition there, but
> never actually did that. Maybe I really should now...
Adding invisible directories to a user's PATH is putting esthetics over
security and is the wrong thing to do.
I have no problem with ~/bin/ but feel a bit reserved about ~/local/bin/
as ~/local might not be obvious to the user as an added binary containing
directory.
I presume you mean "~/.local" rather than "~/local"?
.local/ was introduced and documented in 2003. That's 15 years ago
now. Pretty much everybody settled on it these days, and many
distributions have clear language suggesting its use. For example,
here's the wording from Debian:
"Debian does not require that packages conform to the XDGBDS
but strongly encourages upstreams to do so. "
— https://wiki.debian.org/XDGBaseDirectorySpecification
Now, the ~/.local/bin/ thing is mostly just a natural extension of XDG
basedir, and many systems have adopted it anyway without this being
explicitly written into any spec.
So yeah, I think it's about time we just update the spec to its
natural extension and to what people already use. I don't think anyone
is helped if we introduce yet another directory for this, in
particular as the security benefit of using any other path is not
universally agreed to.
Lennart
--
Lennart Poettering, Red Hat
11:22 a.m.
On Wed, 2 May 2018, Lennart Poettering wrote:
I presume you mean "~/.local" rather than
"~/local"?
I don't. As my argument goes, hidden directories containing binaries
in your path are a bad idea. And it was a bad idea 15 years ago. Note
that my home directory seems to only contain ~/.local/share and nothing
else, so this hidden binary directory concept seems to have not been in
use for 15 years.
Storing configs in ~/.local/share seems okay with me, even though it
just moves the namespace from ~ to ~/.local with no good reason, while
still littering in ~/.??* anyway, but that's another issue.
Paul
> .local/ was introduced and documented in 2003. That's 15 years ago
> now. Pretty much everybody settled on it these days, and many
> distributions have clear language suggesting its use. For example,
> here's the wording from Debian:
>
> "Debian does not require that packages conform to the XDGBDS
> but strongly encourages upstreams to do so. "
>
> — https://wiki.debian.org/XDGBaseDirectorySpecification
>
> Now, the ~/.local/bin/ thing is mostly just a natural extension of XDG
> basedir, and many systems have adopted it anyway without this being
> explicitly written into any spec.
>
> So yeah, I think it's about time we just update the spec to its
> natural extension and to what people already use. I don't think anyone
> is helped if we introduce yet another directory for this, in
> particular as the security benefit of using any other path is not
> universally agreed to.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
11:50 a.m.
On Wed, May 02, 2018 at 12:22:48PM -0400, Paul Wouters wrote:
On Wed, 2 May 2018, Lennart Poettering wrote:
> I presume you mean "~/.local" rather than "~/local"?
I don't. As my argument goes, hidden directories containing binaries
in your path are a bad idea. And it was a bad idea 15 years ago. Note
that my home directory seems to only contain ~/.local/share and nothing
else, so this hidden binary directory concept seems to have not been in
use for 15 years.
Storing configs in ~/.local/share seems okay with me, even though it
just moves the namespace from ~ to ~/.local with no good reason, while
still littering in ~/.??* anyway, but that's another issue.
In this modern age of widespread use of scripting langhuages, looking
at "binaries" is missing the bigger picture. Any of the directories
$HOME/.local/{bin,lib,share} are liable to contain executable code.
My $HOME/.local/share/perl5 contains various Perl modules for example.
So saying $HOME/.local/share is ok while $HOME/.local/bin is not ok
doesn't really make much conceptual sense.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
4:57 a.m.
----- Original Message -----
From: "Lennart Poettering" <mzerqung(a)0pointer.de>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Cc: "Miro Hrončok" <mhroncok(a)redhat.com>
Sent: Wednesday, May 2, 2018 4:28:35 PM
Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
So this came up again recently here:
https://lists.freedesktop.org/archives/xdg/2017-August/013938.html
(see the full thread)
And I even promised to merge the proposed spec addition there, but
never actually did that. Maybe I really should now...
Is it going to specify ordering of the paths too ? It would be good to have some standard
in ordering or at least some recommendation around it, so that all distributions behave
same.
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
--
Siteshwar Vashisht
9:35 a.m.
----- Original Message -----
From: "Tomas Orsava" <torsava(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>, "David Kaspar"
<dkaspar(a)redhat.com>,
"Kamil Dudka" <kdudka(a)redhat.com>, "Miro Hrončok"
<mhroncok(a)redhat.com>, "Petr Viktorin" <pviktori(a)redhat.com>,
"Siteshwar Vashisht" <svashish(a)redhat.com>
Sent: Wednesday, May 2, 2018 3:23:10 PM
Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
Hi!
I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
the PATH.
Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
where the old system-installed executable written in Python (from
/usr/bin) is launched, but it finds new Python sources (installed into
$HOME) which it doesn't work with and crashes.
[bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
I believe the current configuration breaks the intuitive expectation
that things installed closer to the user should take priority. That's
for example how it works with Python.
Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
PATH (though Ubuntu has ~/bin) so we can't take guidance there.
Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
Most of the discussion in this thread focuses on security rather than sane behavior. It is
going to be a system wide change. An application may get affected if it depends on system
provided utilites which gets overridden by ~/.local/bin.
For e.g.
cat /bin/foo
#!/bin/bash
ls -l
cat ~/.local/bin/ls
#!/bin/bash
echo "Strange world!"
/bin/foo
Strange world!
So this change breaks something that is outside user's installation. This should
happen only if a user has explicitly overriden $PATH to prioritize user installation
paths.
Regards,
Tomas
--
--
Siteshwar Vashisht
9:46 a.m.
Dne 2.5.2018 v 16:35 Siteshwar Vashisht napsal(a):
----- Original Message -----
> From: "Tomas Orsava" <torsava(a)redhat.com>
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>, "David Kaspar"
<dkaspar(a)redhat.com>,
> "Kamil Dudka" <kdudka(a)redhat.com>, "Miro Hrončok"
<mhroncok(a)redhat.com>, "Petr Viktorin" <pviktori(a)redhat.com>,
> "Siteshwar Vashisht" <svashish(a)redhat.com>
> Sent: Wednesday, May 2, 2018 3:23:10 PM
> Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
>
> Hi!
> I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
> the PATH.
>
> Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
> where the old system-installed executable written in Python (from
> /usr/bin) is launched, but it finds new Python sources (installed into
> $HOME) which it doesn't work with and crashes.
>
> [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
>
> I believe the current configuration breaks the intuitive expectation
> that things installed closer to the user should take priority. That's
> for example how it works with Python.
> Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
> PATH (though Ubuntu has ~/bin) so we can't take guidance there.
>
> Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
Most of the discussion in this thread focuses on security rather than sane behavior. It
is going to be a system wide change. An application may get affected if it depends on
system provided utilites which gets overridden by ~/.local/bin.
For e.g.
> cat /bin/foo
#!/bin/bash
ls -l
> cat ~/.local/bin/ls
#!/bin/bash
echo "Strange world!"
> /bin/foo
Strange world!
So this change breaks something that is outside user's installation. This should
happen only if a user has explicitly overriden $PATH to prioritize user installation
paths.
User explicitly installed SW into his home directory. Why (s)he needs to
override the $PATH in addition to make the SW work?
Vít
9:53 a.m.
On Wed, 2 May 2018, Vít Ondruch wrote:
User explicitly installed SW into his home directory. Why (s)he needs
to
override the $PATH in addition to make the SW work?
Can you account for all your ~/.??* entries in your home dir? I have
several of which I have no clue what it is or why it got there, and
I have 25 years of homedir experience.
paul@bofh7:~$ ls -al .<tab><tab>
Display all 271 possibilities? (y or n)
So I don't think your "User explicitly installed SW into his home
directory" is true, and it is especially not true if software can
make use of knowing ~/.bin will be there for it to quietly drop some
things in.
Paul
10:44 a.m.
Le 2018-05-02 16:53, Paul Wouters a écrit :
So I don't think your "User explicitly installed SW into his
home
directory" is true, and it is especially not true if software can
make use of knowing ~/.bin will be there for it to quietly drop some
things in.
The XDG spec and its insistence on mediating all accesses via env
variables that themselves (by default) point to hidden directories has
always been a trainwreck. All the more so since the main justification
for this choice was to allow localized directory names in desktop icons
that were supposed to be sourced from ~/ except it was quickly
superseded by ~/Desktop (in English!), many apps could never have dealt
with the codepoints required by some human languages, and the whole
thing was finally dumped overboard by GNOME anyway. After many years
many apps have still not learned to read those env vars, or hardcode
their default value, or whatever. It's massively over-engineered,
under-used, opaque to users and so on.
It badly needs to be rewritten without hidden dotdirs, without positing
apps that by and large rely on hardcoded default values or config files
find suddenly convenient to read env vars all the times just in case
someone deemed smart to rename default dir names to something else (the
legacy XDG envs vars could then point to the new dir hierarchy for the
apps that bother reading them), in fact, without positing that part of
the *nix directory hierarchy has a specific renaming behavior when the
rest is fixed in stone (that's too much schizophrenia for the average
*nix app writer).
But, at the same time, the dotfiles mess that existed before the XDG
spec (and continues to exist since lots of apps have not migrated yet)
was much worse. And writing a spec, and getting consensus on it,
requires a lot of time, work, and persistence.
So in that thence, the XDG spec is wonderful and we should all be glad
it exists.
There is little point in complaining the spec is misdesigned. It has
been known to be misdesigned for years, in fact since it was first
discussed and before it was ever finalized. But, existing alternatives
are worse. Unless someone intends to work on a better XDG v2 today, the
only constructive choice is to apply it as is.
Because alternatives are worse.
Regards,
--
Nicolas Mailhot
12:22 p.m.
On Mi, 02.05.18 17:44, Nicolas Mailhot (nicolas.mailhot(a)laposte.net) wrote:
Le 2018-05-02 16:53, Paul Wouters a écrit :
> So I don't think your "User explicitly installed SW into his home
> directory" is true, and it is especially not true if software can
> make use of knowing ~/.bin will be there for it to quietly drop some
> things in.
The XDG spec and its insistence on mediating all accesses via env variables
that themselves (by default) point to hidden directories has always been a
trainwreck. All the more so since the main justification for this choice was
to allow localized directory names in desktop icons that were supposed to be
sourced from ~/ except it was quickly superseded by ~/Desktop (in
English!),
You are mixing up xdg-basedir and xdg-user-dir:
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
vs.
https://www.freedesktop.org/wiki/Software/xdg-user-dirs/
many apps could never have dealt with the codepoints required by some
human
languages, and the whole thing was finally dumped overboard by GNOME anyway.
After many years many apps have still not learned to read those env vars, or
hardcode their default value, or whatever. It's massively over-engineered,
under-used, opaque to users and so on.
The basedir stuff doesn't bother with l10n at all, only xdg-user-dirs
does. And to my knowledge gnome still very much uses xdg-user-dirs, at
least if I open nautilus I still see all the xdg-user-dirs defined
dirs on the left...
It badly needs to be rewritten without hidden dotdirs, without
positing apps
that by and large rely on hardcoded default values or config files find
suddenly convenient to read env vars all the times just in case someone
deemed smart to rename default dir names to something else (the legacy XDG
envs vars could then point to the new dir hierarchy for the apps that bother
reading them), in fact, without positing that part of the *nix directory
hierarchy has a specific renaming behavior when the rest is fixed in stone
(that's too much schizophrenia for the average *nix app writer).
the xdg-basedir focusses on system level stuff, i.e. libraries, data,
binaries and suchlike. the xdg-userdir stuff focusses on user-facing
stuff, i.e. documents, music, videos, and so on. That's why the former
places stuff in ~/.local, away from the user's view, while the latter
places stuff in localized directories with no dot prefix, as they
should be visible directly.
I mean, I was involved in one of the two specs, hence I am of course
biased, but even if the specs turned out not to be perfect after
15years of use, definitely a lot of thought went into them. And what's
"perfect" anyway?
Lennart
--
Lennart Poettering, Red Hat
9:57 a.m.
----- Original Message -----
From: "Vít Ondruch" <vondruch(a)redhat.com>
To: devel(a)lists.fedoraproject.org
Sent: Wednesday, May 2, 2018 4:46:12 PM
Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
Dne 2.5.2018 v 16:35 Siteshwar Vashisht napsal(a):
>
> ----- Original Message -----
>> From: "Tomas Orsava" <torsava(a)redhat.com>
>> To: "Development discussions related to Fedora"
>> <devel(a)lists.fedoraproject.org>, "David Kaspar"
<dkaspar(a)redhat.com>,
>> "Kamil Dudka" <kdudka(a)redhat.com>, "Miro Hrončok"
<mhroncok(a)redhat.com>,
>> "Petr Viktorin" <pviktori(a)redhat.com>,
>> "Siteshwar Vashisht" <svashish(a)redhat.com>
>> Sent: Wednesday, May 2, 2018 3:23:10 PM
>> Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
>>
>> Hi!
>> I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
>> the PATH.
>>
>> Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
>> where the old system-installed executable written in Python (from
>> /usr/bin) is launched, but it finds new Python sources (installed into
>> $HOME) which it doesn't work with and crashes.
>>
>> [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
>>
>> I believe the current configuration breaks the intuitive expectation
>> that things installed closer to the user should take priority. That's
>> for example how it works with Python.
>> Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
>> PATH (though Ubuntu has ~/bin) so we can't take guidance there.
>>
>> Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
> Most of the discussion in this thread focuses on security rather than sane
> behavior. It is going to be a system wide change. An application may get
> affected if it depends on system provided utilites which gets overridden
> by ~/.local/bin.
>
> For e.g.
>
>> cat /bin/foo
> #!/bin/bash
> ls -l
>> cat ~/.local/bin/ls
> #!/bin/bash
> echo "Strange world!"
>> /bin/foo
> Strange world!
>
> So this change breaks something that is outside user's installation. This
> should happen only if a user has explicitly overriden $PATH to prioritize
> user installation paths.
User explicitly installed SW into his home directory. Why (s)he needs to
override the $PATH in addition to make the SW work?
Users should be aware too that there are 2 different versions of the same utility on their
system. And they should be explicit about not using system provided one.
Vít
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
--
Siteshwar Vashisht
10:31 a.m.
Dne 2.5.2018 v 16:57 Siteshwar Vashisht napsal(a):
----- Original Message -----
> From: "Vít Ondruch" <vondruch(a)redhat.com>
> To: devel(a)lists.fedoraproject.org
> Sent: Wednesday, May 2, 2018 4:46:12 PM
> Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
>
>
>
> Dne 2.5.2018 v 16:35 Siteshwar Vashisht napsal(a):
>> ----- Original Message -----
>>> From: "Tomas Orsava" <torsava(a)redhat.com>
>>> To: "Development discussions related to Fedora"
>>> <devel(a)lists.fedoraproject.org>, "David Kaspar"
<dkaspar(a)redhat.com>,
>>> "Kamil Dudka" <kdudka(a)redhat.com>, "Miro Hrončok"
<mhroncok(a)redhat.com>,
>>> "Petr Viktorin" <pviktori(a)redhat.com>,
>>> "Siteshwar Vashisht" <svashish(a)redhat.com>
>>> Sent: Wednesday, May 2, 2018 3:23:10 PM
>>> Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
>>>
>>> Hi!
>>> I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
>>> the PATH.
>>>
>>> Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
>>> where the old system-installed executable written in Python (from
>>> /usr/bin) is launched, but it finds new Python sources (installed into
>>> $HOME) which it doesn't work with and crashes.
>>>
>>> [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
>>>
>>> I believe the current configuration breaks the intuitive expectation
>>> that things installed closer to the user should take priority. That's
>>> for example how it works with Python.
>>> Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
>>> PATH (though Ubuntu has ~/bin) so we can't take guidance there.
>>>
>>> Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
>> Most of the discussion in this thread focuses on security rather than sane
>> behavior. It is going to be a system wide change. An application may get
>> affected if it depends on system provided utilites which gets overridden
>> by ~/.local/bin.
>>
>> For e.g.
>>
>>> cat /bin/foo
>> #!/bin/bash
>> ls -l
>>> cat ~/.local/bin/ls
>> #!/bin/bash
>> echo "Strange world!"
>>> /bin/foo
>> Strange world!
>>
>> So this change breaks something that is outside user's installation. This
>> should happen only if a user has explicitly overriden $PATH to prioritize
>> user installation paths.
> User explicitly installed SW into his home directory. Why (s)he needs to
> override the $PATH in addition to make the SW work?
Users should be aware too that there are 2 different versions of the same utility on
their system. And they should be explicit about not using system provided one.
If they are experience enough to install SW into ~/.local, they are
probably aware. If they are not aware, you won't save them by $PATH order.
V.
9:49 a.m.
On Wed, May 02, 2018 at 10:35:28AM -0400, Siteshwar Vashisht wrote:
----- Original Message -----
> From: "Tomas Orsava" <torsava(a)redhat.com>
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>, "David Kaspar"
<dkaspar(a)redhat.com>,
> "Kamil Dudka" <kdudka(a)redhat.com>, "Miro Hrončok"
<mhroncok(a)redhat.com>, "Petr Viktorin" <pviktori(a)redhat.com>,
> "Siteshwar Vashisht" <svashish(a)redhat.com>
> Sent: Wednesday, May 2, 2018 3:23:10 PM
> Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
>
> Hi!
> I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
> the PATH.
>
> Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
> where the old system-installed executable written in Python (from
> /usr/bin) is launched, but it finds new Python sources (installed into
> $HOME) which it doesn't work with and crashes.
>
> [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
>
> I believe the current configuration breaks the intuitive expectation
> that things installed closer to the user should take priority. That's
> for example how it works with Python.
> Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
> PATH (though Ubuntu has ~/bin) so we can't take guidance there.
>
> Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
Most of the discussion in this thread focuses on security rather than
sane behavior. It is going to be a system wide change. An application
may get affected if it depends on system provided utilites which gets
overridden by ~/.local/bin.
[snip]
So this change breaks something that is outside user's
installation.
This should happen only if a user has explicitly overriden $PATH to
prioritize user installation paths.
Not prioritizing user paths by default will break other things though.
For example, python pip installations done with --user.
eg. if jenkins-job-builder is installed by RPM and the user decides to
add a local override, the "pip install --user jenkins-job-builder" will
place the new python libs + binary in $HOME/.local/{bin,lib} and will
just work because those dirs are both searched first.
If, however, python searches $HOME/.local/lib/... first, but $PATH has
/usr/bin first, you are going to end up with the /usr/bin/jenkins-jobs
command from RPM using the python modules from the pip install we just
did. This mis-match will end badly for the user.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
10:10 a.m.
----- Original Message -----
From: "Daniel P. Berrangé" <berrange(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Cc: "Kamil Dudka" <kdudka(a)redhat.com>
Sent: Wednesday, May 2, 2018 4:49:18 PM
Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Wed, May 02, 2018 at 10:35:28AM -0400, Siteshwar Vashisht wrote:
>
>
> ----- Original Message -----
> > From: "Tomas Orsava" <torsava(a)redhat.com>
> > To: "Development discussions related to Fedora"
> > <devel(a)lists.fedoraproject.org>, "David Kaspar"
<dkaspar(a)redhat.com>,
> > "Kamil Dudka" <kdudka(a)redhat.com>, "Miro Hrončok"
<mhroncok(a)redhat.com>,
> > "Petr Viktorin" <pviktori(a)redhat.com>,
> > "Siteshwar Vashisht" <svashish(a)redhat.com>
> > Sent: Wednesday, May 2, 2018 3:23:10 PM
> > Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
> >
> > Hi!
> > I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
> > the PATH.
> >
> > Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
> > where the old system-installed executable written in Python (from
> > /usr/bin) is launched, but it finds new Python sources (installed into
> > $HOME) which it doesn't work with and crashes.
> >
> > [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
> >
> > I believe the current configuration breaks the intuitive expectation
> > that things installed closer to the user should take priority. That's
> > for example how it works with Python.
> > Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
> > PATH (though Ubuntu has ~/bin) so we can't take guidance there.
> >
> > Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
>
> Most of the discussion in this thread focuses on security rather than
> sane behavior. It is going to be a system wide change. An application
> may get affected if it depends on system provided utilites which gets
> overridden by ~/.local/bin.
[snip]
> So this change breaks something that is outside user's installation.
> This should happen only if a user has explicitly overriden $PATH to
> prioritize user installation paths.
Not prioritizing user paths by default will break other things though.
For example, python pip installations done with --user.
Things may break both ways, whether you choose to prioritize user installation paths or
not. I will prefer if they break when user installation paths are not prioritized.
eg. if jenkins-job-builder is installed by RPM and the user decides to
add a local override, the "pip install --user jenkins-job-builder" will
place the new python libs + binary in $HOME/.local/{bin,lib} and will
just work because those dirs are both searched first.
If, however, python searches $HOME/.local/lib/... first, but $PATH has
/usr/bin first, you are going to end up with the /usr/bin/jenkins-jobs
command from RPM using the python modules from the pip install we just
did. This mis-match will end badly for the user.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange
|:|
|: https://libvirt.org -o- https://fstop138.berrange.com
|:|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange
|:|
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
--
Siteshwar Vashisht
10:14 a.m.
On Wed, May 02, 2018 at 11:10:05AM -0400, Siteshwar Vashisht wrote:
----- Original Message -----
> From: "Daniel P. Berrangé" <berrange(a)redhat.com>
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
> Cc: "Kamil Dudka" <kdudka(a)redhat.com>
> Sent: Wednesday, May 2, 2018 4:49:18 PM
> Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
>
> On Wed, May 02, 2018 at 10:35:28AM -0400, Siteshwar Vashisht wrote:
> >
> >
> > ----- Original Message -----
> > > From: "Tomas Orsava" <torsava(a)redhat.com>
> > > To: "Development discussions related to Fedora"
> > > <devel(a)lists.fedoraproject.org>, "David Kaspar"
<dkaspar(a)redhat.com>,
> > > "Kamil Dudka" <kdudka(a)redhat.com>, "Miro
Hrončok" <mhroncok(a)redhat.com>,
> > > "Petr Viktorin" <pviktori(a)redhat.com>,
> > > "Siteshwar Vashisht" <svashish(a)redhat.com>
> > > Sent: Wednesday, May 2, 2018 3:23:10 PM
> > > Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
> > >
> > > Hi!
> > > I'd like to propose putting the ~/.local/bin in front of the /usr/bin
on
> > > the PATH.
> > >
> > > Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
> > > where the old system-installed executable written in Python (from
> > > /usr/bin) is launched, but it finds new Python sources (installed into
> > > $HOME) which it doesn't work with and crashes.
> > >
> > > [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
> > >
> > > I believe the current configuration breaks the intuitive expectation
> > > that things installed closer to the user should take priority. That's
> > > for example how it works with Python.
> > > Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
> > > PATH (though Ubuntu has ~/bin) so we can't take guidance there.
> > >
> > > Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
> >
> > Most of the discussion in this thread focuses on security rather than
> > sane behavior. It is going to be a system wide change. An application
> > may get affected if it depends on system provided utilites which gets
> > overridden by ~/.local/bin.
>
> [snip]
>
> > So this change breaks something that is outside user's installation.
> > This should happen only if a user has explicitly overriden $PATH to
> > prioritize user installation paths.
>
> Not prioritizing user paths by default will break other things though.
> For example, python pip installations done with --user.
Things may break both ways, whether you choose to prioritize user
installation paths or not. I will prefer if they break when user
installation paths are not prioritized.
The point was that we need a consistent approach - we can't just consider
$PATH in isolation, because it interacts with other search paths, either
in env vars or builtin to apps. Either all should honour user location
first, or all should honour system location first, a mix of both is the
worst of all possible worlds as it maximises chances of breakage.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
4:35 a.m.
On 05/02/2018 05:14 PM, Daniel P. Berrangé wrote:
On Wed, May 02, 2018 at 11:10:05AM -0400, Siteshwar Vashisht wrote:
>
> ----- Original Message -----
>> From: "Daniel P. Berrangé" <berrange(a)redhat.com>
>> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
>> Cc: "Kamil Dudka" <kdudka(a)redhat.com>
>> Sent: Wednesday, May 2, 2018 4:49:18 PM
>> Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
>>
>> On Wed, May 02, 2018 at 10:35:28AM -0400, Siteshwar Vashisht wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Tomas Orsava" <torsava(a)redhat.com>
>>>> To: "Development discussions related to Fedora"
>>>> <devel(a)lists.fedoraproject.org>, "David Kaspar"
<dkaspar(a)redhat.com>,
>>>> "Kamil Dudka" <kdudka(a)redhat.com>, "Miro
Hrončok" <mhroncok(a)redhat.com>,
>>>> "Petr Viktorin" <pviktori(a)redhat.com>,
>>>> "Siteshwar Vashisht" <svashish(a)redhat.com>
>>>> Sent: Wednesday, May 2, 2018 3:23:10 PM
>>>> Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
>>>>
>>>> Hi!
>>>> I'd like to propose putting the ~/.local/bin in front of the /usr/bin
on
>>>> the PATH.
>>>>
>>>> Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
>>>> where the old system-installed executable written in Python (from
>>>> /usr/bin) is launched, but it finds new Python sources (installed into
>>>> $HOME) which it doesn't work with and crashes.
>>>>
>>>> [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
>>>>
>>>> I believe the current configuration breaks the intuitive expectation
>>>> that things installed closer to the user should take priority.
That's
>>>> for example how it works with Python.
>>>> Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
>>>> PATH (though Ubuntu has ~/bin) so we can't take guidance there.
>>>>
>>>> Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
>>> Most of the discussion in this thread focuses on security rather than
>>> sane behavior. It is going to be a system wide change. An application
>>> may get affected if it depends on system provided utilites which gets
>>> overridden by ~/.local/bin.
>> [snip]
>>
>>> So this change breaks something that is outside user's installation.
>>> This should happen only if a user has explicitly overriden $PATH to
>>> prioritize user installation paths.
>> Not prioritizing user paths by default will break other things though.
>> For example, python pip installations done with --user.
> Things may break both ways, whether you choose to prioritize user
> installation paths or not. I will prefer if they break when user
> installation paths are not prioritized.
Daniel answered—below—better than I could have.
I'd just like to add that while things *may* break if we implement
this—anything can break after all—the fact remains that things already
*are* broken the way it is now.
And debian/ubuntu already prioritize ~/.local/bin, so we're not going
into untested waters either.
The point was that we need a consistent approach - we can't just
consider
$PATH in isolation, because it interacts with other search paths, either
in env vars or builtin to apps. Either all should honour user location
first, or all should honour system location first, a mix of both is the
worst of all possible worlds as it maximises chances of breakage.
Regards,
Daniel
4:37 a.m.
On Thu, May 03, 2018 at 11:35:10AM +0200, Tomas Orsava wrote:
On 05/02/2018 05:14 PM, Daniel P. Berrangé wrote:
> On Wed, May 02, 2018 at 11:10:05AM -0400, Siteshwar Vashisht wrote:
> >
> > ----- Original Message -----
> > > From: "Daniel P. Berrangé" <berrange(a)redhat.com>
> > > To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
> > > Cc: "Kamil Dudka" <kdudka(a)redhat.com>
> > > Sent: Wednesday, May 2, 2018 4:49:18 PM
> > > Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
> > >
> > > On Wed, May 02, 2018 at 10:35:28AM -0400, Siteshwar Vashisht wrote:
> > > >
> > > > ----- Original Message -----
> > > > > From: "Tomas Orsava" <torsava(a)redhat.com>
> > > > > To: "Development discussions related to Fedora"
> > > > > <devel(a)lists.fedoraproject.org>, "David Kaspar"
<dkaspar(a)redhat.com>,
> > > > > "Kamil Dudka" <kdudka(a)redhat.com>, "Miro
Hrončok" <mhroncok(a)redhat.com>,
> > > > > "Petr Viktorin" <pviktori(a)redhat.com>,
> > > > > "Siteshwar Vashisht" <svashish(a)redhat.com>
> > > > > Sent: Wednesday, May 2, 2018 3:23:10 PM
> > > > > Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
> > > > >
> > > > > Hi!
> > > > > I'd like to propose putting the ~/.local/bin in front of the
/usr/bin on
> > > > > the PATH.
> > > > >
> > > > > Currently /usr/bin has priority over ~/.local/bin, which causes
a [bug]
> > > > > where the old system-installed executable written in Python
(from
> > > > > /usr/bin) is launched, but it finds new Python sources
(installed into
> > > > > $HOME) which it doesn't work with and crashes.
> > > > >
> > > > > [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
> > > > >
> > > > > I believe the current configuration breaks the intuitive
expectation
> > > > > that things installed closer to the user should take priority.
That's
> > > > > for example how it works with Python.
> > > > > Interestingly, ubuntu and opensuse do not have ~/.local/bin on
their
> > > > > PATH (though Ubuntu has ~/bin) so we can't take guidance
there.
> > > > >
> > > > > Does anyone see a reason not to prioritize ~/.local/bin over
/usr/bin?
> > > > Most of the discussion in this thread focuses on security rather
than
> > > > sane behavior. It is going to be a system wide change. An
application
> > > > may get affected if it depends on system provided utilites which
gets
> > > > overridden by ~/.local/bin.
> > > [snip]
> > >
> > > > So this change breaks something that is outside user's
installation.
> > > > This should happen only if a user has explicitly overriden $PATH to
> > > > prioritize user installation paths.
> > > Not prioritizing user paths by default will break other things though.
> > > For example, python pip installations done with --user.
> > Things may break both ways, whether you choose to prioritize user
> > installation paths or not. I will prefer if they break when user
> > installation paths are not prioritized.
Daniel answered—below—better than I could have.
I'd just like to add that while things *may* break if we implement
this—anything can break after all—the fact remains that things already *are*
broken the way it is now.
And debian/ubuntu already prioritize ~/.local/bin, so we're not going into
untested waters either.
Alot of the docs you read about Linux are written from the POV of people
using Debian/Ubuntu and their derivatives, much more so than docs from
people using Fedora sadly. With our divergant behaviour, people will try
to follows docs, and potentially find it doesn't work as expected on
Fedora which gives a bad impression of our distro.
> The point was that we need a consistent approach - we can't just consider
> $PATH in isolation, because it interacts with other search paths, either
> in env vars or builtin to apps. Either all should honour user location
> first, or all should honour system location first, a mix of both is the
> worst of all possible worlds as it maximises chances of breakage.
>
> Regards,
> Daniel
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
3:38 a.m.
On 2018-05-03, Tomas Orsava <torsava(a)redhat.com> wrote:
On 05/02/2018 05:14 PM, Daniel P. Berrangé wrote:
> On Wed, May 02, 2018 at 11:10:05AM -0400, Siteshwar Vashisht wrote:
>>
>> ----- Original Message -----
>>> From: "Daniel P. Berrangé" <berrange(a)redhat.com>
>>> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
>>> Cc: "Kamil Dudka" <kdudka(a)redhat.com>
>>> Sent: Wednesday, May 2, 2018 4:49:18 PM
>>> Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
>>>
>>> On Wed, May 02, 2018 at 10:35:28AM -0400, Siteshwar Vashisht wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Tomas Orsava" <torsava(a)redhat.com>
>>>>> To: "Development discussions related to Fedora"
>>>>> <devel(a)lists.fedoraproject.org>, "David Kaspar"
<dkaspar(a)redhat.com>,
>>>>> "Kamil Dudka" <kdudka(a)redhat.com>, "Miro
Hrončok" <mhroncok(a)redhat.com>,
>>>>> "Petr Viktorin" <pviktori(a)redhat.com>,
>>>>> "Siteshwar Vashisht" <svashish(a)redhat.com>
>>>>> Sent: Wednesday, May 2, 2018 3:23:10 PM
>>>>> Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
>>>>>
>>>>> Does anyone see a reason not to prioritize ~/.local/bin over
/usr/bin?
>>>> Most of the discussion in this thread focuses on security rather than
>>>> sane behavior. It is going to be a system wide change. An application
>>>> may get affected if it depends on system provided utilites which gets
>>>> overridden by ~/.local/bin.
>>> [snip]
>>>
>>>> So this change breaks something that is outside user's installation.
>>>> This should happen only if a user has explicitly overriden $PATH to
>>>> prioritize user installation paths.
>>> Not prioritizing user paths by default will break other things though.
>>> For example, python pip installations done with --user.
>> Things may break both ways, whether you choose to prioritize user
>> installation paths or not. I will prefer if they break when user
>> installation paths are not prioritized.
Daniel answered—below—better than I could have.
I'd just like to add that while things *may* break if we implement
this—anything can break after all—the fact remains that things already
*are* broken the way it is now.
And debian/ubuntu already prioritize ~/.local/bin, so we're not going
into untested waters either.
> The point was that we need a consistent approach - we can't just consider
> $PATH in isolation, because it interacts with other search paths, either
> in env vars or builtin to apps. Either all should honour user location
> first, or all should honour system location first, a mix of both is the
> worst of all possible worlds as it maximises chances of breakage.
>
How does prioritized ~/.local match removing #!/usr/bin/env from
Fedora packages? It smells pretty inconsistently.
-- Petr
3:48 a.m.
On 4.5.2018 10:38, Petr Pisar wrote:> How does prioritized ~/.local
match removing #!/usr/bin/env from
Fedora packages? It smells pretty inconsistently.
When running RPM installed tools we want them to run on RPM installed
interpreters. When you run stuff from /usr/bin that was installed by
dnf/rpm from Fedora repos, we want to make sure it runs on
/usr/bin/python3 or /usr/bin/perl, also installed by dnf/rpm from Fedora
repos.
When you install stuff you installed as an user via pip or cpan or
whatnot, we try to make sure you can run it easily.
This is completely orthogonal.
Also note that without changing /usr/bin/env shebang to "hardcoded"
shebangs, prioritized ~/.local in PATH would actually be dangerous,
because a rpm/dnf installed file with this shebang:
#!/usr/bin/env perl
Would prioritize ~/.local/bin/perl over /usr/bin/perl.
While with the harcoded shebang (no env), the prioritized ~/.local in
PATH does not affect this at all. It all works - dnf installed stuff is
using dnf installed stuff.
So honestly, this smells pretty consistently.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:10 a.m.
On 05/02/2018 03:23 PM, Tomas Orsava wrote:
Hi!
I'd like to propose putting the ~/.local/bin in front of the /usr/bin
on the PATH.
Currently /usr/bin has priority over ~/.local/bin, which causes a
[bug] where the old system-installed executable written in Python
(from /usr/bin) is launched, but it finds new Python sources
(installed into $HOME) which it doesn't work with and crashes.
[bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
I believe the current configuration breaks the intuitive expectation
that things installed closer to the user should take priority. That's
for example how it works with Python.
Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
PATH (though Ubuntu has ~/bin) so we can't take guidance there.
Correction, *debian/ubuntu do include ~/.local/bin on the PATH and
prioritize it over /usr/bin.*
It's been reported as an issue in [2016] and fixed, the fix was then
lost (that's why it's not in the current release), and then it was fixed
again in February [2018].
[2016] https://launchpad.net/debian/+source/bash/4.3-15
[2018] https://launchpad.net/debian/+source/bash/4.4.18-1
Testing on debian:unstable container image confirms the PATH as
advocated for in this mailing thread, ~/.local/bin first:
$ echo $PATH
/home/foo/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Tomas
Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
Regards,
Tomas
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
5:07 p.m.
Hi,
On Wednesday, 2018-05-02 15:23:10 +0200, Tomas Orsava wrote:
Does anyone see a reason not to prioritize ~/.local/bin over
/usr/bin?
Many have argued one way or another.
Here is what I do, sourcing in a .zshrc (or whatever-shell-rc), which
gives me selective control to override certain commands by placing an
identical named script or symlink in $HOME/mytopbin/ and all other
whatever-named scripts go into $HOME/bin/ and any executable in
~/.local/bin does not accidentally get in the way. If need be I can
symlink ~/.local/bin/foo to ~/mytopbin/foo or have a script that
temporarily changes order.
A further advantage is, that the hand full of overrides don't get out of
sight and once a newer or to be used version is installed via RPM can
easily be removed. Or symlinks be changed pointing to other locations.
Similar to the alternatives mechanism.
I prefer a situation where ~/.local/bin *not* being prioritized yields
problems which I could temporarily or permanently solve as I like, than
the other way 'round that a prioritized ~/.local/bin suddenly makes
things wreak havoc and I wouldn't know why.
This ensures that the paths actually are placed where I desire and don't
end up as arbitrary duplicates:
# Prepend to PATH.
if [ -d "$HOME/mytopbin" ]; then
xPF="$HOME/mytopbin"
PATH="${PATH//:$xPF:/:}"
PATH="${PATH/%:$xPF/}"
PATH="${PATH/#$xPF:/}"
PATH="$xPF:$PATH"
fi
# Append to PATH.
if [ -d "$HOME/bin" ]; then
xPF="$HOME/bin"
PATH="${PATH//:$xPF:/:}"
PATH="${PATH/%:$xPF/}"
PATH="${PATH/#$xPF:/}"
PATH="$PATH:$xPF"
fi
if [ -d "$HOME/.local/bin" ]; then
xPF="$HOME/.local/bin"
PATH="${PATH//:$xPF:/:}"
PATH="${PATH/%:$xPF/}"
PATH="${PATH/#$xPF:/}"
PATH="$PATH:$xPF"
fi
Maybe helps.
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
2:34 a.m.
Does this discussion had any outcomes? I tried to find any conclusions in the thread but I
missed to spot them.
I am asking this because I was redirected to this thread after I opened a bug on RHEL for
the same issue, bug that was closed hours later as NOTABUG, something I do not agree
with.
What do we need to do to make Fedora do the right thing (add it to the top of the list),
just like Debian/Ubuntu. I am sure that they had similar discussions and in the end they
decided to do the right thing.
RHEL bug https://bugzilla.redhat.com/show_bug.cgi?id=1583227 (bad description, see
comments).
PS. For those worried that their user installed tools (~/.local/bin) may introduce
surprises, here is a hint: you can always run commands in a non-login shell which would
only use the system default PATH which does not include the user one. This is the right
way to isolate yourself from user config, not by avoiding to fix the bashrc PATH order.
Remember that user can always edit his profile files and modify the PATH order, something
that would have the same kind of effect as installing the tools.
Thanks
Sorin Sbarnea
3:25 a.m.
On 29.5.2018 09:34, Sorin Sbarnea wrote:
What do we need to do to make Fedora do the right thing (add it to
the top of the list), just like Debian/Ubuntu. I am sure that they had similar discussions
and in the end they decided to do the right thing.
A Fedora change proposal.
https://fedoraproject.org/wiki/Changes/Policy
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4:19 a.m.
I ended up creating
https://fedoraproject.org/wiki/Changes/UserPathPrioritization and I invite
others to improve its description.
--
/sorin
On Tue, May 29, 2018 at 9:25 AM, Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 29.5.2018 09:34, Sorin Sbarnea wrote:
> What do we need to do to make Fedora do the right thing (add it to the
> top of the list), just like Debian/Ubuntu. I am sure that they had similar
> discussions and in the end they decided to do the right thing.
>
A Fedora change proposal.
https://fedoraproject.org/wiki/Changes/Policy
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4:47 a.m.
Hi,
On Tue, May 29, 2018 at 10:19:02AM +0100, Sorin Sbarnea wrote:
I ended up creating
https://fedoraproject.org/wiki/Changes/UserPathPrioritization and I invite
others to improve its description.
awesome, I was about to do the same, therefore I added myself as second
owner to express that I will support this. Do you have an opinion about
what to do with ~/bin, IMHO it should be prioritized, too. I am not sure
if there is a real use case to keep it with lower priority. If there is,
then I will add it to the proposal.
Kind regards
Till
5:48 a.m.
On Tue, May 29, 2018 at 10:19:02AM +0100, Sorin Sbarnea wrote:
> I ended up creating
> https://fedoraproject.org/wiki/Changes/UserPathPrioritization and I invite
> others to improve its description.
A very nice description. Can you add some hints on what needs to change
(/etc/profile?).
Zbyszek
6:15 a.m.
On 29.5.2018 12:48, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, May 29, 2018 at 10:19:02AM +0100, Sorin Sbarnea wrote:
>> I ended up creating
>> https://fedoraproject.org/wiki/Changes/UserPathPrioritization and I invite
>> others to improve its description.
A very nice description. Can you add some hints on what needs to change
(/etc/profile?).
I've added it, it's /etc/skel/.bash_profile
On 29.5.2018 11:47, Till Maas wrote:
awesome, I was about to do the same, therefore I added myself as
second
owner to express that I will support this.
I've done the same.
Do you have an opinion about
what to do with ~/bin, IMHO it should be prioritized, too. I am not sure
if there is a real use case to keep it with lower priority. If there is,
then I will add it to the proposal.
I think that this is the last thing that's needed. Technically, I think
it should be prioritized too. See the end of detailed description.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
7:14 a.m.
----- Original Message -----
From: "Sorin Sbarnea" <ssbarnea(a)redhat.com>
To: "Miro Hrončok" <mhroncok(a)redhat.com>
Cc: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Tuesday, May 29, 2018 11:19:02 AM
Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
I ended up creating
https://fedoraproject.org/wiki/Changes/UserPathPrioritization and I invite
others to improve its description.
This change was approved by FESCo, so I have merged related pull request[1].
--
/sorin
On Tue, May 29, 2018 at 9:25 AM, Miro Hrončok < mhroncok(a)redhat.com > wrote:
On 29.5.2018 09:34, Sorin Sbarnea wrote:
What do we need to do to make Fedora do the right thing (add it to the top of
the list), just like Debian/Ubuntu. I am sure that they had similar
discussions and in the end they decided to do the right thing.
A Fedora change proposal.
https://fedoraproject.org/wiki/Changes/Policy
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[1] https://src.fedoraproject.org/rpms/bash/pull-request/7
--
--
Siteshwar Vashisht
4:19 a.m.
On 29 May 2018 at 09:25, Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 29.5.2018 09:34, Sorin Sbarnea wrote:
> What do we need to do to make Fedora do the right thing (add it to the
> top of the list), just like Debian/Ubuntu. I am sure that they had similar
> discussions and in the end they decided to do the right thing.
>
A Fedora change proposal.
https://fedoraproject.org/wiki/Changes/Policy
Does such reply mean that maintainers of some critical packages like pam,
util-linux are completely not interested to even have opinion about the
subject or to provide expertise?
If it is the case rising the change proposal IMO does not make any sense.
Using env (still dnf shows that more than 250 packages is using
/usr/bin/env) or paths in $PATH pointing to the location where there is no
distribution binaries is extremely dangerous, and I'm really surprised that
no one looks on those already discussed here issues (and few similar or
related) as SERIOUS SECURITY TREAT to whole distribution.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
4:37 a.m.
Hi,
On Tue, May 29, 2018 at 10:19:44AM +0100, Tomasz Kłoczko wrote:
distribution binaries is extremely dangerous, and I'm really
surprised that
no one looks on those already discussed here issues (and few similar or
related) as SERIOUS SECURITY TREAT to whole distribution.
IIRC enough people explained why these are not serious security threats.
Kind regards
Till
7:44 a.m.
On 29 May 2018 at 10:37, Till Maas <opensource(a)till.name> wrote:
Hi,
On Tue, May 29, 2018 at 10:19:44AM +0100, Tomasz Kłoczko wrote:
> distribution binaries is extremely dangerous, and I'm really surprised
that
> no one looks on those already discussed here issues (and few similar or
> related) as SERIOUS SECURITY TREAT to whole distribution.
IIRC enough people explained why these are not serious security threats.
This is nothing personal. Some people are unable to understand the subjects
above some level of the complexity or sometimes some classes of the
problems :(
Yes, I've already noticed that some people commenting in this thread really
do not understand the treat, and because some of those people are sometimes
responsible for making some crucial Fedora decisions this is nothing more
than yet another small crack in whole distribution maintenance process.
Just for the record: security risk which I'm talking about is straightly
related not with adding ~/.local/bin to $PATH, but with paths like
/usr/local/bin and /usr/local/sbin which are already used in the $PATH.
This connected with using env in many current packages adds next batch of
possibilities. However, all those possibilities became *few years ago*
suddenly opened/active only because what now is in the $PATH and because
some distribution binaries or scripts allows use programs from outside of
the distribution BEFORE using standard paths where executables are
installed by all packages.
$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin
Any compilation of the packages on the distro build systems, any execution
of the program without full; path in ALL scripts (check /etc/profile can
you find such programs called in script like this one) or most of the use
execve() with above $PATH in env is affected as well by what is in the
$PATH .. NOW!
Adding ~/.local/bin to the $PATH with the current level of the risk would
be barely noticeable.
Just try to grep across /usr for /usr/local. This is not only about $PATH.
Many scripts, programs or configuration files have HARDCODED checking
availability of some resources or executables in /usr/local before start
use those from /usr.
Something what started many decades ago (in U*nix epoch of the flint) in
the time when people have' been installing additional programs in
/usr/local prefix because they've been developing something or because
distributions where very small almost always was necessary to install
something now STILL is used without all those reasons.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
9:22 a.m.
On 29 May 2018 at 13:57, Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 29.5.2018 14:44, Tomasz Kłoczko wrote:
> This connected with using env in many current packages adds next batch of
> possibilities.
>
Agreed. Hence we try to fight env shebangs by brp scripts.
Problem is that this bpr script brs been already introduces something like
few months ago.
Next day after new version of the redhat-rpm-config package with this brp
script has been introduced someone should send ALL packages affected by
this issue send as batch to rebuild..
Result is is that none of the Fedora packagers with proven packager
permissions are involved in such changes which should be done under "Shoot
And Forget".regime.
The same with not only critical changes but some improvements which should
be introduces in SAF mode/regime.
~Year ago I've initiated some of such changes and they never been finished
to the bottom of the list.
Few examples:
# (dnf -C repoquery --whatrequires initscripts; dnf -C repoquery
--whatrequires systemd)|sort|uniq -d| wc -l
25
# dnf -C repoquery --whatrequires initscripts| wc -l
66
Q: How long already systemd iis in use in Fedora?
# dnf -C repoquery --whatrequires /sbin/ldconfig| wc -l
18675
# dnf -C repoquery --whatrequires /sbin/install-info| wc -l
389
Almost no one removes bcond macroisation for EOSed <=F25 oe epel{4,5}
.
.
(I can make this list at least 3-4 times longer)
In other words: I've already lost faith that using env will be wiped out
because it is literally NULL focus of the Fedora Committees to coordinate,
control and report progress on such changes.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
9:31 a.m.
On 29.5.2018 16:22, Tomasz Kłoczko wrote:
On 29 May 2018 at 13:57, Miro Hrončok <mhroncok(a)redhat.com
<mailto:mhroncok@redhat.com>> wrote:
On 29.5.2018 14:44, Tomasz Kłoczko wrote:
This connected with using env in many current packages adds next
batch of possibilities.
Agreed. Hence we try to fight env shebangs by brp scripts.
Problem is that this bpr script brs been already introduces something
like few months ago.
Next day after new version of the redhat-rpm-config package with this
brp script has been introduced someone should send ALL packages affected
by this issue send as batch to rebuild..
Actually this was supposed to be covered by mass rebuild. However there
are packages that FTBFS for ages.
See for example:
https://koji.fedoraproject.org/koji/packageinfo?packageID=15893
Now finally we will remove those:
https://fedoraproject.org/wiki/Fails_to_build_from_source
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:24 a.m.
Hi,
On Tue, May 29, 2018 at 01:44:00PM +0100, Tomasz Kłoczko wrote:
Just try to grep across /usr for /usr/local. This is not only about
$PATH.
Many scripts, programs or configuration files have HARDCODED checking
availability of some resources or executables in /usr/local before start
use those from /usr.
This is also not a serious security threat.
Kind regards
Till
11:18 a.m.
On 29 May 2018 at 15:24, Till Maas <opensource(a)till.name> wrote:
Hi,
On Tue, May 29, 2018 at 01:44:00PM +0100, Tomasz Kłoczko wrote:
> Just try to grep across /usr for /usr/local. This is not only about
$PATH.
> Many scripts, programs or configuration files have HARDCODED checking
> availability of some resources or executables in /usr/local before start
> use those from /usr.
This is also not a serious security threat.
And this claim bases on what kind of facts?
Can you prove this?
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
11:38 a.m.
On Tue, May 29, 2018 at 05:18:48PM +0100, Tomasz Kłoczko wrote:
On 29 May 2018 at 15:24, Till Maas <opensource(a)till.name>
wrote:
> This is also not a serious security threat.
>
And this claim bases on what kind of facts?
Can you prove this?
Sure, there is no logo or catchy name for it.
Kind regards
Till
2130
days inactive
2185
days old
70 comments
24 participants
participants (24)
-
Björn Persson -
Daniel P. Berrangé -
Eike Rathke -
Iain Rae -
John Florian -
Jonathan Wakely -
Kamil Dudka -
Lennart Poettering -
Miro Hrončok -
Nicolas Mailhot -
Panu Matilainen -
Paul Wouters -
Petr Pisar -
Przemek Klosowski -
R P Herrold -
Siteshwar Vashisht -
Sorin Sbarnea -
Stephen Gallagher -
Stephen John Smoogen -
Till Maas -
Tomas Orsava -
Tomasz Kłoczko -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek