Re: Bits from the Security Team

[Moritz Muehlenhoff]

On Thu, Mar 06, 2014 at 05:33:42AM +0100, Matthias Klose wrote:
> Am 06.03.2014 02:00, schrieb Paul Wise:
> >> * The distribution hardening using dpkg-buildflags is coming along
> >>   nicely.
> > 
> > Unfortunately this doesn't apply to binaries compiled outside of the
> > package building system. It would be great if we could adopt the
> > Ubuntu approach of just enabling the flags in GCC itself. Even better
> > would be to get GCC upstream to finally enable them by default.
> 
> This should not be enabled in the distro itself, and if, then not before it 
> can
> be enabled upstream.  From my point of view it was a mistake to enable it this
> way before getting this upstream.  However it is a lot of work to get the
> compiler to build itself with these flags and the testsuite produce the same
> results as without these.  In the past neither the Ubuntu security team nor 
> the
> Google ChromeOS team had time and resources to bring these patches upstream.

I agree we should stick with dpkg-buildflags until this is fixed upstream.
Gentoo Hardened tried to upstream this a year ago, but apparently this didn't 
make 
the cut yet:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00473.html

As for the GSoC project; GCC partiticates, if anyone wants to push this, I 
suggest
to talk to GCC developers and see whether there's a mentor available.

Cheers,
Moritz


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

Bug#741011: ITP: getdns -- modern asynchronous DNS API

[Ondřej Surý]

Package: wnpp
Severity: wishlist
Owner: "Ondřej Surý" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: getdns
  Version : 0.1.0
  Upstream Author : NLnet Labs, Verisign Labs and No Mountain Software
* URL : http://getdnsapi.net
* License : BSD
  Programming Lang: C
  Description : modern asynchronous DNS API

 getdns is a modern asynchronous DNS API.  It implements DNS entry
 points from a design developed and vetted by application developers,
 in an API specification edited by Paul Hoffman.  With the development
 of this API, we intend to offer application developers a modernized
 and flexible way to access DNS security (DNSSEC) and other powerful
 new DNS features; a particular hope is to inspire application
 developers towards innovative security solutions in their
 applications.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlMZqZIACgkQ9OZqfMIN8nMbFgCdFJ66ylapZoa5AXqVnCJ3QqRZ
OAgAn2SC1zNOAa8+HcrzmrDV1UuV4G92
=Q9ZB
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140307111221.31946.7927.report...@howl.nic.cz

Re: Bits from the Security Team

[Stephan Seitz]

On Thu, Mar 06, 2014 at 12:21:06PM +1100, Craig Small wrote:

On Thu, Mar 06, 2014 at 12:54:00AM +0100, Vincent Danjean wrote:

  I'm not sure I will let this setup (hidepid=1) on my computers. My
current POV (that can change) is that I prefer to be able to do the
maximum of thing as a normal user (top, ps, read log (I'm in the
adm group), ...) ans switch to root when I really need to do some
modifications.

You apparently can have a "special" group that can see everything.


Aren’t there PAM modules which can grant capabilities to certain users?


That might be worthwhile for a default.
It makes things like pstree look odd, so I'll be expecting some new bug
reports.


It will break software like nagios with check_procs. Any ideas how one 
can solve this? dpkg-stateoverwrite doesn’t support capabilities, only 
the standard chmod commands.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Bits from the Security Team

[Stephan Seitz]

On Thu, Mar 06, 2014 at 04:32:34PM +0100, Guido Günther wrote:

Luckily this is not the case. :) root can see other users' /proc
entries just fine. Perhaps the documentation should be improved.

I should have checked the code first. If I read that correctly
CAP_SYS_PTRACE is necessary here. I've forwarded a patch upstream.


I did a „setcap cap_sys_ptrace+eip /usr/lib/nagios/plugins/check_procs”, 
but a normal user can’t still check for running programs of another user.


What did I wrong?

Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Bits from the Security Team

[Matthias Urlichs]

Hi,

Stephan Seitz:
> I did a „setcap cap_sys_ptrace+eip
> /usr/lib/nagios/plugins/check_procs”, but a normal user can’t still
> check for running programs of another user.
> 
> What did I wrong?
> 
check_procs is a script, not a "real" executable.

Since starting an interpreter with capabilities (or setuid, for that
matter) of a script involves a race condition (kernel starts interpreter
with script's rights, Joe Badass replaces the script with something
nefarious, interpreter gets around to opening script) this is a good
thing.

So you need a small C helper program here. Or not so small -- Apache's
suexec is a good example of almost-all of the things which can go wrong.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Bits from the Security Team

