Re: Extending the update-rc.d API to change runlevel and disable scripts?

[Petter Reinholdtsen]

[Luk Claes]
> Isn't this just a matter of stopping the service and renaming the S (K)
> links to s (k) links so one can easily revert?

Probably not.  When only stop symlinks are present, one need to know
which runlevels should keep the stop symlinks, and which should be
changed.  I suspect the easiest way to revert to the default settings
is to remove all the packages start settings (update-rc.d -f script
remove), and reconfigure it to let the postinst script call
update-rc.d to enable it again.

For dependency based boot sequencing, the default runlevel settings
are in the LSB header in the script, while for the rest it is in the
postinst script.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[Josselin Mouette]

Le vendredi 07 décembre 2007 à 19:18 +0100, Martin Pitt a écrit :
> Hi all,
> 
> one thing that has bothered me for a long time already is the
> complete lack of a security boundary between processes of the same
> user. Things like LD_PRELOAD and ptrace() (IOW, gdb) are enabled by
> default for all users, and especially for developers this is a good
> thing.
> 
> However, a lot of programs that we have deal with passwords and other
> secrets which deserve some protection, like passwords you type into
> ssh, screensavers, seahorse, etc.

> One easy solution that comes to my mind is to install those affected
> programs setgid, and drop the additional group immediately after
> program start with setgid(getgid()). For this we should introduce a
> new static group into base-passwd, like "noptrace", to not abuse
> existing groups and not confuse auditing tools.

Given that it seems unlikely that we obtain another solution, should we
start right now with that stuff? 

Colin, as base-passwd maintainer, do you have anything against creating
such a group?

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Building with -msse

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Faidon Liambotis <[EMAIL PROTECTED]> writes:
>> Russ Allbery wrote:
>
>>> However, a user mentioned that he thinks all chips that fall into the
>>> amd64 architecture have SSE and hence adding -msse would be safe for the
>>> amd64 build.  Is that correct?  And in general are there any guidelines
>>> about things like this?  I assume that using -msse for the i386 build is
>>> still out since we still support 486 chips.
>
>> AFAIK, the amd64 gcc enables those extension by default.
>
> Yeah, that was one of the things that was confusing me.  It looks like
> gnubg also has some custom code that's enabled based on a configure
> argument as well.

You should talk to upstream and have it default to on for amd64.

And check if there is any sse3 support. That one needs cpu suport on
amd64 too.

> Also, it looks like it probes at runtime for SSE, so I may be able to
> build with that on i386 as well.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[Goswin von Brederlow]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le vendredi 07 décembre 2007 à 19:18 +0100, Martin Pitt a écrit :
>> Hi all,
>> 
>> one thing that has bothered me for a long time already is the
>> complete lack of a security boundary between processes of the same
>> user. Things like LD_PRELOAD and ptrace() (IOW, gdb) are enabled by
>> default for all users, and especially for developers this is a good
>> thing.
>> 
>> However, a lot of programs that we have deal with passwords and other
>> secrets which deserve some protection, like passwords you type into
>> ssh, screensavers, seahorse, etc.
>
>> One easy solution that comes to my mind is to install those affected
>> programs setgid, and drop the additional group immediately after
>> program start with setgid(getgid()). For this we should introduce a

Can one trace a sgid programm after it has dropped the group?

>> new static group into base-passwd, like "noptrace", to not abuse
>> existing groups and not confuse auditing tools.
>
> Given that it seems unlikely that we obtain another solution, should we
> start right now with that stuff? 
>
> Colin, as base-passwd maintainer, do you have anything against creating
> such a group?
>
> Cheers,

Can't you do something against ptrace in the binary itself and only
for critical sections?

No idea how to prevent LD_PRELOAD and people could always use their
own linker to ignore the sgid bit anyway. Seems silly to block that as
it can't exploited between unrelated binaries.

But for ptrace I would rather introduce PTRACE_HIDE_TRACEME,
PTRACE_SHOW_TRACEME for temporary disabling and PTRACE_DONT_TRACEME
for permanent disabling.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[Colin Watson]

