Re: bash without importing shell functions from the environment

2014-10-01 Thread Ian Jackson 
Nikolaus Rath writes ("Re: bash without importing shell functions from the 
environment"):
> I think the latter. I was actually curious as well and checked. The
> wheezy version has custom debian/patches handling where e.g.
> debian/patches/series is processed by the C preprocessor. I think that
> qualifies at least as exotic :-).

I am indeed talking about the layout of the source packages in
oldstable and stable.  I don't want to explain in detail because I
can't put forward my opinion of what I found without violating the
mailing list code of conduct.  (And, as people are pointing out,
because it's fixed in unstable/testing.)

As I say, it led to me more greatly appreciate the hard work done (and
pain suffered) on all our behalf by the stable and LTS security teams.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21548.1076.407015.829...@chiark.greenend.org.uk

Re: bash without importing shell functions from the environment

2014-09-30 Thread Nikolaus Rath 
Matthias Klose  writes:
> Am 25.09.2014 um 17:29 schrieb Ian Jackson:
>> (It took me merely a few moments with the source code to prepare the
>> code patch.  But then I had to spend an hour or two wrestling with the
>> patch systems of the packages in squeeze and wheezy.  I would like to
>> take this opportunity to say how much I appreciate the work of the
>> security team, who have to cope on a daily basis with [CoC violation]
>> such as that found in the squeeze and wheezy bash Debian `source'
>> packages.)
>> 
>> Ian.
>
> so maybe as a non-native speaker I am unaware of some joke here, or are you 
> just
> trolling about something fixed for jessie/unstable?

I think the latter. I was actually curious as well and checked. The
wheezy version has custom debian/patches handling where e.g.
debian/patches/series is processed by the C preprocessor. I think that
qualifies at least as exotic :-).

Best,
Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738b8ilk9@vostro.rath.org

Re: bash without importing shell functions from the environment

2014-09-30 Thread Jonathan Dowland 
On Tue, Sep 30, 2014 at 07:58:38PM +0200, Matthias Klose wrote:
> so maybe as a non-native speaker I am unaware of some joke here, or are you 
> just
> trolling about something fixed for jessie/unstable?

I was curious to see what Ian was complaining about, and what has changed up to
the jessie version. I can see that the rules file is a little bit simpler. I 
guess
that's because you've moved to the 3.0 (quilt) package type? I couldn't find the
changelog entry documenting when you did this.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140930201939.GA8221@debian

Re: bash without importing shell functions from the environment

2014-09-30 Thread Matthias Klose 
Am 25.09.2014 um 17:29 schrieb Ian Jackson:
> (It took me merely a few moments with the source code to prepare the
> code patch.  But then I had to spend an hour or two wrestling with the
> patch systems of the packages in squeeze and wheezy.  I would like to
> take this opportunity to say how much I appreciate the work of the
> security team, who have to cope on a daily basis with [CoC violation]
> such as that found in the squeeze and wheezy bash Debian `source'
> packages.)
> 
> Ian.

so maybe as a non-native speaker I am unaware of some joke here, or are you just
trolling about something fixed for jessie/unstable?

Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/542aef4e.9000...@debian.org

Re: bash without importing shell functions from the environment

2014-09-26 Thread Ian Jackson 
Joey Hess writes ("Re: bash without importing shell functions from the 
environment"):
> Jonathan Dowland wrote:
> > Thank you very much for doing this. I would love to see Debian
> > transition to having this facility disabled by default at some
> > point in the future.
> 
> Florian Weimer's patch doesn't go that far, instead environment
> variables have to have special BASH_FUNC_FOO() names before bash will
> process them as function imports.
> 
> Same result though; as of bash 4.2+dfsg-0.1+deb7u3 we don't have to
> worry about the shell script parser being run on every env var. So,
> the problem is fully solved AFAIK, and in a way that bypasses nearly all
> potential breakage.

Indeed.  Florian's fix is better.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21541.42329.570629.405...@chiark.greenend.org.uk

Re: bash without importing shell functions from the environment

2014-09-26 Thread Joey Hess 
Jonathan Dowland wrote:
> Thank you very much for doing this. I would love to see Debian transition to
> having this facility disabled by default at some point in the future.

Florian Weimer's patch doesn't go that far, instead environment
variables have to have special BASH_FUNC_FOO() names before bash will
process them as function imports.

Same result though; as of bash 4.2+dfsg-0.1+deb7u3 we don't have to
worry about the shell script parser being run on every env var. So,
the problem is fully solved AFAIK, and in a way that bypasses nearly all
potential breakage.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: bash without importing shell functions from the environment

2014-09-26 Thread Jonathan Dowland 
On Thu, Sep 25, 2014 at 04:29:05PM +0100, Ian Jackson wrote:
> I have prepared bash packages which do not honour any shell functions
> they find in the environment.  IMO that is a crazy feature, which
> ought to be disabled.  (I'm running this on chiark now and nothing has
> visibly broken yet.)

Thank you very much for doing this. I would love to see Debian transition to
having this facility disabled by default at some point in the future.

> A codesearch [1] shows that this change will break very few things.

Of course that won't help indicate which external scripts will be affected.  To
get something like this in the archive, we will probably need a runtime switch
to re-enable the old behaviour, if your patches don't already (I haven't looked
yet).

> Arguably we (Debian) should apply this in sid (hence this bug report).
> Doing it in security updates to stable releases is sadly too risky.
> But people who want to take that risk themselves are welcome to
> install my packages.

I'm definitely going to try this in a few places to test to see how widespread
the impact might be.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140926130844.GA7563@debian

Re: bash without importing shell functions from the environment

2014-09-26 Thread Josselin Mouette 
Juliusz Chroboczek  wrote: 
Just to make things clear -- you're advocating #!/bin/sh and running 
dash
as /bin/sh?

(Likely alternatives include at least ksh and mksh, formerly pdksh.)

I think this has already happened wherever it was easy. So to
remove /bin/bash scripts, it needs either some work to remove all
bashisms, or a replacement for the most common functions. So ksh is
certainly part of the solution. 

The global approach should be to make a clear separation between
software intended as login shells (bash, zsh, tcsh) and software that
can be used as script interpreters (dash, mksh… *). And eventually to
forbid using the former ones for the latter use. 

(*) I intendedly omitted csh because it is extremely bad for
both use cases.

-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411721506.8969.1486.camel@dsp0698014

Re: bash without importing shell functions from the environment

2014-09-26 Thread Thorsten Glaser 
On Thu, 25 Sep 2014, shawn wilson wrote:

> In that case, I'd think busybox's sh is *much* more minimalist. Why dash
> over busybox?

There is something called bugs. The busybox implementation
is artificially limited. Also, it uses the busybox common
code, which makes its codebase rather large.

The smallest somewhat self-contained shell is probably the
dash binary from klibc, but it only exists on linux-any.

That being said, there’s another compact, portable shell with
good security properties around…

… but anyway, if bash leaves Essential, I can just replace
dash with mksh locally anyway… goal achieved just the same.
(Modulo the APT bug that makes it not want to install my
replacement package.)

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409260946280.3...@tglase.lan.tarent.de

Re: bash without importing shell functions from the environment

2014-09-25 Thread Russ Allbery 
shawn wilson  writes:
> On Sep 25, 2014 9:36 PM, "Russ Allbery"  wrote:

>> That may be overkill, but I will say that I'm feeling *extremely*
>> grateful the last few days that we pushed forward with switching
>> /bin/sh to dash, even though some folks thought this was a bad idea.
>> Having the shell used by system() and popen() be as simple as possible
>> turns out to be rather important.

> In that case, I'd think busybox's sh is *much* more minimalist. Why dash
> over busybox?

There's a tradeoff between minimal enough to not be caught by surprise by
complexity or bugs, and having sufficient features that people don't just
change all their shells to start with #!/bin/bash or complain so much that
we can't switch at all.  Given that we just *barely* managed with dash, I
don't think we would have succeeded with anything even more minimal.  As
is, I believe some additional features were added to dash over the course
of the (long) push for the change to make it viable to replace /bin/sh,
and a lot of our users still immediately changed /bin/sh back to bash (and
therefore were more vulnerable to this bug).

It's possible we could go more minimal, but it's a lot of effort to drop
features, and really painful to track down all the places those features
are used.  We worked on getting rid of bashisms in the archive for
literally years.  I don't think it's a good time/value tradeoff to switch
to anything with fewer features than dash.

Now, if there's another small shell that supports everything dash supports
but is better on some other axis, we could certainly consider it.  But
don't underestimate the amount of work it takes to validate the whole
archive under a different /bin/sh.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjdnnlbb@hope.eyrie.org

Re: bash without importing shell functions from the environment

2014-09-25 Thread shawn wilson 
On Sep 25, 2014 9:36 PM, "Russ Allbery"  wrote:
>
> Josselin Mouette  writes:
>
> > Since I’m pretty sure we haven’t uncovered all of bash’s “features”,
> > wouldn’t it be a good opportunity to make a release goal of killing all
> > scripts with a #!/bin/bash shebang?
>
> That may be overkill, but I will say that I'm feeling *extremely* grateful
> the last few days that we pushed forward with switching /bin/sh to dash,
> even though some folks thought this was a bad idea.  Having the shell used
> by system() and popen() be as simple as possible turns out to be rather
> important.
>

In that case, I'd think busybox's sh is *much* more minimalist. Why dash
over busybox?

Re: bash without importing shell functions from the environment

2014-09-25 Thread Russ Allbery 
Josselin Mouette  writes:

> Since I’m pretty sure we haven’t uncovered all of bash’s “features”,
> wouldn’t it be a good opportunity to make a release goal of killing all
> scripts with a #!/bin/bash shebang?

That may be overkill, but I will say that I'm feeling *extremely* grateful
the last few days that we pushed forward with switching /bin/sh to dash,
even though some folks thought this was a bad idea.  Having the shell used
by system() and popen() be as simple as possible turns out to be rather
important.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjdnp3hs@hope.eyrie.org

Re: bash without importing shell functions from the environment

2014-09-25 Thread Juliusz Chroboczek 
> Since I’m pretty sure we haven’t uncovered all of bash’s “features”,
> wouldn’t it be a good opportunity to make a release goal of killing all
> scripts with a #!/bin/bash shebang?

Just to make things clear -- you're advocating #!/bin/sh and running dash
as /bin/sh?

(Likely alternatives include at least ksh and mksh, formerly pdksh.)

--jch


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d2ajl0mj.wl-...@pps.univ-paris-diderot.fr

Re: bash without importing shell functions from the environment

2014-09-25 Thread Josselin Mouette 
Le jeudi 25 septembre 2014 à 16:29 +0100, Ian Jackson a écrit :
> I have prepared bash packages which do not honour any shell functions
> they find in the environment.  IMO that is a crazy feature, which
> ought to be disabled.  (I'm running this on chiark now and nothing has
> visibly broken yet.)

Thanks for your effort.

Since I’m pretty sure we haven’t uncovered all of bash’s “features”,
wouldn’t it be a good opportunity to make a release goal of killing all
scripts with a #!/bin/bash shebang?

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411673743.10816.8.ca...@kagura.malsain.org

Re: bash without importing shell functions from the environment

2014-09-25 Thread Thijs Kinkhorst 
Hi Ian,

On Thu, September 25, 2014 17:29, Ian Jackson wrote:
> I have prepared bash packages which do not honour any shell functions
> they find in the environment.  IMO that is a crazy feature, which
> ought to be disabled.  (I'm running this on chiark now and nothing has
> visibly broken yet.)

> A codesearch [1] shows that this change will break very few things.
> Arguably we (Debian) should apply this in sid (hence this bug report).
> Doing it in security updates to stable releases is sadly too risky.
> But people who want to take that risk themselves are welcome to
> install my packages.

Thanks for your message, I'm sure it's useful to people who just want to
be safe and are sure that they do not require this feature. As you say,
given the known real world usage of this functionality this is still too
risky to upload to stable.

Discussions are ongoing on how to address this issue in a way that's
acceptable in terms of breakage to existing systems.

Huzaifa Sidhpurwala's message posted to oss-security just now gives a good
state of affairs of the current thinking and accompanying patches to apply
and/or review.
http://marc.info/?l=oss-security&m=141166689117442&w=2

Cheers,
Thijs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/5a2c911d137eb1446cf2e2bcac0e836c.squir...@aphrodite.kinkhorst.nl