Hi,
Martin Uecker:
> While everybody is looking at bash, isn't this the real the
> injection part? Why are there still programs which copy stuff
> from the network into environment without proper sanitation?
Probably either sheer laziness, or for the usual, misguided-these-days
(IMHO) "be lenien
❦ 26 septembre 2014 10:38 +1000, Brian May :
> True, the usecases overlap somewhat, but they're still different.
>
> I wouldn't want to install n-m (and the 30 libraries it depends
> on)
> in an initramfs, for instance.
>
> Unless I am mistaken, I believe systemd-networkd wo
Brian May writes:
> No, I don't think that is the case. I believe sudo interprets those
> assignments itself (as also shown in man page), and the error I got
> clearly shows this to be the case.
> brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }' ./test.sh
> sudo: sorry, you are not allow
On Fri, Sep 26, 2014 at 01:37:48PM +1000, Brian May wrote:
> On 26 September 2014 12:08, Russ Allbery wrote:
> >
> > > brian@aquitard:~$ sudo echo='() { /bin/echo bar; }' bash
> > > root@aquitard:/home/brian# echo hello
> > > bar
> >
> > I think you have that backwards, don't you? Shouldn't that
On 26 September 2014 14:15, Russ Allbery wrote:
> That would surprise me. In one case, you're setting an environment
> variable and then running sudo. In the other case, you're telling sudo to
> run the command "echo='() { /bin/echo bar; }' echo foo" via a shell.
>
> No, I don't think that is t
Brian May writes:
> On 26 September 2014 12:08, Russ Allbery wrote:
>>
>> I think you have that backwards, don't you? Shouldn't that be:
>>
>> echo='() { /bin/echo bar; }' sudo bash
> I think sudo treats both as the same/similar thing.
That would surprise me. In one case, you're setting a
On 26 September 2014 12:08, Russ Allbery wrote:
>
> > brian@aquitard:~$ sudo echo='() { /bin/echo bar; }' bash
> > root@aquitard:/home/brian# echo hello
> > bar
>
> I think you have that backwards, don't you? Shouldn't that be:
>
> echo='() { /bin/echo bar; }' sudo bash
>
I think sudo treat
On Thu, Sep 25, 2014 at 04:29:05PM +0100, Ian Jackson wrote:
> Package: bash
> Version: 4.1-3
>
> 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 n
On Thu, Sep 25, 2014 at 06:49:32PM -0700, Cameron Norman wrote:
> Perhaps making all those scripts either depend on bash or transition
> to /bin/sh would be a good idea. This could be done through a lintian
> warning I think. Then people interested in working on fully
> transitioning to /bin/sh cou
On Thu, Sep 25, 2014 at 11:21 PM, Christoph Anton Mitterer wrote:
> Well I think snapshot is it's own construction site, isn't it?
snapshot is a read-only (modulo cosmic rays and removal of
non-redistributable things) historical record, files in it will not be
modified to re-sign with newer keys
Russ Allbery :
> Martin Uecker writes:
>
> > While everybody is looking at bash, isn't this the real the injection
> > part? Why are there still programs which copy stuff from the network
> > into environment without proper sanitation?
>
> The previous sanitization for environment variables most
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 she
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
Martin Uecker writes:
> While everybody is looking at bash, isn't this the real the injection
> part? Why are there still programs which copy stuff from the network
> into environment without proper sanitation?
The previous sanitization for environment variables mostly focused on not
letting the
Brian May writes:
> I thought sudo was suppose to be ok, sure doesn't look ok to me.
> brian@aquitard:~$ sudo echo='() { /bin/echo bar; }' bash
> root@aquitard:/home/brian# echo hello
> bar
I think you have that backwards, don't you? Shouldn't that be:
echo='() { /bin/echo bar; }' sudo b
On Thu, Sep 25, 2014 at 12:35 PM, Josselin Mouette wrote:
> 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 r
On 26 September 2014 10:26, Nikolaus Rath wrote:
> Wasn't there some web server that used to put query script variables
> into the environment of the CGI script? Or am I confusing that with
> PHP's evil register_globals?
>
CGI is just one avenue for attack.
There are other avenues. e.g. the ssh
Samuel Thibault:
> Matthias Urlichs, le Thu 25 Sep 2014 21:17:58 +0200, a écrit :
> > Samuel Thibault:
> > > Sounds crazy to me.
> > >
> > Definitely. This is now out in the wild; exploits which simply replace
> > echo or cat-without-/bin are going to happen. :-/
>
> That's not so easy to exploi
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
Simon McVittie writes:
> Approach 1, which is (IMO) better when the changes you are making in
> experimental are truly experimental, like enabling features or patches
> whose medium-term future you're not sure about:
> 2.2.5-5+exp1, ... or -6~exp1, ... or whatever to experimental
> 2.2.5-6 to un
> 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
Samuel Thibault writes:
> Matthias Urlichs, le Thu 25 Sep 2014 21:17:58 +0200, a écrit :
>> Samuel Thibault:
>> > Sounds crazy to me.
>> >
>> Definitely. This is now out in the wild; exploits which simply replace
>> echo or cat-without-/bin are going to happen. :-/
>
> That's not so easy to explo
On 26 September 2014 09:32, Matthias Urlichs wrote:
> True, the usecases overlap somewhat, but they're still different.
>
> I wouldn't want to install n-m (and the 30 libraries it depends on)
> in an initramfs, for instance.
>
Unless I am mistaken, I believe systemd-networkd would be a lot bett
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 608 (new: 16)
Total number of packages offered up for adoption: 138 (new: 0)
Total number of packages reques
On Thu, Sep 25, 2014 at 10:23 PM, Thomas Goirand wrote:
> As wrote by others earlier, that's the amount of memory needed for
> compression. 65 MB of RAM is needed for decompression. That's nothing!!!
That is half the RAM available on my Debian-based phone. Having to
shut down the UI just to insta
Hi,
Guido Günther:
> The overlap between n-m and systemd-networkd saddens me. n-m got
> support for team/bond interfaces, VLANs, etc a while ago and now we get
> to see yet another tool from systemd-* to redo this.
True, the usecases overlap somewhat, but they're still different.
I wouldn't want
Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg
* Package name: bytecode-compatibility-transformer
Version : 1.5
Upstream Author : Kohsuke Kawaguchi
* URL :
https://github.com/jenkinsci/bytecode-compatibility-transformer
* License : MIT
Programming La
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
* Package name: libxml-structured-perl
Version : 1.0-1
Upstream Author : Michael Schroeder
* URL : https://metacpan.org/release/XML-Structured
* License : Artistic or GPL-1+
Programming Lang: Perl
Descri
Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen
* Package name: slapi-nis
Version : 0.53
Upstream Author : Red Hat, Inc
* URL : https://fedorahosted.org/slapi-nis/
* License : GPL-2
Programming Lang: C
Description : NIS Server and Schema Compatibi
Matthias Urlichs, le Thu 25 Sep 2014 21:17:58 +0200, a écrit :
> Samuel Thibault:
> > Sounds crazy to me.
> >
> Definitely. This is now out in the wild; exploits which simply replace
> echo or cat-without-/bin are going to happen. :-/
That's not so easy to exploit. You have to manage to inject th
Package: wnpp
Severity: wishlist
Owner: Johan Van de Wauw
* Package name: owslib
Version : 0.8.9
Upstream Author : Several authors
* URL : https://pypi.python.org/pypi/OWSLib
* License : BSD-like
Programming Lang: Python
Description : Client library fo
On Thu, 25 Sep 2014, Neil Williams wrote:
> Use the bug title as the subject when replying to a message using the
> reply link and when replying to the bug report directly from the bug
> number link at the top of the page.
>
> That avoids problems with the package being a pseudo-package were the
>
On 13710 March 1977, Christoph Anton Mitterer wrote:
>> I'm not sure going below a dinstall cycle is useful. Probably even two.
>> Have it expire before the new stuff even got a chance to get out is not
>> a good idea, IMO.
> Are there any numbers how long it actually takes for the stuff to get
> d
Package: wnpp
Severity: wishlist
Owner: Alessio Treglia
* Package name: masscan
Version : 1.0.3-80-g69cf75a
Upstream Author : Robert David Graham
* URL : https://github.com/robertdavidgraham/masscan
* License : AGPL-3
Programming Lang: C
Description :
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.)
On Thu, 2014-09-25 at 19:07 +0200, Guido Günther wrote:
> On Wed, Sep 24, 2014 at 12:53:51PM +0100, Simon McVittie wrote:
> > My understanding is that they recommend NetworkManager or ConnMan (which
> > are competitors, and fill a similar niche) for dynamic / mobile /
> > wireless situations; where
Hi,
Samuel Thibault:
> Sounds crazy to me.
>
Definitely. This is now out in the wild; exploits which simply replace
echo or cat-without-/bin are going to happen. :-/
Maybe we should add the patched version, with an appropriate NEWS entry,
to backports?
--
-- Matthias Urlichs
signature.asc
De
On Thu, 25 Sep 2014 10:30:09 -0700
Don Armstrong wrote:
> On Wed, 24 Sep 2014, Neil Williams wrote:
> > Please always include the package name / topic in the subject of the
> > email or, as a matter of last resort, in the first few lines of the
> > content of the message.
>
> This requires a lot
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.)
On Wed, 24 Sep 2014, Neil Williams wrote:
> Please always include the package name / topic in the subject of the
> email or, as a matter of last resort, in the first few lines of the
> content of the message.
This requires a lot of work on the part of the sender.
Currently, the package is already
On Wed, Sep 24, 2014 at 12:53:51PM +0100, Simon McVittie wrote:
> My understanding is that they recommend NetworkManager or ConnMan (which
> are competitors, and fill a similar niche) for dynamic / mobile /
> wireless situations; whereas systemd-networkd is intended to be more
> like a competitor f
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: murano-agent
Version : 2014.2~b3
Upstream Author : openstack Development Mailing List
* URL : https://github.com/stackforge/murano-agent
* License : Apache-2.0
Programming Lang: Python
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-semver
Version : 2.0.1
Upstream Author : Alexander Shorin
* URL : https://github.com/k-bx/python-semver/
* License : BSD-3-clauses
Programming Lang: Python
Description : sema
Ian Jackson, le Thu 25 Sep 2014 16:29:05 +0100, 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.)
Yes.
Re: Adam D. Barratt 2014-09-25
<3653b875c93fd474b8b354b4c76f4...@mail.adsl.funky-badger.org>
> On 2014-09-25 8:16, Daniel Pocock wrote:
> >Or should my next upload
> >to unstable by 2.2.5-8? Or do I just ignore the version numbers I
> >uploaded to experimental and use 2.2.5-6 as the next version
On Mon, 2014-09-15 at 00:04 +0200, Stefan Lippers-Hollmann wrote:
> Please consider that too short intervals (24h might still work, but
> it's hard on the limit) make non-primary (cron based) mirrors basically
> impossible. Including local mirrors used for systems that can't connect
> to the int
Package: bash
Version: 4.1-3
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.)
Packages (i386) for squeeze, wheezy and
Hey Joerg.
On Sun, 2014-09-14 at 21:52 +0200, Joerg Jaspert wrote:
> Technically we could go down to 1 second, validtime is expressed in
> seconds in our setup.
;-)
> > My proposal would be something like that:
> > unstable/testing: 4-12 hours
> > [wheezy|squeeze]/updates at security.d.o: 1-6 h
On 09/25/2014 06:02 PM, Wouter Verhelst wrote:
> Because you can't know what your users *actually* use? Let's say someone
> wants to use openstack on a bunch of ARM devices or some such, and they
> *don't* have two gigs of RAM?
I'd be curious what kind of workload you'd be running on this kind of
On 25/09/14 13:21, Henrique de Moraes Holschuh wrote:
> On Thu, 25 Sep 2014, Simon McVittie wrote:
>> Approach 1, which is (IMO) better when the changes you are making in
>> experimental are truly experimental, like enabling features or patches
>> whose medium-term future you're not sure about:
>>
On Wed, 24 Sep 2014, Jakub Wilk wrote:
> > You can easily do this by downloading an email from the bug thread and
> > replying to that.
>
> Luckily, if you do that, there's a great chance that you'll get both a helpful
> Subject and References. :-)
Except if it’s the first mail in the thread, th
On Thu, 25 Sep 2014, Ritesh Raj Sarraf wrote:
> I think I did the same with some settings in pbuilder.
I see nothing there that actually generates a Packages file.
> ## For details, see: http://wiki.debian.org/PbuilderTricks
This also indicates you need a “D” hook script to do that.
I just wrot
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: murano
Version : 2014.2~b3
Upstream Author : OpenStack Development Mailing List
* URL : https://github.com/stackforge/murano
* License : Apache-2.0
Programming Lang: Python
Description
On Thu, 25 Sep 2014, Simon McVittie wrote:
> Approach 1, which is (IMO) better when the changes you are making in
> experimental are truly experimental, like enabling features or patches
> whose medium-term future you're not sure about:
>
> 2.2.5-5+exp1, ... or -6~exp1, ... or whatever to experime
On Wednesday 24 September 2014 06:24 PM, Thorsten Glaser wrote:
I’ve just written a hookscript for pbuilder which makes the
locally cached files available during a package build. Just
chmod +x it, drop it into the --hookdir, and you’re set¹².
Usage scenario here is mostly debian-ports: when buil
On Thu, 25 Sep 2014, Riku Voipio wrote:
> On Wed, Sep 24, 2014 at 03:18:02PM -0300, Henrique de Moraes Holschuh wrote:
> > OTOH, using -z9 on datasets smaller than the -z8 dictionary size *is* a
> > waste of memory (I don't know about cpu time, and xz(1) doesn't say anything
> > on that matter). T
Hi Henrique,
On Wed, Sep 24, 2014 at 03:18:02PM -0300, Henrique de Moraes Holschuh wrote:
> OTOH, using -z9 on datasets smaller than the -z8 dictionary size *is* a
> waste of memory (I don't know about cpu time, and xz(1) doesn't say anything
> on that matter). The same goes for -z8 and datasets
On 25/09/14 08:16, Daniel Pocock wrote:
>
> Is there any convention for version numbers in experimental?
>
> E.g. when uploading to backports, we add a suffix like "A.B.C~bpo70+1"
> so that the system can cleanly upgrade to version A.B.C when upgrading
> to the next stable release.
>
> I have a
On Thu, 25 Sep 2014 11:15:46 +0200
Daniel Pocock wrote:
> If I upload 2.2.5-8 to unstable, should it include the changelog
> entries for experimental too or that doesn't matter either way?
Depends if 2.2.5-8 includes all the changes made in experimental or
whether experimental was just for an ex
On Thu, Sep 25, 2014 at 03:09:16PM +0800, Thomas Goirand wrote:
> On 09/25/2014 02:18 AM, Henrique de Moraes Holschuh wrote:
> > On Thu, 25 Sep 2014, Thomas Goirand wrote:
> >> On 09/02/2014 09:39 PM, Henrique de Moraes Holschuh wrote:
> >>> For -z9, it is as bad as ~670MiB to
> >>> compress, and ~
Package: wnpp
Severity: wishlist
Owner: Ansgar Burchardt
* Package name: dune-alugrid
Version : 2.3
Upstream Author : Bernhard Schupp
Mario Ohlberger
Robert Kloefkorn
Andreas Dedner
Martin Nolte
* URL
On Thu, Sep 25, 2014 at 09:16:46AM +0200, Daniel Pocock wrote:
> Is there any convention for version numbers in experimental?
No such convention exists TTBOMK.
[...]
> I uploaded 2.2.5-6 and 2.2.5-7 to experimental. Should I have given
> them versions like 2.2.5-6~exp1 or something and then uplo
Le Thu, Sep 25, 2014 at 11:15:46AM +0200, Daniel Pocock a écrit :
> On 25/09/14 10:00, Neil Williams wrote:
> > On Thu, 25 Sep 2014 09:42:42 +0200
> > Jonas Smedegaard wrote:
> >
> >> Quoting Daniel Pocock (2014-09-25 09:16:46)
> >>> I have a package, version 2.2.5-5 in unstable and testing
> >>>
On 25/09/14 10:00, Neil Williams wrote:
> On Thu, 25 Sep 2014 09:42:42 +0200
> Jonas Smedegaard wrote:
>
>> Quoting Daniel Pocock (2014-09-25 09:16:46)
>>> I have a package, version 2.2.5-5 in unstable and testing
>>>
>>> I uploaded 2.2.5-6 and 2.2.5-7 to experimental. Should I have
>>> given the
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-yaql
Version : 0.2.3
Upstream Author : Mirantis, Inc.
* URL : https://github.com/ativelkov/yaql
* License : Apache-2.0
Programming Lang: Python
Description : Yet Another Quer
On Thu, 25 Sep 2014 09:42:42 +0200
Jonas Smedegaard wrote:
> Quoting Daniel Pocock (2014-09-25 09:16:46)
> > I have a package, version 2.2.5-5 in unstable and testing
> >
> > I uploaded 2.2.5-6 and 2.2.5-7 to experimental. Should I have
> > given them versions like 2.2.5-6~exp1 or something and
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-muranoclient
Version : 0.5.5
Upstream Author : OpenStack Development Mailing List
* URL : https://github.com/stackforge/python-muranoclient
* License : Apache-2.0
Programming Lang
Quoting Daniel Pocock (2014-09-25 09:16:46)
>
> Is there any convention for version numbers in experimental?
There are multiple conventions.
> E.g. when uploading to backports, we add a suffix like "A.B.C~bpo70+1"
> so that the system can cleanly upgrade to version A.B.C when upgrading
> to th
On 2014-09-25 8:16, Daniel Pocock wrote:
Or should my next upload
to unstable by 2.2.5-8? Or do I just ignore the version numbers I
uploaded to experimental and use 2.2.5-6 as the next version number for
an unstable upload, even if it doesn't contain the same things as
2.2.5-6 in experimental?
On Thu, 25 Sep 2014 09:16:46 +0200
Daniel Pocock wrote:
>
> Is there any convention for version numbers in experimental?
>
> E.g. when uploading to backports, we add a suffix like "A.B.C~bpo70+1"
> so that the system can cleanly upgrade to version A.B.C when upgrading
> to the next stable relea
Is there any convention for version numbers in experimental?
E.g. when uploading to backports, we add a suffix like "A.B.C~bpo70+1"
so that the system can cleanly upgrade to version A.B.C when upgrading
to the next stable release.
I have a package, version 2.2.5-5 in unstable and testing
I uplo
On 09/25/2014 02:18 AM, Henrique de Moraes Holschuh wrote:
> On Thu, 25 Sep 2014, Thomas Goirand wrote:
>> On 09/02/2014 09:39 PM, Henrique de Moraes Holschuh wrote:
>>> For -z9, it is as bad as ~670MiB to
>>> compress, and ~65MiB to decompress.
>>
>> I'd say this really depends on what you do. For
72 matches
Mail list logo