On Sun, Apr 27, 2008 at 10:52:38AM +0200, Josselin Mouette wrote:
> Le vendredi 07 décembre 2007 à 19:18 +0100, Martin Pitt a écrit :
> > one thing that has bothered me for a long time already is the
> > complete lack of a security boundary between processes of the same
> > user. Things like LD_PRELOAD and ptrace() (IOW, gdb) are enabled by
> > default for all users, and especially for developers this is a good
> > thing.
> > 
> > However, a lot of programs that we have deal with passwords and other
> > secrets which deserve some protection, like passwords you type into
> > ssh, screensavers, seahorse, etc.
> 
> > One easy solution that comes to my mind is to install those affected
> > programs setgid, and drop the additional group immediately after
> > program start with setgid(getgid()). For this we should introduce a
> > new static group into base-passwd, like "noptrace", to not abuse
> > existing groups and not confuse auditing tools.
> 
> Given that it seems unlikely that we obtain another solution, should we
> start right now with that stuff? 
> 
> Colin, as base-passwd maintainer, do you have anything against creating
> such a group?

I think it was my suggestion to Martin in the first place, so no, I
don't have any objection. :-) I haven't been following the thread,
though - has there been general consensus on this?

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building with -msse

[Kurt Roeckx]

On Sat, Apr 26, 2008 at 07:05:17PM -0700, Russ Allbery wrote:
> gnubg supports optionally building with SSE support for increased speed in
> the analytical engine.  I have to date kept this disabled to not generate
> binaries that might not run on all otherwise-supported Debian systems.
> 
> However, a user mentioned that he thinks all chips that fall into the
> amd64 architecture have SSE and hence adding -msse would be safe for the
> amd64 build.  Is that correct?

There is no need to enable -msse on amd64.  It has always been on by
default.

> And in general are there any guidelines
> about things like this?  I assume that using -msse for the i386 build is
> still out since we still support 486 chips.

