Things we wish upstream would know

[Thomas Koch]

Hi,

some time ago I started to collect hints for upstream developers on a wiki 
page:

http://wiki.debian.org/Java/UpstreamHints

The page is intended for the audience of upstream developers who care that 
their software be included in a distribution and would be willing to do their 
part to make this happen.
A Debian maintainer can point upstream to individual sections of the page 
instead of reiterating the rationale for a specific wish.

The page first only contained java specific topics but could grow to include 
language independent or other language specific topics with your help. In that 
case the page should be moved out of the java/ namespace.

I'm not a native english speaker. Any help to make this page more polite and 
inviting would be welcome.

Best regards,

Thomas Koch, http://www.koch.ro


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202020939.46417.tho...@koch.ro

Re: Things we wish upstream would know

[Lars Wirzenius]

On Thu, Feb 02, 2012 at 09:39:46AM +0100, Thomas Koch wrote:
> Hi,
> 
> some time ago I started to collect hints for upstream developers on a wiki 
> page:
> 
> http://wiki.debian.org/Java/UpstreamHints

I am Lars Wirzenius and I approve of this page.

However, http://wiki.debian.org/UpstreamGuide is an existing page for
the same purpose, without a Java bias. Would it make sense to combine
yours into the generic one?

-- 
Freedom-based blog/wiki/web hosting: http://www.branchable.com/


signature.asc
Description: Digital signature

Re: Linux 3.2 in wheezy

[Moritz Naumann]

On 02.02.2012 02:21 Russell Coker wrote:
> Are there many users who need root containment but who won't have the 
> resources to run Xen or KVM when the support for Squeeze ends?

I am convinced there are several hosting providers and NGOs who use
linux-vservers for (amongst other) the purpose of root containment and
lack the coins to run the systems they have in a para-virtualization or
full virtualization configuration, and while some of them may get ahold
of newer hardware in the meantime this will not change the overall
situation for them (they will still need cheap computing power) but just
allows them to grow a little.

It's not primarily (but also) organizations in the richer countries on
this planet which I have in mind. Cheap computational resources are
necessary for grassroots organizations to flourish and I think that some
if not many of these cannot afford to replace their root containment
setups by para-virtualization, not now and not in three years.

Obviously, the "it will only get done if someone does it" argument is
(always) valid, too.

Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f2a55a1.1020...@moritz-naumann.com

Bug#658347: ITP: rudecgi -- C++ parser library for CGI applications

[medhamsh]

Package: wnpp
Severity: wishlist
Owner: medhamsh 


* Package name: rudecgi
  Version : 5.0.0
  Upstream Author : Matthew Flood 
* URL : http://www.rudeserver.com/cgiparser/index.html
* License : (GPL)
  Programming Lang: (C++)
  Description : C++ parser library for CGI applications

The RudeCGI C++ CGI Parser library is used for accessing HTTP form data,
path info, and cookie data from CGI applications. In addition to normal
GET and POST data, the component supports file uploads
(multipart/form-data), and simple xml content types (text/xml) -
allowing easy use with xml based clients such as Flash applications.
Furthermore, the component supports path-mapping, allowing information
to be specified without identifying keywords. In addition to normal CGI
operation, if the component detects that it is not in a web-environment,
it provides an interactive console dialog to let you supply formdata in
real-time as the application requests it. The component does not parse
the environment until the application first accesses the instance
object. As such, no parsing overhead will occur if the application does
not explicitly access the component. 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120202093526.18458.66199.report...@hackersbox.iiit.ac.in

Versionned dependencies

[Tanguy Ortolo]

Packages can currenctly declared dependencies on specific versions of
other packages, with simple relations: <<, <=, =, >= and >>. For
instance:
Package: xul-ext-adblock-plus
Depends: iceweasel (>= 3.6.13) | iceape (>= 2.1) | …

While this is sufficient for most cases, it does not cover one
interesting case: a dependencies on a range of versions. For instance:
Package: xul-ext-adblock-plus
Depends: iceweasel (>= 3.6.13, << 12.0~a1+) | iceape (>= 2.1, << 2.9~a1+) | 
…

Because this kind of conceptual dependency cannot be expressed¹, what is
currently done is:
Package: xul-ext-adblock-plus
Depends: iceweasel (>= 3.6.13) | iceape (>= 2.1) | …
Breaks: iceweasel (>= 12.0~a1+), iceweasel (<< 3.6.13),
iceape (>= 2.9~a1+), iceape (<< 2.1)
which is not accurate and has unwanted since it declares conflicts whith
other package versions that do not really conflict but only do not
satisfy the real dependency.

In practice, this causes problems such as #653302: installing
xul-ext-adblock-plus removes iceape just because the current packaged
version of iceape cannot take advantage of adblock-plus.

I would like to hear your opinions on that subject. Independently of the
Mozilla extension context, I think that double-versionned dependency
make as much sense as simple versionned ones. Or, in other words, if a
piece of software can depend on some other one's versions superior to X,
or inferior to Y, it could very well depend on versions superior to X
and inferior to Y, and I do not see a reason why we should not be able
to represent that.


Note:
¹ Technically, it could be expressed by expanding it according to de
  Morgan's laws, but the result would be a huge and complicated
  dependency list, which would probably give a hard time to dependency
  solvers.

-- 
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer
 \_


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jgdmg7$rdk$1...@dough.gmane.org

Re: Things we wish upstream would know

[Andreas Tille]

On Thu, Feb 02, 2012 at 09:39:46AM +0100, Thomas Koch wrote:
> some time ago I started to collect hints for upstream developers on a wiki 
> page:
> 
> http://wiki.debian.org/Java/UpstreamHints

This is helpful.  However, I do not see a point in advertising Git in
this specific content.  It is not that I do not agree with your point
however, I do not think it does properly fit into this page and I do
not think that we should have an opinion upon the Vcs upstream is using
if they regard all other items mentioned above.

Thanks for assembling this page (and in contrast to Lars I think there
are some typical Java issues which should be marked here, but a link
to the general page should be added).

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202100059.gb2...@an3as.eu

Re: Versionned dependencies

[Alexander Reichle-Schmehl]

Hi!

Am 02.02.2012 10:54, schrieb Tanguy Ortolo:
> Packages can currenctly declared dependencies on specific versions of
> other packages, with simple relations: <<, <=, =, >= and >>. For
> instance:
> Package: xul-ext-adblock-plus
> Depends: iceweasel (>= 3.6.13) | iceape (>= 2.1) | …
> 
> While this is sufficient for most cases, it does not cover one
> interesting case: a dependencies on a range of versions. For instance:
> Package: xul-ext-adblock-plus
> Depends: iceweasel (>= 3.6.13, << 12.0~a1+) | iceape (>= 2.1, << 2.9~a1+) 
> | …
[..]

Isn't that why we have versioned provides?  E.g. iceweasel and iceape
could provide xul-api-3.6 (or whatever), while all the xul-ext packages
depends on xul-api-3.6.

Isn't the best solution, but seems to be more elegant that the break you
mentioned.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f2a6213.9010...@debian.org

Re: Versionned dependencies

[Mike Hommey]

On Thu, Feb 02, 2012 at 11:14:43AM +0100, Alexander Reichle-Schmehl wrote:
> Hi!
> 
> Am 02.02.2012 10:54, schrieb Tanguy Ortolo:
> > Packages can currenctly declared dependencies on specific versions of
> > other packages, with simple relations: <<, <=, =, >= and >>. For
> > instance:
> > Package: xul-ext-adblock-plus
> > Depends: iceweasel (>= 3.6.13) | iceape (>= 2.1) | …
> > 
> > While this is sufficient for most cases, it does not cover one
> > interesting case: a dependencies on a range of versions. For instance:
> > Package: xul-ext-adblock-plus
> > Depends: iceweasel (>= 3.6.13, << 12.0~a1+) | iceape (>= 2.1, << 
> > 2.9~a1+) | …
> [..]
> 
> Isn't that why we have versioned provides?  E.g. iceweasel and iceape
> could provide xul-api-3.6 (or whatever), while all the xul-ext packages
> depends on xul-api-3.6.
> 
> Isn't the best solution, but seems to be more elegant that the break you
> mentioned.

There is no such thing as a xul api that iceweasel, iceape and icedove
provide. Sure some parts are common, but some aren't, especially the UI
bits. So in the end, you still need to express a dependency on specific
versions of iceweasel, iceape and icedove.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202103301.ga6...@glandium.org

Re: Versionned dependencies

[Mike Hommey]

On Thu, Feb 02, 2012 at 11:33:01AM +0100, Mike Hommey wrote:
> On Thu, Feb 02, 2012 at 11:14:43AM +0100, Alexander Reichle-Schmehl wrote:
> > Hi!
> > 
> > Am 02.02.2012 10:54, schrieb Tanguy Ortolo:
> > > Packages can currenctly declared dependencies on specific versions of
> > > other packages, with simple relations: <<, <=, =, >= and >>. For
> > > instance:
> > > Package: xul-ext-adblock-plus
> > > Depends: iceweasel (>= 3.6.13) | iceape (>= 2.1) | …
> > > 
> > > While this is sufficient for most cases, it does not cover one
> > > interesting case: a dependencies on a range of versions. For instance:
> > > Package: xul-ext-adblock-plus
> > > Depends: iceweasel (>= 3.6.13, << 12.0~a1+) | iceape (>= 2.1, << 
> > > 2.9~a1+) | …
> > [..]
> > 
> > Isn't that why we have versioned provides?  E.g. iceweasel and iceape
> > could provide xul-api-3.6 (or whatever), while all the xul-ext packages
> > depends on xul-api-3.6.
> > 
> > Isn't the best solution, but seems to be more elegant that the break you
> > mentioned.
> 
> There is no such thing as a xul api that iceweasel, iceape and icedove
> provide. Sure some parts are common, but some aren't, especially the UI
> bits. So in the end, you still need to express a dependency on specific
> versions of iceweasel, iceape and icedove.

As discussed on irc, if you instead do iceweasel-api-3.6, iceweasel-api-4.0,
etc. you end up having crazy dependencies like:
Depends: iceweasel-api-3.6 | iceweasel-api-4.0 | iceweasel-api-5.0 |
iceweasel-api-6.0 | ... | iceweasel-api-11.0 | iceape-api-2.1 |
iceape-api-2.2 | ...

How exactly is that better?

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202110652.ga25...@glandium.org

Re: Versionned dependencies

[Cyril Brulebois]

Mike Hommey  (02/02/2012):
> As discussed on irc, if you instead do iceweasel-api-3.6, iceweasel-api-4.0,
> etc. you end up having crazy dependencies like:
> Depends: iceweasel-api-3.6 | iceweasel-api-4.0 | iceweasel-api-5.0 |
> iceweasel-api-6.0 | ... | iceweasel-api-11.0 | iceape-api-2.1 |
> iceape-api-2.2 | ...
> 
> How exactly is that better?

No Breaks makes it less likely for your package manager to think about
removing packages.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#658356: ITP: libfusioninventory-agent-task-deploy-perl -- Software deployment support for FusionInvnetory

[Gonéri Le Bouder]

Package: wnpp
Severity: wishlist
Owner: "Gonéri Le Bouder" 