[Stephan Seitz]

On Fri, Mar 07, 2014 at 02:51:41PM +0100, Matthias Urlichs wrote:

I did a „setcap cap_sys_ptrace+eip
/usr/lib/nagios/plugins/check_procs”, but a normal user can’t still
check for running programs of another user.
What did I wrong?

check_procs is a script, not a "real" executable.


Wrong.
[stse@osgiliath]: file /usr/lib/nagios/plugins/check_procs
/usr/lib/nagios/plugins/check_procs: ELF 64-bit LSB shared object…

If I do a „chmod u+s check_procs” it works. But I think capabilities are 
a safer solution than s-bit.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


signature.asc
Description: Digital signature

Re: Bits from the Security Team

[Vincent Danjean]

On 05/03/2014 22:33, Jakub Wilk wrote:
> hidepid=1 means users may not access any /proc// directories but their 
> own.

Even that is strange. I just tried. Processus that are not mine
are not shown anymore by ps, but even some of mine disappeared! (mostly
urxvt ones)

See this example (the [] in the grep command are here to avoid to find
the grep command itself):

$ ps axfu | grep 321[6]1
vdanjean 32161  0.0  0.0 104796  2244 ?Sfévr.24   0:01 
/usr/bin/urxvt
$ sudo mount -o remount,hidepid=1 /proc
$ ps axfu | grep 321[6]1
$ sudo mount -o remount,hidepid=0 /proc
$ ps axfu | grep 321[6]1
vdanjean 32161  0.0  0.0 104796  2244 ?Sfévr.24   0:01 
/usr/bin/urxvt
$ logname
vdanjean
$ sudo mount -o remount,hidepid=2 /proc
$ ps axfu | grep 321[6]1
$ sudo ps axfu | grep 321[6]1
vdanjean 32161  0.0  0.0 104796  2244 ?Sfévr.24   0:01 
/usr/bin/urxvt
$ sudo mount -o remount,hidepid=1 /proc
$ sudo ps axfu | grep 321[6]1
vdanjean 32161  0.0  0.0 104796  2244 ?Sfévr.24   0:01 
/usr/bin/urxvt
# ==> root still see my processus
$ ps axfu | grep 321[6]1
$ ls /proc/32161/
ls: impossible d'ouvrir le répertoire /proc/32161/: Opération non permise
$ ls -ld /proc/32161
dr-xr-xr-x 9 vdanjean vdanjean 0 mars   7 15:33 /proc/32161
$

  Why can't I see my own urxvt processus ?

  Regards,
Vincent


-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5319daa6.3040...@free.fr

Bug#741022: RFA: kupfer -- fast and lightweight desktop summoner/launcher

[Luca Falavigna]

Package: wnpp
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org


I request an adopter for kupfer source package.
It should be in a decent state, upstream is not very active lately,
but he's always been very responsive.

Package is maintained under Python Application Team umbrella, bonus
points if perspective adopters are willing to maintain it there.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CADk7b0Prei-wM2gSJ=xbfeyx2eb1trbqjdc_cl8h6pex8g4...@mail.gmail.com

Bug#741021: RFA: keybinder -- registers global key bindings for applications

[Luca Falavigna]

Package: wnpp
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org


I request an adopter for keybinder source package.
It should be in a decent state, upstream is not very active lately,
but he's always been very responsive.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cadk7b0m5ghmjoo7djpb9a9n9fdk-h5tnno7pabyiba-xhfg...@mail.gmail.com

Bug#741028: ITP: capstone -- lightweight multi-platform, multi-architecture disassembly framework

[David Martínez Moreno]

Package: wnpp
Severity: wishlist
Owner: "David Martínez Moreno" 

* Package name: capstone
  Version : 2.1
  Upstream Author : Nguyen Anh Quynh 
* URL : http://www.capstone-engine.org/
* License : BSD
  Programming Lang: C, Java, Python
  Description : lightweight multi-platform, multi-architecture disassembly 
framework

 Capstone is a lightweight multi-platform, multi-architecture disassembly 
framework.
 
 Features:
 - Support hardware architectures: ARM, ARM64 (aka ARMv8), Mips, PowerPC & 
Intel.
 - Clean/simple/lightweight/intuitive architecture-neutral API.
 - Provide details on disassembled instruction (called "decomposer" by some
 others).
 - Provide some semantics of the disassembled instruction, such as list of
 implicit registers read & written.
 - Implemented in pure C language, with bindings for Python, Ruby, C#, Java, GO,
 OCaml & Vala available.
 - Native support for Windows & *nix (with Mac OSX, Linux, *BSD & Solaris 
confirmed).
 - Thread-safe by design.
 - Special support for embedding into firmware or OS kernel.