If you want to have different optimizations depending on the cpu,
there are a two options I know of:
- When you hace shared libraries you can put them in directories like
  /usr/lib/i686/sse/.  The dynamic linker whould pick it up for
  you in that case.  (I have no idea if it looks at i686/sse or not,
  but it looks at various other dirs, I can't find documentation for it.)
- Use runtime detection of the cpu and select the best option yourself.

> (I don't think the performance gain warrants the complexity of building
> two binaries, although it is noticable.)

It all depends if you think the performance gain is worth it.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[Colin Watson]

On Sun, Apr 27, 2008 at 12:56:28PM +0200, Goswin von Brederlow wrote:
> Josselin Mouette <[EMAIL PROTECTED]> writes:
> > Le vendredi 07 décembre 2007 à 19:18 +0100, Martin Pitt a écrit :
> >> one thing that has bothered me for a long time already is the
> >> complete lack of a security boundary between processes of the same
> >> user. Things like LD_PRELOAD and ptrace() (IOW, gdb) are enabled by
> >> default for all users, and especially for developers this is a good
> >> thing.
> >> 
> >> However, a lot of programs that we have deal with passwords and other
> >> secrets which deserve some protection, like passwords you type into
> >> ssh, screensavers, seahorse, etc.
> >
> >> One easy solution that comes to my mind is to install those affected
> >> programs setgid, and drop the additional group immediately after
> >> program start with setgid(getgid()). For this we should introduce a
> 
> Can one trace a sgid programm after it has dropped the group?

No; see kernel/ptrace.c:__ptrace_may_attach().

> >> new static group into base-passwd, like "noptrace", to not abuse
> >> existing groups and not confuse auditing tools.
> >
> > Given that it seems unlikely that we obtain another solution, should we
> > start right now with that stuff? 
> >
> > Colin, as base-passwd maintainer, do you have anything against creating
> > such a group?
> 
> Can't you do something against ptrace in the binary itself and only
> for critical sections?

You can (use prctl() to disable PR_SET_DUMPABLE), but it's only checked
on ptrace_attach so that would be racy. In any case, there are programs
such as ssh-agent that intentionally keep secrets around for a long
time, not just during critical sections. (ssh-agent is already setgid
ssh to prevent attacks on this.)

> No idea how to prevent LD_PRELOAD and people could always use their
> own linker to ignore the sgid bit anyway.

If they want to deliberately start a program with reduced protection and
then type their password into it, then that's their (foolish) choice.
The point of this is so that processes started in good faith can't have
their memory inspected so easily later on.

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Package with hardening support FTBFS on amd64 and i386

[Jörg Sommer]

Hi,

I've added [1] the CFLAGS and LDFLAGS to debian/rules of my package slrn
to enable hardening of the binaries.

ifeq (,$(findstring nohardening,$(DEB_BUILD_OPTIONS)))
# http://lists.debian.org/debian-devel-announce/2008/01/msg6.html
CFLAGS += -fPIC -fPIE -fstack-protector -Wformat=2 -Wextra
export LDFLAGS += -Wl,-zrelro,-pie
ifeq  (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -D_FORTIFY_SOURCE=2
endif
endif

The build went fine on all arches except i386, amd64 and m68k. I've no
idea why the build on m68k failed, but I guess the build failed on i386
and amd64, because the use gcc-4.2 while all other architectures use
gcc-4.3. The build on amd64 fails with this message [2]

configure:2586: checking for C compiler default output file name
configure:2613: gcc -g -O2 -Wall -g -O2 -fPIC -fPIE -fstack-protector 
-Wformat=2 -Wextra -D_FORTIFY_SOURCE=2
-Wl,-zrelro,-pie conftest.c  >&5
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib64/crt1.o: 
relocation R_X86_64_32S against
`__libc_csu_fini' can not be used when making a shared object; recompile with 
-fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib64/crt1.o: could not read 
symbols: Bad value
collect2: ld returned 1 exit status

What should I do?

Bye, Jörg.

[1] 
http://git.debian.org/?p=users/jo-guest/slrn.git;a=commit;h=238faf37e46f2bd54295e41987ecbc3959a739d3
[2] http://bugs.debian.org/478057
-- 
Wenn du nur einen Hammer hast, sieht jedes Problem aus wie ein Nagel.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building with -msse

[Bernd Zeimetz]

> And check if there is any sse3 support. That one needs cpu suport on
> amd64 too.

Are there amd64 machines which do *not* support sse3?


-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building with -msse

[Steinar H. Gunderson]

On Sun, Apr 27, 2008 at 07:17:14AM +0200, Bernd Eckenfels wrote:
>> Also, it looks like it probes at runtime for SSE, so I may be able to
>> build with that on i386 as well.
> If it probes, it is most likely loading an optimized asm module, and you
> dont need the SSE switch at all.

If you use gcc inline assembler and want to use SSE registers in constraints
(or use SSE intrinsics), you'll need -msse even if you write all the SSE code
yourself. It's not an unusual situation.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#477699: marked as done (general: No read permission for /usr/include/GL directory)

[Debian Bug Tracking System]

Your message dated Sun, 27 Apr 2008 15:46:27 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Heisenbug, probably nVidia's fault
has caused the Debian Bug report #477699,
regarding general: No read permission for /usr/include/GL directory
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
477699: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477699
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: general
Severity: important

Directory /usr/include/GL lacks read permissions, and thus, can not be 
listed:

$ ls -la /usr/include/GL
total 640
drwx--x--x   2 root root   4096 2008-04-24 18:49 .
drwxr-xr-x 102 root root  12288 2008-04-24 18:49 ..
-rw-r--r--   1 root root 372677 2008-04-11 10:29 glext.h
-rw-r--r--   1 root root  89697 2008-04-11 10:29 gl.h
-rw-r--r--   1 root root  83950 2008-04-11 10:29 gl_mangle.h
-rw-r--r--   1 root root  17075 2008-04-11 10:29 glu.h
-rw-r--r--   1 root root   3315 2008-04-11 10:29 glu_mangle.h
-rw-r--r--   1 root root  32565 2008-04-11 10:29 glxext.h
-rw-r--r--   1 root root  15234 2008-04-11 10:29 glx.h
-rw-r--r--   1 root root   3412 2008-04-11 10:29 glx_mangle.h

My root user has default umask 0077.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.22.1 (PREEMPT)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash


--- End Message ---
--- Begin Message ---

Closing this bug as it's probably a result of using the nVidia
installer as per discussion with submitter.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

--- End Message ---

Re: Building with -msse

[Goswin von Brederlow]

Bernd Zeimetz <[EMAIL PROTECTED]> writes:

>> And check if there is any sse3 support. That one needs cpu suport on
>> amd64 too.
>
> Are there amd64 machines which do *not* support sse3?

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 4
model name  : AMD Athlon(tm) 64 Processor 3200+
stepping: 8
cpu MHz : 2002.585
cache size  : 1024 KB
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips: 4008.05
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

Does any Athlon64 support sse3?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building with -msse

[Goswin von Brederlow]

Kurt Roeckx <[EMAIL PROTECTED]> writes:

> On Sat, Apr 26, 2008 at 07:05:17PM -0700, Russ Allbery wrote:
>> gnubg supports optionally building with SSE support for increased speed in
>> the analytical engine.  I have to date kept this disabled to not generate
>> binaries that might not run on all otherwise-supported Debian systems.
>> 
>> However, a user mentioned that he thinks all chips that fall into the
>> amd64 architecture have SSE and hence adding -msse would be safe for the
>> amd64 build.  Is that correct?
>
> There is no need to enable -msse on amd64.  It has always been on by
> default.
>
>> And in general are there any guidelines
>> about things like this?  I assume that using -msse for the i386 build is
>> still out since we still support 486 chips.
>
> If you want to have different optimizations depending on the cpu,
> there are a two options I know of:
> - When you hace shared libraries you can put them in directories like
>   /usr/lib/i686/sse/.  The dynamic linker whould pick it up for
>   you in that case.  (I have no idea if it looks at i686/sse or not,
>   but it looks at various other dirs, I can't find documentation for it.)

It doesn't. But one could add /usr/lib/sse via
/etc/ld.so.conf.d/package-sse when package-sse gets installed with
some check that the system actualy does have sse support.

> - Use runtime detection of the cpu and select the best option yourself.

Always better. Someone might want to share /usr between systems with
and without sse.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building with -msse

[Kurt Roeckx]

On Sun, Apr 27, 2008 at 04:06:40PM +0200, Goswin von Brederlow wrote:
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
> > If you want to have different optimizations depending on the cpu,
> > there are a two options I know of:
> > - When you hace shared libraries you can put them in directories like
> >   /usr/lib/i686/sse/.  The dynamic linker whould pick it up for
> >   you in that case.  (I have no idea if it looks at i686/sse or not,
> >   but it looks at various other dirs, I can't find documentation for it.)
> 
> It doesn't. But one could add /usr/lib/sse via
> /etc/ld.so.conf.d/package-sse when package-sse gets installed with
> some check that the system actualy does have sse support.

It's not because it has or doesn't have sse when you installed it, that
the hosts that is going run it is actually going to be the same.  If sse
is important for some libraries, it shouldn't be that hard to change
the dynamic linker to look there.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[Goswin von Brederlow]

Colin Watson <[EMAIL PROTECTED]> writes:

> On Sun, Apr 27, 2008 at 12:56:28PM +0200, Goswin von Brederlow wrote:
>> No idea how to prevent LD_PRELOAD and people could always use their
>> own linker to ignore the sgid bit anyway.
>
> If they want to deliberately start a program with reduced protection and
> then type their password into it, then that's their (foolish) choice.
> The point of this is so that processes started in good faith can't have
> their memory inspected so easily later on.

So it is their own fault if they set LD_PRELOAD to something that will
steal passwords. :)

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building with -msse

[Bernd Zeimetz]

> Does any Athlon64 support sse3?

yes, since Venice Stepping E3 and San Diego Stepping E4.

But thanks for the reminder, there were indeed CPUs before that.

-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Extending the update-rc.d API to change runlevel and disable scripts?

[Michael Schutte]

On Sun, Apr 27, 2008 at 09:41:49AM +0200, Petter Reinholdtsen wrote:
> [Luk Claes]
> > Isn't this just a matter of stopping the service and renaming the S (K)
> > links to s (k) links so one can easily revert?
> 
> Probably not.  When only stop symlinks are present, one need to know
> which runlevels should keep the stop symlinks, and which should be
> changed.  I suspect the easiest way to revert to the default settings
> is to remove all the packages start settings (update-rc.d -f script
> remove), and reconfigure it to let the postinst script call
> update-rc.d to enable it again.

You probably mis-parsed Luk’s suggestion: He is talking about
lowercasing the initial letters of the start/stop symlinks; this could
easily be changed back again when a script is reactivated.

And since people tend to forget about file-rc: I suppose adding a
special character (for example, a dash) to the beginning command column
in /etc/runlevel.conf and ignoring these lines in /etc/init.d/rc would
work well for this purpose.

Best regards,
-- 
Michael Schutte <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Building with -msse

[Bastian Blank]

On Sun, Apr 27, 2008 at 02:02:24PM +0200, Kurt Roeckx wrote:
> - When you hace shared libraries you can put them in directories like
>   /usr/lib/i686/sse/.  The dynamic linker whould pick it up for
>   you in that case.  (I have no idea if it looks at i686/sse or not,
>   but it looks at various other dirs, I can't find documentation for it.)

| /usr/lib/i686/sse2: (hwcap: 0x00080400)

The documentation is the source.

Bastian

-- 
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
   stardate unknown.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[Florian Weimer]

* Josselin Mouette:

> Given that it seems unlikely that we obtain another solution, should we
> start right now with that stuff? 

I think it's a bit foolish to abuse SGID bits to take away permissions.
This kind of restriction is essentially a configuration option, and
applying it to the wrong program may break tools like fakeroot.  This
information should not be stored under /usr.

There has to be a cleaner solution, such as a sysctl that, when enabled,
restricts ptrace to root.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: ffmpegthumbnailer -- fast and lightweight video thumbnailer

[Lionel Le Folgoc]

Package: wnpp
Severity: wishlist
Owner: Lionel Le Folgoc <[EMAIL PROTECTED]>


* Package name: ffmpegthumbnailer
  Version : 1.2.5
  Upstream Author : Dirk Vanden Boer <[EMAIL PROTECTED]>
* URL : http://code.google.com/p/ffmpegthumbnailer/
* License : GPL
  Programming Lang: C++
  Description : fast and lightweight video thumbnailer

FFmpegthumbnailer is a lightweight video thumbnailer that can be used by file 
managers to create thumbnails for video files. The thumbnailer uses ffmpeg to 
decode frames from the video files, so supported videoformats depend on the
configuration flags of ffmpeg.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#478167: ITP: cowpoke -- Builds a single Debian source package with a remote cowbuilder

[Ron]

Package: wnpp
Severity: wishlist
Owner: Ron <[EMAIL PROTECTED]>

  Package name: cowpoke
  Version : 0.1
  Upstream Author : Ron <[EMAIL PROTECTED]>
  URL : git://git.debian.org/git/users/ron/cowpoke.git (coming soon)
  License : GPL
  Programming Lang: bash
  Description : Builds a single Debian source package with a remote 
cowbuilder

 The cowpoke script automates the task of sending a package to a remote
 cowbuilder instance, to be built (and optionally also signed and uploaded)
 immediately.  It is not a replacement for a scheduling build daemon in
 situations where many packages are continuously being built, but it does
 take a lot of the manual work out of the task of doing a 'final' package
 build in a clean-room environment (or for alternative architectures), for
 people with build machines that are idle enough for manual scheduling to
 be entirely sufficient.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building with -msse

[Russ Allbery]

"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> On Sun, Apr 27, 2008 at 07:17:14AM +0200, Bernd Eckenfels wrote:

>> If it probes, it is most likely loading an optimized asm module, and
>> you dont need the SSE switch at all.

> If you use gcc inline assembler and want to use SSE registers in
> constraints (or use SSE intrinsics), you'll need -msse even if you write
> all the SSE code yourself. It's not an unusual situation.

After further investigation, it looks like gnubg does runtime probing, but
if you tell it to use SSE, it also adds -msse to the build flags.  Will
building with -msse break the binaries on i386 chips without SSE all by
itself, even if gnubg doesn't run any of its SSE code unless SSE is
actually detected?

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Convocatoria para Cantar

[Coral Mirabilia]

Estimados: 

Para Ciudad de BS. As. y alrededores (para zona norte de gran Buenos Aires,
leer opción 2):

1) El Grupo Coral Mirabilia, http://www.btesa.com.ar/mirabilia dirigido por
el Maestro Fernando Polonuer, convoca voces masculinas para reforzar las 
cuerdas de bajo y tenor.

Los ensayos son los miércoles de 19 a 22 hs en el barrio de Palermo.
Se requiere experiencia coral (no excluyente) y afinación. 
El repertorio es variado, con predominio de música popular y con la idea de
comenzar durante este año, también la preparación de una obra sinfónico
coral. Los ensayos se dan en un ambiente de excelente compañerismo,
dedicación y alegría.
Contacto: [EMAIL PROTECTED]


2) PARA ZONA NORTE GRAN BUENOS AIRES ( Olivos, Martinez, La lucila, San
Isidro, beccar, Victoria, Virreyes, San Fernando, Tigre, etc): 


El CORO DEL CLUB DE LEONES DE BECCAR, dirigido por Fernando Polonuer,
CONVOCA VOCES EN TODOS LOS REGISTROS. Nuestro repertorio es amplio y no se
limita a ningún estilo en particular. Nuestra propuesta es compartir este
espacio con alegría y hacer música buscando mejorar día a día nuestro nivel.
Ensayamos en la sede del club (sobre Av. Centenario, atrás del centro cívico
de Beccar) los días Lunes por la noche. 
Dentro de cada ensayo dedicamos una parte a la preparación vocal del grupo y
otra al armado del repertorio. 
Pueden contactarse con el Director a este email : [EMAIL PROTECTED]
Muchas gracias.

NOTA: Si usted ya canta en otro coro o no es de la zona de Bs.As. o
alrededores, sepa disculparnos e ignore este correo. Gracias.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[Thomas Viehmann]

Colin Watson wrote:

I think it was my suggestion to Martin in the first place, so no, I
don't have any objection. :-) I haven't been following the thread,
though - has there been general consensus on this?


I must say that the thread did not do much to convince me.[1]

Kind regards

T.

1. http://lists.debian.org/debian-devel/2007/12/msg00322.html


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[brian m. carlson]

On Mon, Apr 28, 2008 at 12:51:48AM +0200, Thomas Viehmann wrote:

Colin Watson wrote:

I think it was my suggestion to Martin in the first place, so no, I
don't have any objection. :-) I haven't been following the thread,
though - has there been general consensus on this?


I must say that the thread did not do much to convince me.[1]


The only benefit that this has is to prevent programs from spying on
other programs run by the same user.  I don't know about you, but I
don't run arbitrary programs on my system, so if there is any process
spying on my ssh-agent, then either:

1) it came from Debian, in which case I suggest we handle that program
like micq (which had a malicious upstream); or
2) I wrote it myself, in which case I obviously designed it to do
exactly that.

So basically, the only interesting case is that Debian is shipping some
program that surreptitiously spies on other programs.  Is that the case?

I don't see how we gain any benefit by disabling ptrace.  All it
prevents me from doing is snooping on my own programs, which I might
want to do for any number of reasons (strace comes to mind).

IANADD.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Building with -msse

[Steinar H. Gunderson]

On Sun, Apr 27, 2008 at 12:36:05PM -0700, Russ Allbery wrote:
> After further investigation, it looks like gnubg does runtime probing, but
> if you tell it to use SSE, it also adds -msse to the build flags.  Will
> building with -msse break the binaries on i386 chips without SSE all by
> itself, even if gnubg doesn't run any of its SSE code unless SSE is
> actually detected?

-msse might very well make GCC generate SSE assembler from regular C code,
yes.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[Goswin von Brederlow]

"brian m. carlson" <[EMAIL PROTECTED]> writes:

> On Mon, Apr 28, 2008 at 12:51:48AM +0200, Thomas Viehmann wrote:
> 1) it came from Debian, in which case I suggest we handle that program
> like micq (which had a malicious upstream); or
> 2) I wrote it myself, in which case I obviously designed it to do
> exactly that.

3) Some program has a security bug enabling others to run code.

For example your browser might have a faulty plugin and the next time
you use ssh-agent your ssh key and passphrase is reported back to some
malicious site.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

heimdal and testing

[Brian May]

Hello,

Can somebody please interpret why Heimdal is blocked from testing for me:



As far as I can tell, it won't get installed because that would break
kolab-cyrus-imapd
,
and kolab-cyrus-imapd

is broken due to #411240
 (shouldn't
this be RC?) and a dependency on libkvm-dev

which is no longer in Debian.

Is there anything I can do about this?

Thanks Brian May


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: heimdal and testing

[Filipus Klutiero]

One of the things you could do is wait one day, after which 
cyrus-imapd-2.2 would be old enough to transition. cyrus-imapd-2.2 needs 
to be updated, otherwise cyrus-common-2.2 would become uninstallable due 
to its dependency on libkrb5-22-heimdal in testing.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

How do I trace aptitude dependencies?

[Bryan Donlan]

Hi,

Currently I have a situation where attempting to upgrade imagemagick
from version 7:6.2.4.5.dfsg1-1+lenny1 to version 7:6.3.7.9.dfsg1-2+b1
pulls in over 200mb of dependencies, including mozilla-browser,
iceape-browser, and half of gnome. Using aptitude's 'i' command to
attempt to get information on why some of these are being installed
results in things like:
i   pbuilder   Recommends devscripts
i A devscripts Recommends www-browser
piA iceape-browser Provides   www-browser
piA iceape-browser Recommends iceape-gnome-support

This makes no sense, as I already have links installed for
www-browser. Even stranger are things like:

i   pbuilder   Recommends devscripts
i A devscripts Recommends www-browser
p   konqueror  Provides   www-browser
p   konqueror  Dependslibqt3-mt (>= 3:3.3.8b)
p   libqt3-mt  Dependslibaudio2

Konqueror is not installed, nor is aptitude attempting to install it.

Is this a bug in aptitude? If not, how can I find out where the errant
dependencies are coming from so I can file bugs on the appropriate
package? I've tried refusing the packages it lists one by one to try
to find where the bad recommends is, but I quickly get lost, given how
many packages are involved.

Any help debugging this would be greatly appreciated.

Thanks,

Bryan Donlan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How do I trace aptitude dependencies?

[Russ Allbery]

"Bryan Donlan" <[EMAIL PROTECTED]> writes:

> Currently I have a situation where attempting to upgrade imagemagick
> from version 7:6.2.4.5.dfsg1-1+lenny1 to version 7:6.3.7.9.dfsg1-2+b1
> pulls in over 200mb of dependencies, including mozilla-browser,
> iceape-browser, and half of gnome.

Both devscripts and djvulibre have some really unfortunate Recommends
right now.  I've been doing selected dist-upgrades with aptitude -R (make
sure that you use the unstable aptitude or -R doesn't work).

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]