* Package name: libfusioninventory-agent-task-deploy-perl
  Version : 1.0.9901 
  Upstream Author : Gonéri Le Bouder  
* URL : http://www.fusioninventory.org/
* License : GPL, Perl
  Programming Lang: Perl
  Description : Software deployment support for FusionInventory

With this module, FusionInventory can accept software deployment
request from an GLPI server with the FusionInventory plugin.

This module uses SSL certificat to authentificat the server.

If the P2P option is turned on, the agent will looks for peer in its
network to speed up the file downloads.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202110849.8270.35694.reportbug@localhost

Re: Versionned dependencies

[Mike Hommey]

On Thu, Feb 02, 2012 at 12:10:17PM +0100, Cyril Brulebois wrote:
> Mike Hommey  (02/02/2012):
> > As discussed on irc, if you instead do iceweasel-api-3.6, iceweasel-api-4.0,
> > etc. you end up having crazy dependencies like:
> > Depends: iceweasel-api-3.6 | iceweasel-api-4.0 | iceweasel-api-5.0 |
> > iceweasel-api-6.0 | ... | iceweasel-api-11.0 | iceape-api-2.1 |
> > iceape-api-2.2 | ...
> > 
> > How exactly is that better?
> 
> No Breaks makes it less likely for your package manager to think about
> removing packages.

You can also have no Breaks, and no *-api-*.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202112026.ga2...@glandium.org

mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts

[Andreas Beckmann]

Hi,

I'm planning to file bugs against all packages that currently fail the
piuparts test with a 'deluser/delgroup: command not found' error in
wheezy and sid.
Currently 17 binary packages from 15 source packages are affected.

Most of these errors happen during the 'postrm purge' phase because
non-essential programs are called by the maintainer script without
checking their existance.

The 'command-not-found' failure logs are available from
http://piuparts.debian.org/sid/command_not_found_error.html
http://piuparts.debian.org/wheezy/command_not_found_error.html

The 'postinst-failed' logs (mostly due to command-not-found, so showing
more or less the same packages) are here:
http://piuparts.debian.org/sid/unknown_purge_error.html
http://piuparts.debian.org/wheezy/unknown_purge_error.html

I'll file these bugs with Severity: important since having a piuparts
clean archive is a release goal since lenny.

The bug report will be based on this template:


Hi,

during a test with piuparts I noticed your package failed to purge
due to a command not found. According to policy 7.2 you cannot rely
on the depends being available during purge, only the essential
packages are available for sure.

The fix should be easy: your package is using adduser or deluser
from the adduser package, which is only priority important. Using
useradd or userdel from the passwd package should fix this problem.

Filing this as important because a.) it's a clear policy violation
(to not clean up at purge) b.) having a piuparts clean archive is a
release goal since lenny and c.) this package being piuparts buggy
blocks packages depending on it from being tested by piuparts (and
thus possibly the detection of more severe problems).

From the attached log (scroll to the bottom...):

$LOGEXCERPT

Attachment: $PACKAGE_$VERSION.log.gz


The logfiles will be checked individually to determine that the
command-not-found is really the most serious error and caused the test
to fail.

Following is a list of maintainers and their source packages that have
at least one binary package that both fails the piuparts test and has
'deluser/delgroup: not found' errors (but may contain false positives).


Regards,

Andreas


Bdale Garbee 
   bind9 (U)

Damien Raude-Morvan 
   tomcat6 (U)

Debian Java Maintainers 
   tomcat6
   tomcat7

Debian OLPC 
   sugar-0.86
   sugar-0.88
   sugar-0.90

Debian Virtualbox Team 
   virtualbox

Dirk Eddelbuettel 
   slurm-llnl (U)

Evgeni Golov 
   bley

Felix Geyer 
   virtualbox (U)

Gennaro Oliva 
   slurm-llnl

Igor Stroh 
   ldap2dns

James Page 
   tomcat7 (U)

Jeremy Malcolm 
   gozerbot

John M Collins 
   gnuspool

Jonas Smedegaard 
   sugar-0.86 (U)
   sugar-0.88 (U)
   sugar-0.90 (U)

LaMont Jones 
   bind9

Ludovic Claude 
   tomcat6 (U)

Luke Faraone 
   sugar-0.88 (U)
   sugar-0.90 (U)

Mario Izquierdo (mariodebian) 
   tcos

Martin Schulze 
   sysklogd

Michael Koch 
   tomcat6 (U)

Michael Meskes 
   virtualbox (U)

Mickael Profeta 
   prelude-manager
   prelude-manager (U)

Miguel Landaeta 
   tomcat6 (U)
   tomcat7 (U)

Niels Thykier 
   tomcat6 (U)

Philip Hands 
   gnuspool (U)

Pierre Chifflier 
   prelude-manager
   prelude-manager (U)

tony mancill 
   tomcat6 (U)
   tomcat7 (U)

Torsten Werner 
   tomcat6 (U)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f2a7d7c.40...@abeckmann.de

Suhosin patch disabled by default in Debian php5 builds

[Ondřej Surý]

Crossposting to php-internals too since those are the guys who receive
the bugreports...

Debian unstable packages has recently disabled suhosin patch by
default (it is still kept as optional part which could be enabled at
compile time).

I am trying to summarize the reasons why I have decided to disable
suhosin patch here.

Please keep the discussion civil and on the technical level and if you
want to engage in deeper discussion please try to keep it isolated in
pkg-php-ma...@lists.alioth.debian.org and 657...@bugs.debian.org, so
we don't flood cross-post. [Sorry for such huge initial cross-post.]

There are already some reasons listed here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657698#15

The manpower issue which was mentioned several times is not the only
one (it mainly comes to mind if we have to keep to sets of packages w/
and w/o suhosin). Although the pkg-php team is always looking for new
victims^Umembers.

I'll try even harder to list more reasons, why I have changed my mind
over a time regarding the suhosin patch:

1. Suhosin patch has an impact on the speed and memory usage. This has
been documented and even author admits it [1].

2. It doesn't help our users when reporting bugs to upstream - the
usual answer is - try if that happens with vanilla php.

3. Stefan's relationships with PHP upstream (and vice versa)[1] isn't
helping very much - and I think we (pkg-php) have improved our
relationship with upstream in past few years a lot.

4. PHP has improved a lot, in fact I haven't seen a canary report in
past few years (probably 5.3.x). Also there are very few segfaults
reported in 5.3 (compared to 5.2 which was a living nightmare from
what I remember).

5. Keeping our code close to upstream and to other linux distros
(Fedora - no, Suse - optional) is a way how to provide our users with
consistent behaviour across the Linux ecosystem.

My personal feeling is that most people see suhosin as "this is about
security, thus it must be good". This combined with bad PHP security
history makes everybody feel insecure when suhosin was removed, but
the real question is if the suhosin is still really helping with PHP
security or it is just a burden in the general installations now.

I have walked the bug list for 5.3 mentioning suhosin[2] to actually
at least partially support what I have just said. I have found few
bugs where suhosin was causing a problems ([3],[4]) and a handful of
bugs with "have suhosin, cannot help". I know this isn't (and can't
be) a definitive list, but it just show that

P.S.: Also see stas reply[5] about valgrind.

Links:
1. 
http://www.hardened-php.net/hphp/faq.html#why_is_hardening-patch_not_part_of_php
2. 
https://bugs.php.net/search.php?search_for=suhosin&boolean=0&limit=90&order_by=&direction=DESC&cmd=display&status=All&bug_type=All&project=PHP&php_os=&phpver=5.3&cve_id=&assign=&author_email=&bug_age=0&bug_updated=0
3. https://bugs.php.net/bug.php?id=60216
4. https://bugs.php.net/bug.php?id=60935
5. 
http://www.suspekt.org/2008/10/12/suhosin-canary-mismatch-on-efree-heap-overflow-detected/

-- 
Ondřej Surý 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caljhhg_wyvjn-z+x9fjui+dgmz+ha9bd54n5vwhnejm4sg1...@mail.gmail.com

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Carlos Alberto Lopez Perez]

On 02/02/12 14:31, Stefan Esser wrote:
> considering the fact that you write this email the very same day that a 
> remote code execution vulnerability in PHP is found that is easy to exploit 
> from remote and is greatly mitigated by the use of Suhosin you look pretty 
> stupid. (In case of usage of Suhosin-Extension in default config, it is even 
> completely killed).
> 
> Just saying.
> 

I think that you words are out of tone, there is not need to be unpolite


And where is such exploit??? I don't see any CVE

http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74



-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Stefan Esser]

Hello Ondřej,

> My personal feeling is that most people see suhosin as "this is about
> security, thus it must be good". This combined with bad PHP security
> history makes everybody feel insecure when suhosin was removed, but
> the real question is if the suhosin is still really helping with PHP
> security or it is just a burden in the general installations now.

considering the fact that you write this email the very same day that a remote 
code execution vulnerability in PHP is found that is easy to exploit from 
remote and is greatly mitigated by the use of Suhosin you look pretty stupid. 
(In case of usage of Suhosin-Extension in default config, it is even completely 
killed).

Just saying.


Regards,
Stefan Esser


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/5fb5cfda-6fe8-4c20-a9b9-7844ed966...@nopiracy.de

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Pierre Joye]

Hi Stefan,

On Thu, Feb 2, 2012 at 2:31 PM, Stefan Esser  wrote:
> Hello Ondřej,
>
>> My personal feeling is that most people see suhosin as "this is about
>> security, thus it must be good". This combined with bad PHP security
>> history makes everybody feel insecure when suhosin was removed, but
>> the real question is if the suhosin is still really helping with PHP
>> security or it is just a burden in the general installations now.
>
> considering the fact that you write this email the very same day that a 
> remote code execution vulnerability in PHP is found that is easy to exploit 
> from remote and is greatly mitigated by the use of Suhosin you look pretty 
> stupid. (In case of usage of Suhosin-Extension in default config, it is even 
> completely killed).

Another very important part of Ondrej's email was:

"Please keep the discussion civil and on the technical level"

And at this point, I may suggest you to keep such posts for yourself.

About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and
will have bugs. This is not really hot news. That does not affect this
discussion.

I, for one, like the idea to finally see distros droping Suhosin and
focus on making PHP itself better and safer instead of distracting us
and our users with custom patches or extensions.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAEZPtU7jtQTDNpUovxxnDdRunjH9BOdX=wbs8jcgz+5wkz8...@mail.gmail.com

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Stefan Esser]

Hello Pierre,

> About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and
> will have bugs. This is not really hot news. That does not affect this
> discussion.

I know that for many years you have not understood the idea behind Suhosin, the 
concept of exploit mitigations.

The only reason why Suhosin exists is because there will ALWAYS be bugs. And 
because that is a fact you must have safe guards in case something goes wrong.
Suhosin/HPHP provides this safe guard for 8 years to the PHP community.

Ideas like: I haven't seen much bugs lately so lets drop all the safe guards is 
like not paying for your life insurance anymore, because you haven't died too 
often recently.

BTW: You should really really look into the history of PHP security and check 
for each of the last 8 years how many features were in Suhosin and later merged 
into PHP because of some nasty security problem.
You will see that at least 2 features of Suhosin per year were merged into PHP.