This package is being maintained in collab-maint:
   http://git.debian.org/?p=collab-maint/capstone.git;a=summary


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140307163353.22985.13778.report...@belgarath.thefacebook.com

Bug#741029: ITP: redo -- a top-down software build system

[Nils Dagsson Moskopp]

Package: wnpp
Severity: wishlist
Owner: Nils Dagsson Moskopp  

* Package name: redo
  Version : 0.0.1
  Upstream Author : Nils Dagsson Moskopp 
* URL : http://news.dieweltistgarnichtso.net/bin/
* License : AGPLv3+
  Programming Lang: Bourne shell
  Description : a top-down software build system

redo is a software build system envisioned by Daniel J. Bernstein, which is 
simultaneously smaller, faster, more powerful and less complex than make. 
Build scripts are shell scripts, but can be written in almost any language.



This implementation of redo is simpler and faster than the redo implementation 
by Avery Pennarun. While Pennarun's version of redo is written in Python, this 
version of redo depends only on the Bourne shell and standard utilities 
provided by the GNU coreutils or Busybox packages.

Caveat: This version of redo is missing the redo-ifcreate command, which 
creates dependencies on files not yet existing. Adding it should be simple.

As I am the upstream author, I maintain this version of redo. I expert 
maintenance effort to be low, as the software is essentially finished.

I probably need a sponsor for uploading the package.


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

Bug#741030: ITP: zsh-antigen -- manage your zsh plugins

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: zsh-antigen
  Version : 1
  Upstream Author : Shrikant Sharat Kandula 
* URL : https://github.com/zsh-users/antigen
* License : Expat
  Programming Lang: ZSH
  Description : manage your zsh plugins

Antigen is a small set of functions that help you easily manage your shell
(zsh) plugins, called bundles. The concept is pretty much the same as bundles
in a typical vim+pathogen setup. Antigen is to zsh, what Vundle is to vim.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJTGf3iAAoJEGlMre9Rx7W2ocAP/1g8xp6vTct7jPfl7fPvJGwD
37oKKqMxZlCbcBfJD4jTiBpW0mkLK3Vxm8VGC3x5bSHmTLIenFTsqFoy7KNPLRTd
+VjWDDIzA+x0ib1SiqLjmcBnNsZPJhqAMxL9jyOf2yZyzvmXZjdTyszX9phtortS
zhmIQbfiCjhtLzKaxzCY6hKkcx471PxVq7eBJNN+qv3dHGjhV3nAWX1d6neSflKf
yC3Mo85skZCDd2+CgP3/SUMXOJ/oNltwbc87/1Hv+mv845RKgQkimdakkt2/M11b
fdc1GvPttJet7qcdVyb32oZsOe+Puu1e3T9Yi3w3dL1YNWOSGPuO5rdULt2pN1Wi
1DHKWtUdpa8yG2ToMVft3F5W+3+0aSWC6zSrQ8bJWGhPc+Fut4A+/bP/rEU6Umk5
vat58OSQEQSVR0dXJvjpcXCnYwhr1zA2Dqw2UodHEpUS7ttujKZPNGj1C7WyxQlv
3qrOGdLkGBTFRstrsihoG04J1CnHamHmsjBJeqpf+AP/pxChHd2Uh8FQaXXYfHiq
br7UFPjNNG9aUiaWRBmPDAtZMkKe1fA9P3NRvYRufaCr9TXBthtaKnq7dSo7WIni
870EKdSsOoB8pcosz/ZG2Vwo5inomuyyd355DCVnOEWyYuN67bPiWZUY4/Qtug1f
wXZEXaC19asdrXWxTiJH
=xV/e
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140307171206.12302.76667.report...@server.home.fladi.at

Re: debian/copyright: how extensive ...

[Osamu Aoki]

Hi,

On Thu, Mar 06, 2014 at 10:29:31PM +0100, Joerg Jaspert wrote:
> On 13507 March 1977, Osamu Aoki wrote:
> > Is there any rules in place written somewhere?
> 
> If one takes it all the way to the end, then each and every file ought
> to be documented. This, however, is not realistic, especially not for
> the class of files you listed. The more people do this, the better, but
> we would have to reject 90% of all uploads if we enforce listings like this.

Good ... this seems to indicate you welcome to have them. (I was
afraid that you hate to see them.)
 
