Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Thomas Goirand]

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 what I do (eg: OpenStack
>> packages), I don't see how 65MB could be a problem. I do compress with
>> -z9, and have no intention to change this, because it makes sense for
>> these packages, where the bottleneck for large deployments will more be
>> the network transfers than uncompressing on each individual nodes.
> 
> OTOH, using -z9 on datasets smaller than the -z8 dictionary size *is* a
> waste of memory

Exactly why should I care when there's all the chances in the world that
my users will have plenty of RAM?

These days, in a cloud deployment, a server with 64 GB of RAM is small,
and can be considered from the old generation (such amount of RAM cost
about 300 EUR w/o tax). 256 GB is quite common. And we're talking about
a few dozens of MB for decompressing. There's an 1k order of magnitude
difference here at least. So: I don't care what you call "a lot" of RAM:
for my application, that's not a lot, that's negligible.

Thomas


-- 
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/5423bf9c.40...@debian.org

versions / suffixes in experimental

[Daniel Pocock]

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 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 upload a proper
2.2.5-6 to unstable when I am happy with it?  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?





-- 
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/5423c15e.1090...@pocock.pro

Re: versions / suffixes in experimental

[Neil Williams]

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 release.
> 
> 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 then upload a proper
> 2.2.5-6 to unstable when I am happy with it?  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?

2.2.5-8 would seem typical practice.

2.2.5-6 will not work for a new upload to unstable - it already exists in the 
archive.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: versions / suffixes in experimental

[Adam D. Barratt]

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?


No. Under no circumstances should version numbers be reused. (There's 
some disagreement about cases such as reintroducing old packages that 
aren't even in oldstable any more, but a contemporaneous upload to 
multiple suites using the same version number is absolutely wrong.)


Regards,

Adam


--
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/3653b875c93fd474b8b354b4c76f4...@mail.adsl.funky-badger.org

Re: versions / suffixes in experimental

[Jonas Smedegaard]

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 the next stable release.
>
> 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 then upload a proper 
> 2.2.5-6 to unstable when I am happy with it?  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?

Both approaches makes sense to me - depending on your reason for using 
experimental in the first place - and on your mood.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#762787: ITP: python-muranoclient -- cloud-ready application catalog - Python client

[Thomas Goirand]

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: Python
  Description : cloud-ready application catalog - Python client

 Murano Project introduces an application catalog, which allows application
 developers and cloud administrators to publish various cloud-ready
 applications in a browsable categorised catalog, which may be used by the
 cloud users (including the inexperienced ones) to pick-up the needed
 applications and services and composes the reliable environments out of them
 in a "push-the-button" manner.
 .
 This is a client for Murano. There's a Python API (the "muranoclient"
 module), and a command-line script ("murano").


-- 
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/20140925075621.24566.98811.report...@buzig.gplhost.com

Re: versions / suffixes in experimental

[Neil Williams]

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 then upload
> > a proper 2.2.5-6 to unstable when I am happy with it?  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?
> 
> Both approaches makes sense to me - depending on your reason for
> using experimental in the first place - and on your mood.

Any approach which tries to use the same version in multiple suites at
the same time does not make sense to the archive. The mood of the
maintainer is rightly ignored by dak.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Bug#762792: ITP: python-yaql -- Yet Another Query Language

[Thomas Goirand]

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 Query Language

 At the beginning of millennium the growing trend towards data formats
 standardization and application integrability made XML extremely popular. XML
 became lingua franca of the data. Applications tended to process lots of XML
 files ranging from small config files to very large datasets. As these data
 often had a complex structure with many levels of nestedness it is quickly
 became obvious that there is a need for specially crafted domain specific
 languages to query these data sets. This is how XPath and later XQL were born.
 .
 With later popularization of REST services and Web 2.0 JSON started to take
 XML’s place. JSON’s main advantage (besides being simpler than XML) is that is
 closely reassembles data structures found in most programming languages
 (arrays, dictionaries, scalars) making it very convenient for data
 serialization. As JSON lacked all the brilliant XML-related technologies like
 XSLT, XML Schema, XPath etc. various attempts to develop similar languages for
 JSON were made. One of those efforts was JSONPath library developed in 2007 by
 Stefan Gössner. Initial implementation was for PHP and JavaScript languages,
 but later on ports to other languages including Python were written. YAQL is
 one of the implementations in Python.


-- 
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/20140925082434.27780.30871.report...@buzig.gplhost.com

Re: versions / suffixes in experimental

[Daniel Pocock]

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 them versions like 2.2.5-6~exp1 or something and then upload
>>> a proper 2.2.5-6 to unstable when I am happy with it?  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?
>> Both approaches makes sense to me - depending on your reason for
>> using experimental in the first place - and on your mood.
> Any approach which tries to use the same version in multiple suites at
> the same time does not make sense to the archive. The mood of the
> maintainer is rightly ignored by dak.
>

Personally, I think the suffix would be useful for cases where the
upload to experimental and unstable are both otherwise identical

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?



-- 
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/5423dd42.6060...@pocock.pro

Re: versions / suffixes in experimental

[Charles Plessy]

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
> >>>
> >>> 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 upload
> >>> a proper 2.2.5-6 to unstable when I am happy with it?  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?
> >> Both approaches makes sense to me - depending on your reason for
> >> using experimental in the first place - and on your mood.
> > Any approach which tries to use the same version in multiple suites at
> > the same time does not make sense to the archive. The mood of the
> > maintainer is rightly ignored by dak.
> >
> 
> Personally, I think the suffix would be useful for cases where the
> upload to experimental and unstable are both otherwise identical
> 
> 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?

Hi Daniel,

Recently, I have have used Experimental as dead-end branches, for instance:

 - foo_1.2-3 uploaded to Unstable.

 - foo_1.2-4~experimental1 uploaded to Experimental

 - foo_1.2-4 uploaded to Unstable with the changelog entry from
   version 1.2-4~experimental1 merged in the entry for version 1.2-4.

I think that this is nicer than having a changelog entry for Unstable pointing
at the changelog entry from the upload to Experimental: think for instance to
the links to the change files in the package tracker.

Have a nice day,

-- 
Charles


-- 
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/20140925092716.ga11...@falafel.plessy.net

Re: versions / suffixes in experimental

[Wouter Verhelst]

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 upload a proper
> 2.2.5-6 to unstable when I am happy with it?  Or should my next upload
> to unstable by 2.2.5-8?