And there are many many good reasons, why Suhosin must be external to PHP.
The most obvious one is that the code is clearly separated, so that not someone 
of the hundred PHP commiters accidently breaks a safe guard.

Regards,
Stefan Esser

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/46104cb6-a868-41c3-b8e1-f1e0ac06b...@nopiracy.de

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Josselin Mouette]

Le jeudi 02 février 2012 à 02:14 +, Wookey a écrit : 
> It wasn't at all obvious that the actual reason was a conspiracy to
> remove mime file support from evince. Now that I know about it, I'm
> not very impressed. Andreas has already expressed this annoyance so I
> won't say it again.

Being annoyed and angry is nice and all, but if you want people to be
impressed, actually working on the issue might achieve better results.

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


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

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Nico Golde]

* Carlos Alberto Lopez Perez  [2012-02-02 14:46]:
> On 02/02/12 14:31, Stefan Esser wrote:
> > considering the fact that you write this email the very same day that a 
> > remote code execution vulnerability in PHP is found that is easy to 
> > exploit from remote and is greatly mitigated by the use of Suhosin you 
> > look pretty stupid. (In case of usage of Suhosin-Extension in default 
> > config, it is even completely killed).
> > 
> > Just saying.
> 
> I think that you words are out of tone, there is not need to be unpolite
> 
> 
> And where is such exploit??? I don't see any CVE
> 
> http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74

The fact that there is no CVE id or that you don't know about it, has nothing 
to do with something not existing:
http://thexploit.com/sec/critical-php-remote-vulnerability-introduced-in-fix-for-php-hashtable-collision-dos/

Cheers
Nico


pgpaiX3nOWylo.pgp
Description: PGP signature

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Holger Levsen]

On Donnerstag, 2. Februar 2012, Nico Golde wrote:
> http://thexploit.com/sec/critical-php-remote-vulnerability-introduced-in-fi
> x-for-php-hashtable-collision-dos/

Oh my... :(

sigh.



thanks Stefan, thanks Nico.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202021549.45633.hol...@layer-acht.org

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Jonas Smedegaard]

On 12-02-02 at 03:32pm, Josselin Mouette wrote:
> Le jeudi 02 février 2012 à 02:14 +, Wookey a écrit : 
> > It wasn't at all obvious that the actual reason was a conspiracy to 
> > remove mime file support from evince. Now that I know about it, I'm 
> > not very impressed. Andreas has already expressed this annoyance so 
> > I won't say it again.
> 
> Being annoyed and angry is nice and all, but if you want people to be 
> impressed, actually working on the issue might achieve better results.

The "issue" here (or at least at the dawn of this thread) is that some 
package maintainers have chosen to break something that used to work.

It seems to me that Wookie indeed is "working on the issue": Attempting 
to help clarify what is the issue, so that hopefully change the minds of 
those upstreams and/or package maintainers currently tidying to only 
provide XDG hints before being supported generally in Debian either 
directly or through some clever Debian infrastructure.

...or at least help minimize the amount of fellow usptreams and/or 
package maintainers following in the footsteps of those - hopefully few 
- misguided ones currently tidying their packaging too aggressively.


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

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Stefan Esser]

Ohh btw…

> I have walked the bug list for 5.3 mentioning suhosin[2] to actually
> at least partially support what I have just said. I have found few
> bugs where suhosin was causing a problems ([3],[4]) and a handful of
> bugs with "have suhosin, cannot help". I know this isn't (and can't
> be) a definitive list, but it just show that
> 
> P.S.: Also see stas reply[5] about valgrind.
> 
> Links:
> 1. 
> http://www.hardened-php.net/hphp/faq.html#why_is_hardening-patch_not_part_of_php
> 2. 
> https://bugs.php.net/search.php?search_for=suhosin&boolean=0&limit=90&order_by=&direction=DESC&cmd=display&status=All&bug_type=All&project=PHP&php_os=&phpver=5.3&cve_id=&assign=&author_email=&bug_age=0&bug_updated=0
> 3. https://bugs.php.net/bug.php?id=60216
> 4. https://bugs.php.net/bug.php?id=60935
> 5. 
> http://www.suspekt.org/2008/10/12/suhosin-canary-mismatch-on-efree-heap-overflow-detected/

1) You understand that Hardening-Patch is not Suhosin-Patch, do you?

2) Maybe you should also search for: Have Debian, then use a clean PHP not a 
broken Debian build

Bug 3 -> is not a bug in Suhosin, it is the fact that the 
suhosin.executor.max_depth function was not set correctly. Reading the 
documentation helps: 
http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.max_depth

Bug 4 -> the guy is actually writing inside the bug report that the problem 
occurs with and without Suhosin

5) You can just start PHP with the environment variable 
SUHOSIN_MM_USE_CANARY_PROTECTION=0 and can use valgrind.


So basically all points you bring up are no issues.

Regards,
Stefan Esser



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/029d6007-0100-4d92-99ae-7d7b1b365...@nopiracy.de

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Josselin Mouette]

Le jeudi 02 février 2012 à 15:51 +0100, Jonas Smedegaard a écrit : 
> The "issue" here (or at least at the dawn of this thread) is that some 
> package maintainers have chosen to break something that used to work.

Claiming that the mime-support system actually works is stretching
reality as much as a bone who just met Chuck Norris’ fist. The policy
might claim it is the recommended way, but only a handful of programs,
such as mutt and lynx, actually make use of this information.

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


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

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Andrea Bolognani]

On Thu, Feb 02, 2012 at 03:14:56PM +0100, Stefan Esser wrote:

> BTW: You should really really look into the history of PHP security and check 
> for each of the last 8 years how many features were in Suhosin and later 
> merged into PHP because of some nasty security problem.
> You will see that at least 2 features of Suhosin per year were merged into 
> PHP.

If that’s the case, then you have nothing to worry about.

As more and more Suoshin features are merged into mainline PHP, Debian’s
PHP package will get more and more secure. That’s the way it happens for
many other packages, I fail to see why PHP should be treated differently.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: Digital signature

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Andreas Tille]

On Thu, Feb 02, 2012 at 04:23:01PM +0100, Josselin Mouette wrote:
> 
> Claiming that the mime-support system actually works is stretching
> reality as much as a bone who just met Chuck Norris’ fist.

I fail to see a reason to fall back to polemics.

> The policy
> might claim it is the recommended way, but only a handful of programs,
> such as mutt and lynx, actually make use of this information.

Any reason you are leaving out those two programs (see, mc) which were
explicitely given in the bug report.  Adding w3m makes your hand really
full and a five minutes research would uncover another hand full. 

However, to prove your point you need to mention counter examples which
are actually failing to use mime-support or are actually broken because
of using mime-support.

Kind regards

  Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202154331.ga9...@an3as.eu

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Bernhard R. Link]

* Josselin Mouette  [120202 16:23]:
> [the usual insults removed] The policy
> might claim it is the recommended way, but only a handful of programs,
> such as mutt and lynx, actually make use of this information.

Or programs like "see" or everything using it that wants to savely run
a program for a given mime type. (xdgopen has still not got an option
to specify the mime-type, has it?)

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202152839.ga18...@server.brlink.eu

Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts

[Ian Jackson]

Andreas Beckmann writes ("mass bug filing of 'deluser/delgroup: command not 
found' errors detected by piuparts"):
> Most of these errors happen during the 'postrm purge' phase because
> non-essential programs are called by the maintainer script without
> checking their existance.

We had a conversation (here I think) last year about whether programs
should be trying to automatically remove users in their postrm.  IIRC
the conclusion of that discussion the answer was that they should not,
at least in the default case.

We should double check this, before you submit your MBF, so that
information about what to do can be included in your bug report.

> The fix should be easy: your package is using adduser or deluser
> from the adduser package, which is only priority important. Using
> useradd or userdel from the passwd package should fix this problem.

In particular, I think this is the wrong advice because IMO the
correct fix is not to call any of these tools from postrm purge.

Thanks,
Ian.


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

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Josselin Mouette]

Le jeudi 02 février 2012 à 16:43 +0100, Andreas Tille a écrit : 
> > The policy
> > might claim it is the recommended way, but only a handful of programs,
> > such as mutt and lynx, actually make use of this information.
> 
> Any reason you are leaving out those two programs (see, mc) which were
> explicitely given in the bug report.  Adding w3m makes your hand really
> full and a five minutes research would uncover another hand full. 

Oh, great. That changes everything, of course. 

> However, to prove your point you need to mention counter examples which
> are actually failing to use mime-support or are actually broken because
> of using mime-support.

Are you trying to troll, or do you actually not know anything of the
topic you are talking about?

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


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

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Pierre Joye]

hi Stefan,

On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser  wrote:
> Hello Pierre,
>
>> About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and
>> will have bugs. This is not really hot news. That does not affect this
>> discussion.
>
> I know that for many years you have not understood the idea behind Suhosin, 
> the concept of exploit mitigations.

Let me disagree with your way of doing things without telling me that
I do not understand what you do. It is two different concepts. I also
perfectly understand the goals of Suhosin, the technical as well as
the non technical ones. The anonymity of a project is not always
helpful.

> The only reason why Suhosin exists is because there will ALWAYS be bugs.

Indeed, so it is for Suhosin as well.

> BTW: You should really really look into the history of PHP security and check 
> for each of the last 8 years how many features were in Suhosin and later 
> merged into PHP because of some nasty security problem.
> You will see that at least 2 features of Suhosin per year were merged into 
> PHP.

For one, some were not not ported but features were implemented, with
the support of their original authors. They are not related to
Suhosin, like the Blowfish support, which I ported to php with the
help of Solar Designer. Suhosin uses the same implementation.

> And there are many many good reasons, why Suhosin must be external to PHP.
> The most obvious one is that the code is clearly separated, so that not 
> someone of the hundred PHP commiters accidently breaks a safe guard.

I would be the happiest man on Earth if PHP would have hundred active
PHP contributors. As a matter of fact, we have like 3-4 active weekly,
less than 10 yearly and maybe around 15 for the 'let commit something'
area.

While we discuss about the reasons why I do not think Suhosin is not
the right way, let start from the beginning.

I understand why you left the security team and the php project years
ago. Back then I was not on the security team, so I won't comment this
period (and I would have partially agreed with you). However, I am
part of this team since some years now and I (along with other) have
been pushing drastic changes in the way we work, for releases or
security issues in particular. You are ignoring these changes and
progresses.

