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

[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 eas

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

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

Re: Building with -msse

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?

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

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

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

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_PRE

Re: Building with -msse

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

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

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 bet

Package with hardening support FTBFS on amd64 and i386

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

Re: Building with -msse

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

Re: Building with -msse

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

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

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

Re: Building with -msse

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 : A

Re: Building with -msse

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 o

Re: Building with -msse

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

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

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 protect

Re: Building with -msse

> 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

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

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 runleve

Re: Building with -msse

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 o

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

* 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 pr

ITP: ffmpegthumbnailer -- fast and lightweight video thumbnailer

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 Programmi

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

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 Descri

Re: Building with -msse

"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

Convocatoria para Cantar

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 l

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

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:

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

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 thr

Re: Building with -msse

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, ev

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

"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

heimdal and testing

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

Re: heimdal and testing

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

How do I trace aptitude dependencies?

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 informati

Re: How do I trace aptitude dependencies?

"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 dev