Both are okay.

> 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?

As others have pointed out, dak will refuse this.

This is only natural, if you think about it; when you upload something
to experimental and later upload it to unstable but with a version
number that sorts before the experimental version number, people who've
used the experimental version will be "stuck" with the version they
have, which is wrong any way you look at it.

In theory, it *should* be okay to migrate packages from experimental to
unstable without re-uploading them in the same manner that packages are
migrated from unstable to testing without re-upload. I don't know if dak
supports this mode of operation, however.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
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/20140925094824.gb7...@grep.be

Bug#762801: ITP: dune-alugrid -- toolbox for solving PDEs -- unstructured simplicial and cube grids

[Ansgar Burchardt]

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 : http://users.dune-project.org/projects/dune-alugrid
* License : GPL-2+
  Programming Lang: C++
  Description : toolbox for solving PDEs -- unstructured simplicial and 
cube grids

 DUNE, the Distributed and Unified Numerics Environment is a modular toolbox
 for solving partial differential equations (PDEs) with grid-based methods.
 It supports the easy implementation of methods like Finite Elements (FE),
 Finite Volumes (FV), and also Finite Differences (FD).
 .
 DUNE-ALUGrid is a grid manager providing unstructured simplicial and
 cube grids.

The package will be maintained in the Debian Science Team.

Ansgar


-- 
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/20140925095029.15221.31976.report...@snout.igpm.rwth-aachen.de

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Wouter Verhelst]

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 ~65MiB to decompress.
> >>
> >> I'd say this really depends on what you do. For what I do (eg: OpenStack
> >> packages), I don't see how 65MB could be a problem. I do compress with
> >> -z9, and have no intention to change this, because it makes sense for
> >> these packages, where the bottleneck for large deployments will more be
> >> the network transfers than uncompressing on each individual nodes.
> > 
> > OTOH, using -z9 on datasets smaller than the -z8 dictionary size *is* a
> > waste of memory
> 
> Exactly why should I care when there's all the chances in the world that
> my users will have plenty of RAM?

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?

What about the buildd machines that your packages are being built on?

670M is a lot of memory, especially if you don't need it. The "memory is
cheap nowadays" argument is a fallacy, because that'll always be true
(RAM has been getting cheaper since the 1940s, essentially; that doesn't
mean you should just waste it for no particularly good reason other than
"I'm lazy")

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
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/20140925100221.gc7...@grep.be

Re: versions / suffixes in experimental

[Neil Williams]

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 experiment which itself led to a
dead-end. If the changes are included, the changes need to be described
in the changelog.

Every change made to a package goes into the changelog.
Changes not included in the package don't go into the changelog.

/me not sure why this needs to be said.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: versions / suffixes in experimental

[Simon McVittie]

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 package, version 2.2.5-5 in unstable and testing

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 unstable

Approach 2, which is (IMO) better when the changes you are making in
experimental are the main line of development, and you're only not
uploading to unstable because you're trying to avoid a freeze or getting
tangled into a transition or something:

2.2.5-6, -7, ... to experimental
2.2.5-5+deb8u1 to unstable (if needed)

(i.e. in approach 2 you're treating the unstable branch as
stable-updates to a stable release that doesn't exist yet).

Either can work. I've done both in the past.

If the upstream versions in unstable and experimental are different (as
in, for instance, GNOME a couple of weeks ago, with 3.12.x in unstable
and 3.13.x in experimental), then you don't need a special suffix either
way because the upstream versions are sufficient.

S


-- 
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/5423ebf0.2040...@debian.org

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Riku Voipio]

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 smaller than -z7
> dictionary size, and so on.
 
> It is rather annoying that xz is not smart enough to detect this and
> downgrade the -z level when it is given a seekable file (which it can stat()
> and know the full size of beforehand).

This wouldn't seem too hard to implement in xz - have you asked upstream
about it?

Riku


-- 
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/20140925095914.ga4...@afflict.kos.to

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Henrique de Moraes Holschuh]

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).  The same goes for -z8 and datasets smaller than -z7
> > dictionary size, and so on.
>  
> > It is rather annoying that xz is not smart enough to detect this and
> > downgrade the -z level when it is given a seekable file (which it can stat()
> > and know the full size of beforehand).
> 
> This wouldn't seem too hard to implement in xz - have you asked upstream
> about it?

No, I haven't.  Feel free to do it!

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20140925102838.ga10...@khazad-dum.debian.net

Re: new cowbuilder tool: make local package cache available

[Ritesh Raj Sarraf]

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 building
packages that depend on each other, you no longer have to
wait until the first package is Installed until you can
build the second package³. It also makes older packages,
e.g. arch:all ones, available so that you can, with some
APT pinning⁴, build packages against others that have
temporarily become uninstallable in unstable, e.g. to
break build dependency cycles.


Hi Thorsten:

I think I did the same with some settings in pbuilder.

## IF you do not bind mount, precious tmpfs space is wasted, and you 
will very soon

## run out of it when building a big package like Bespin/IceDove/KDE
#APTCACHE="/var/cache/apt/archives/"   ### We set this to off because we 
are already bind-mounting it.
## Aslo settings cachelink to no becasue we are bind mounting it, thus 
no need to create a link

APTCACHE=""
BINDMOUNTS="/var/cache/apt/archives/"
APTCACHEHARDLINK=no

AUTOCLEANAPTCACHE=no
EXTRAPACKAGES="eatmydata apt-utils debdelta"


## Use these when you have a package build-dep that is not yet pushed 
into archive.

## For details, see: http://wiki.debian.org/PbuilderTricks
#OTHERMIRROR="deb file:///var/tmp/Debian-Build/pbuilder-deps ./"
#BINDMOUNTS="$BINDMOUNTS /var/tmp/Debian-Build/pbuilder-deps"
# Comment HOOKDIR when you are at home with very slow internet 
connection because

# it runs apt-get update on each pbuilder build invocation
#HOOKDIR="/home/rrs/.pbuilder/hooks"
#ALLOWUNTRUSTED=yes


--
Given the large number of mailing lists I follow, I request you to CC me
in replies for quicker response


--
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/0f4dfb-5t2@news.researchut.com

Re: versions / suffixes in experimental

[Henrique de Moraes Holschuh]

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 experimental
> 2.2.5-6 to unstable