For example the Release RFC (https://wiki.php.net/rfc/releaseprocess):

 . does not allow new features after x.y.0 final

 . enforce quick release when a flaw is discovered
   much easier to do as no noise commits will be present

 . many other good things

Only the two first points will drastically increase the quality and
safety of our releases. The reason is that the amount of unnecessary
commits will be null, or almost null. That kills the argument about
'hundred of commit(ers) breaking PHP'. It also helps to get fixes out
sooner rather than later.

Many features are making their way to PHP as well, on a case by case
basis. We have changed and we are on the right track since quite some
time already. If you have features that you consider that it must be
in the core, then let discuss it, on this list. But so far I failed to
see other features in Suhosin that we need to implement without having
more cons than pros.

I am also convinced that these new policies will also allow
distributions to update to the latest release of a given branches
instead of having to backport fixes to their tree. And that alone is a
huge step forward.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAEZPtU4oqvSmjU=3oh3iurtw5mzlagtplwfu-kttq_scksu...@mail.gmail.com

Re: Linux 3.2 in wheezy

[Ben Hutchings]

On Thu, 2012-02-02 at 09:29 +0200, Jonathan Carter (highvoltage) wrote:
[...]
> We tried the 2.6.32 VZ kernel on squeeze / wheezy / lucid / precise - 
> and it works.

That's what I would expect, but it's good to know.

> We have a PPA[1] for our experimental packages too. We 
> might run into bugs with some userspace things needing a newer kernel, 
> but we haven't found anything yet. The big downside is also that we rely 
> on the VZ project to release security updates and we have to be vigilant 
> to update regularly.
> 
> All the work that the above is causing (and to an extent the risk) makes 
> me quite eager to move to LXC. If distributions like Debian and Ubuntu 
> could continue supporting it it would be a different story, but it 
> sounds like OpenVZ is a borderline hostile upstream who isn't interested 
> in working with anyone, and that makes me want to move away even more.

In my experience the OpenVZ project is not at all hostile, but it does
have limited development resources.  Its primary stable branch is based
on the RHEL 6 kernel - which, despite being initially based on 2.6.32,
is now very different from 2.6.32.y.

Also, many of the improvements to container support in mainline Linux
are coming from OpenVZ developers.  It's just taking a long time to
implement that functionality in a way that's acceptable in mainline.

Ben.

-- 
Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing anyway.


signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[jpauli]

On Thu, Feb 2, 2012 at 4:49 PM, Pierre Joye  wrote:

> hi Stefan,
>
> On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser  wrote:
> > Hello Pierre,
> >
> >> About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and
> >> will have bugs. This is not really hot news. That does not affect this
> >> discussion.
> >
> > I know that for many years you have not understood the idea behind
> Suhosin, the concept of exploit mitigations.
>
> Let me disagree with your way of doing things without telling me that
> I do not understand what you do. It is two different concepts. I also
> perfectly understand the goals of Suhosin, the technical as well as
> the non technical ones. The anonymity of a project is not always
> helpful.
>
> > The only reason why Suhosin exists is because there will ALWAYS be bugs.
>
> Indeed, so it is for Suhosin as well.
>
> > BTW: You should really really look into the history of PHP security and
> check for each of the last 8 years how many features were in Suhosin and
> later merged into PHP because of some nasty security problem.
> > You will see that at least 2 features of Suhosin per year were merged
> into PHP.
>
> For one, some were not not ported but features were implemented, with
> the support of their original authors. They are not related to
> Suhosin, like the Blowfish support, which I ported to php with the
> help of Solar Designer. Suhosin uses the same implementation.
>
> > And there are many many good reasons, why Suhosin must be external to
> PHP.
> > The most obvious one is that the code is clearly separated, so that not
> someone of the hundred PHP commiters accidently breaks a safe guard.
>
> I would be the happiest man on Earth if PHP would have hundred active
> PHP contributors. As a matter of fact, we have like 3-4 active weekly,
> less than 10 yearly and maybe around 15 for the 'let commit something'
> area.
>
> While we discuss about the reasons why I do not think Suhosin is not
> the right way, let start from the beginning.
>
> I understand why you left the security team and the php project years
> ago. Back then I was not on the security team, so I won't comment this
> period (and I would have partially agreed with you). However, I am
> part of this team since some years now and I (along with other) have
> been pushing drastic changes in the way we work, for releases or
> security issues in particular. You are ignoring these changes and
> progresses.
>
> For example the Release RFC (https://wiki.php.net/rfc/releaseprocess):
>
>  . does not allow new features after x.y.0 final
>
>  . enforce quick release when a flaw is discovered
>   much easier to do as no noise commits will be present
>
>  . many other good things
>
> Only the two first points will drastically increase the quality and
> safety of our releases. The reason is that the amount of unnecessary
> commits will be null, or almost null. That kills the argument about
> 'hundred of commit(ers) breaking PHP'. It also helps to get fixes out
> sooner rather than later.
>
> Many features are making their way to PHP as well, on a case by case
> basis. We have changed and we are on the right track since quite some
> time already. If you have features that you consider that it must be
> in the core, then let discuss it, on this list. But so far I failed to
> see other features in Suhosin that we need to implement without having
> more cons than pros.
>
> I am also convinced that these new policies will also allow
> distributions to update to the latest release of a given branches
> instead of having to backport fixes to their tree. And that alone is a
> huge step forward.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
In fact, I agree that it'd be a good idea to discuss more widely PHP
Security , why not through specific RFCs, with POCs of each ideas/concepts
, so that people could comment on them, and approve/decline the
concepts/patches :)

Julien.P

Re: lack of replacement for linux-vserver

[Micah Anderson]

Bernd Zeimetz  writes:

> On 01/31/2012 10:37 PM, Ben Hutchings wrote:
> [...]
>> If anyone wishes to volunteer to maintain VServer in Debian - you are
>> very welcome, but please start by addressing the bugs filed against
>> them in squeeze and reviewing the existing conflicts.  If you can
>> prove yourself by doing that, then you may convince me and the rest of
>> the kernel team that you can maintain it in wheezy as well.
>> Otherwise, no chance.
>> 
>> The above all applies to OpenVZ as well, and what I've suggested to is
>> that the interested developers maintain an APT repository of kernel
>> packages for Debian using whichever version the OpenVZ project is
>> prepared to support.  Maybe the Linux-VServer project can do that too.
>
> I've tried to convince the linux-vserver developers on various ocassions
> on irc to work together with a person of their choice from Debian to
> maintain the patch for stable releases. But they are not willing to
> support Debian as they neither use Debian nor have any interest in
> supporting the Debian kernel.

Hmm, I do not agree on that representation of upstream's position. On
the contrary, they are happy to not only port the Linux-Vserver patches
to work with the Debian kernel's set of patches, but also keeping those
kernels up-to-date, as long as they are working with someone in Debian
who can do the 'debian-specific' work.

Neither of the two active upstream developers use Debian as a host, so
they would not be people who use the kernel or have any vested interest
in it. Their position is that if someone inside Debian steps up to do
the 'debian-specific' work, they have no problem working with that
person with both an initial port to the Debian kernel, or keeping those
kernels up-to-date.


-- 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehudjj6j@algae.riseup.net

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Ian Jackson]

Josselin Mouette writes ("Re: Breaking programs because a not yet implemented 
solution exists in theory (Was: Bug#658139: evince: missing mime entry)"):
> Le jeudi 02 février 2012 à 15:51 +0100, Jonas Smedegaard a écrit : 
> > The "issue" here (or at least at the dawn of this thread) is that some 
> > package maintainers have chosen to break something that used to work.
> 
> Claiming that the mime-support system actually works is stretching
> reality as much as a bone who just met Chuck Norris’ fist. The policy
> might claim it is the recommended way, but only a handful of programs,
> such as mutt and lynx, actually make use of this information.

The correct approach if you don't like the existing machinery, and
think policy is mandating an obsolete mechanism, is to get consensus
to change the approach for Debian as a whole.

The correct approach it is not to unilaterally decide to do switch to
some other half-implemented system, remove support for the previously
working machinery, and demand that bug submitters write the
compatibility code.

Ian.


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

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Ian Jackson]

[resent with 7-bit headers. apologies for any mangled names:]

Pierre Joye writes ("Re: [PHP-DEV] Suhosin patch disabled by default in Debian 
php5 builds"):
> [...] But so far I failed to see other features in Suhosin that we
> need to implement without having more cons than pros.

I know nearly nothing about PHP security and nothing about Suhosin.

But from what I have read in this thread, I find this kind of argument
very unconvincing.  Surely the time to drop something like Suhosin
would be when PHP stops actually having bugs which are mitigated by
Suhosin.  Not when the PHP project claims to have improved its
processes so that these bugs won't occur any more.  

The decision should be based on the existence or not of the
vulnerabilities, and whether Suhosin in actual fact helps.

Ian.


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

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Josselin Mouette]

Le jeudi 02 février 2012 à 16:12 +, Ian Jackson a écrit : 
> The correct approach it is not to unilaterally decide to do switch to
> some other half-implemented system, remove support for the previously
> working machinery, and demand that bug submitters write the
> compatibility code.

The correct approach is to notice you have a perfectly working,
fully-implemented system, that works fine across the whole distribution
except for a handful of packages, and to remove the compatibility code
for the legacy system.

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


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

Re: Call for volunteers to join DebConf Committee

[Guido Trotter]

Hi,

I'd be happy to help, if you don't find any better suited candidate
(if you have volunteers who are more expert than me, by all means go
for them!!) I definitely have made it to plenty of debconfs, and sure
hope to continue the trend.

Thanks,

Guido


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAM4p=JPE3w-otFF+aB9fXsChn0+thjb93w45s_-V+=wqrne...@mail.gmail.com

RE : mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts

[PICCA Frédéric-Emmanuel]

> We had a conversation (here I think) last year about whether programs
> should be trying to automatically remove users in their postrm.  IIRC
> the conclusion of that discussion the answer was that they should not,
> at least in the default case.

> We should double check this, before you submit your MBF, so that
> nformation about what to do can be included in your bug report.

> In particular, I think this is the wrong advice because IMO the
> correct fix is not to call any of these tools from postrm purge.

In that case you got his kind of piuparts error [1], if you did not remove the 
homedir of the previously added user.

What is the right fice for this ?

Cheers,

Frederic
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657146

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/a2a20ec3b8560d408356cac2fc148e5325072...@sun-dag1.synchrotron-soleil.fr

Re: RE : mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts

[Lars Wirzenius]

On Thu, Feb 02, 2012 at 05:09:42PM +, PICCA Frédéric-Emmanuel wrote:
> > We had a conversation (here I think) last year about whether programs
> > should be trying to automatically remove users in their postrm.  IIRC
> > the conclusion of that discussion the answer was that they should not,
> > at least in the default case.
> 
> > We should double check this, before you submit your MBF, so that
> > nformation about what to do can be included in your bug report.
> 
> > In particular, I think this is the wrong advice because IMO the
> > correct fix is not to call any of these tools from postrm purge.

The relevant bug is this:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621833

And I agree with Ian's summary: system users should be created, but
not removed.

> In that case you got his kind of piuparts error [1], if you did not
> remove the homedir of the previously added user.
> 
> What is the right fice for this ?

The proper way to fix this is to change piuparts to not complain
about home directories that belong to system users created during
the package install.

-- 
Freedom-based blog/wiki/web hosting: http://www.branchable.com/


signature.asc
Description: Digital signature

Re: Linux 3.2 in wheezy

[Vincent Bernat]

OoO En cette nuit striée d'éclairs du jeudi 02 février 2012, vers 02:21,
Russell Coker  disait :

>> However, a low profile container/virtualization solution is needed, and I
>> know there is quite some demand for it: both some larger scale
>> organisations and several smaller/non-profit organisations I am acquainted
>> with use either OpenVZ or linux-vserver and some of them will be in
>> trouble if there is no equivalent and not at least a rough migration path.

> Are there many users who need root containment but who won't have the 
> resources to run Xen or KVM when the support for Squeeze ends?

With vservers and  OpenVZ you can run each service  in its own container
with a small  memory footprint. With Xen/KVM, you  will need to allocate
at least 128 MB for each container.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)