> > Also, not all files in archive come copyright/license text within the file.
> 
> Not all files CAN come with a license included in them. It is one of the
> reasons why one (upstream) should include a file with the (C)/license
> text prominently in the distribution. Than one can default to "files not
> marked especially with a license follow that one" and revisit that idea
> when there is reasonable doubt. (Say, multiple files with license text,
> having lots of source files appearently imported, ...)

Understood and that is why I glob COPYING files and include them in
debian/copyright. So this is good for me.

> > There is no DEP-5 rules on what to do.
> 
> There is no way to have a clear rule.

Sure but I needed some idea how far my script does.  Including all these
files listed is easier than excluding autogenerated permissive license
files.

Let me play a bit on autogeneration of copyright file template.  I is
lokking better now here.

Thank you.

Osamu


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

Re: Bits from the Security Team

[Jakub Wilk]

* Vincent Danjean , 2014-03-07, 15:41:
hidepid=1 means users may not access any /proc// directories but 
their own.


Even that is strange. I just tried. Processus that are not mine are not 
shown anymore by ps, but even some of mine disappeared! (mostly urxvt 
ones)


$ ls -l /usr/bin/urxvt
-rwxr-sr-x 1 root utmp 1272864 Dec 22 18:50 /usr/bin/urxvt

It's setgid, so it can't be ptraced, so it doesn't show up in /proc.

The inability to see your own setgid processes makes this feature 
unappealing. :(


--
Jakub Wilk


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

Re: Bits from the Security Team

[Jakub Wilk]

* Stephan Seitz , 2014-03-07, 15:25:

But I think capabilities are a safer solution than s-bit.


Maybe, maybe not. Many capabilities, including CAP_SYS_PTRACE, can be 
easily elevated to full root.


Adding capabilities to software that wasn't specifically designed to 
deal with them is a bad idea.


--
Jakub Wilk


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

Re: Roll call for porters of architectures in sid and testing

[Svante Signell]

On Thu, 2014-03-06 at 04:20 +0100, Guillem Jover wrote:
> Hi!
> 
> On Tue, 2013-10-01 at 00:49:17 +0200, Guillem Jover wrote:
> > I am an active porter for the following architectures and I intend
> > to continue this for the lifetime of the jessie release:
(about kfreebsd and hurd)
> > I am a DD.
> 
> Please, consider the above commitments rescinded.

Thanks a lot for your work and professional feedback. Sorry to see you
leave Debian and look forward to see you as upstream provider.

Verbatim from a mail to debian-hurd:
> I've been progressively scaling down my involvement in Debian (due to
> continued dissatisfaction with the project), and given that I've not
> been very active maintaining GNU/Hurd packages since the switch of the
> packaging to git (as I find maintaining packaging with full upstream
> sources in the same repo slightly annoying), but mostly because Samuel
> has been doing excellent work anyway so I didn't need to do
> anything :),
> I thought it would be proper to make the records match reality, so I'm
> leaving the team.

> I just removed myself from Uploaders from the gnumach and mig
> packages,
> from the web site [O] and from the debian-hurd and pkg-hurd alioth
> projects, for which I was still admin.
> 
>   [O] 
> 
> I probably will still be lurking around, and might show up in the
> upstream lists or here from time to time, though.

Amazing that no-one from Debian side have noticed you are phasing
yourself out. Well, maybe other distros can be potential new Debian
replacements. Currently I'm staying, but if something better pops up,
I'll switch faster than light (including kfreebsd and hurd of course)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1394219026.25425.52.ca...@g3620.my.own.domain

Re: Bits from the Security Team

[Kevin Chadwick]

previously on this list Matthias Urlichs contributed:

> > I did a „setcap cap_sys_ptrace+eip
> > /usr/lib/nagios/plugins/check_procs”, but a normal user can’t still
> > check for running programs of another user.
> > 
> > What did I wrong?
> >   
> check_procs is a script, not a "real" executable.
> 
> Since starting an interpreter with capabilities (or setuid, for that
> matter) of a script involves a race condition (kernel starts interpreter
> with script's rights, Joe Badass replaces the script with something

Is it writable by others than root?

I don't know the details of hidepid but the grsecurity patch has similar?
functionality and lets users see their own processes or a group see them
all.



+menu "Filesystem Protections"
+depends on GRKERNSEC
+
+config GRKERNSEC_PROC
+   bool "Proc restrictions"
+   help
+ If you say Y here, the permissions of the /proc filesystem
+ will be altered to enhance system security and privacy.  You MUST
+ choose either a user only restriction or a user and group restriction.
+ Depending upon the option you choose, you can either restrict users to
+ see only the processes they themselves run, or choose a group that can
+ view all processes and files normally restricted to root if you choose
+ the "restrict to user only" option.  NOTE: If you're running identd or
+ ntpd as a non-root user, you will have to run it as the group you
+ specify here.
+
+config GRKERNSEC_PROC_USER
+   bool "Restrict /proc to user only"
+   depends on GRKERNSEC_PROC
+   help
+ If you say Y here, non-root users will only be able to view their own
+ processes, and restricts them from viewing network-related 
information,
+ and viewing kernel symbol and module information.
+
+config GRKERNSEC_PROC_USERGROUP
+   bool "Allow special group"
+   depends on GRKERNSEC_PROC && !GRKERNSEC_PROC_USER
+   help
+ If you say Y here, you will be able to select a group that will be
+  able to view all processes and network-related information.  If 
you've
+  enabled GRKERNSEC_HIDESYM, kernel and symbol information may still
+  remain hidden.  This option is useful if you want to run identd as
+  a non-root user.
+
+config GRKERNSEC_PROC_GID
+   int "GID for special group"
+   depends on GRKERNSEC_PROC_USERGROUP
+   default 1001
+
+config GRKERNSEC_PROC_ADD
+   bool "Additional restrictions"
+   depends on GRKERNSEC_PROC_USER || GRKERNSEC_PROC_USERGROUP
+   help
+ If you say Y here, additional restrictions will be placed on
+ /proc that keep normal users from viewing device information and 
+ slabinfo information that could be useful for exploits.
+
+config GRKERNSEC_LINK
+   bool "Linking restrictions"
+   help
+ If you say Y here, /tmp race exploits will be prevented, since users
+ will no longer be able to follow symlinks owned by other users in
+ world-writable +t directories (e.g. /tmp), unless the owner of the
+ symlink is the owner of the directory. users will also not be
+ able to hardlink to files they do not own.  If the sysctl option is
+ enabled, a sysctl option with name "linking_restrictions" is created.



-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/64312.74336...@smtp121.mail.ir2.yahoo.com

Re: Bits from the Security Team

[Julien Cristau]

On Fri, Mar  7, 2014 at 18:41:02 +0100, Jakub Wilk wrote:

> * Vincent Danjean , 2014-03-07, 15:41:
> >>hidepid=1 means users may not access any /proc//
> >>directories but their own.
> >
> >Even that is strange. I just tried. Processus that are not mine
> >are not shown anymore by ps, but even some of mine disappeared!
> >(mostly urxvt ones)
> 
> $ ls -l /usr/bin/urxvt
> -rwxr-sr-x 1 root utmp 1272864 Dec 22 18:50 /usr/bin/urxvt
> 
> It's setgid, so it can't be ptraced, so it doesn't show up in /proc.
> 
> The inability to see your own setgid processes makes this feature
> unappealing. :(
> 
Any reason urxvt can't use libutempter?

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#741054: ITP: gtkextra -- useful set of widgets for creating GUI's for GTK+

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: gtkextra
  Version : 3.1.0
  Upstream Author : Adrian E. Feiguin 

* URL : http://gtkextra.sourceforge.net/cms/
* License : LGPL-2
  Programming Lang: C++, flex, bison
  Description : useful set of widgets for creating GUI's for GTK+
  The library includes the following widgets:
 .
  GtkSheet, a matrix widget; GtkPlot, which allows you to draw high quality
  scientific plots; the package also includes GtkPlot3D and GtkPlotPolar;
  GtkPlotCanvas is a GtkFixed subclass and allows you to DnD plots etc.
  The distribution includes also a PostScript driver.
  GtkIconList, which allows you to display a table of xpm icons;
  etc. (more to come with debian/control)
 .
 Please notice that this package has been removed from Debian some time
 ago. Upstream development has been revived inbetween, and it can be packaged
 again.
 .
 The package gpsim which I maitain could not be built with its GUI. Now the GUI
 can be built again, it build-depends on gtkextra.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140307223535.23878.34753.report...@georges.khaznadar.fr

Bug#741065: ITP: etcd-- A highly-available key value store for shared configuration and service discovery

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: etcd
  Version : 0.3.0
* URL : https://github.com/coreos/etcd
* License : Apachev2
  Programming Lang: Go
  Description : A highly-available key value store for shared configuration 
and service discovery

A highly-available key value store for shared configuration and service
discovery. etcd is inspired by zookeeper and doozer, with a focus on:

* Simple: curl'able user facing API (HTTP+JSON)
* Secure: optional SSL client cert authentication
* Fast: benchmarked 1000s of writes/s per instance
* Reliable: Properly distributed using Raft


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