Keep in mind the BTS version tracking requirements, which translate into
requirements for which past package changelog entries must be included in
debian/changelog as well.

When there is a continuity in the bug-tracking sense between 2.2.5-5~exp1
and 2.2.5-6~exp1, regardless of what your workflow is, 2.2.5-6~exp1's
debian/changelog must include a merge of 2.2.5-5~exp1's debian/changelog and
2.2.5-6's debian/changelog.

Otherwise, as soon as 2.2.5-6~exp1 gets installed in experimental, the BTS
will think any bugs against 2.2.5-5~exp1 are on a different branch, and will
not consider these closed by the 2.2.5-6~exp1 upload.

It is also important to use the correct -vVERSION flag in dpkg-genchanges,
to make sure the correct debian/changelog entries will go in the .changes
file for the upload.  This is well explained in the debian-backports
guidelines, but it applies to uploads to *any* suite (experimental,
stable-proposed-updates, stable-security, backports, etc).

For example: in the experimental upload above, you'd need to call
dpkg-buildpackage -v2.2.5-5~exp1  (or pbuilder --debbuildopts
"-v2.2.5-5~exp1", etc) when preparing the 2.2.5-6~exp1 upload, which will
get passed down to dpkg-genchanges by debhelper.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20140925122100.gc10...@khazad-dum.debian.net

Bug#762822: ITP: murano -- cloud-ready application catalog

[Thomas Goirand]

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 : cloud-ready application catalog

 Murano Project introduces an application catalog, which allows application
 developers and cloud administrators to publish various cloud-ready
 applications in a browsable categorised catalog, which may be used by the
 cloud users (including the inexperienced ones) to pick-up the needed
 applications and services and composes the reliable environments out of them
 in a "push-the-button" manner.


-- 
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/2014092516.12275.5459.report...@buzig.gplhost.com

Re: new cowbuilder tool: make local package cache available

[Thorsten Glaser]

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 wrote one, which requires less local configuration,
and avoids pulling the local packages into builds that do
not need them by adding the sources.list line late.

But sure, use either. I just felt like sharing.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"


--
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.1409251518130.21...@tglase.lan.tarent.de

Re: Request when replying to bugs: include the package name / topic.

[Thorsten Glaser]

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, then you will get
either a new bugreport or an error.

I really wish reportbug would not send the initial mail to me
either but leave that to the BTS which would, of course, need
to be patched to send it out then. That way, the submitter
also would immediately have an eMail they could reply to,
instead of things ending up at submit@b.d.o – which is also
true for the people you enter when you’re asked for Cc, as
opposed as adding them later with ‘s’.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general


--
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.1409251521350.21...@tglase.lan.tarent.de

Re: versions / suffixes in experimental

[Simon McVittie]

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:
>>
>> 2.2.5-5+exp1, ... or -6~exp1, ... or whatever to experimental
>> 2.2.5-6 to unstable
> 
> When there is a continuity in the bug-tracking sense between 2.2.5-5~exp1
> and 2.2.5-6~exp1, regardless of what your workflow is, 2.2.5-6~exp1's
> debian/changelog must include a merge of 2.2.5-5~exp1's debian/changelog and
> 2.2.5-6's debian/changelog.

AIUI the general rule is that you must merge debian/changelog if and
only if you merged the actual changes?

In other words, if version A is an ancestor of version B (think about
what the graph of branches and merges would look like in gitk or
whatever), then version B must have version A's debian/changelog entry
somewhere below its own.

S


-- 
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/54241f7a@debian.org

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Thomas Goirand]

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
RAM footprint.

> What about the buildd machines that your packages are being built on?

Most of my packages are arch independent (eg: Python), so not affected
(for the moment).

Also, only OpenStack specific packages are compressed with -z9, other
Python modules which may be used for generic purpose have the -z9 option
only enabled on *my* computer when I build: the debian/rules has an
optional include (prefixed with a minus sign) that fixes the option, and
in the buildd servers, the file wont be there, so the option wont be
activated. I think it's the best trade-off.

> 670M is a lot of memory, especially if you don't need it.

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!!!

> The "memory is
> cheap nowadays" argument is a fallacy, because that'll always be true
> (RAM has been getting cheaper since the 1940s, essentially; that doesn't
> mean you should just waste it for no particularly good reason other than
> "I'm lazy")

The "I'm lazy" isn't the reason. Getting the result which I consider
"the best" is.

Thomas Goirand (zigo)


-- 
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/54242557.7020...@debian.org

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Christoph Anton Mitterer]

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 hours
> 
> 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
distributed?

But apart from that, even if it take a while for the actual package
files to distribute through all the mirrors, once that is done, only the
re-signed meta-data files would need to be distributed, which should be
quite fast.
So if copying is done smart, I'd guess this could be made to work.