pgpX38v2OXLlH.pgp
Description: PGP signature

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Andreas Tille]

On Thu, Feb 02, 2012 at 04:52:22PM +0100, Josselin Mouette wrote:
> > However, to prove your point you need to mention counter examples which
> > are actually failing to use mime-support or are actually broken because
> > of using mime-support.
> 
> Are you trying to troll, or do you actually not know anything of the
> topic you are talking about?

I'm probably a troll to consider answering messages like this, but in
the paragraph above I was talking about logic and how to prove some
statement.  At least when I was young I was winning some mathematics
contests where those knowledge was a precondition.  So I'd like to
answer at lest the second part with "I know a bit about this".

Could you please now come back to the topic

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202175907.gc9...@an3as.eu

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Stas Malyshev]

Hi!


I know that for many years you have not understood the idea behind
Suhosin, the concept of exploit mitigations.


I think we have a difference of approaches here, and it is well known.
There's more or less a consensus among PHP dev that to introduce a
feature, especially with high user performance cost and other risks,
into PHP its necessity to the user needs to be proven and outweigh the
problems it causes. You seem to advocate the approach in which
performance and convenience can and should be sacrificed to security. It 
is a matter of opinion, and each one has its own validity. We probably 
would have for now to agree to disagree here.


That said, I personally would be happy to see more participation from
you - including and especially contributing and maintaining parts of
Suhosin patch that do not have high costs and user issues associated
with them and are not controversial - I think it would benefit PHP a
lot. Of course, it's your decision, but I think that would be better
both for PHP security and PHP users which have little interest in what
belongs where and why, but right now the only person who can maintain
and support any line of code in Suhosin is you, which is not always
helpful to the users.


The most obvious one is that the code is clearly separated, so that
not someone of the hundred PHP commiters accidently breaks a safe
guard.


There's no "hundred PHP committers" except in theory. In practice, 
number of people regularly committing to relevant part of the core is 
probably less then 10.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f2aceeb.4080...@sugarcrm.com

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Ian Jackson]

Josselin Mouette writes ("Re: Breaking programs because a not yet implemented 
solution exists in theory (Was: Bug#658139: evince: missing mime entry)"):
> Le jeudi 02 février 2012 à 16:12 +, Ian Jackson a écrit : 
> > The correct approach it is not to unilaterally decide to do switch to
> > some other half-implemented system, remove support for the previously
> > working machinery, and demand that bug submitters write the
> > compatibility code.
> 
> The correct approach is to notice you have a perfectly working,
> fully-implemented system, that works fine across the whole distribution
> except for a handful of packages, and to remove the compatibility code
> for the legacy system.

Whether something is a "legacy" system is a matter of opinion which
reasonable people can disagree on.

That's why you should get consensus before charging full steam ahead
with a change like this.

Ian.


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

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Philip Hands]

On Thu, 02 Feb 2012 18:08:33 +0100, Josselin Mouette  wrote:
> Le jeudi 02 février 2012 à 16:12 +, Ian Jackson a écrit : 
> > The correct approach it is not to unilaterally decide to do switch to
> > some other half-implemented system, remove support for the previously
> > working machinery, and demand that bug submitters write the
> > compatibility code.
> 
> The correct approach is to notice you have a perfectly working,
> fully-implemented system, that works fine across the whole distribution
> except for a handful of packages, and to remove the compatibility code
> for the legacy system.

I presume the subject of this thread explains why my emacs+notmuch setup
has lost the ability to show me pdfs.

I only very rarely get attachments, so the irritation of saving the file
and then pointing evince at it by hand was minor enough that I'd not got
round to finding out what the problem was.

Are you really saying that intentionally inflicting such low-grade
breakage and annoyance on your users is what you think it takes to
encourage them to write software for you?

This hardly seems compatible with our social contract.

Also, I note that there seems to be no warning that you've done this in
the NEWS or README files -- did you document this vandalism anywhere?

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgph2z0vkF09H.pgp
Description: PGP signature

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Ángel González]

Stefan Esser wrote:
> And there are many many good reasons, why Suhosin must be external to PHP.
> The most obvious one is that the code is clearly separated, so that not 
> someone of the hundred PHP commiters accidently breaks a safe guard.
That's not a justification to keep it as a patch.
Safe guards could prefectly be skipped by a commit which changed near
code, reestructures the function or creates a different path, *even if
the patch still applies*.
So you would still need to check for all kind of unexpected changes anyway.

If it were in core, at least anyone changing the related code would
realise that it's there, and could take that into account for not
breaking it. If it's maintained by someone else as a patch, that simply
won't happen.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f2ad757.3070...@gmail.com

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[brian m. carlson]

On Thu, Feb 02, 2012 at 06:08:33PM +0100, Josselin Mouette wrote:
> Le jeudi 02 février 2012 à 16:12 +, Ian Jackson a écrit : 
> > The correct approach it is not to unilaterally decide to do switch to
> > some other half-implemented system, remove support for the previously
> > working machinery, and demand that bug submitters write the
> > compatibility code.
> 
> The correct approach is to notice you have a perfectly working,
> fully-implemented system, that works fine across the whole distribution
> except for a handful of packages, and to remove the compatibility code
> for the legacy system.

The mime-support solution is part of Policy.  It is a perfectly working,
fully-implemented solution.  If you feel that it is obsolescent or
obsolete and should be replaced by a different solution, then it's your
job to convince other people of that, do the work to make that happen,
and request that Policy be amended accordingly.  I have yet to see a bug
filed on the debian-policy package requesting that.

As it is, evince does not display PDFs from mutt.  Thus your solution is
inadequate, because mutt does not use your solution (and there is no bug
filed against mutt to do so).  You have thus broken an otherwise
perfectly working solution because you don't like it.

As a package maintainer, you're going to have to support some things you
don't like.  If you hate natural alignment and think sparc is awful, you
still have to support it or find a co-maintainer who will.  However
awful you think mime-support is, it's still part of Policy, and agreeing
on one system improves the experience for users, which is one of the
main purposes of a Linux distribution.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Michael Biebl]

On 02.02.2012 20:11, brian m. carlson wrote:

> The mime-support solution is part of Policy.  It is a perfectly working,

...

> As a package maintainer, you're going to have to support some things you
> don't like.  If you hate natural alignment and think sparc is awful, you

Show us where mime-support is a required part in policy and then we can
talk again.

Seriously, all this whining is tiresome and doesn't get us one step
closer to a (technical) solution.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Processed: reassign 658139 to general, tagging 658139 ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 658139 general
Bug #658139 [evince] evince: missing mime entry
Bug reassigned from package 'evince' to 'general'.
> tags 658139 - patch
Bug #658139 [general] evince: missing mime entry
Removed tag(s) patch.
> retitle 658139 generate mailcap entries from desktop files
Bug #658139 [general] evince: missing mime entry
Changed Bug title to 'generate mailcap entries from desktop files' from 
'evince: missing mime entry'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
658139: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658139
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.13282133033650.transcr...@bugs.debian.org

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Thomas Goirand]

On 02/03/2012 01:59 AM, Stas Malyshev wrote:
> You seem to advocate the approach in which
> performance and convenience can and should be sacrificed to security.
> It is a matter of opinion

Something I don't get here. If there's this issue, and
different tastes, why can't a build flag be used, so
that you can choose security or speed depending on your
needs? If you do some:

#ifdef ENABLE_SLOWER_SUHOSIN_SECURITY

in the controversial parts, then I don't see how this
would be of trouble for anyone to have Suhosin included
in upstream PHP.

Cheers,

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: http://lists.debian.org/4f2aedf8.2010...@debian.org

Re: Breaking programs because a not yet implemented solution exists in theory

[Russ Allbery]

Michael Biebl  writes:

> Show us where mime-support is a required part in policy and then we can
> talk again.

Policy 9.7 currently says that it's a bug to not support mime-support:

Packages which provide the ability to view/show/play, compose, edit or
print MIME types should register themselves as such following the
current MIME support policy.

and:

In the normative part of this manual, the words must, should and may,
and the adjectives required, recommended and optional, are used to
distinguish the significance of the various guidelines in this policy
document.  Packages that do not conform to the guidelines denoted by
must (or required) will generally not be considered acceptable for the
Debian distribution.  Non-conformance with guidelines denoted by
should (or recommended) will generally be considered a bug, but will
not necessarily render a package unsuitable for distribution.

So it depends on your definition of "required," I suppose.

Anyway, I think this discussion is painful and not likely to change
anyone's mind, whereas the necessary glue between desktop files and
mime-support looks like a couple of days of work.  I'm currently playing
with the idea of writing a spec and posting it to Planet Debian asking
someone with the skill and some free time to implement it.

-- 
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: http://lists.debian.org/877h05q7fo@windlord.stanford.edu

Re: Breaking programs because a not yet implemented solution exists in theory

[Michael Biebl]

On 02.02.2012 21:58, Russ Allbery wrote:

> Anyway, I think this discussion is painful and not likely to change
> anyone's mind, whereas the necessary glue between desktop files and
> mime-support looks like a couple of days of work.  I'm currently playing
> with the idea of writing a spec and posting it to Planet Debian asking
> someone with the skill and some free time to implement it. 

That would be very much appreciated.
And btw, thanks a lot for staying technical in this whole discussion!

I've reassigned #658139 to general.

I guess it would make sense to discuss further technical details there
or at least keep it updated with the outcome of your blog posting?

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Breaking programs because a not yet implemented solution exists in theory

[Andreas Tille]

Hi Russ,

On Thu, Feb 02, 2012 at 12:58:03PM -0800, Russ Allbery wrote:
> Michael Biebl  writes:
> 
> > Show us where mime-support is a required part in policy and then we can
> > talk again.
> 
> Policy 9.7 currently says that it's a bug to not support mime-support:

Many thanks for always bringing discussions to some reasonable state by
sticking to pure facts.

> Anyway, I think this discussion is painful and not likely to change
> anyone's mind, whereas the necessary glue between desktop files and
> mime-support looks like a couple of days of work.  I'm currently playing
> with the idea of writing a spec and posting it to Planet Debian asking
> someone with the skill and some free time to implement it.
 
It might make sense to mention #658139 in this spec which is now
assigned to general.  When becoming suspicious about mime types
I noticed the following:

$ see test.ogg 
Error: no "view" mailcap rules found for type "audio/ogg"

$ see test.mp3
  -> brings up alsaplayer

So even some ogg capable players and probably other programs might
profit here.  I just detected this by chance and thus would like to
mention that it might be needed to do some more general research.  I
admit that I could perfectly live without a `see *.ogg` which is way
below my interest in getting proper settings for *.pdf - just mentioning
that in fact the problem is more general.

Kind regards

  Andreas (who regrets to waste time of his fellow developers
   by not resisting a provocation sometimes)

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202213054.gh9...@an3as.eu

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Carlos Alberto Lopez Perez]

On 02/02/12 14:43, Carlos Alberto Lopez Perez wrote:
> On 02/02/12 14:31, Stefan Esser wrote:
>> considering the fact that you write this email the very same day that a 
>> remote code execution vulnerability in PHP is found that is easy to exploit 
>> from remote and is greatly mitigated by the use of Suhosin you look pretty 
>> stupid. (In case of usage of Suhosin-Extension in default config, it is even 
>> completely killed).
>>
>> Just saying.
>>
> 
> I think that you words are out of tone, there is not need to be unpolite
> 
> 
> And where is such exploit??? I don't see any CVE
> 

Answering myself:


 Original Message 
From: Tomas Hoger 
To: OSS Security 
Cc: secur...@php.net, Stefan Esser 
Subject: [oss-security] PHP remote code execution introduced via HashDoS fix

Hi!

Internets are buzzing with info on the PHP flaw found by Stefan Esser
in the fix for CVE-2011-4885.

http://thexploit.com/sec/critical-php-remote-vulnerability-introduced-in-fix-for-php-hashtable-collision-dos/
http://www.h-online.com/security/news/item/Critical-PHP-vulnerability-being-fixed-1427316.html
http://svn.php.net/viewvc?view=revision&revision=323007

This got CVE-2012-0830 assigned earlier today.  This is sent to make
the assignment public and avoid possible duplicate assignment.

-- 
Tomas Hoger / Red Hat Security Response Team




-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Re: Linux 3.2 in wheezy

[Christopher Hagar]

unsubscribe

On Sun, Jan 29, 2012 at 1:22 PM, Ben Hutchings  wrote:

> Debian 7.0 'wheezy' will include Linux 3.2.  This is currently in
> unstable and will soon enter testing.
>
> The kernel team is open to backporting some features from later kernel
> versions, particularly to support newer hardware.
>
> Featuresets
> ---
>
> The only featureset provided will be 'rt' (realtime), currently built
> for amd64 only.  If there is interest in realtime support for other
> architectures, we may be able to add that.  However, we do need to
> consider the total time taken to build binary packages for each
> architecture.
>
> If there are particular container features that should be enabled or
> backported to provide a useful replacement for OpenVZ or VServer,
> please let us know.  We cannot promise that these will all be enabled
> but we need to know what is missing.
>
> Compatibility
> -
>
> If you maintain a package for which the current stable version is not
> compatible with Linux 3.2, excluding kernel module packages, please
> consider making a stable update that fixes this.
>
> If you maintain a kernel module package, please ensure that this is
> compatible with Linux 3.2 in time for the freeze.  Any modules that
> are not compatible will not be included in the release.  I recently
> tested building all the module packages I could find against Linux 3.1
> and have filed bugs against those that failed to build; however I have
> not tested against Linux 3.2 and would prefer that the respective
> maintainers did so.
>
> We intend to switch to 2-component upstream version numbers in the
> kernel version string, e.g.  3.3-1-amd64.  This change has been
> deferred until after wheezy to avoid incompatibility with packages in
> squeeze that assume 3-component version numbers.  If your package uses
> uname(1) or uname(2) please ensure that it is prepared for this *in
> wheezy* so that we can make the change immediately after.
>
> Upstream support
> 
>
> Debian, Ubuntu and others will work upstream on a 3.2.y longterm
> series of bug fixes.
>
> Ben.
>
> --
> Ben Hutchings
> We get into the habit of living before acquiring the habit of thinking.
>  - Albert Camus
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIVAwUBTyWOS+e/yOyVhhEJAQqAvA/+LomQCJ5JWEDQ1x2I6TtdZul2kKqruA9h
> oSKj6zlVWWOqocaSKX6VnCtbhm6mSPMGl+/pF5OegbGEiluyY4QyUyOHap5aR6ID
> S7KwQ516NmgBQ+rjQuG+3MHAE8afCdhH2yA/uDub7rya+gfp9MaWbDFS2wSdMyXb
> u37JJAJiSbWVnI/bRYVZFMSffZ4NCYhjyNJLE1ljlHj+UVurtR/zLm5t0lg4nrGq
> IWNmef867qy6DG6G+EYMndswxDw2OJvJn0bsYVpyXXj3Eh1Vl2+PsyaVEyoTH8a6
> 1z4PhSlLDliqug4Mt5/h7Q4+HcJyipl0pSzleVuNb31nmQ9xptFddKkJibq4mz61
> 5uyGVQG7AVn2T7riXMiQux2jiw+u5yLxULSZJoqbOHwXqeHTU9VMYpsRpr0H8voT
> 35f+2ucyTGZmLWAS1WhmigYxEqcAvLuPdHX7adRne82VNlPttLXbCAKDCzJPwWdt
> uWfTh+NrhdiVzXZlcbUhIbk3G7c9MhaANl0J3QKQtb0i3hwEp59z1ufZGFBsrtpU
> As5YZpCgnJt+NRSDh9J7p5DVAfiO50MS5s3OUyKzL25O0Zon4djns6X2fNbd9UDU
> S61EjW+pzyYObyZFGrMFttzXLl6cvWU0jbM5U5pnFnrEmTJNlpAxnv3i/gfcOKab
> Ke7aiKb8hvw=
> =LAU4
> -END PGP SIGNATURE-
>
>

Bug#658434: ITP: miniupnpd -- daemon providing UPnP Internet Gateway Device (IGD) services

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: miniupnpd
  Version : 1.6.20120121
  Upstream Author : Thomas Bernard 
* URL : http://miniupnp.free.fr/
* License : BSD
  Programming Lang: C
  Description : daemon providing UPnP Internet Gateway Device (IGD) services

 MiniUPnPd is a small daemon providing UPnP Internet Gateway Device (IGD)
 services to your network. UPnP and NAT-PMP are used to improve internet
 connectivity for devices behind a NAT router. Any peer to peer network
 application such as games, IM, etc. can benefit from a NAT router supporting
 UPnP and/or NAT-PMP. For example the latest generation Microsoft XBOX 360 and
 Sony Playstation 3 game machines use UPnP commands to enable the online play
 with the XBOX Live service and the Playstation Network. It has been reported
 that MiniUPnPd is correctly working with the two consoles.

Note that I've been waiting quite a while until it's finally possible to
package this software. Recent inclusion of (now embedded) kernel headers
for iptables, which are still not packaged in Debian, in the upstream
sources, makes it possible to finally compile this software in Debian,
while this has been possible for years in other distributions. I don't
want to relaunch a controverse, so please do not start a troll here,
but I'd still prefer if these were in iptables-dev. It seems there's
no choice, so I agree with upstream decision.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120202231531.2232.28687.report...@buzig.gplhost.com

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Josselin Mouette]

Le jeudi 02 février 2012 à 18:59 +0100, Andreas Tille a écrit : 
> On Thu, Feb 02, 2012 at 04:52:22PM +0100, Josselin Mouette wrote:
> > > However, to prove your point you need to mention counter examples which
> > > are actually failing to use mime-support or are actually broken because
> > > of using mime-support.
> > 
> > Are you trying to troll, or do you actually not know anything of the
> > topic you are talking about?
> 
> I'm probably a troll to consider answering messages like this, but in
> the paragraph above I was talking about logic and how to prove some
> statement.  At least when I was young I was winning some mathematics
> contests where those knowledge was a precondition.  So I'd like to
> answer at lest the second part with "I know a bit about this".

I’m very happy to read about that, but this is not a mathematics
contest.

> Could you please now come back to the topic

So I understand your answer to my question is the second option.

This is the MIME system most programs in Debian, including anything
related to GNOME, KDE, Xfce and certainly more (Firefox and rox come to
mind), are using nowadays:
http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html
And the standard for application associations:
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

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


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

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Russ Allbery]

Ian Jackson  writes:
> Pierre Joye writes:

>> [...] But so far I failed to see other features in Suhosin that we need
>> to implement without having more cons than pros.

> I know nearly nothing about PHP security and nothing about Suhosin.

> But from what I have read in this thread, I find this kind of argument
> very unconvincing.  Surely the time to drop something like Suhosin would
> be when PHP stops actually having bugs which are mitigated by Suhosin.
> Not when the PHP project claims to have improved its processes so that
> these bugs won't occur any more.

> The decision should be based on the existence or not of the
> vulnerabilities, and whether Suhosin in actual fact helps.

Well, from the Debian perspective, it also needs to be based on the
maintainability of the patch and on the benefit versus complexity
tradeoff.

For example, Debian could immediately become a much more secure OS by
enabling SELinux in enforcing mode on all Debian systems.  The reason why
we don't do this is that currently that tradeoff doesn't make sense; too
much other stuff doesn't work, too much other effort is required, and
we're not in a position to enforce that technology, even if it would
increase security.

I think the maintainers need to make a judgement call about whether the
problems and additional work required to maintain packages with the patch
integrated, for both the Debian maintainers and the PHP user community on
Debian, is justified by the benefits provided by the patch.

-- 
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: http://lists.debian.org/87fwesq0jz@windlord.stanford.edu

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Josselin Mouette]

Le jeudi 02 février 2012 à 19:11 +, brian m. carlson a écrit : 
> The mime-support solution is part of Policy.  It is a perfectly working,
> fully-implemented solution.  

This is a blatant lack of knowledge of the current state of the
distribution.

> If you feel that it is obsolescent or
> obsolete and should be replaced by a different solution, then it's your
> job to convince other people of that, do the work to make that happen,
> and request that Policy be amended accordingly.  I have yet to see a bug
> filed on the debian-policy package requesting that.

This system has *already* been replaced by a different solution. That
horse was already dead several years ago. Get a grip. Fix the policy if
you want to spend time on the problem.

> As it is, evince does not display PDFs from mutt.  Thus your solution is
> inadequate, because mutt does not use your solution (and there is no bug
> filed against mutt to do so).  You have thus broken an otherwise
> perfectly working solution because you don't like it.

As it is, programs registered in mime-support are not used from firefox,
evolution, epiphany, nautilus, rox-filer and konqueror. Thus your
solution is inadequate, because these programs do not use your solution
(there is no bug filed against them to do so, and if there was, we would
have a good laugh and close it).

> As a package maintainer, you're going to have to support some things you
> don't like.

Maybe you want to maintain all these programs instead of their
respective maintainers, and replace a modern MIME system with decent
support for aliases, subtypes, defaults by a system that requires you to
write overly long files in an obscure language - but that works with
mutt.

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


signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Russell Coker]

On Fri, 3 Feb 2012, Russ Allbery  wrote:
> For example, Debian could immediately become a much more secure OS by
> enabling SELinux in enforcing mode on all Debian systems.  The reason why
> we don't do this is that currently that tradeoff doesn't make sense; too
> much other stuff doesn't work, too much other effort is required, and
> we're not in a position to enforce that technology, even if it would
> increase security.

SE Linux is supported in critical packages including the kernel, sysvinit, and 
cron.  So any user who wants to use it can just install the SE Linux specific 
packages and rely on the built-in support for SE Linux in important base 
packages.

This compares to the PHP/Suhosin situation where users who want that have no 
option other than to download the source and the Suhosin patch and build their 
own packages.

For the analogy you want to make a better option would be GR Security which is 
not supported in the Debian kernel and won't be supported in the forseeable 
future.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202031046.00230.russ...@coker.com.au

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Russ Allbery]

Russell Coker  writes:

> SE Linux is supported in critical packages including the kernel,
> sysvinit, and cron.  So any user who wants to use it can just install
> the SE Linux specific packages and rely on the built-in support for SE
> Linux in important base packages.

> This compares to the PHP/Suhosin situation where users who want that
> have no option other than to download the source and the Suhosin patch
> and build their own packages.

> For the analogy you want to make a better option would be GR Security
> which is not supported in the Debian kernel and won't be supported in
> the forseeable future.

Good point, thank you.  That's a better analogy.

-- 
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: http://lists.debian.org/87wr84ol0r@windlord.stanford.edu

Re: Bug#605090: Linux 3.2 in wheezy

[Christoph Anton Mitterer]

On Thu, 2012-02-02 at 12:18 +1100, Russell Coker wrote:
> The current approach of having a kernel patch package seems to work well.
Phew... well there are many people running at >stable... and for
them it does not... as the package seems more or less orphaned.

Also,.. configuring something complex like grsec is probably nothing for
the end-user who, however, should have also an easy way to benefit from
it.


> It 
> removes the need for involvement of the kernel and security teams (presumably 
> security changes to the kernel will usually not require changes to the 
> grsecurity patch) and allows the users to easily build their own kernels.
Well, even though it means [much] work for them,... wouldn't that
involvement be just the good thing? Having some real experts, looking
after everything?!


> Spender suggested that people who want GRSecurity on Debian would be better 
> off using a .deb he provides and working on user-space hardening.
Well IMHO, at best, one should never need to rund anything from outside
the Debian archives ;)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#605090: Linux 3.2 in wheezy

[Ben Hutchings]

On Fri, Feb 03, 2012 at 12:55:59AM +0100, Christoph Anton Mitterer wrote:
> On Thu, 2012-02-02 at 12:18 +1100, Russell Coker wrote:
> > The current approach of having a kernel patch package seems to work well.
> Phew... well there are many people running at >stable... and for
> them it does not... as the package seems more or less orphaned.
> 
> Also,.. configuring something complex like grsec is probably nothing for
> the end-user who, however, should have also an easy way to benefit from
> it.

There is an easy way to benefit from it.  Download and build an
official release.  I assume 'make deb-pkg' works like in mainline
Linux.

> > It 
> > removes the need for involvement of the kernel and security teams 
> > (presumably 
> > security changes to the kernel will usually not require changes to the 
> > grsecurity patch) and allows the users to easily build their own kernels.
> Well, even though it means [much] work for them,... wouldn't that
> involvement be just the good thing? Having some real experts, looking
> after everything?!

You flatter us.  General experience with kernel development does not
make someone an expert that is capable of understanding all the
implications of rebasing a patch or patch set that modifies many core
kernel features.

> > Spender suggested that people who want GRSecurity on Debian would be better 
> > off using a .deb he provides and working on user-space hardening.
> Well IMHO, at best, one should never need to rund anything from outside
> the Debian archives ;)

Wishing it so doesn't make it practically possible.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120203003410.gx12...@decadent.org.uk

Re: Suhosin patch disabled by default in Debian php5 builds

[Christoph Anton Mitterer]

Hey.

First, thanks Ondřej, for bringing this to a wider audience :)




On Thu, 2012-02-02 at 13:55 +0100, Ondřej Surý wrote:
> 1. Suhosin patch has an impact on the speed and memory usage. This has
> been documented and even author admits it [1].
> 
> 2. It doesn't help our users when reporting bugs to upstream - the
> usual answer is - try if that happens with vanilla php.
>
> 5. Keeping our code close to upstream and to other linux distros
> (Fedora - no, Suse - optional) is a way how to provide our users with
> consistent behaviour across the Linux ecosystem.


I guess these three could be solved by my suggestion of having separate
packages with and without the suhosin core patched applied.
In case of (1), people can just choose. This is just what Stas Malyshev
talked about. Some people may depend on speed/memory... some absolutely
not (just take my little DAViCal server which is responsible for #657698
and this discussion ;) ).

In case of (2), one can ask them to reproduce it first with the
non-suhosin package.


> 3. Stefan's relationships with PHP upstream (and vice versa)[1] isn't
> helping very much - and I think we (pkg-php) have improved our
> relationship with upstream in past few years a lot.

I don't know any details here, but as long as his patched work well on
the vanilla source,... it shouldn't be a major issue for Debian, right?



I agree with Stefan, that having such guards is a good thing. This is to
some extent why things like grsceurity, PaX, and similar exist. There
always was need for them,.. and I guess there allways will be.
Just saying "there were only few security holes recently" is not an
argument. An argument would be "most/all features of suhosin are now
integrated or handled similarly in PHP anyway".
I think that also his argument of the advantage of having such a patch
external is not to stupid,... of course it makes problems in other
corners.

Btw: Stefan, while I understand that you may feel offended that suhosin
it dropped/attacked/criticised, I guess it doesn't help that you use
unfriendly words.
And the same applies to those who did vice versa (to Stefan).


On Thu, 2012-02-02 at 15:26 -0800, Russ Allbery wrote:
> For example, Debian could immediately become a much more secure OS
> by enabling SELinux in enforcing mode on all Debian systems.
> The reason why we don't do this is that currently that tradeoff
> doesn't make sense; too much other stuff doesn't work, too much
> other effort is required, and we're not in a position to enforce
> that technology, even if it would increase security.

I don't want to open a discussion about whether SELinux or some other
framwork is THE answer ;-) but I always had the impression that the
blocker here was rather that there is (which is also a good think) no
single dictator in Debian who can really say: All maintainers, listen
up, go an support SELinux in your packages.
(Which RedHat can do).

Apart from that, I fully agree with your arguments.


The reasons why I've opened #657698 was just, because I though it could
be possible for the PHP maintainers to reduce their burden, by just
offering both, packages with suhosin and without.
If there are bugs in the with suhosin version, they can either redirect
people to upstream, or the no suhosin version or even (if time is
available) try to help.

I have however still not understood, whether one would need to compile
the extensions for both versions, Stefan?!




On Fri, 2012-02-03 at 10:45 +1100, Russell Coker wrote:
> SE Linux is supported in critical packages including the kernel,
> sysvinit, and cron.  So any user who wants to use it can just
> install the SE Linux specific packages and rely on the built-in
> support for SE Linux in important base packages.
> This compares to the PHP/Suhosin situation where users who want that
> have no option other than to download the source and the Suhosin
> patch and build their own packages.

Phew,.. but is it really a good idea to let this be done by innocent
end-users?! I mean this IS just why the critical packages support
SELinux and don't require the the users to do it themselves.
Analogously, this applies to the PHP core packages, IMHO.




On Fri, 2012-02-03 at 04:11 +0800, Thomas Goirand wrote:
> Something I don't get here. If there's this issue, and
> different tastes, why can't a build flag be used, so
> that you can choose security or speed depending on your
> needs? If you do some:
> 
> #ifdef ENABLE_SLOWER_SUHOSIN_SECURITY
> 
> in the controversial parts, then I don't see how this
> would be of trouble for anyone to have Suhosin included
> in upstream PHP.
Absolutely +1 ;-)

But this wouldn't solve our discussion here... the question would still
be open, whether Debian sets this flag or not, or whether it makes two
binary packages.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Work-needing packages report for Feb 3, 2012

[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: 395 (new: 1)
Total number of packages offered up for adoption: 150 (new: 0)
Total number of packages requested help for: 59 (new: 0)

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



The following packages have been orphaned:

   prelink (#657967), orphaned 3 days ago
 Description: ELF prelinking utility to speed up dynamic linking
 Reverse Depends: prelink
 Installations reported by Popcon: 1895

394 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 150 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#646208), requested 103 days ago
 Description: Apache HTTP Server
 Reverse Depends: aegis-web apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (178 more
   omitted)
 Installations reported by Popcon: 60734

   apt-xapian-index (#567955), requested 731 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: adept ept-cache fuss-launcher packagesearch
 Installations reported by Popcon: 51120

   asymptote (#517342), requested 1070 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 2993

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

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

   bastille (#592137), requested 544 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 252

   boinc (#511243), requested 1120 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc boinc-amd-opencl boinc-app-milkyway
   boinc-app-seti boinc-dbg boinc-nvidia-cuda
 Installations reported by Popcon: 1868

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

   chromium-browser (#583826), requested 613 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-browser chromium-browser-dbg
   chromium-browser-inspector chromium-browser-l10n chromium-dbg
   chromium-l10n mozplugger
 Installations reported by Popcon: 9876

   cryptsetup (#600777), requested 470 days ago
 Description: configures encrypted block devices
 Reverse Depends: cryptsetup cryptsetup-udeb libcryptsetup-dev
   libguestfs0 libpam-mount ltsp-client mandos-client partman-crypto-dm
   rescue-mode systemd
 Installations reported by Popcon: 7390

   cvs (#354176), requested 2170 days ago
 Description: Concurrent Versions System
 Reverse Depends: cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html
   cvschangelogbuilder cvsconnect cvsd cvsps cvsservice cvssuck (8 more
   omitted)
 Installations reported by Popcon: 17682

   dctrl-tools (#448284), requested 1559 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies debtree dlocate
   haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo
   postgresql-server-dev-all simple-cdd (1 more omitted)
 Installations reported by Popcon: 14892

   debtags (#567954), requested 731 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2578

   doc-central (#566364), requested 740 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 217

   dpkg (#282283), requested 2629 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: a2ps acct ace-gperf acl2-doc
   ada-reference-manual-info adacontrol advi advi-examples alien
   alqalam (709 more omitted)
 Installations reported by Popcon: 120662

   elvis (#432298), requested 1669 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon:

Re: Bug#605090: Linux 3.2 in wheezy

[Christoph Anton Mitterer]

On Fri, 2012-02-03 at 00:34 +, Ben Hutchings wrote:
> There is an easy way to benefit from it.
Well still the user wouldn't know how to configure it...
Actually I must admit that I haven't followed PaX/grsec now for some
time (mainly due to the deb package being always out of date in sid).

Wasn't it once the case with PaX that packages have to be compiled
specially? Or some ELF headers added or so?
And there were no execute features which are perhaps superseded to some
extent (now that AMD64 has NX bit)...
So what I mean in the end,... I'm surely not an expert with respect to
the kernel, but at least I used to have my own .config since years,..
still it would mean quite some effort for me to get PaX/grsec running in
a way that I for myself believe I've done it right.
And this does not include tracing problems (I _very_ vaguely remember
that one had to make exceptions e.g. for Java?)

And that's why I think that such "special" frameworks like PaX/grsec,
SElinux, Apparmor, Smack, etc. pp. make only sense if well supported by
the distro, at least for some (blind guess:) 80-90% of all potential
users.



> You flatter us.  General experience with kernel development does not
> make someone an expert that is capable of understanding all the
> implications of rebasing a patch or patch set that modifies many core
> kernel features.
Well come on Ben,.. you've already helped me so often with issues with
the kernel,... you guys have at least some very good overview on
everything!


> > Well IMHO, at best, one should never need to rund anything from outside
> > the Debian archives ;)
> Wishing it so doesn't make it practically possible.
Well.. so far I do :D


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Work-needing packages report for Feb 3, 2012

[Jerome BENOIT]

Hello Lists:

May I add that there are also packages waiting for a sponsor for uploading ?

Cheers,
Jerome

On 03/02/12 01:26, w...@debian.org wrote:

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: 395 (new: 1)
Total number of packages offered up for adoption: 150 (new: 0)
Total number of packages requested help for: 59 (new: 0)

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



The following packages have been orphaned:

prelink (#657967), orphaned 3 days ago
  Description: ELF prelinking utility to speed up dynamic linking
  Reverse Depends: prelink
  Installations reported by Popcon: 1895

394 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 150 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

apache2 (#646208), requested 103 days ago
  Description: Apache HTTP Server
  Reverse Depends: aegis-web apache2 apache2-dbg apache2-mpm-event
apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
apache2-prefork-dev apache2-suexec apache2-suexec-custom (178 more
omitted)
  Installations reported by Popcon: 60734

apt-xapian-index (#567955), requested 731 days ago
  Description: maintenance tools for a Xapian index of Debian packages
  Reverse Depends: adept ept-cache fuss-launcher packagesearch
  Installations reported by Popcon: 51120

asymptote (#517342), requested 1070 days ago
  Description: script-based vector graphics language inspired by
MetaPost
  Installations reported by Popcon: 2993

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

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

bastille (#592137), requested 544 days ago
  Description: Security hardening tool
  Installations reported by Popcon: 252

boinc (#511243), requested 1120 days ago
  Description: BOINC distributed computing
  Reverse Depends: boinc boinc-amd-opencl boinc-app-milkyway
boinc-app-seti boinc-dbg boinc-nvidia-cuda
  Installations reported by Popcon: 1868

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

chromium-browser (#583826), requested 613 days ago
  Description: Chromium browser
  Reverse Depends: chromium chromium-browser chromium-browser-dbg
chromium-browser-inspector chromium-browser-l10n chromium-dbg
chromium-l10n mozplugger
  Installations reported by Popcon: 9876

cryptsetup (#600777), requested 470 days ago
  Description: configures encrypted block devices
  Reverse Depends: cryptsetup cryptsetup-udeb libcryptsetup-dev
libguestfs0 libpam-mount ltsp-client mandos-client partman-crypto-dm
rescue-mode systemd
  Installations reported by Popcon: 7390

cvs (#354176), requested 2170 days ago
  Description: Concurrent Versions System
  Reverse Depends: cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html
cvschangelogbuilder cvsconnect cvsd cvsps cvsservice cvssuck (8 more
omitted)
  Installations reported by Popcon: 17682

dctrl-tools (#448284), requested 1559 days ago
  Description: Command-line tools to process Debian package
information
  Reverse Depends: aptfs debian-goodies debtree dlocate
haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo
postgresql-server-dev-all simple-cdd (1 more omitted)
  Installations reported by Popcon: 14892

debtags (#567954), requested 731 days ago
  Description: Enables support for package tags
  Reverse Depends: goplay packagesearch
  Installations reported by Popcon: 2578

doc-central (#566364), requested 740 days ago
  Description: web-based documentation browser
  Installations reported by Popcon: 217

dpkg (#282283), requested 2629 days ago
  Description: dselect: a user tool to manage Debian packages
  Reverse Depends: a2ps acct ace-gperf acl2-doc
ada-reference-manual-info adacontrol advi advi-examples alien
alqalam (709 more omitted)
  Installations reported by Popcon: 

Re: Bug#605090: Linux 3.2 in wheezy

[Russell Coker]

On Fri, 3 Feb 2012, Christoph Anton Mitterer  wrote:
> Wasn't it once the case with PaX that packages have to be compiled
> specially? Or some ELF headers added or so?

Some shared libraries have code which can't be run without an executable 
stack, it's a small number of libraries that are written in assembler code.  
We want to allow running them but don't want to give all programs permission 
to execute code on the stack.

From memory the GR Security option for this was to flag the rare executables 
that want an executable stack and are permitted to have it.

The solution devised by libc/gcc upstream was to have a special assembly 
section in every shared object that doesn't require an executable stack and if 
an executable only loads shared objects that don't require it then the 
executable stack is disabled.  Then we have SE Linux policy to prevent most 
programs from having an executable stack which means that if they are tricked 
into loading some of the rare libraries that need it then it doesn't do 
anything bad.

The downside to the latter approach is that lots of shared objects which have 
some assembler code needed to be patched.

The PaX approach involved less work.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202031215.27866.russ...@coker.com.au

Team maintaining miniupnp: a set of 4 packages to manage IGD protocols

[Thomas Goirand]

Hi,

I'm currently maintaining alone the following source packages:
libnatpmp, minissdpd, miniupnpc and miniupnpd

For that last one, I've just sent an ITP, since it finally becomes
possible to build it in Debian (and the packaging is already done,
sitting in my public_git on Alioth). MiniUPnPd is already used in many
embedded devices like OpenWRT, and in some major ISP ADSL boxes (I wont
write names, but for example, the 2nd and 3rd largest ISP in France runs
it).

The miniupnpc is a nice library that may be use by many games, and is
already used by some software in the archive, like warzone2100,
transmission, and bitcoind. Both minissdpd and miniupnpc are quite high
already in popcon, with more than 8000 users, which also is pushing me
to ask for other sets of eyes to look into my packaging. The miniupnpc
client library would need a transition to reach testing the correct way
(because of a tiny change in the API, the package is already in
Experimental), and I have no experience with that, help would be
appreciated.

I found that team maintaining is cool, and I'd like to know if others
would like to join my effort to keep all the MiniUPnP software into
shape in Debian. It wouldn't be much work, just the usual work to keep
the packages updated with what upstream releases.

Note that upstream (Thomas Bernard) is a very good friend of mine, and
is both a cool guy and very responsive.

So if you wish to join the maintenance effort for MiniUPnPd, please get
in touch, and we'll build a (new) Alioth project.

Cheers,

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: http://lists.debian.org/4f2b35d3.80...@debian.org

Bug#658449: ITP: gcin -- GTK+ based input method platform for Chinese users

[魏銘廷]

Package: wnpp
Severity: wishlist
Owner: "Yao Wei (魏銘廷)" 

* Package name: gcin
  Version : 2.7.1
  Upstream Author : Edward Der-Hua Liu 
* URL : http://hyperrate.com/dir.php?eid=67
* License : LGPL2
  Programming Lang: C
  Description : GTK+ based input method platform for Chinese users

This package was removed since #652508. This IME is widely used by
Taiwan users despite of low popcon. There are also some local
distributions rely on this package such as EzGo.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120203043953.896.29739.reportbug@homura

Re: Versionned dependencies

[Josh Triplett]

Tanguy Ortolo wrote:
> Packages can currenctly declared dependencies on specific versions of
> other packages, with simple relations: <<, <=, =, >= and >>. For
> instance:
> Package: xul-ext-adblock-plus
> Depends: iceweasel (>= 3.6.13) | iceape (>= 2.1) | …
> 
> While this is sufficient for most cases, it does not cover one
> interesting case: a dependencies on a range of versions. For instance:
> Package: xul-ext-adblock-plus
> Depends: iceweasel (>= 3.6.13, << 12.0~a1+) | iceape (>= 2.1, << 2.9~a1+) 
> | …

In the particular case of iceweasel, the "compatible by default" change
(in upstream version 10) should help in the future for many addons.


More generally, it would help greatly to have one level of grouping in
dependencies:

Package: xul-ext-adblock-plus
Depends: (iceweasel (>= 3.6.13), iceweasel (<< 12.0~)) | (iceape ...

This would also help in various other cases:

Depends: some-package (<< 1~split) | (some-package (>= 1~split), 
some-package-important-piece)

I currently have some personal metapackages which work on a wide range
of package versions; they often have to write things like this (which I
just realized I can drop since I no longer care about pre-squeeze
systems):
Depends:
 printer-driver-hpcups | hplip-cups | hplip,
 printer-driver-hpcups | hplip-cups | hpijs-ppds,

I'd much rather write that as:

Depends: printer-driver-hpcups | hplip-cups | (hplip, hpijs-ppds)

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120203044407.GA12793@leaf

Re: [PHP-DEV] Re: Suhosin patch disabled by default in Debian php5 builds

[Florian Anderiasch]

On 02/03/2012 01:28 AM, Christoph Anton Mitterer wrote:
> But this wouldn't solve our discussion here... the question would
> still be open, whether Debian sets this flag or not, or whether it
> makes two binary packages.

Now that's something I didn't read from Ondřej's mail, but delivering
the packages with and without suhosin would, while being more work,
certainly the most helpful way for users. Then again I'd gladly help if
there's anything of this additional work that can be done.

I'd prefer to have Debian's default php5 package with Suhosin as usual,
but I'm hardly the one making demands or suggestions here.

I'm with Soenke (different mail in this thread) - better keep the
securest-possible package by default. When I need performance, I'm
rolling my own php anyway - no matter what base system or package format.

Greetings,
Florian


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f2b7cfd.4050...@anderiasch.de

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Mike Hommey]

On Fri, Feb 03, 2012 at 12:27:40AM +0100, Josselin Mouette wrote:
> Le jeudi 02 février 2012 à 19:11 +, brian m. carlson a écrit : 
> > The mime-support solution is part of Policy.  It is a perfectly working,
> > fully-implemented solution.  
> 
> This is a blatant lack of knowledge of the current state of the
> distribution.
> 
> > If you feel that it is obsolescent or
> > obsolete and should be replaced by a different solution, then it's your
> > job to convince other people of that, do the work to make that happen,
> > and request that Policy be amended accordingly.  I have yet to see a bug
> > filed on the debian-policy package requesting that.
> 
> This system has *already* been replaced by a different solution. That
> horse was already dead several years ago. Get a grip. Fix the policy if
> you want to spend time on the problem.
> 
> > As it is, evince does not display PDFs from mutt.  Thus your solution is
> > inadequate, because mutt does not use your solution (and there is no bug
> > filed against mutt to do so).  You have thus broken an otherwise
> > perfectly working solution because you don't like it.
> 
> As it is, programs registered in mime-support are not used from firefox,
> evolution, epiphany, nautilus, rox-filer and konqueror. Thus your
> solution is inadequate, because these programs do not use your solution
> (there is no bug filed against them to do so, and if there was, we would
> have a good laugh and close it).

Firefox does, and if it doesn't, it's a bug to be filed. It lacks
support for some keywords, though.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120203062324.ga20...@glandium.org

Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts

[Josh Triplett]

Lars Wirzenius wrote:
> On Thu, Feb 02, 2012 at 05:09:42PM +, PICCA Frédéric-Emmanuel wrote:
> > In that case you got his kind of piuparts error [1], if you did not
> > remove the homedir of the previously added user.
> > 
> > What is the right fice for this ?
> 
> The proper way to fix this is to change piuparts to not complain
> about home directories that belong to system users created during
> the package install.

Almost all system users should use a non-existent home directory, which
solves the problem for those users.  And in cases like the one linked to
from footnote [1] above, I think rm -rf on purge seems like the right
solution, even if the user/group itself sticks around.  Most of the time
packages shouldn't leave data around when purged, even if they leave
users around just in case something else uses the UID.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120203072301.GA15817@leaf