On 8 October 2014 12:35, Miloslav Trmač m...@redhat.com wrote:
Been away for a week and come back to this nonsense. Why put so much
effort into arguing *against* having the right interpreter listed at
the top of a script. Seems pretty perverse to insist it should be
/bin/sh to maintain a
On Wed, Oct 8, 2014 at 5:11 PM, Gerald B. Cox gb...@bzb.us wrote:
My thought is this whole topic was started as a result of the recent Bash
vulnerability which has since been corrected. Not bad for a product that
has been around for decades. Nothing against Dash, but changing a default
On Thu, 2 Oct 2014 14:12:12 +0100
Daniel P. Berrange berra...@redhat.com wrote:
I'd be curious of the results if someone wants to take a stock Fedora 21
install and switch /bin/sh to point to dash and report if they can still
boot login to GNOME.
I did a smaller run on a server without
- Original Message -
On 6 October 2014 17:28, Miloslav Trmač m...@redhat.com wrote:
- Original Message -
usage/requirement as well. Bringing the benefits of supporting dash to…
the satisfaction of pedantically using the POSIX /bin/sh path as
frequently as possible?
My thought is this whole topic was started as a result of the recent Bash
vulnerability which has since been corrected. Not bad for a product that
has been around for decades. Nothing against Dash, but changing a default
isn't something that should be done each time the wind changes direction.
A
Il 02/10/2014 11:04, Zdenek Kabelac ha scritto:
It used to give significant boost for automake libtool based software
- however at some point libtool started to use bashisms and so you
cannot just replace /bin/sh - dash - as build will fail.
This is wrong.
libtool detects whether you can
Il 04/10/2014 18:17, Zdenek Kabelac ha scritto:
And yes - with UsrMove we lost distinction between
what are system tools
and
what are usr tools.
What you call system tools is simply the content of the initramfs.
Paolo
--
devel mailing list
devel@lists.fedoraproject.org
Dne 6.10.2014 v 08:21 Paolo Bonzini napsal(a):
Il 04/10/2014 18:17, Zdenek Kabelac ha scritto:
And yes - with UsrMove we lost distinction between
what are system tools
and
what are usr tools.
What you call system tools is simply the content of the initramfs.
Paolo
Close - but not exactly.
Dne 6.10.2014 v 08:06 Paolo Bonzini napsal(a):
Il 02/10/2014 11:04, Zdenek Kabelac ha scritto:
It used to give significant boost for automake libtool based software
- however at some point libtool started to use bashisms and so you
cannot just replace /bin/sh - dash - as build will fail.
On 10/06/2014 08:57 AM, Zdenek Kabelac wrote:
Well all I can say is autoconf (at least on my rawhide) doesn't work
with dash for quite some time.
Care to share more details?
Could be a dash bug, could be an autoconf bug, could be a local
configuration breakage, could be something else.
On Sat, Oct 4, 2014 at 8:37 AM, Panu Matilainen
pmati...@laiskiainen.org wrote:
I'm sure rpmlint can (be made to) check for bashisms...
https://sourceforge.net/p/rpmlint/tickets/39/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 6 October 2014 00:06, Paolo Bonzini pbonz...@redhat.com wrote:
Il 02/10/2014 11:04, Zdenek Kabelac ha scritto:
It used to give significant boost for automake libtool based software
- however at some point libtool started to use bashisms and so you
cannot just replace /bin/sh - dash -
as the default
shell and Android uses mksh. While this appears to have been done
primary to increase bootup efficiency (which is not relevant with
systemd), it might help with security
More bashism's in .spec files:
+ pushd src
/tmp/rpm/rpm-tmp.047Jay: 43: /tmp/rpm/rpm-tmp.047Jay: pushd
(https://lwn.net/Articles/343924/) have been using dash as the default
shell and Android uses mksh. While this appears to have been done
primary to increase bootup efficiency (which is not relevant with
systemd), it might help with security
More bashism's in .spec files:
+ pushd src
- Original Message -
At that point switching anything to dash can _only increase_, not reduce,
the disk space needed, and is very likely to increase the total page cache
usage/requirement as well. Bringing the benefits of supporting dash to…
the satisfaction of pedantically using
On 6 October 2014 17:28, Miloslav Trmač m...@redhat.com wrote:
- Original Message -
At that point switching anything to dash can _only increase_, not reduce,
the disk space needed, and is very likely to increase the total page cache
usage/requirement as well. Bringing the benefits
On 10/04/2014 01:05 AM, Rahul Sundaram wrote:
On Fri, Oct 3, 2014 at 6:59 PM, Nico Kadel-Garci wrote:
And it's going to break backports to EPEL for RHEL 5 or RHEL 6, or
CentOS or Scientific Linux, pretty seriously
Please explain how.
Systems which haven't undergone UsrMove don't
Dne 4.10.2014 v 18:00 Florian Weimer napsal(a):
On 10/04/2014 01:05 AM, Rahul Sundaram wrote:
On Fri, Oct 3, 2014 at 6:59 PM, Nico Kadel-Garci wrote:
And it's going to break backports to EPEL for RHEL 5 or RHEL 6, or
CentOS or Scientific Linux, pretty seriously
Please explain how.
On 10/04/2014 06:03 PM, Zdenek Kabelac wrote:
We still have universal:
#/usr/bin/env bash
Sadly, some systems have /bin/env, but not /usr/bin/env.
--
Florian Weimer / Red Hat Product Security
--
devel mailing list
devel@lists.fedoraproject.org
Am 04.10.2014 um 18:08 schrieb Florian Weimer:
On 10/04/2014 06:03 PM, Zdenek Kabelac wrote:
We still have universal:
#/usr/bin/env bash
Sadly, some systems have /bin/env, but not /usr/bin/env
on the Fedoras side a non-brainer
just use /bin/env since after UsrMove both works
Dne 4.10.2014 v 18:08 Florian Weimer napsal(a):
On 10/04/2014 06:03 PM, Zdenek Kabelac wrote:
We still have universal:
#/usr/bin/env bash
Sadly, some systems have /bin/env, but not /usr/bin/env.
Sadly it's fault of that distro - Fedora is not here to fix other distro
mistakes...
'env'
On 10-2-14 10:01:45 Rahul Sundaram wrote:
On Thu, Oct 2, 2014 at 9:56 AM, Miroslav Suchý wrote:
On 10/02/2014 04:39 AM, Rahul Sundaram wrote:
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora?
Why starting with changing target of /bin/sh?
Can we
On 10/01/2014 08:39 PM, Rahul Sundaram wrote:
Hi
Is it worth considering using Dash as the default (non-interactive)
shell in Fedora? Other distributions including Ubuntu and Debian
(https://lwn.net/Articles/343924/) have been using dash as the default
shell and Android uses mksh. While
On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:
Is it worth considering using Dash as the default (non-interactive)
shell in Fedora? Other distributions including Ubuntu and Debian
(https://lwn.net/Articles/343924/) have been using dash as the default
shell and Android uses
dash as the default
shell and Android uses mksh. While this appears to have been done
primary to increase bootup efficiency (which is not relevant with
systemd), it might help with security
More bashism's in .spec files:
+ pushd src
/tmp/rpm/rpm-tmp.047Jay: 43: /tmp/rpm/rpm-tmp.047Jay: pushd
(https://lwn.net/Articles/343924/) have been using dash as the default
shell and Android uses mksh. While this appears to have been done
primary to increase bootup efficiency (which is not relevant with
systemd), it might help with security
More bashism's in .spec files:
+ pushd src
/tmp/rpm/rpm
Hi
On Fri, Oct 3, 2014 at 9:04 AM, Garry T. Williams gtwilli...@gmail.com
wrote:
$ (checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin) )
21 /dev/null|grep 'possible bashism'|awk '{print $4}'|sort -u|wc -l
113
$
Many of these trigger multiple warnings from
On Fri, Oct 3, 2014 at 6:14 PM, Rahul Sundaram methe...@gmail.com wrote:
Hi
On Fri, Oct 3, 2014 at 9:04 AM, Garry T. Williams gtwilli...@gmail.com
wrote:
$ (checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin) )
21 /dev/null|grep 'possible bashism'|awk '{print $4}'|sort
Hi
On Fri, Oct 3, 2014 at 6:59 PM, Nico Kadel-Garci wrote:
And it's going to break backports to EPEL for RHEL 5 or RHEL 6, or
CentOS or Scientific Linux, pretty seriously
Please explain how.
Rahul
--
devel mailing list
devel@lists.fedoraproject.org
On Fri, Oct 03, 2014 at 06:14:05PM -0400, Rahul Sundaram wrote:
On Fri, Oct 3, 2014 at 9:04 AM, Garry T. Williams gtwilli...@gmail.com
wrote:
$ (checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin) )
21 /dev/null|grep 'possible bashism'|awk '{print $4}'|sort -u|wc -l
Hi
On Fri, Oct 3, 2014 at 7:12 PM, Jakub Jelinek wrote:
But why? Seriously, bash has lots of nice extensions, are you going in
this
quest to stop using extensions
You seem to have misread what I said. Bash is great and I love some of
the extensions but if you want to use bash, just make
Once upon a time, Jakub Jelinek ja...@redhat.com said:
But why? Seriously, bash has lots of nice extensions, are you going in this
quest to stop using extensions going to suggest that we get rid of GNU C
library extensions usages in the distro programs next, or GCC extensions,
what else?
To
Hi
On Fri, Oct 3, 2014 at 7:23 PM, Chris Adams wrote:
To be fair, portable programs wrap GCCisms in #ifdefs.
Indeed. To wrap this up for now, I have filed
https://fedorahosted.org/fesco/ticket/1352
Rahul
--
devel mailing list
devel@lists.fedoraproject.org
? Other distributions including Ubuntu and Debian
(https://lwn.net/Articles/343924/) have been using dash as the default
shell and Android uses mksh. While this appears to have been done
primary to increase bootup efficiency (which is not relevant with
systemd), it might help with security
More
/343924/) have been using dash as the default shell
and Android uses mksh. While this appears to have been done primary to
increase bootup efficiency (which is not relevant with systemd), it might
help with security
I know not of those various reasons why in Debian and friends, dash is
the shell
On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:
Hi
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
https://lwn.net/Articles/343924/) have been using dash as the default shell
On Wed, 01.10.14 22:19, Chris Adams (li...@cmadams.net) wrote:
One thing that might be a good topic for consideration: is there a
reasonable way to allow different implementations to take the /bin/sh
symlink? Could this be handled through the alternatives system, so that
admins could choose
On 10/02/2014 08:33 AM, Lennart Poettering wrote:
If you change /bin/sh to dash, then you'll have to map two shell
binaries into memory (since the login shell is going to stay on bash),
hence the resource usage grows.
The login shell is a per-user configurable setting, thus the memory
On 10/02/2014 08:42 AM, Lennart Poettering wrote:
On Wed, 01.10.14 22:19, Chris Adams (li...@cmadams.net) wrote:
One thing that might be a good topic for consideration: is there a
reasonable way to allow different implementations to take the /bin/sh
symlink? Could this be handled through the
://lwn.net/Articles/343924/) have been using dash as the default shell
and Android uses mksh. While this appears to have been done primary to
increase bootup efficiency (which is not relevant with systemd), it might
help with security
Since the recent Shellshock aka Bashdoor vulnerability
://lwn.net/Articles/343924/) have been using dash as the default shell
and Android uses mksh. While this appears to have been done primary to
increase bootup efficiency (which is not relevant with systemd), it might
help with security
Since the recent Shellshock aka Bashdoor vulnerability, there have
/) have been using dash as the default shell
and Android uses mksh. While this appears to have been done primary to
increase bootup efficiency (which is not relevant with systemd), it might
help with security
Since the recent Shellshock aka Bashdoor vulnerability, there have been
some discussions
On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
Hi
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
https://lwn.net/Articles/343924/) have been using dash as the default shell
and Android
On 10/02/2014 09:14 AM, Tomasz Torcz wrote:
/bin/sh isn't supposed to stay in memory. It's for one-off scripts,
not for interactive use.
It will stay in memory around command invocations, and the executable
code and mapped data will remain in the page cache (hopefully).
Allegedly, dash
Hi
On Thu, Oct 2, 2014 at 4:04 AM, Richard W.M. Jones wrote:
On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
For Ubuntu the stated reason to follow Debian was pretty bogus[1] --
Ubuntu didn't follow Debian here. It was the other way around.
It doesn't even avoid Debian
hello
Don't we consider using zsh?
Balint
On Thu, 2014-10-02 at 10:04 +0200, Florian Weimer wrote:
On 10/02/2014 09:14 AM, Tomasz Torcz wrote:
/bin/sh isn't supposed to stay in memory. It's for one-off scripts,
not for interactive use.
It will stay in memory around command
On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):
On the other hand - usage of dash significantly speeds up compilation of
autoconf projects - it's pretty interesting to see the compilation with
dash
is then maybe even 50% faster in non
On 2014-10-02 10:25, Rahul Sundaram wrote:
It doesn't even avoid Debian Ubuntu having a security problem, since
they still need to fix bash.
Sure. Unless they stop shipping bash, they got to fix security problems.
That is no surprise. The real question is whether it reduced the impact of
On 10/02/2014 10:32 AM, Balint Szigeti wrote:
hello
Don't we consider using zsh?
I'd rather not. Thoughout its history, zsh has had lots of issues
originating from limitations, bugs and incompatibilities.
I don't know about the current situation, but e.g., the configure
scripts I just
Dne 2.10.2014 v 10:40 Ralf Corsepius napsal(a):
On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):
On the other hand - usage of dash significantly speeds up compilation of
autoconf projects - it's pretty interesting to see the compilation with
On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:
On 10/02/2014 10:32 AM, Balint Szigeti wrote:
hello
Don't we consider using zsh?
I'd rather not. Thoughout its history, zsh has had lots of issues
originating from limitations, bugs and incompatibilities.
hm... Interesting, I
On 10/02/2014 11:04 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 10:40 Ralf Corsepius napsal(a):
On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):
It used to give significant boost for automake libtool based software
- however at some point
On 10/02/2014 11:25 AM, Balint Szigeti wrote:
On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:
On 10/02/2014 10:32 AM, Balint Szigeti wrote:
hello
Don't we consider using zsh?
I'd rather not. Thoughout its history, zsh has had lots of issues
originating from limitations, bugs and
Am 02.10.2014 um 09:14 schrieb Tomasz Torcz:
On Thu, Oct 02, 2014 at 08:33:23AM +0200, Lennart Poettering wrote:
since you have two packages to look after (Yes, by adding dash to the
default stack you just put the extra burden on Fedora to quickly
update two packages instead of just one in
On Thu, 2014-10-02 at 12:07 +0200, Ralf Corsepius wrote:
On 10/02/2014 11:25 AM, Balint Szigeti wrote:
On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:
On 10/02/2014 10:32 AM, Balint Szigeti wrote:
hello
Don't we consider using zsh?
I'd rather not. Thoughout its history,
Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
The shell is API.
Yep, and that API is the POSIX shell language, an extended version of
the Bourne shell. It is a Linux curiousity that came along to use bash
as /bin/sh.
Currently, if people write shell (#!/bin/sh) scripts
on
Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
If you change /bin/sh to dash, then you'll have to map two shell
binaries into memory (since the login shell is going to stay on bash),
hence the resource usage grows.
systemd (as PID 1, not counting additional required processes)
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
Changing the default /bin/sh is going to break the world.
[citation needed]
Anything that depends on bash as /bin/sh is already getting Fedora
specific. Debian/Ubuntu don't use bash as /bin/sh for years, and none
of the other major
Hi
On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:
If that's the case, why do we have the /bin/sh symlink? Just remove it
and make the bash dependency explicit (so everything has to call
/bin/bash).
I understand this is a rherotical argument but the symlink exists because
it is
On Thu, Oct 02, 2014 at 08:07:14AM -0500, Chris Adams wrote:
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
Changing the default /bin/sh is going to break the world.
[citation needed]
Anything that depends on bash as /bin/sh is already getting Fedora
specific.
On 10/1/2014 22:39, Rahul Sundaram wrote:
Since the recent Shellshock aka Bashdoor vulnerability, there have
been some discussions about more distributions switching over...
So there's a vulnerability found in bash, it gets patched almost
immediately, and all of a sudden there's a push to
On Thu, 02.10.14 14:12, Daniel P. Berrange (berra...@redhat.com) wrote:
On Thu, Oct 02, 2014 at 08:07:14AM -0500, Chris Adams wrote:
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
Changing the default /bin/sh is going to break the world.
[citation needed]
Anything
Hi
On Thu, Oct 2, 2014 at 9:18 AM, Tom Rivers wrote:
So there's a vulnerability found in bash, it gets patched almost
immediately, and all of a sudden there's a push to abandon it altogether?
That is a mischaracterization. Bash will remain the interactive shell.
This discussion is limited
On Thu, Oct 02, 2014 at 08:05:09AM -0500, Chris Adams wrote:
Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
If you change /bin/sh to dash, then you'll have to map two shell
binaries into memory (since the login shell is going to stay on bash),
hence the resource usage
On Thu, Oct 2, 2014 at 9:27 AM, Rahul Sundaram methe...@gmail.com wrote:
Hi
On Thu, Oct 2, 2014 at 9:18 AM, Tom Rivers wrote:
So there's a vulnerability found in bash, it gets patched almost
immediately, and all of a sudden there's a push to abandon it altogether?
That is a
On 10/2/2014 09:27, Rahul Sundaram wrote:
That is a mischaracterization. Bash will remain the interactive
shell. This discussion is limited to switching the system shell
(/bin/sh) from Bash to potentially Dash.
While I appreciate your technical correction on the scope of this
proposed
Hi
On Thu, Oct 2, 2014 at 9:42 AM, Josh Boyer wrote:
But the prompt for doing so is a security incident that has already
been fixed. If this was really a worthwhile endeavour, why hasn't it
come up before?
Our needs continue to evolve. We didn't consider size as much before but
there is a
On 10/02/2014 04:39 AM, Rahul Sundaram wrote:
Is it worth considering using Dash as the default (non-interactive) shell in
Fedora?
Why starting with changing target of /bin/sh?
Can we start with smaller step?
Like put in Packing Guidelines, that authors and maintainers of non-interactive
Once upon a time, Miroslav Suchý msu...@redhat.com said:
Like put in Packing Guidelines, that authors and maintainers of
non-interactive shell scripts should use
#!/usr/bin/dash
rather then
#!/bin/sh or
#!/usr/bin/bash
No, /bin/sh is the standard-defined definitive place for the
Hi
On Thu, Oct 2, 2014 at 9:49 AM, Tom Rivers wrote:
While I appreciate your technical correction on the scope of this proposed
switch, you conveniently failed to address the core argument I made which
is by far the larger issue: the impetus...
I didn't address it because it was not
Hi
On Thu, Oct 2, 2014 at 9:56 AM, Miroslav Suchý wrote:
On 10/02/2014 04:39 AM, Rahul Sundaram wrote:
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora?
Why starting with changing target of /bin/sh?
Can we start with smaller step?
Like put in Packing
On Thu, Oct 02, 2014 at 03:21:33PM +0200, Lennart Poettering wrote:
I am more concerned about code written by admins and users. I kinda
hope that we don't ship too massive shell programs in Fedora, (well,
except of course autoconf scripts...), but I am pretty sure that shell
is one of the most
On 10/02/2014 03:07 PM, Chris Adams wrote:
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
Changing the default /bin/sh is going to break the world.
[citation needed]
Just look for brace expansion in spec files. It's use is *extremely*
common. And many of the failures are
On 10/2/2014 09:58, Rahul Sundaram wrote:
I didn't address it because it was not really relevant either. The
impetus is merely the backstory.
On the contrary, the rationale for your proposed change is very
relevant. The reasons for undertaking a project of this magnitude
should be
Hi
On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers wrote:
On 10/2/2014 09:58, Rahul Sundaram wrote:
I didn't address it because it was not really relevant either. The
impetus is merely the backstory.
On the contrary, the rationale for your proposed change is very relevant.
Sure but the
On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
Thanks for bringing up the discussion. Just as we shouldn't change things
for no reason, we
Hello,
On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers wrote:
On 10/2/2014 09:58, Rahul Sundaram wrote:
I didn't address it because it was not really relevant either. The
impetus
is
merely the backstory.
On the contrary, the rationale for your proposed change is very
Hi
On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač wrote:
OK, then; care to explicitly list the advantages you expect to see from
such a switch, and why they outweigh the disadvantages and the migration
costs?
I don't have a predrawn conclusion that I am advocating strongly for here
but I
I don't see any real benefit to move to dash since we get rid of sysV
init, no security improvements, but a lot of breakages to fix (Debian
spent a lot of time to fix bashisms in their packages ...)
That doesn't mean that we shouldn't consider it -this is a sane to
periodically re-assess our
On Thu, Oct 02, 2014 at 11:53:18AM -0400, Rahul Sundaram wrote:
Hi
On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač wrote:
OK, then; care to explicitly list the advantages you expect to see from
such a switch, and why they outweigh the disadvantages and the migration
costs?
I
Am 02.10.2014 um 17:53 schrieb Rahul Sundaram:
On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač wrote:
The expected security improvement is essentially nonexistent. In the
current case of importing functions from
the environment (and we could have a looong philosophical conversation
On 10/2/2014 11:13, Rahul Sundaram wrote:
Sure but the rationale isn't just security as I have explained
earlier. Do read the links and other mails fully.
I have read the emails fully. Sure, I see where you said there were
other reasons later in the discussion, but that's not what your
The expected security improvement is essentially nonexistent. In the current
case of importing functions from the environment (and we could have a looong
philosophical conversation about whether this is a vulnerability in bash or
in its callers, where the likely outcome is “not a vulnerability
2014-10-02 17:56 GMT+02:00 Tomasz Torcz to...@pipebreaker.pl:
Also it will reduce differences between Linux distribution. And take us
closed to what majority (Ubuntu and Debian) does.
I don't see the point, now that we use systemd ...
Besides, even on Debian/Ubuntu, Bash is still the most
On Thu, Oct 02, 2014 at 05:56:17PM +0200, Tomasz Torcz wrote:
Also it will reduce differences between Linux distribution. And take us
closed to what majority (Ubuntu and Debian) does.
We don't need to follow Ubuntu or Debian in every not-so-smart decision they
make, we haven't followed them
On 10/02/2014 03:07 PM, Rahul Sundaram wrote:
Hi
On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:
If that's the case, why do we have the /bin/sh symlink? Just remove it
and make the bash dependency explicit (so everything has to call
/bin/bash).
I understand this is a
On Thu, Oct 02, 2014 at 11:59:54 -0400,
Miloslav Trmač m...@redhat.com wrote:
As I said in the snipped part, anyone able to submit arbitrary input to a shell
can already cause it to do arbitrary things. The parser bugs do not give the
attacker anything they don’t already have, so they are
Hi
On Thu, Oct 2, 2014 at 12:13 PM, Ralf Corsepius rc040...@freenet.de wrote:
No. /bin/sh is supposed to be a POSIX-compatible shell.
Right. This is what I meant. We can't just remove /bin/sh completely and
require users to always use dash or bash explicitly. Whether it is a
symlink and
Dne 2.10.2014 v 18:00 Haïkel napsal(a):
2014-10-02 17:56 GMT+02:00 Tomasz Torcz to...@pipebreaker.pl:
Also it will reduce differences between Linux distribution. And take us
closed to what majority (Ubuntu and Debian) does.
I don't see the point, now that we use systemd ...
Besides, even
On Thu, Oct 02, 2014 at 11:22:18AM -0500, Bruno Wolff III wrote:
I think the disconnect there was that people assumed that as long as
you controlled which environment variables (by name) were passed you
were OK. It was assumed that the values weren't processed outside of
what you explicitly
On Thu, Oct 02, 2014 at 13:05:27 -0400,
Matthew Miller mat...@fedoraproject.org wrote:
For the case of arbitrary variables (like USER_AGENT), the problem is
closed, because now only variables prefixed BASH_FUNC_ and with a suffix of
() in our current patch or %% upstream are scanned for
Am 02.10.2014 um 19:08 schrieb Bruno Wolff III:
On Thu, Oct 02, 2014 at 13:05:27 -0400,
Matthew Miller mat...@fedoraproject.org wrote:
For the case of arbitrary variables (like USER_AGENT), the problem is
closed, because now only variables prefixed BASH_FUNC_ and with a suffix of
() in our
Hi
On Thu, Oct 2, 2014 at 11:59 AM, Tom Rivers wrote:
You know, you could've simply replied to my original take on your
self-described opportunistic proposal with something like, No, Tom, I'm
not just making this proposal because of Shellshock. I really think there
are some merits to dash
On 2 October 2014 17:13, Ralf Corsepius rc040...@freenet.de wrote:
On 10/02/2014 03:07 PM, Rahul Sundaram wrote:
Hi
On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:
If that's the case, why do we have the /bin/sh symlink? Just remove
it
and make the bash dependency explicit (so
On 2 October 2014 13:59, Chris Adams li...@cmadams.net wrote:
Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
In general, I am pretty sure that except a couple of programming
language or UNIX aficionades very few people can actually correctly
separate bashisms from true
Hi
On Thu, Oct 2, 2014 at 11:57 AM, Reindl Harald wrote:
because the conclusion that dash is not vulerable for
other things is invalid
I am afraid there was no such conclusions. To acknowledge known bugs in
bash doesn't require anyone to conclude that dash doesn't have bugs.
Rahul
--
Am 02.10.2014 um 22:45 schrieb Rahul Sundaram:
On Thu, Oct 2, 2014 at 11:57 AM, Reindl Harald wrote:
because the conclusion that dash is not vulerable for
other things is invalid
I am afraid there was no such conclusions. To acknowledge known bugs in bash
doesn't require
Hi
On Thu, Oct 2, 2014 at 4:56 PM, Reindl Harald wrote:
then that paragraph refer to Shellshock was not really appropriate without
make really clear that this is not a panic reaction in context of already
fixed bash bugs
I didn't think one would assume it is just a panic reaction if they
Hi
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
https://lwn.net/Articles/343924/) have been using dash as the default shell
and Android uses mksh. While this appears to have been done primary to
increase
Once upon a time, Rahul Sundaram methe...@gmail.com said:
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
https://lwn.net/Articles/343924/) have been using dash as the default shell
and Android uses mksh
100 matches
Mail list logo