Anyway, even if there are technical issues, don't you think that it
sounds kinda stupid, if all the distros and security guys try to
orchestrate the publication of important issues (like the apt or bash
stuff we've seen these days), so that basically fixed packages could be
available for all distros at nearly the same time, while we still leave
our users basically vulnerable by having far too long validity times.


> Also, going down to such small intervals means we MUST resign, even if
> there is no update at all in the archive (so an extra cronjob, just to
> be sure).
Sure, I mean that's the whole point of constantly and frequently
assuring that the package meta-data (including it's information about
security things) is current... doing these resigns often is basically
what prevents downgrade/blocking attacks.

> That's no problem in the main archive, there is always enough
> going on, but security can go way longer without an update (which is why
> such a (weekly) cronjob exists on security).
So does this mean that it *would* be a problem for e.g. non-main
archives?


> That is technically not a big problem. Unless you happen to look at
> services like snapshot, which run an import on every trigger. No idea
> how much it hurts them if only the Release files change, need to find out.
Well I think snapshot is it's own construction site, isn't it?
IIRC, snapshot ships the old Release files, and thus everything older
than a few weeks is anyway considered invalid, right?
And doesn't it also use the old GPG keys?

IMHO that makes it a bit difficult to use snapshot.d.o. I think it would
be better if there was a special GPG key for snapshot.d.o.
As for the Release files and their validity, one could go probably two
ways:
- constantly resign them (or give them basically infinite validity),
thereby making it easy to use it (i.e. no warnings from APT), assuming
that it is clear to everyone who uses snapshot.d.o that these packages
are not current and probably full of security issues.
- leaving it as is, i.e. keep the original expiration times in the
Release files and people must manually tell their APT/aptitude/etc. to
ignore this.




Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

bash without importing shell functions from the environment

[Ian Jackson]

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 sid are here:
  http://www.chiark.greenend.org.uk/~ian/bash-noshellfunctions/

dgit format git branches are here:
  git://git.chiark.greenend.org.uk/~ianmdlvl/bash.git
  http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git/bash.git/

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.

(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.

[1] http://codesearch.debian.net/search?q=export\+-f


-- 
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/21540.13505.438186.122...@chiark.greenend.org.uk

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Christoph Anton Mitterer]

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 internet directly or potentially even setups used for (personal)
> archive-wide rebuilds or debian-cd related tasks. Intervals below an
> hour, besides probably even invalidating most primary mirrors, are 
> likely to render apt-get update to expire before it has finished
> downloading the meta data for all repos on slower internet connections.
Well as I've said in my post before: such slow systems should just need
to resync the (re-signed) metadata files at a more current point.

But of course you're right, extremely slow mirrors and/or pull models
are likely to cause troubles (or break), but their working model is
simply broken, at least with respect to security.


> Decreasing these validity cycles too much would force many of these 
> uses to ignore expiry times alltogether - or having to re-sign a local 
> archive mirror with longer periods (which is not exactly a reasonable 
> task for most users or anything that involves debootstrapping). I guess
> most uses would opt to go with the first option instead, which won't 
> help anyone...
Well, users can always take a gun and shoot themselves. No reason to
expose *all* users to security issues, if there is (small?) fraction of
users who would just completely deactivate secure APT, if it means too
much effort for them.

I mean that's basically always the problem with security, isn't it? You
don't get it for free, which is why we have crap like the Internet's
X.509 certificate hierarchy that basically fails and breaks and all
points. If a really strong (i.e. meshed) system would have been used,
many end-users would have refused to use it altogether, wich is why we
have a system now, that is basically useless for all.


> Personally I think 24 hours (better something like 26-28 hours to allow
> some overlap for secondary/ tertiary/ local mirrors only updated daily)
> would be the technical limit that might be possible, but anything 
> shorter than a week (or at very least three days) would already 
> significantly impact many valid use cases where local mirroring and/or 
> a fixed archive state is required.
Don't you think it would be possible for mirrors, to have faster resync
of just the meta-datafiles? I mean these are really small, and actually
it should be only necessary to frequently resync the [In]Release* files,
if everything else stayed the same, only they will have changed for the
new validity times.


> While there might be an argument to decrease the expiry times for 
> security.d.o, perhaps even down to a day or at least half a day[1], the
> negative net impact for all normal archives (especially testing and
> unstable) would imho far outweigh any potential security improvements.
Why?
I guess many people use e.g. sid as their main system, so all of them
will get their security upgrades via that and not via security.d.o.
So they would be still left vulnerable downgrade attacks in case of such
things like the bash/apt holes from these days, even though Debian might
have perfectly reacted and already supplies fixed packages.


> Just look at the common advice given for expired signatures on 
> snapshots.d.o, most suggest to use a global 
> 
>   apt-get -o Acquire::Check-Valid-Until=false update
> or
>   Acquire::Check-Valid-Until "0";
> 
> for apt.
Well sure, but snapshots.d.o is a completely different story, isn't it?
Everyone using it, should be aware that these are old archived packages,
and that it's not so unlikely that they contain security issues.
In other words, there is no implicit guarantee in any way that
snapshot.d.o gives you secure stuff - therefore we don't need to defend
against things like blocking/downgrade attacks.


> For these reasons I would suggest against changing the current 
> intervals, especially least not into the hour- or single day regions.
Well I think the current intervals (what were they? 1 month?) are *far*
too long.
If there should be really insolvable technical issues (and I guess most
of them might be solved by quickly resyncing the [In]Release* files,
which should be trivial)... than one day is probably the interval I'd go
for.



Cheers,
Chris. 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: versions / suffixes in experimental

[Christoph Berg]

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 number for
> >an unstable upload, even if it doesn't contain the same things as
> >2.2.5-6 in experimental?
> 
> No. Under no circumstances should version numbers be reused. (There's some
> disagreement about cases such as reintroducing old packages that aren't even
> in oldstable any more, but a contemporaneous upload to multiple suites using
> the same version number is absolutely wrong.)

We recently reintroduced cl-interpol 0.2.1-1 to sid, after the package
was removed in 2009. There were still around half a dozen
installations reported on popcon, but the worse part is that this made
the UDD changes importer explode with a unique key violation. I think
they fixed it by deleting this upload from UDD, and we quickly
uploaded -2 to get the package also upgraded on the old systems out
there, but the bottom line should be "don't do that".

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: Bug#762839: bash without importing shell functions from the environment

[Samuel Thibault]

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.

€ cat test.sh
#!/bin/bash
echo foo

€ export echo='() { /bin/echo bar; }'

€ ./test.sh 
bar

Sounds crazy to me.

Samuel


-- 
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/20140925162026.ga11...@type.bordeaux.inria.fr

Bug#762848: ITP: python-semver -- semantic versioning

[Thomas Goirand]

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 : semantic versioning

 This Python module helps to compare versions as noted at http://semver.org/.
 The system is like this: given a version number MAJOR.MINOR.PATCH, increment
 the:
  * MAJOR version when you make incompatible API changes,
  * MINOR version when you add functionality in a backwards-compatible
manner,
  * PATCH version when you make backwards-compatible bug fixes.
 .
 Additional labels for pre-release and build metadata are available as
 extensions to the MAJOR.MINOR.PATCH format.


-- 
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/20140925163707.23491.6854.report...@buzig.gplhost.com

Bug#762851: ITP: murano-agent -- cloud-ready application catalog - VM agent

[Thomas Goirand]

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
  Description : cloud-ready application catalog - VM agent

 Murano Project introduces an application catalog, which allows application
 developers and cloud administrators to publish various cloud-ready
 applications in a browsable categorised catalog, which may be used by the
 cloud users (including the inexperienced ones) to pick-up the needed
 applications and services and composes the reliable environments out of them
 in a "push-the-button" manner.
 .
 This package contains the Murano Agent, which is a VM-side guest agent that
 accepts commands from Murano Conductor and executes them.


-- 
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/20140925165403.26445.30916.report...@buzig.gplhost.com

Re: Seeking help with OpenVPN scripts and systemd

[Guido Günther]

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 for ifupdown or equivalent, in simpler or more static
> situations like "my server has two network cards with static IP
> addresses" or "my NAS has one Ethernet socket which gets its address via
> dhcp".

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. I'm a big fan of
many of systemd's features and interfaces but bundling everything
into one systemd repo/package is going to hit us hard sooner or later
if we can't standarize on a set of (e.g. DBus) interfaces.
Cheers,
 -- Guido


-- 
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/20140925170754.ga2...@bogon.m.sigxcpu.org

Re: Request when replying to bugs: include the package name / topic.

[Don Armstrong]

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 included in X-Debbugs-PR-Package:
header, and I don't have a problem adding X-Debbugs-PR-Subject: which
recapitulates the subject if that would help, either.
 
I don't want to munge subjects, though. The only reason why the bug
number is currently put on the subject is because the BTS uses it to
figure out what bug you replied to if you send a mail to
sub...@bugs.debian.org.

-- 
Don Armstrong  http://www.donarmstrong.com

I leave the show floor, but not before a pack of caffeinated Jolt gum
is thrust at me by a hyperactive girl screaming, "Chew more! Do more!"
The American will to consume more and produce more personified in a
stick of gum. I grab it.
 -- Chad Dickerson


-- 
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/20140925173009.gi8...@teltox.donarmstrong.com

Re: bash without importing shell functions from the environment

[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

Re: Request when replying to bugs: include the package name / topic.

[Neil Williams]

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 of work on the part of the sender.

I disagree it's a "lot" of work - it's some work, yes.
 
> Currently, the package is already included in X-Debbugs-PR-Package:
> header, and I don't have a problem adding X-Debbugs-PR-Subject: which
> recapitulates the subject if that would help, either.
>  
> I don't want to munge subjects, though. The only reason why the bug
> number is currently put on the subject is because the BTS uses it to
> figure out what bug you replied to if you send a mail to
> sub...@bugs.debian.org.

What about the later suggestion?

::

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
name of the pseudo-package is the same as the name of the mailing list
(like release.debian.org).

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: Bug#762839: bash without importing shell functions from the environment

[Matthias Urlichs]

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
Description: Digital signature

Re: Seeking help with OpenVPN scripts and systemd

[Svante Signell]

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; whereas systemd-networkd is intended to be more
> > like a competitor for ifupdown or equivalent, in simpler or more static
> > situations like "my server has two network cards with static IP
> > addresses" or "my NAS has one Ethernet socket which gets its address via
> > dhcp".
> 
> 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. I'm a big fan of
> many of systemd's features and interfaces but bundling everything
> into one systemd repo/package is going to hit us hard sooner or later
> if we can't standarize on a set of (e.g. DBus) interfaces.

Maybe there is a rescue out of this situation: uselessd :)
http://uselessd.darknedgy.net/ a fork of systemd with only the basic
features.


-- 
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/1411672586.3189.1.ca...@gmail.com

Re: bash without importing shell functions from the environment

[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

Bug#762866: ITP: masscan -- TCP port scanner

[Alessio Treglia]

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 : TCP port scanner

 MASSCAN is TCP port scanner which transmits SYN packets
 asynchronously and produces results similar to nmap,
 the most famous port scanner. Internally, it operates
 more like scanrand, unicornscan, and ZMap, using
 asynchronous transmission.
 It's a flexible utility that allows arbitrary address and
 port ranges.


-- 
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/20140925194410.9099.11131.reportbug@nemesis

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Joerg Jaspert]

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
> distributed?

Maybe somewhere, dont know.

> Anyway, even if there are technical issues, don't you think that it
> sounds kinda stupid, if all the distros and security guys try to
> orchestrate the publication of important issues (like the apt or bash
> stuff we've seen these days), so that basically fixed packages could be
> available for all distros at nearly the same time, while we still leave
> our users basically vulnerable by having far too long validity times.

It also sounds quite stupid that suddenly all users have no working
mirror anymore, should there be an outage of ftp-master or
security-master longer than the signing time.

Or a release going on, during which we commonly turn off the archive
and ALL cronjobs. Until we are sure that it is all fine again.
No, a full release doesn't go through in less than a dinstalls time.

Even down to two dinstall intervals is short and would require us to add
one more level of complexity to our working.

>> That is technically not a big problem. Unless you happen to look at
>> services like snapshot, which run an import on every trigger. No idea
>> how much it hurts them if only the Release files change, need to find out.
> Well I think snapshot is it's own construction site, isn't it?
> IIRC, snapshot ships the old Release files, and thus everything older
> than a few weeks is anyway considered invalid, right?
> And doesn't it also use the old GPG keys?

I don't care here what snapshot ships. Wrong point to look at. It's
import runs are costly, and it gets ALL of the mirror runs.


-- 
bye, Joerg
 er, *not* what I meant, is what I meant


signature.asc
Description: PGP signature

Re: Request when replying to bugs: include the package name / topic.

[Don Armstrong]

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
> name of the pseudo-package is the same as the name of the mailing list
> (like release.debian.org).

Yes. This is actually an oversight on my part; the reply link on the BTS
should be changed to have this.

I'll try to get to that soonish.

-- 
Don Armstrong  http://www.donarmstrong.com

Those who begin coercive elimination of dissent soon find themselves
exterminating dissenters. Compulsory unification of opinion achieves
only the unanimity of the graveyard.
 -- Justice Roberts in 319 U.S. 624 (1943)


-- 
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/20140925200458.gl8...@teltox.donarmstrong.com

Bug#762869: ITP: owslib -- Client library for Open Geospatial (OGC) web services

[Johan Van de Wauw]

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 for Open Geospatial (OGC) web services
 OWSLib is a Python package for client programming with Open Geospatial
 Consortium (OGC) web service (hence OWS) interface standards, and their
 related content models.
 .
 Full documentation is available at http://geopython.github.io/OWSLib
 .
 OWSLib provides a common API for accessing service metadata and wrappers
 for numerous OGC Web Service interfaces.

This library is a dependency of pycsw, for which I filed an ITP (#762145) one
week ago.
This library was already packaged for the OSGeo live dvd (ubuntu based) by
Angelos Tzotsos. We (Angelos and I) intent to maintain this package in the
Debian-GIS team.


-- 
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/20140925201807.17719.11824.report...@debian-usb.fritz.box

Re: Bug#762839: bash without importing shell functions from the environment

[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 exploit. You have to manage to inject those precise
variable names.

Samuel


-- 
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/20140925203900.gt3...@type.youpi.perso.aquilenet.fr

Bug#762874: ITP: slapi-nis -- NIS Server and Schema Compatibility plugins for 389 Directory Server

[Timo Aaltonen]

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 Compatibility plugins for 389 
Directory Server

This package provides two plugins for Red Hat and 389 Directory Server.

The NIS Server plugin allows the directory server to act as a NIS
server for clients, dynamically generating and updating NIS maps
according to its configuration and the contents of the DIT, and
serving the results to clients using the NIS protocol as if it were
an ordinary NIS server.

The Schema Compatibility plugin allows the directory server to provide
an alternate view of entries stored in part of the DIT, optionally
adding, dropping, or renaming attribute values, and optionally
retrieving values for attributes from multiple entries in the tree.


-- 
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/20140925204000.18636.34150.reportbug@eldon

Bug#762880: ITP: libxml-structured-perl -- XML data into a predefined Perl data structure and back

[Mike Gabriel]

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
  Description : XML data into a predefined Perl data structure and back

 The XML::Structured module provides a way to convert XML data into a
 predefined Perl data structure and back to XML. Unlike with modules like
 XML::Simple it is an error if the XML data does not match the provided
 skeleton (the "dtd"). Another advantage is that the order of the attributes
 and elements is taken from the dtd when converting back to XML.



 This package is a dependency of obs-build / obs-server.


-- 
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/20140925212326.20051.34276.report...@minobo.das-netzwerkteam.de

Bug#762881: ITP: bytecode-compatibility-transformer -- Bytecode manipulation library for managing backward compatibility in Java code

[Emmanuel Bourg]

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 Lang: Java
  Description : Bytecode transformation-based library for managing
backward compatibility

This Java library provides a set of annotations and bytecode transformer
that helps you evolve modular codebase without losing compatibility.

This package is a new dependency of Jenkins and is required to help
fixing #762798.



signature.asc
Description: OpenPGP digital signature

Re: Seeking help with OpenVPN scripts and systemd

[Matthias Urlichs]

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 to install n-m (and the 30 libraries it depends on)
in an initramfs, for instance.

-- 
-- Matthias Urlichs


-- 
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/20140925233226.gb6...@smurf.noris.de

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Paul Wise]

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 install Debian font packages would be
annoying.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
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/caktje6g3ohsj_f0fqftm88avgriyed0avgnhwee-ctvwjop...@mail.gmail.com

Work-needing packages report for Sep 26, 2014

[wnpp]

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 requested help for: 58 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   bluemon (#762537), orphaned 2 days ago
 Description: Activate or deactivate programs based on Bluetooth link
   quality
 Installations reported by Popcon: 258

   id3ren (#762538), orphaned 2 days ago
 Description: id3 tagger and renamer
 Installations reported by Popcon: 788

   imdb-tools (#762539), orphaned 2 days ago
 Description: Lookup film details on IMDB
 Installations reported by Popcon: 90

   libmatthew-java (#762540), orphaned 2 days ago
 Description: Unix socket API and bindings for Java
 Reverse Depends: jitsi libdbus-java zemberek-server
 Installations reported by Popcon: 993

   live-f1 (#762541), orphaned 2 days ago
 Description: Formula 1 live timing
 Installations reported by Popcon: 46

   maelstrom (#762499), orphaned 3 days ago
 Description: An arcade-style game resembling Asteroids.
 Installations reported by Popcon: 171

   meanwhile (#762509), orphaned 3 days ago
 Description: open implementation of the Lotus Sametime Community
   Client protocol
 Reverse Depends: kopete libmeanwhile-dev libpurple0
 Installations reported by Popcon: 70243

   nxcl (#762542), orphaned 2 days ago
 Description: NX X compression client library
 Reverse Depends: libnxcl-bin libnxcl-dev
 Installations reported by Popcon: 218

   otpw (#762543), orphaned 2 days ago
 Description: OTPW library development files and documentation
 Installations reported by Popcon: 70

   pescetti (#762544), orphaned 2 days ago
 Description: Bridge Pseudo-duplimate generator
 Installations reported by Popcon: 28

   pop3browser (#762497), orphaned 3 days ago
 Description: Allows to check a pop3 mailbox before downloading any
   mail
 Installations reported by Popcon: 46

   python-scriptutil (#762545), orphaned 2 days ago
 Description: Python module which provides the functionality of find
   and grep
 Installations reported by Popcon: 33

   salliere (#762546), orphaned 2 days ago
 Description: Bridge duplicate scorer
 Reverse Depends: gsalliere
 Installations reported by Popcon: 35

   solfege (#762451), orphaned 3 days ago
 Description: Ear training software
 Reverse Depends: solfege-oss
 Installations reported by Popcon: 656

   trilead-ssh2 (#762548), orphaned 2 days ago
 Description: Java SSH library
 Reverse Depends: libnb-ide14-java libsvnkit-java svnkit
 Installations reported by Popcon: 2350

   ytalk (#762556), orphaned 2 days ago
 Description: enhanced talk program
 Installations reported by Popcon: 1178

592 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 138 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 1697 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache goplay packagesearch
 Installations reported by Popcon: 76635

   athcool (#278442), requested 3621 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 52

   awstats (#755797), requested 64 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 4165

   balsa (#642906), requested 1096 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 775

   cardstories (#624100), requested 1249 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 10

   chromium-browser (#583826), requested 1579 days ago
 Description: Chromium browser
 Reverse Depends: chromedriver chromium chromium-dbg chromium-l10n
   mozplugger
 Installations reported by Popcon: 25617

   cups (#532097), requested 1937 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cinnamon-settings-daemon
   cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client
   cups-core-drivers (63 more omi

Re: Seeking help with OpenVPN scripts and systemd

[Brian May]

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 better
suited the n-m on servers. Configuration is stored in plain text files, can
be recorded in etckeeper/git, etc.

I have nothing against either solution, but trying to solve all problems
with one tool isn't going to work, I think.
-- 
Brian May 

Re: Bug#762839: bash without importing shell functions from the environment

[Nikolaus Rath]

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 exploit. You have to manage to inject those precise
> variable names.

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?

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/87oau3mdkv@vostro.rath.org

Re: bash without importing shell functions from the environment

[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: versions / suffixes in experimental

[Russ Allbery]

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 unstable

> Approach 2, which is (IMO) better when the changes you are making in
> experimental are the main line of development, and you're only not
> uploading to unstable because you're trying to avoid a freeze or getting
> tangled into a transition or something:

> 2.2.5-6, -7, ... to experimental
> 2.2.5-5+deb8u1 to unstable (if needed)

> (i.e. in approach 2 you're treating the unstable branch as
> stable-updates to a stable release that doesn't exist yet).

> Either can work. I've done both in the past.

Yes.  To some extent it's a matter of style, and different people will
have different styles, and that's okay.

My personal feeling on this is that I believe people generally over-think
version numbers and add more complexity than is actually required.  I
therefore have a personal rule that I use the simplest version numbers
that I can get away with in any situation.  I've not seen much practical
reason to prefer the sequence:

2.2.5-6~exp1  (experimental)
2.2.5-6~exp2  (experimental)
2.2.5-7   (unstable)

to:

2.2.5-7   (experimental)
2.2.5-8   (experimental)
2.2.5-9   (unstable)

and the latter is simpler, so I pretty much always use that.

Either way, you have to do something "weird" if you need to upload
something to unstable from a different branch, particularly if you don't
want the unstable version to be newer than the experimental version (which
I almost never do).

The only argument that I've found convincing for putting an "exp" in the
experimental package versions is if they're *really* experimental, as in
"this may all be a horrible idea that I will disclaim in the morning"
sort of experimental, and it's really important to get that information in
front of the user in the version number.

But in general I think people are way too conservative about not just
using the next version number.  Integers are cheap, and you won't ever run
out.  :)  It's akin to the problem of endless releases of software widely
used all over the world that still has a 0.x version number.  Just call it
1.0 already.

-- 
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/874mvvqi7k@hope.eyrie.org

Re: bash without importing shell functions from the environment

[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: Bug#762839: bash without importing shell functions from the environment

[Martin Uecker]

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 exploit. You have to manage to inject those precise
> variable names.

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? 
This bash bug makes this easy to exploit, but it is not hard
to imagine that this can confuse other programs in different
ways. In fact, there were very similar bugs in the past:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0997



Martin


--
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/20140925182221.4ff545d1@lemur

Re: Bug#762839: bash without importing shell functions from the environment

[Brian May]

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 one, if I understand correctly, would
allow setting any environment variable to any value.

See list of packages here:

https://access.redhat.com/articles/1200223

In addition, if there are any setuid/setgid program, either in Debian or
installed locally, that make external calls to bash, these would be
vulnerable.

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

brian@aquitard:~$ sudo echo='() { /bin/echo bar; }'  ./test.sh
bar

brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }'  ./test.sh
bar
uid=0(root) gid=0(root) groups=0(root)
-- 
Brian May 

Fwd: bash without importing shell functions from the environment

[Cameron Norman]

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 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?

FYI: I have removed the bug from CC, since this discussion seems a bit
separated from it.

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 could just find the reverse depends of bash
and the packages affected by the lintian warning.

Best regards,
--
Cameron Norman


--
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/CALZWFRL+tfaoLQ=0tme9zhosb20u9iqydbfu4s6oed6bdfm...@mail.gmail.com

Re: Bug#762839: bash without importing shell functions from the environment

[Russ Allbery]

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 bash

if you're testing whether sudo sanitizes the environment?

I believe the syntax that you're using runs the command:

echo='() { /bin/echo bar; }'  bash

under sudo.  If you have all-command sudo privileges, you can indeed run
whatever you want via sudo, including commands that set various
interesting environment variables.  :)

sudo should stop you from doing things like this unless you've explicitly
told sudo to allow the client to set any environment variable.

-- 
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/87a95np1zi@hope.eyrie.org

Re: Bug#762839: bash without importing shell functions from the environment

[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 mostly focused on not
letting the client set arbitrary environment variables and instead tightly
restricting which variables could be set.  The problem with this
vulnerability is that the varible doesn't matter, only the value, which is
a new type of problem.

Also, prior to the discovery of this bug, I'm dubious that anyone would
have found this particular environment variable pattern all that
concerning.  It's not obvious why it would be an issue.  So only a pure
whitelisting approach on environment variable *contents* would have been
effective, and it's hard to define what language you want to restrict the
contents to.

It's very useful in some web situations to get access to arbitrary client
data via environment variables.  I sometimes want *exactly* what the
client sent as its Browser string, for instance, metacharacters and all.
I should be able to get that as an environment variable and process it;
there's no obvious reason to believe that should be unsafe.  I think
assuming the mere contents of an environment variable restricted to a
namespace like HTTP_* and kept well away from, say, LD_* would not be
interpreted as executable code is pretty reasonable.

-- 
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/8761gbp1tf@hope.eyrie.org

Re: bash without importing shell functions from the environment

[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

[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: Re: Bug#762839: bash without importing shell functions from the environment

[Martin Uecker]

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 mostly focused on not
> letting the client set arbitrary environment variables and instead tightly
> restricting which variables could be set.  The problem with this
> vulnerability is that the varible doesn't matter, only the value, which is
> a new type of problem.

See the link I posted. This was about shell escaping and fixed
with sanitization of the content in dhclient. But for some reason
it seems it was not applied to all variables, which would have
prevented the present problem for dhcp.

> Also, prior to the discovery of this bug, I'm dubious that anyone would
> have found this particular environment variable pattern all that
> concerning.  It's not obvious why it would be an issue.  So only a pure
> whitelisting approach on environment variable *contents* would have been
> effective, and it's hard to define what language you want to restrict the
> contents to.

Yes, it is a bit difficult to decide what is acceptable and what
not. But environment variables are a huge attack surface because
they are passed on and you have to garantuee that no child process
does something stupid. E.g. some process may dump its complete
environment into a log file and have a buffer overrun there...
Does not seem unlikely to me.

> It's very useful in some web situations to get access to arbitrary
> client data via environment variables. I sometimes want *exactly* what the 
> client sent as its Browser string, for instance, metacharacters and all.
> I should be able to get that as an environment variable and process it;
> there's no obvious reason to believe that should be unsafe. 

I would say it is problematic because it is not contained but
ends up in a lot of places, i.e. all child processes. One could
at least encode special characters etc... 

> I think assuming the mere contents of an environment variable
> restricted to a namespace like HTTP_* and kept well away from, say, 
> LD_* would not be interpreted as executable code is pretty reasonable.


Martin



-- 
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/20140925194743.52fbc006@lemur

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Paul Wise]

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 nor to update Valid-Until.

Updating the Release files more often will simply mean slightly more
disk space used for the extra Release files. Depending on the update
frequency, the quantity of data is probably too little to make any
significant difference in the disk usage of the snapshot service so
nothing to worry about IMO.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
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/CAKTje6G53nRQBd5w=1nsoovh3icg8giy3mcdedazv9pddef...@mail.gmail.com

Re: Fwd: bash without importing shell functions from the environment

[Clint Adams]

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 could just find the reverse depends of bash
> and the packages affected by the lintian warning.

https://lists.debian.org/debian-devel/2011/04/msg00185.html


-- 
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/20140926032245.ga27...@scru.org

Re: Bug#762839: bash without importing shell functions from the environment

[Mike Hommey]

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 nothing has
> visibly broken yet.)
> 
> Packages (i386) for squeeze, wheezy and sid are here:
>   http://www.chiark.greenend.org.uk/~ian/bash-noshellfunctions/
> 
> dgit format git branches are here:
>   git://git.chiark.greenend.org.uk/~ianmdlvl/bash.git
>   http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git/bash.git/
> 
> 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.
> 
> (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.)

Note that an upstreamable change would be to, at the very least, disable
it in posix mode (the one you get when running bash as sh), since
export -f is, after all, a bashism.

Mike


-- 
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/20140926030040.ga20...@glandium.org

Re: Bug#762839: bash without importing shell functions from the environment

[Brian May]

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 treats both as the same/similar thing.

However, just edited /etc/sudoers and replaced:

%sudo  ALL=(ALL:ALL) ALL

with:

%sudo ALL = (ALL:ALL) /home/brian/test.sh

i.e. lets me run only that specific command, and now sudo does sanitize the
environment:

brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }'  ./test.sh
sudo: sorry, you are not allowed to set the following environment
variables: echo


sudo should stop you from doing things like this unless you've explicitly
> told sudo to allow the client to set any environment variable.
>

Seems to be it is disabled if you allow the client to run any command too.

However, forget my concern for sudo, it doesn't exist.
-- 
Brian May 

Re: Bug#762839: bash without importing shell functions from the environment

[Russ Allbery]

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 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.  In
other words, with your original command, the actual command that you're
running with sudo is probably something like:

/bin/bash -e "echo='() { /bin/echo bar; }' echo foo"

and sudo itself never sees your environment setting.

sudo controls whether it's willing to pass arbitrary environment variables
to the command it runs with the env_reset, env_keep, and env_check
options.

-- 
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/87tx3vnhjm@hope.eyrie.org

Re: Bug#762839: bash without importing shell functions from the environment

[Brian May]

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 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 allowed to set the following environment
variables: echo

My understanding is that sudo doesn't invoke any sort of shell unless you
expressly tell it to do so.

aquitard# strace -ff -eprocess sudo A=B date
execve("/usr/bin/sudo", ["sudo", "A=B", "date"], [/* 21 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7fc58a68b7a0) = 0
clone(Process 25854 attached (waiting for parent)
Process 25854 resumed (parent 25853 ready)
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7fc58a68ba70) = 25854
[pid 25854] execve("/bin/date", ["date"], [/* 18 vars */]) = 0
[pid 25854] arch_prctl(ARCH_SET_FS, 0x7fef50d2c700) = 0
Friday 26 September  14:27:51 EST 2014
[pid 25854] exit_group(0)   = ?
Process 25854 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(25854, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED,
NULL) = 25854
exit_group(0)   = ?

-- 
Brian May 

Re: Bug#762839: bash without importing shell functions from the environment

[Mike Hommey]

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 be:
> >
> > echo='() { /bin/echo bar; }' sudo bash
> >
> 
> I think sudo treats both as the same/similar thing.
> 
> However, just edited /etc/sudoers and replaced:
> 
> %sudo  ALL=(ALL:ALL) ALL
> 
> with:
> 
> %sudo ALL = (ALL:ALL) /home/brian/test.sh
> 
> i.e. lets me run only that specific command, and now sudo does sanitize the
> environment:
> 
> brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }'  ./test.sh
> sudo: sorry, you are not allowed to set the following environment
> variables: echo
> 
> 
> sudo should stop you from doing things like this unless you've explicitly
> > told sudo to allow the client to set any environment variable.
> >
> 
> Seems to be it is disabled if you allow the client to run any command too.
> 
> However, forget my concern for sudo, it doesn't exist.

Note that bash itself has /some/ protection, according to bash -c 'help
set':

  -p  Turned on whenever the real and effective user ids do not match.
  Disables processing of the $ENV file and importing of shell
  functions.  Turning this option off causes the effective uid and
  gid to be set to the real uid and gid.

Mike


-- 
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/20140926043721.ga10...@glandium.org

Re: Bug#762839: bash without importing shell functions from the environment

[Russ Allbery]

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 allowed to set the following environment
> variables: echo

Ah!  You're right.  I totally missed that capability of sudo.

-- 
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/87eguzng2z@hope.eyrie.org

Re: Seeking help with OpenVPN scripts and systemd

[Vincent Bernat]

 ❦ 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 would be a lot better
> suited the n-m on servers. Configuration is stored in plain text
> files, can be recorded in etckeeper/git, etc.

NetworkManager stores its configuration in plain text in
/etc/NetworkManager.
-- 
printk("HPFS: G... Kernel memory corrupted ... going on, but 
it'll crash very soon :-(\n");
2.4.3 linux/fs/hpfs/super.c


signature.asc
Description: PGP signature

Re: Bug#762839: bash without importing shell functions from the environment

[Matthias Urlichs]

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 lenient in what you accept" reason.

In any case, there are a bunch of crazy URL schemes out there,
so who are you to decide that PATH_TRANSLATED="() {:;};rm -rf $(ls /)"
is unreasonable? Literally all of these characters occur in actual
real-world URLs, and RFC 3875 explicitly says that it may contain "any
character".

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature