what is the family of ......

[Caitlin Riddle]

What family is the potato bug in?
Because I saw one in my back yard.
It was reaaly freaky.
Tell me .

Re: Bug#219139: ITP: cdcat -- a graphical (QT based) catalog program

[Henning Makholm]

Scripsit Jorge Bernal (Koke) <[EMAIL PROTECTED]>

>  CDCat is a graphical, multiplatform media catalog program which scans the
>  directories/drives you specify and makes a list of the filesystem (including
>  the tags of MP3s) and stores the result in a gzipped XML file.

Perhaps not "drives", unless the program will actually mount and
unmount media if given a device name rather than a directory?

-- 
Henning Makholm   "No one seems to know what
   distinguishes a bell from a whistle."

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:

>   second, paxtest had some bugs which Exec-Shield exposed and made
>   Exec-Shield appear better than it is. i've fixed them here and
>   expect to release 0.9.5 today or so. the results now look like:

i downloaded the new 0.9.5 paxtest package and amongst other changes it
has the following oneliner change:

--- paxtest-0.9.4/body.c
+++ paxtest-0.9.5/body.c
@@ -29,6 +29,7 @@
fflush( stdout );
 
if( fork() == 0 ) {
+   do_mprotect((unsigned long)argv & ~4095U, 4096, 
PROT_READ|PROT_WRITE|PROT_EXEC);
doit();
} else {
wait( &status );

this intentionally calls mprotect(PROT_EXEC) for the highest possible
address one can think of. This call has no useful purpose at all. In other
words, this is a specific, underhand cheat to trigger 'Vulnerable'
messages for all items when running paxtest on exec-shield kernels.  
Bravo!

frankly, i've never experienced anything like this in my many years in the
Linux world. You so far gave the impression of a reasonable and balanced
person but this is as low as it gets. Shame on you.

here are the paxtest-0.9.5 results with that single purpose-less line
removed, for the categories that matter to me:

 Executable anonymous mapping : Killed
 Executable bss   : Killed
 Executable data  : Killed
 Executable heap  : Killed
 Executable stack : Killed
 Anonymous mapping randomisation test : 8 bits (guessed)
 Heap randomisation test (ET_EXEC): 13 bits (guessed)
 Heap randomisation test (ET_DYN) : 13 bits (guessed)
 Main executable randomisation (ET_EXEC)  : No randomisation
 Main executable randomisation (ET_DYN)   : 12 bits (guessed)
 Shared library randomisation test: 12 bits (guessed)
 Stack randomisation test (SEGMEXEC)  : 17 bits (guessed)
 Stack randomisation test (PAGEEXEC)  : 17 bits (guessed)
 Executable shared library bss: Vulnerable
 Executable shared library data   : Vulnerable

Ingo

Re: A case study of a new user turned off debian

[Adam Heath]

On 4 Nov 2003, Greg Stark wrote:

> So all it would take to make the tools handle this would be to somehow make
> apt aware of more revisions of packages. They're all in the pool after all.
> Short of making some king of humongous mega-Packages file with every revision
> of every package -- which apt wouldn't scale up to anyways -- they're
> currently unavailable to APT.

snapshot.debian.net

Re: A case study of a new user turned off debian

[Jonathan Dowland]

On Mon, Nov 03, 2003 at 08:12:38PM +, Steve Kemp wrote:
> On Mon, Nov 03, 2003 at 03:05:56PM -0500, Greg Stark wrote:
> 
> > All he had to do was install an older version of libc6 and every other 
> > package
> > would have been happy. All the infrastructure is there to do this, the old
> > packages are all on the ftp/http sites, the package may even be sitting in
> > apt's cache. But there's no interface for it.
> 
>   Sure there is, 'dpkg --install $foo.deb'.  Doesn't that do exactly the
>  correct thing, even at the expense of downgrading?

So its possible.. it isn't easy, intuitive or flexible. I suppose he
could grab the pristine tarball too.

-- 
Jon Dowland
http://jon.dowland.name/

Re: [debian-devel] Re: A case study of a new user turned off debian

[Jonathan Dowland]

On Tue, Nov 04, 2003 at 06:48:09AM +, Magos?nyi ?rp?d wrote:
> I guess having kernel-image-vanilla and/or
> kernel-image-onlybugfix in debian would not hurt.

Or kernel-image-hx ... what caught me out was believing
kernel-image-2.4.xx or whatever was relatively pristine. However naive
that makes me I know I am not alone.

> I think the same about the rest, however I understand that
> Herbert does the best kernel debs you can apt-get install,
> and he does a very importand job no one else is willing to
> do, and he does it well (but with a different approach I or
> you do not do).

I definitely appreciate Herbert's work, regardless of my differences of
opinion on how it should be done :-)

-- 
Jon Dowland
http://jon.dowland.name/

Re: What's the deal with NMUs? [was Re: Are you still there?]

[Bernd Eckenfels]

On Tue, Nov 04, 2003 at 04:42:14PM -0800, Tom wrote:
> I'm confused by the concept of NMU: can anybody just arbitrarily upload 
> a new version of a package?  I have a feeling that are some controls but 
> it seems pretty wild and wooly, and subject to abuse.

Any Debian Developer can, but not unnoticed.

> The whole openness of the bug tracking system and package system seems 
> particularly vulnerable to persons with malicious and subversive intent.

How do you think the open process, which is the main feature of debian can
be exploited in that area?

> Has anybody ever "attacked" the Debian process?  Are there specific 
> controls in place to prevent "attacks", or has it just never come up?

Indeed the large base of trusted developers is a problem and a feature at
the same time. But since we are able to pretty well track all modifications,
it is not such a big issue.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

What's the deal with NMUs? [was Re: Are you still there?]

[Tom]

On Tue, Nov 04, 2003 at 07:17:12PM -0500, Alex Pennace wrote:
> A well meaning NMU to unstable can be helpful in the interim.
> Naturally, submit a bug to describe the NMU; a diff is useful. If I
> notice any problems I'll work with the uploader while the package is
> still in unstable.

I'm confused by the concept of NMU: can anybody just arbitrarily upload 
a new version of a package?  I have a feeling that are some controls but 
it seems pretty wild and wooly, and subject to abuse.

The whole openness of the bug tracking system and package system seems 
particularly vulnerable to persons with malicious and subversive intent.  
Has anybody ever "attacked" the Debian process?  Are there specific 
controls in place to prevent "attacks", or has it just never come up?

Re: Are you still there?

[Alex Pennace]

On Tue, Nov 04, 2003 at 02:22:35PM -0500, Andrés Roldán wrote:
> I'd like to know if you are still working for your debian packages,
> specially libelfg0 which one of my packages may depend on.
> 
> If you have no time, I'd like to take over this package since it's
> pretty important for me.

I have time, just lack resources. I hope to have a new hard drive
within a few weeks, and plan to finish up my TODOs and send them up.

A well meaning NMU to unstable can be helpful in the interim.
Naturally, submit a bug to describe the NMU; a diff is useful. If I
notice any problems I'll work with the uploader while the package is
still in unstable. In particular, I'd be happy if Bug #211240 was
addressed with the suggested fix for the short-term.

Re: Bug#219139: ITP: cdcat -- a graphical (QT based) catalog program

[Matthew Palmer]

On Wed, Nov 05, 2003 at 12:44:40AM +0100, Jorge Bernal wrote:
> What about this?: 
> 
> Description: media catalog program 
>  CDCat is a graphical, multiplatform media catalog program which scans the
>   
>  directories/drives you specify and makes a list of the filesystem (including
>  the tags of MP3s) and stores the result in a gzipped XML file. 
> 
> I have done s/music/media/ because it indexes not only music, although it's
> oriented to that by the fact that it reads the id3 tags

Perfect.  I now know exactly what it does, and (if I was looking for a
program to do that) would pick cdcat straight up.

Pity I'm not looking for a program to index my media, otherwise I'd sponsor
your uploads.  

- Matt

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:

> since a few points have been made regarding $subject, let me clear
> up a few of them:
> 
> 1. 'It seems that exec-shield does 99% of what PaX does'

this is not the case and i'm not claiming it. If you feel attacked, please
dont - i'll stipulate that PaX gives better security than exec-shield, ok?

>   i don't know the origin of that number above, for now i'll just
>   stick to the facts i know:
> 
>   - PaX implements perfect non-executable pages on amd64, i386,
> ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has
> some imitation of it only on i386 (it's not true per-page).

non-executable pages on anything else but i386 is a triviality, as the
hardware and the kernel supports it. There's virtually nothing that PaX or
exec-shield has to add to enable them - they are there. [there's the minor
issue of the process stack's protection bits.]

>   - PaX implements best-effort randomization of the entire
> address space, Exec-Shield does it too but at a higher
> code complexity and a lower entropy rate while having
> a worse effect on the kernel entropy pool.

lets also point out that exec-shield offers relative randomization of DSOs
to each other, while PaX only randomizes a single base of the DSOs, their
relative addresses remain constant. This way the randomization bits of
exec-shield add up for brute-force attacks. Lets add it that if a limited
exploit can be turned into an information leak then relative randomization
does not help - but it does help if the first exploit itself needs precise
addresses from multiple DSOs. (I agree that exec-shield drains the entropy
pool more, i've got this on my TODO.)

>   second, paxtest had some bugs which Exec-Shield exposed and made
>   Exec-Shield appear better than it is. i've fixed them here and
>   expect to release 0.9.5 today or so. the results now look like:

( how fair that you give me a chance to run it ... not. )

> 3. MPROTECT is bogus
> 
>   it is not. Ingo says so because he did not understand how
>   PaX works. [...]

[ ... to 100% prevent: ]

>   (1) introduce/execute arbitrary code
>   (2) execute existing code out of original program order
>   (3) execute existing code in original program order with arbitrary data

no. No offense meant, but i say so because right now i dont see the way to
have a generic and usable Linux system with all the restrictions you are
talking about. If you complete your project and everything works and it's
still the same live, flexible and kicking Linux system that we all know
and love then i was clearly wrong. Right now it seems to be heading more
in the direction of a prison - but this is just my judgement. In any case,
i did not want to add any of that to exec-shield. I'll leave the prison
guard work to selinux.

you do realise that most of those 'exploit techniques' overlap with some
programming concepts, and you think that those concepts are flawed by
design and should be eliminated - i dont agree with this characterisation.

denying executability of non-executable memory is a fair game - well
specified and a clear-cut goal. Restricting an OS to do what is arguably a
fair thing to do in a number of cases did not sound so clear-cut to me -
end of story. You might still be right in the long run, but it wasnt
obviously right at first sight, and was not complete either so it had
limited value at this stage.

> 4. PaX breaks apps, specs, whatnot

>   - apps that by their nature want to generate code runtime (e.g.,
> java). they're  broken for good which many people noticed by now.
> that's good, that was my purpose because i wanted to draw
> attention to the fact that runtime code generation is an
> important privilege that should be carefully managed (as it
> happens to be also one of the exploit techniques). [...]

i think here we are in a fundamental disagreement. To take it to the
extreme, being able to 'generate code' [ie. allow an application to write
code, etc.] is one of the fundamental properties of any Linux user
account, and hopefully remains so in the future. If you take that
'privilege' away you'll take away what drives Linux forward - a constantly
growing pool of programmers. I dont want good security to rely on the
system's insistence to remove the ability to generate code from as many
codepaths as possible. There's got to be another way to secure those damn
apps ... the price you are willing to pay is i believe way too high.

i find your approach interesting nevertheless, and i wish you good luck in
bringing it to completion.

>   about PaX breaking specs: i urge Ingo and others saying this to
>   point me to the precise location in SUSv3 or POSIX 1003.1-2001
>   that PaX conflicts with. [...]

many areas of PaX conflict with one of the most basic rule of Linux:

   http://lwn.net/Articles/32980/

[ that i was part of that discussion is only an annoying accident, ending
  up in an API/ABI discussion again wa

Bug#212988: Are you still packaging this?

[Elizabeth Fong]

Package: wnpp
Severity: wishlist
Followup-For: Bug #212988

I just compiled a copy of turck-mmcache today, and absolutely love it.  
It's working nearly perfectly on my system, integrating well with PHP4 
and Apache.  This doesn't seem like a terrifically difficult package to 
put in: like all the other php4 extensions, it should theoretically only 
require the mmcache.so file to be put in /usr/lib/php4/20020429/ and 
some basic modifications to php.ini in /etc/php4/apache that Adam Conrad 
already has a template for doing...  The administration php file might 
take a little more work (maybe add it into the webserver directories as 
phpmyadmin adds itself), but shouldn't be a huge pain.  I wouldn't mind 
doing the work to put this package in Debian, if a developer will 
sponsor me and take care of the uploading to the archives.
As for the stability issues: if you don't want to risk instability, 
don't install it - I think it's well worth it, as my aging machine went 
from 4 second page generation times with a very hacked up phpBB to 0.4 
second page generation times.
Since there hasn't been any activity on this for 38 days, I'm not sure 
exactly what's going on with the present DD Jonathan Oxer who has 
offered to package this.  Please let me know what would be the most 
expedient way to get mmcache into Debian.  I'm willing to help however I 
can.

Thanks,

Elizabeth Fong, admin at ctyalcove.org and bodalliance.com


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux linuxdesktop 2.4.21-4-686 #1 Sat Aug 2 23:27:25 EST 2003 i686
Locale: LANG=C, LC_CTYPE=C

Re: Bug#219139: ITP: cdcat -- a graphical (QT based) catalog program

[Koke]

On Wed, 5 Nov 2003 10:03:38 +1100
Matthew Palmer <[EMAIL PROTECTED]> wrote:
> Maybe fix the capitalisation of CDCat to that which upstream uses.

What about this?: 

Description: media catalog program 
 CDCat is a graphical, multiplatform media catalog program which scans the  
 directories/drives you specify and makes a list of the filesystem (including
 the tags of MP3s) and stores the result in a gzipped XML file. 


I have done s/music/media/ because it indexes not only music, although it's
oriented to that by the fact that it reads the id3 tags

PS: thanks for all of the suggestions

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


-- 
"Dios es real, a no ser que sea declarado como entero"

Jorge Bernal "Koke" http://sindominio.net/~koke/
Jabber-ID: [EMAIL PROTECTED]
<[EMAIL PROTECTED]> || <[EMAIL PROTECTED]>
.: www.augustux.org   ::pulsar.gotdns.org:.


pgppq4kBqeImn.pgp
Description: PGP signature

Re: Bug#219139: ITP: cdcat -- a graphical (QT based) catalog program

[Matthew Palmer]

On Wed, Nov 05, 2003 at 12:00:57AM +0100, Jorge Bernal wrote:
> Description: a graphical catalog program

Catalog of what?  Music, by the look of it.  Can it scan anything other than
MP3s?  if not, you could say it's an MP3 catalog program.

>  The cdcat is a graphical multiplatform (Linux/Windows) catalog program which
>  scan the directories/drives you want and memorise the filesystem (including
>  the tags of mp3's)  and store it in a file.
> 
>  The database is stored in a gzipped XML format, so you can hack it, or use 
> it if necessary :-)

CDCat is a graphical, multiplatform music catalog program which scans the
directories/drives you specify and makes a list of the filesystem (including
the tags of MP3s) and stores the result in a gzipped XML file.

Maybe fix the capitalisation of CDCat to that which upstream uses.

- Matt

Re: Grsec/PaX and Exec-shield

[spender]

> yes. It's a compatible opt-in for something that cannot be enabled for all
> binaries, instead of an opt-out. You say it's a bug, i say it's a feature.  
> A really bad analogy: it's like spam, you want to opt-in not opt-out ;)

That is indeed a really bad analogy.  Security shouldn't be as unwanted 
as spam.
> 
> > [...] Note that PaX enables itself on all binaries by default, and that
> > Ingo here does not argue that exec-shield=2 could result in a
> > non-working system.  Basically, his following argument, which I cannot
> > refute, is that if exec-shield is DISABLED BY DEFAULT ON ALL BINARIES,
> > then it results in a working system.
> 
> my main argument is that on a PT_GNU_STACK-recompiled system, you'll see
> that the overwhelming majority of binaries and libraries have a non-exec
> stack almost straight away. With some extra tweaking and patching it's up
> to 99.9%.
> 
> [ or you can manually force on the feature for every binary, if you dont
> have a PT_GNU_STACK system, via exec-shield=2, and disable exec-shield on
> a per binary basis, if you want/need to. ]
> 
> i'm not sure why you are fighting the PT_GNU_STACK concept - it's not
> connected to exec-shield at all - just take the ELF loader bits from the
> exec-shield patch and use it in PaX - it will be for the better to get rid
> of a fair share of chpax use. (Like you changed the library layout in PaX
> to match that of exec-shield.)
> 
> if you could get rid of the 1.5 GB VM limitation of PaX and if you could
> change it to use PT_GNU_STACK to set the process stack's protection bits
> then i think there's no need for exec-shield - PaX will provide better
> protection at no cost and no tradeoffs. I did and still do exec-shield to
> solve a problem. If something else does it better with no tradeoffs then
> all the better, one less maintainance headache :-)
> 
> > Now, I remember some complaining about having to chpax java if you run
> > it and PaX breaks it.  How is that more work than running exec-shield in
> > =1 mode, and having to explicitly enable it on all binaries you think
> > should have protection, since you don't recommend =2 for production
> > machines?
> 
> you dont have to explicitly enable it on all binaries you think should
> have protection - the compiler will do this just fine via PT_GNU_STACK. It
> is a property of the binary, not some policy question, whether an
> application needs an executable stack or not.
> 
> where does PaX re-enable stack executability if an application dlopen()s a
> library that needs an executable stack - because eg. it is using gcc
> trampolines? Can you enable PaX for Mozilla and guarantee that no plugin
> will ever need an executable stack?

If a library uses trampolines, PaX doesn't need to enable stack 
executability because it has trampoline emulation.  I enable PaX on 
mozilla and use several plugins including flash with no problems.

> java (or any other non-PT_GNU_STACK third party app) will just default to
> exec-shield-off.
> 
> > Viewing the process' maps file isn't going to tell you what kind of
> > protection the process currently has. [...]

Sorry, I should have said "what protection the process had a millisecond 
before you decided to check its maps file"  It's this kind of "quantum 
security" (while you don't observe it, it could be doing what you want 
or nothing at all) that I wouldn't want as an administrator.  If a 
binary decides to create a mapping with some bad protections, in 
PaX, the administrator would be notified.  In Exec-shield, this 
kind of behavior will affect the executability of sections of the address
space that were previously non-executable and the administrator might 
never know, even if he had the same script as you checking processes on 
the system.

> this is an old announcement, and says other things too that are not the
> case anymore. E.g. this area got reworked since then and these (rare but
> existing) apps/libs are detected automatically via the PT_GNU_STACK
> mechanism.

but is it not still true that you don't have trampoline emulation: if an 
application uses trampolines the solution in exec-shield is to make the 
entire stack executable?

> really, if you think granularity is a big issue for everything else but
> library bss/data then feel free to install Fedora and check out the
> mappings. It just doesnt happen all that often anymore that an app
> triggers some really bad protection layout, and if it happens, it's
> fixable in a nonintrusive way. The important thing is to have protection
> here and now for 99% of the layouts in a generic distribution. [with the
> caveat of library bss/data, as you correctly observed.]

I'm making a big issue of the granularity because you make a big issue 
of the 1.5GB limit.  While granularity in your case actually is an issue 
for all exec-shield apps, the fact is I've received no reports of anyone 
running into address space limits with PaX.  So I'll agree that the 
granularity in cases other than librarie

Re: Bug#219139: ITP: cdcat -- a graphical (QT based) catalog program

[Joe Drew]

On Tue, 2003-11-04 at 10:20, Jorge Bernal (Koke) wrote:
>   Description : a graphical (QT based) catalog program

As Matthew said, drop "QT based". Also drop the leading "a," and
"graphical" too, I think.

What you should insert is what sort of catalog program it is. For
example:

Description: music catalog program

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#219139: ITP: cdcat -- a graphical (QT based) catalog program

[Koke]

I juest copied some descriptions from the cdcat website and it seems the english
of the author is worst than mine ;)

Here is he modified result (I'll update the package tomorrow if there's no 
other correction):

Description: a graphical catalog program
 The cdcat is a graphical multiplatform (Linux/Windows) catalog program which
 scan the directories/drives you want and memorise the filesystem (including
 the tags of mp3's)  and store it in a file.

 The database is stored in a gzipped XML format, so you can hack it, or use it 
if necessary :-)


On Wed, 5 Nov 2003 08:10:59 +1100
Matthew Palmer <[EMAIL PROTECTED]> wrote:

> 
> I think I've picked enough nits here today.
> 
> - Matt
> 

-- 
"Dios es real, a no ser que sea declarado como entero"

Jorge Bernal "Koke" http://sindominio.net/~koke/
Jabber-ID: [EMAIL PROTECTED]
<[EMAIL PROTECTED]> || <[EMAIL PROTECTED]>
.: www.augustux.org   ::pulsar.gotdns.org:.


pgpCQ0R0breEQ.pgp
Description: PGP signature

Re: A case study of a new user turned off debian

[Steve Greenland]

On 03-Nov-03, 16:22 (CST), Erik Steffl <[EMAIL PROTECTED]> wrote: 
>   Oh, not this crap again. Or perhaps you're contending that what is 
> usefull for you is usefull for everybody.

No, I didn't, My point was to object to YOUR contention that anything
over 3 months old is "Useless". Woody Emacs works just fine. So does
GNOME 1.2. Not as pretty, perhaps, as 2.4, but it seems to start up a
hell of lot quicker. And Galeon 1.2.9 works a lot better than what's in
stable - more features (that I find useful, anyway), fewer bugs.

And I object to people who insist on installing 'unstable" and then
bitch when it breaks. There's reasons for testing, and the only way it's
worse than unstable (as some have said) is that you have build your own
security fixes. Hey, baby, such is life.

And for the record, you can get the vast majority of the new desktop
stuff from one or more backport repositories (see www.apt-get.org), all
with the safety of a stable libc.

The woody install instructions describe how to use an alternate kernel
for installation. There's absolutely nothing preventing you from making
a CD image with a newer kernel. If there's such a huge fscking demand
for it, why isn't it out there?

And yes, I'm going to continue to object everytime someone makes stupid
statements like "Woody is so old it's useless". That's just noise,
unless you add "... for purposes a, b, and c".

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: Debian Jr. joins with OSEF to focus on outreach

[Tom Badran]

On Tuesday 04 Nov 2003 21:54, Richard B. Kreckel wrote:
> On Tue, 4 Nov 2003, Ben Armstrong wrote on [EMAIL PROTECTED]:
> [...]
>
> > For two years, Justin Zeigler of OSEF has handed out Knoppix for Kids
> > CDs[1] to dozens of Trick-or-treaters visiting his house on Halloween.
>
> Sigh..  Ben, your email comes five days too late.  We could have had so
> much fun now that Halloween has become so popular over here in Germany.
> Would have spared me some embarrassing moments searching for sweets...

We forgot about halloween in our house so one of the girls had to give out 
fruit. When i was a kid we hated the people that did that ;)

Tom

-- 
 ^__^| Tom Badran
 (oo)\__ | Imperial College
 (__)\   )\/\| Department of Computing
||w || ---
|| ||| Using Debian SID


pgpd8jryBcxeY.pgp
Description: signature

Re: Debian Jr. joins with OSEF to focus on outreach

[Richard B. Kreckel]

On Tue, 4 Nov 2003, Ben Armstrong wrote on [EMAIL PROTECTED]:
[...]
> For two years, Justin Zeigler of OSEF has handed out Knoppix for Kids
> CDs[1] to dozens of Trick-or-treaters visiting his house on Halloween.

Sigh..  Ben, your email comes five days too late.  We could have had so
much fun now that Halloween has become so popular over here in Germany.
Would have spared me some embarrassing moments searching for sweets...

Looking forward to H2004
  -richy.
-- 
  .''`.  Richard B. Kreckel
 : :' :  <[EMAIL PROTECTED]>
 `. `'   <[EMAIL PROTECTED]>
   `-

Changes in t1lib.

[Artur R. Czechowski]

Hello Developers,

I would like to inform you, that some important changes happened to
t1lib 1.3.1-4[1] package.

I changed the naming scheme. All binary packages contain version in its
name, i.e.: t1lib-dev is now named t1lib1-dev. Of course old packages are
provided as a dumb packages with dependencies only. However technicaly it
requires no changes in your packages, it would be nice and polite if you
changed Build-Deps from t1lib-dev to t1lib1-dev. I am going to submit
a wishlist bug against those packages as soon as 1.3.1-4 is approved.

List of involved packages:

editex, Stefano Zacchiroli zack.at.debian.dot.org
gfontview, Steve Haslam araqnid.at.debian.dot.org
grace, Torsten Werner twerner.at.debian.dot.org
gtkmathview, Stefano Zacchiroli zack.at.debian.dot.org
lablgtkmathview, Stefano Zacchiroli zack.at.debian.dot.org
microwindows, David Schleef ds.at.schleef.dot.org
php4, Adam Conrad adconrad.at.0c3.dot.net
php4-gd2, Adam Conrad adconrad.at.0c3.dot.net
sylpheed-claws, Gustavo Noronha Silva kov.at.debian.dot.org
tetex-bin, teTeX maintainers debian-tetex-maint.at.lists.dot.debian.dot.org
tex-guy, Masayuki Hatta mhatta.at.debian.dot.org
ttf2pt1, Anthony Fok foka.at.debian.dot.org
ultrapoint, Takuo KITAME kitame.at.northeye.dot.org
vflib3, Masayuki Hatta mhatta.at.debian.dot.org
xdvik-ja, TSUCHIYA Masatoshi tsuchiya.at.namazu.dot.org
xpdf, Hamish Moffatt hamish.at.debian.dot.org

OTOH I am working on t1lib 5.0.0 which will be uploaded[2] soon.

Regards
Artur

[1] this version has been uploaded 2 days ago and it is awaiting for
ftpmasters' approval (#189694).
[2] as t1lib5 package; if you like extreme sports ;) fetch it now from
http://blabluga.hell.pl/t1lib5/, this version is binary incompatible
with 1.3, so be careful.
-- 
Nie wszystko dioda, co sie świeci
/z pamiętnika administratora/

Bug#219183: ITP: libgetopt-argvfile-perl -- simple supplement to option handling modules

[Sami Haahtinen]

Package: wnpp
Severity: wishlist

  Package name: libgetopt-argvfile-perl
  Version : 1.06
  Upstream Author : Jochen Stenzel <[EMAIL PROTECTED]>
  URL : http://search.cpan.org/dist/Getopt-ArgvFile/
  License : Artistic
  Description : simple supplement to option handling modules

 This module is a simple supplement to other option handling modules.
 It allows script options and parameters to be read from files instead
 of from the command line by interpolating file contents into @ARGV.

I'll upload the package asap, txt2html depends on this package so it's
being held up by this.

Sami

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux monet 2.6.0-test9-1-386 #1 Sun Oct 26 22:32:52 EST 2003 i686
Locale: LANG=en_US, LC_CTYPE=en_US

Re: Bug#219139: ITP: cdcat -- a graphical (QT based) catalog program

[Matthew Palmer]

On Tue, Nov 04, 2003 at 04:20:26PM +0100, Jorge Bernal (Koke) wrote:
>   Description : a graphical (QT based) catalog program
> 
>  The cdcat is a graphical (QT based) multiplatform (Linux/Windows)
>  catalog program which scan your directoryes/drives you want and
>  memoryze the filesystem /including the tags of mp3's/  and store it a
>  small file.  The database is stored in a gzipped XML format, so you can
>  hack it, or use it if necessary :-)

s/(QT based) //g

We don't need to know the toolkit it uses.  We have dependencies to show
that.

Oh, and s/mp3's/mp3s/.

Hmm, s/memoryze/memorise/ (or memorize if you're a 'merkin).

s/directoryes/directories/

Possibly drop the leading 'The', since 'cdcat' is more of a proper noun.

"scan your directories/drives you want" should possibly be "scan the
directories/drives you want", or perhaps "scan your directories/drives".

I think that the slashes in the description detract from the readability.  I
know they're there for emphasis, but I don't think it's really that
important to emphasise that phrase.

"store it a small file" should be "store it in a small file".  And how do
you know it will be small?  XML isn't particularly space-conscious, and
peoples' MP3 collections tend to be fairly comprehensive - I'd remove the
word "small" there.

I think I've picked enough nits here today.

- Matt

Exec-Shield vs. PaX

[pageexec]

since a few points have been made regarding $subject, let me clear
up a few of them:

1. 'It seems that exec-shield does 99% of what PaX does'

  i don't know the origin of that number above, for now i'll just
  stick to the facts i know:

  - PaX implements perfect non-executable pages on amd64, i386,
ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has
some imitation of it only on i386 (it's not true per-page).

  - PaX implements a concept about how runtime code generation
should be done, there's nothing similar in Exec-Shield, and
it seems that Ingo does not even understand why this is
important (for Ingo: please read and understand [1] before
you call something bogus, see below for more).

  - PaX implements best-effort randomization of the entire
address space, Exec-Shield does it too but at a higher
code complexity and a lower entropy rate while having
a worse effect on the kernel entropy pool.

2. paxtest 'proofs'

  i saw several people point to paxtest results to 'prove' how
  good Exec-Shield it is. it is not. first, Exec-Shield has a
  fundamental design problem stemming from the lack of understanding
  or design on Ingo's part (what i call MPROTECT in PaX). you'll
  really have to read the PaX design docs to understand its role
  in the grand scheme of things (see below for a bit more).

  second, paxtest had some bugs which Exec-Shield exposed and made
  Exec-Shield appear better than it is. i've fixed them here and
  expect to release 0.9.5 today or so. the results now look like:

PaXtest - Copyright(c) 2003 by Peter Busser <[EMAIL PROTECTED]>
Released under the GNU Public Licence version 2 or later

It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003 by Peter Busser <[EMAIL PROTECTED]>
Released under the GNU Public Licence version 2 or later

Executable anonymous mapping : Vulnerable
Executable bss   : Vulnerable
Executable data  : Vulnerable
Executable heap  : Vulnerable
Executable stack : Vulnerable

  the above changes are the result of Ingo's approach to create
  non-executable memory on i386, they're not per page as a simple
  mprotect on the top of the stack shows. before i get accused of
  specifically rigging the tests, i'll tell you that running
  multithreaded apps would have almost the same effect (only the
  main stack would stay non-exec under Exec-Shield). needless to
  say, PaX passes all the above as before.

Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect): Vulnerable
Executable data (mprotect)   : Vulnerable
Executable heap (mprotect)   : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect)  : Vulnerable
Anonymous mapping randomisation test : 8 bits (guessed)
Heap randomisation test (ET_EXEC): 13 bits (guessed)
Heap randomisation test (ET_DYN) : 13 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : 12 bits (guessed)
Shared library randomisation test: 12 bits (guessed)
Stack randomisation test (SEGMEXEC)  : 17 bits (guessed)
Stack randomisation test (PAGEEXEC)  : 17 bits (guessed)
Return to function (strcpy)  : Vulnerable
Return to function (strcpy, RANDEXEC): Vulnerable
Return to function (memcpy)  : Vulnerable
Return to function (memcpy, RANDEXEC): Vulnerable

Executable shared library bss: Vulnerable
Executable shared library data   : Vulnerable

  these two had bugs in them (they were trying to execute code
  from the wrong location). i find it somewhat funny that the
  Exec-Shield proponents (including Ingo himself) have used the
  previous false results as a justification for their claims.

  apparently none of you understood what the tests and Exec-
  Shield did, otherwise you would have known that Exec-Shield
  cannot possibly pass these tests due to its design (or at
  least not without going down the OpenBSD road).

Writable text segments   : Vulnerable


3. MPROTECT is bogus

  it is not. Ingo says so because he did not understand how
  PaX works. the short story (there's no substitute to reading
  the docs!) is that in PaX we want to handle the problems posed
  by memory corruption bugs. all such bugs. the approach chosen
  in PaX is based on preventing exploit techniques from working
  (vs. preventing specific bug situations from occuring, at least
  for now, efficient full runtime bounds checking will have to
  wait a bit). in the docs you will find a classificaiton of
  exploit techniques:

  (1) introduce/execute arbitrary code
  (2) execute existing code out of original program order
  (3) execute existing code in original program 

Re: A case study of a new user turned off debian

[Brian May]

On Tue, Nov 04, 2003 at 12:01:10PM -0500, Greg Stark wrote:
> Hm, it appears to be true that not every single revision is here. But there
> are certainly more than just the unstable and testing revisions too:
> 
>  libc6_2.2.5-11.2_i386.deb   26-Sep-2002 11:32   3.2M  

stable

>  libc6_2.2.5-11.5_i386.deb   08-Jun-2003 01:32   3.2M  

proposed-updates

>  libc6_2.3.2-9_i386.deb  26-Oct-2003 21:47   3.6M  

testing

>  libc6_2.3.2.ds1-8_i386.deb  30-Oct-2003 12:17   4.6M  

guessing: will get deleted soon if hasn't been deleted
already.

Packages aren't removed the instant the are no longer referenced,
there is a delay of several days.

>  libc6_2.3.2.ds1-9_i386.deb  02-Nov-2003 11:18   4.6M  

unstable.

Source: madison on ftp-master:


[EMAIL PROTECTED]:~$ madison libc6
W: Archive maintenance is in progress; database inconsistencies are possible.
 libc6 | 2.2.5-11.2 |stable | arm, hppa, i386, m68k, mips, mipsel, 
powerpc, s390, sparc
 libc6 | 2.2.5-11.5 | proposed-updates | arm, hppa, i386, m68k, mips, 
mipsel, powerpc, s390, sparc
 libc6 |2.3.2-7 |   testing | mips, mipsel
 libc6 |2.3.2-7 |  unstable | mips
 libc6 |2.3.2-9 |   testing | arm, hppa, i386, m68k, powerpc, s390, 
sparc
 libc6 | 2.3.2.ds1-8 |  unstable | arm, m68k
 libc6 | 2.3.2.ds1-9 |  unstable | hppa, i386, mipsel, powerpc, s390, 
sparc
-- 
Brian May <[EMAIL PROTECTED]>

Linux kernel re-packaged using CDBS

[Robert Millan]

Hi there!

Well, this is to announce that I just [re-]packaged the Linux kernel. It's
not that I'm unhappy with the current (somewhat strange) way of packaging
Linux, but rather than I wanted to try something new and package it as a
standard Debian package (which means, sources in orig.tar.gz, debian/ dir
in diff.gz, etc) using CDBS.

Don't get me wrong with this, my impression is that the packages and tools
available in Debian to compile the Linux kernel are pretty exploitable and
a good choice for the power user, who typicaly wants to re-compile Linux
perself, apply per's own set of patches, etc. However, I feel that an option
for newbie users to "install & forget" just like we do for every Debian
package is missing for what the Linux kernel is concerned.

So, to the results:

 - DBS-style debian/rules (CDBS)
 - The patchset is _exactly_ the same as the default patchset from Herbert.
   Actualy, it's updated dynamicaly by build-depending on kernel-patch-debian
   (see debian/rules).
 - You can check the source in http://people.debian.org/~rmh/linux/
   (download the orig.tar.gz from upstream, see 00README.)

Please try it out and send me some feedback, thanks!

-- 
Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

 -- J.R.R.T, Ainulindale (Silmarillion)

Re: Grsec/PaX and Exec-shield

[Ingo Molnar]

On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:

> [...] Exec-shield "can" stop, but "will" stop is a completely different
> matter. I'll let the bugfixed paxtest tell this story, however.

i am 100% sure that by taking the range-property of exec-shield into
account you can construct 'bugfixed' mapping scenarios where exec-shield
will be 'Vulnerable' for each test you can construct. If you do that you
might as well rename 'pax-test' to 'pax-is-best' ;-)

my argument is that for common apps here and now running on my system the
layout is good enough for exec-shield to be quite close to that of PaX.
(It wont be as complete as PaX though, notably the library bss/data areas
wont be protected.)

Ingo

Bug#219172: RFA: lm-sensors, i2c

[David Z Maze]

Package: wnpp
Severity: normal

I'm looking for someone to take over maintenance of the lm-sensors
hardware monitoring package, along with the corresponding i2c interface
kernel modules.   These two packages have the same upstream and they're
pretty closely related, so it'd be nice if they had the same maintainer.

Both packages involve kernel modules.  The lm-sensors package also
involves a shared library and a few userspace packages.  I'd like to say
that these are clean friendly packages; they're at least lintian-clean,
and the packaging is fairly sane (and debhelperful, if that matters to
you), but there are Issues...

(1) lm-sensors 2.8 userspace depends on lm-sensors 2.8 kernel modules,
which depend on i2c 2.8 kernel modules.  But the Linux kernel has
i2c 2.6 kernel modules, and mix-and-match ==> kernel panic.  See
bug #209228.  I haven't figured out a good way around this yet.
Also, you can't just patch the kernel to use the newer i2c modules,
since i2c support bleeds over into several other kernel modules.

(2) The library's soname has changed recently.  This wouldn't be so
bad, but lm-sensors 2.7.0 contained a different libsensors1 from
lm-sensors 2.6.5, so later versions of lm-sensors 2.7.0 had a
libsensors-1debian1.  Upstream did fix the soname, so now lm-sensors
2.8.0 has libsensors2.  But, meanwhile, kdebase has a package
(ksysguardd) that got compiled against libsensors-1debian1, and
went into testing (!) in spite of the corresponding libsensors
never having made it.

(3) Minor i18n things that I've never gotten to looking at, mostly with
the output wanting to use a "degree" character.

I haven't really been using my one machine that can use lm-sensors
much, and my current housemates object to it being left on (it's loud),
so I don't have good access to a machine to test it on.  If you're
looking at this package, you should definitely have hardware that
can make use of this package, and maybe you're using it already.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux everett 2.4.21-3-everett #1 Thu Aug 7 13:20:54 UTC 2003 i686
Locale: LANG=C, LC_CTYPE=C

re: Grsec/PaX and Exec-shield

[Andrew Saunders]

On Tue 4 November, spender wrote:

> I've spared you your precious time and gone ahead and done this for
> you.

You might have a better reception if you dropped the attitude.

Anyone reading the thread will quickly form the opinion that maintaining
PaX within Debian would likely require frequent interaction with people
like yourself{1}, Tiago Assumpcao{2} and Peter Busser{3}. On the other
hand, maintaining exec-shield would involve collaborating with people
like Ingo Molnar. From reading your respective posts, I know which I'd prefer...

{1}
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00076.html
- Arrogant arsehole. Professes not to care if users get rooted, and
would apparently withhold security vulnerabilities he discovers in
competing projects in order to further the ends of the one he himself
prefers.

{2}
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00090.html
- Paranoid loon who believes the exec-shield ITP is part of some
sinister RedHat conspiracy to take away our freedoms. 

{3}
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00158.html
- Wants to ensure that Adamantix will have an edge in security over
Debian in the future. Claims he "would very much like to see that this
project [Adamantix] serves no purpose anymore, because some or all of
its ideas ended up in other (more mainstream) distributions"
(http://www.adamantix.org/motivation.html), but started the distro
before even looking into the possibility of working within Debian. Later
opted *not* to become a Debian subproject when approached by the DPL.
Yet still has the audacity to berate others for not doing enough to get
PaX into Debian!

Re: Advices on choosing a documentation license for an upstream project

[Brian T. Sniffen]

Arnaud Quette <[EMAIL PROTECTED]> writes:

> [@ -legal: please cc me on reply as I'm not subscribed]
>
> Hi folks,
>
> We (Network UPS Tools project) are currently
> looking at creating a complete documentation
> set using docbook, for output formats and i18n
> reasons.

That's great.  Thanks.

> This improvement in the upstream will, by side
> effect, (re)create a nut-doc package in Debian.
>
> Knowing that:
> - NUT is a pure GPL project, thus we need a _free_
> documentation licence,
> - GFDL seems to be to doc what GPL is to source code,
> so it seems the good choice for our aim,
> - the current consensus on -legal is that GFDL isn't DFSG
> compliant in its current form (from what I've read in the
> Debian Statement about GFDL and -devel),
> - Debian is our GNU/Linux reference distribution for
> several reasons, and we don't want nut packages to
> be split between main and non-free!
> - however, if choosing GFDL, the RM won't consider
> it as an RC bug (so not blocking for sarge/future stable),

The RM won't consider existing GFDL documents to be RC bugs.  New GFDL
documents might or might not be approved, and in the interests of
minimizing later headaches, I'd suggest avoiding that license.

Non-free documentation almost certainly will be RC at woody+2.

> - the FSF steps about modifying GFDL might not occur
> before long (a year seems, according to RMS main
> focus on GPL V3)
>
> So, what are your advices about choosing a _free_
> documentation licence for NUT?

Well, given you talk about being a pure GPL project, why not put your
documentation under the GPL as well?  Even if you were writing in
plain text or in a WYSIWYG program, it's a reasonable choice.  But
given you're writing in docbook, with a very clear
source-compiled-to-object mapping, the GPL is a great choice for a
free documentation license.

It has the added advantage of being GPL-compatible: that is, you *and
the recipients* can freely move data between the program and the
documentation.  This makes writing and examples easy and productive.

-Brian

> Thanks for your constructive advices, and
> please, don't start any flamewar as it's not
> the aim of this mail.
>
> Arnaud Quette
> ---
> DD (nut, wmnut, knutclient)
> Upstream developer Team of NUT
> ...
> ---
> References:
> - NUT upstream: http://www.exploits.org/nut/
> - NUT Sid packages:
> http://packages.debian.org/cgi-bin/search_packages.pl?keywords=nut&searchon=names&subword=1&version=unstable&release=all
> - Debian Statement about GFDL:
> http://people.debian.org/~srivasta/Position_Statement.xhtml

-- 
Brian T. Sniffen[EMAIL PROTECTED]
   http://www.evenmere.org/~bts/

Re: Grsec/PaX and Exec-shield

[Ingo Molnar]

On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:

> [...] the main point of my argument: exec-shield=2 means enabling
> exec-shield on all binaries but the ones it is disabled for.  This would
> be a secure-by-default design, and yet it's being recommended for
> "testing purposes" only?  [...]

yes. It's a compatible opt-in for something that cannot be enabled for all
binaries, instead of an opt-out. You say it's a bug, i say it's a feature.  
A really bad analogy: it's like spam, you want to opt-in not opt-out ;)

> [...] Note that PaX enables itself on all binaries by default, and that
> Ingo here does not argue that exec-shield=2 could result in a
> non-working system.  Basically, his following argument, which I cannot
> refute, is that if exec-shield is DISABLED BY DEFAULT ON ALL BINARIES,
> then it results in a working system.

my main argument is that on a PT_GNU_STACK-recompiled system, you'll see
that the overwhelming majority of binaries and libraries have a non-exec
stack almost straight away. With some extra tweaking and patching it's up
to 99.9%.

[ or you can manually force on the feature for every binary, if you dont
have a PT_GNU_STACK system, via exec-shield=2, and disable exec-shield on
a per binary basis, if you want/need to. ]

i'm not sure why you are fighting the PT_GNU_STACK concept - it's not
connected to exec-shield at all - just take the ELF loader bits from the
exec-shield patch and use it in PaX - it will be for the better to get rid
of a fair share of chpax use. (Like you changed the library layout in PaX
to match that of exec-shield.)

if you could get rid of the 1.5 GB VM limitation of PaX and if you could
change it to use PT_GNU_STACK to set the process stack's protection bits
then i think there's no need for exec-shield - PaX will provide better
protection at no cost and no tradeoffs. I did and still do exec-shield to
solve a problem. If something else does it better with no tradeoffs then
all the better, one less maintainance headache :-)

> Now, I remember some complaining about having to chpax java if you run
> it and PaX breaks it.  How is that more work than running exec-shield in
> =1 mode, and having to explicitly enable it on all binaries you think
> should have protection, since you don't recommend =2 for production
> machines?

you dont have to explicitly enable it on all binaries you think should
have protection - the compiler will do this just fine via PT_GNU_STACK. It
is a property of the binary, not some policy question, whether an
application needs an executable stack or not.

where does PaX re-enable stack executability if an application dlopen()s a
library that needs an executable stack - because eg. it is using gcc
trampolines? Can you enable PaX for Mozilla and guarantee that no plugin
will ever need an executable stack?

java (or any other non-PT_GNU_STACK third party app) will just default to
exec-shield-off.

> Viewing the process' maps file isn't going to tell you what kind of
> protection the process currently has. [...]

the maps file will precisely tell you what kind of protection the process
currently has - take the highest executable address. I've got a script
with which you can continuously monitor the protection status of various
apps on the system. Offenders are taken care of :-)

> [...] How about if someone mprotects a page of the stack rwx?  Whoops,
> entire address space because executable.

yes. No app currently running on my box does this though.

this is one fundamental difference in the approach: instead of breaking
apps and then chpax-ing them, exec-shield lets apps tell that they are
capable of a non-exec stack.

>  From your announcement:
> 
> To provide as good protection as possible, there's no trampoline
> workaround in the exec-shield code - ie. exec-limit violations in the
> trampoline case are never let through. Applications that need to rely on
> gcc trampolines will have to use the per-binary ELF flag to make the
> stack executable again.

this is an old announcement, and says other things too that are not the
case anymore. E.g. this area got reworked since then and these (rare but
existing) apps/libs are detected automatically via the PT_GNU_STACK
mechanism.

it's very easy to list the app executability requirements and the current
protections in a live system, and it's easy to improve them one by one -
while still having a 100% working system.

> [...] (funny how it was never mentioned that PaX is a true per-page
> implementation, while yours is much more coarse grained...that sounds
> pretty substantial too).

under the exec-shield VM layout the only real relevance this has is on
library bss/data executability, for like 99% (or more) of the apps. But
yes, page granularity execution bits are a plus and are available on the
platforms of the future. It was not acceptable to limit the VM to 1.5GB on
x86. It's a tradeoff.

really, if you think granularity is a big issue for everything else but
library bss/data then feel free to ins

Re: Advices on choosing a documentation license for an upstream project

[Chad Walstrom]

On Tue, Nov 04, 2003 at 07:49:38PM +0100, Arnaud Quette wrote:
> Knowing that:
> - NUT is a pure GPL project, thus we need a _free_
> documentation licence,
> 
> So, what are your advices about choosing a _free_
> documentation licence for NUT?

Why not use the GPL to cover the documentation as well?  If you tarball
the documents with the software, it would be considered a single work,
covered by the same license.

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpIrkyxRIJTY.pgp
Description: PGP signature

Re: Grsec/PaX and Exec-shield

[spender]

On Tue, Nov 04, 2003 at 06:49:58PM +0100, Ingo Molnar wrote:
> 
> On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:
> 
> > [...] Are you so certain that Exec-shield stops execution in shared
> > library bss/data? [...]
> 
> no, it doesnt, this is the main (and pretty much only) substantial
> difference between exec-shield and PaX.

Well that sounds quite a bit different than what you had to say about 
these yesterday:
"these are caught by exec-shield too, and are quite important categories to
catch."  Clearly both cannot be correct at the same time.

> Exec-shield will stop execution in
> ET_EXEC binary's bss/data but it will not stop code injection into library
> bss/data. Here is the 'protection matrix' of all the overflowable and
> shellcodable virtual memory areas:
> 

That's not quite correct.  Exec-shield "can" stop, but "will" stop is a 
completely different matter.  I'll let the bugfixed paxtest tell this 
story, however.

> If you mean exec-shield=2 then it is 'forcing' exec-shield and is only
> recommended for testing purposes.

For the benefit of the readers that might have missed this subtle 
attempt at diverting the main point of my argument: exec-shield=2 means 
enabling exec-shield on all binaries but the ones it is disabled for.  
This would be a secure-by-default design, and yet it's being recommended 
for "testing purposes" only?  Note that PaX enables itself on all 
binaries by default, and that Ingo here does not argue that 
exec-shield=2 could result in a non-working system.   Basically, his 
following argument, which I cannot refute, is that if exec-shield is 
DISABLED BY DEFAULT ON ALL BINARIES, then it results in a working 
system.

Now, I remember some complaining about having to chpax java if you run 
it and PaX breaks it.  How is that more work than running exec-shield in 
=1 mode, and having to explicitly enable it on all binaries you think 
should have protection, since you don't recommend =2 for production 
machines?

Or, through what mechanism have you devised to notify the user when an 
application he thought was protected by exec-shield decides to mprotect 
an anonymous mapping rwx, thus making the main executable's bss and data 
sections executable?  Viewing the process' maps file isn't going to tell 
you what kind of protection the process currently has.  How about if 
someone mprotects a page of the stack rwx?  Whoops, entire address space 
because executable.  I'm also curious, given the rest of your model, how 
the lack of trampoline emulation is a security feature.  From your 
announcement:

To provide as good protection as possible, there's no trampoline
workaround in the exec-shield code - ie. exec-limit violations in the
trampoline case are never let through. Applications that need to rely on
gcc trampolines will have to use the per-binary ELF flag to make the 
stack executable again.


This all sounds very contradictory to your point that there's only one 
substantial difference between PaX and Exec-shield (funny how it was 
never mentioned that PaX is a true per-page implementation, while yours
is much more coarse grained...that sounds pretty substantial too).

Though, I don't know what I'm talking about here.  Clearly every Debian 
developer who was kind enough to make useless non-technical posts to 
this thread know much more about this subject than I do.  So please, 
listen to your in house "security experts" instead of me.  They're 
probably better for a good laugh, anyways.

-Brad

Are you still there?

[Andrés Roldán]

Hi Alex.

I'd like to know if you are still working for your debian packages,
specially libelfg0 which one of my packages may depend on.

If you have no time, I'd like to take over this package since it's
pretty important for me.

Thanks.

-- 
Andres Roldan

Fluidsignal Group   <[EMAIL PROTECTED]>
The Debian Project  <[EMAIL PROTECTED]>
GPG Key-ID: 0xB29396EB  
Home Page   http://people.fluidsignal.com/~aroldan


pgpl9adVm9NVW.pgp
Description: PGP signature

Re: Grsec/PaX and Exec-shield

[viro]

On Tue, Nov 04, 2003 at 07:51:52PM +0100, Josselin Mouette wrote:
> Le mar 04/11/2003 à 16:56, [EMAIL PROTECTED] a écrit :
> > Also, I think both you and Ingo will be interested to see the results of 
> > a bugfixed version of paxtest.  Are you so certain that Exec-shield 
> > stops execution in shared library bss/data?  Or did you just say it 
> > because that's what a program told you?  Do you want to change your 
> > answer before it's released?  Or can you tell me why Exec-shield will 
> > prevent execution in those areas?  If you can tell my why, I'll be sure 
> > to tell you why it doesn't, and why it's impossible for it to.
> 
> Give us facts. Are you advertising the latest Windows 2012 server
> software before it is written, or discussing about computer security?

Nah, he just tries to imitate Theo.  Unfortunately, he misses some elements -
clue, taste and understanding of the difference between arguments and
handwaving.  Working in that area can make one an asshole; however, being
an asshole does not qualify for such work...

Re: Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86

[Andreas Metzler]

In article <[EMAIL PROTECTED]> (local.debian-devel) you wrote:
> Package: wnpp
> Severity: wishlist

> * Package name: synaptic-touchpad
>  Version : 0.12.0
>  Upstream Author : Peter Österlund <[EMAIL PROTECTED]>
> * URL : http://w1.894.telia.com/~u89404340/touchpad/index.html
> * License : GPL
>  Description : Synaptics TouchPad driver for XFree86
[...]

Iirc this driver has already been included into the packages of XFree
4.3 in Debian/experimental.
   cu andreas

Re: Grsec/PaX and Exec-shield

[Josselin Mouette]

Le mar 04/11/2003 à 16:56, [EMAIL PROTECTED] a écrit :
> Also, I think both you and Ingo will be interested to see the results of 
> a bugfixed version of paxtest.  Are you so certain that Exec-shield 
> stops execution in shared library bss/data?  Or did you just say it 
> because that's what a program told you?  Do you want to change your 
> answer before it's released?  Or can you tell me why Exec-shield will 
> prevent execution in those areas?  If you can tell my why, I'll be sure 
> to tell you why it doesn't, and why it's impossible for it to.

Give us facts. Are you advertising the latest Windows 2012 server
software before it is written, or discussing about computer security?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=

Advices on choosing a documentation license for an upstream project

[Arnaud Quette]

[@ -legal: please cc me on reply as I'm not subscribed]
Hi folks,
We (Network UPS Tools project) are currently
looking at creating a complete documentation
set using docbook, for output formats and i18n
reasons.
This improvement in the upstream will, by side
effect, (re)create a nut-doc package in Debian.
Knowing that:
- NUT is a pure GPL project, thus we need a _free_
documentation licence,
- GFDL seems to be to doc what GPL is to source code,
so it seems the good choice for our aim,
- the current consensus on -legal is that GFDL isn't DFSG
compliant in its current form (from what I've read in the
Debian Statement about GFDL and -devel),
- Debian is our GNU/Linux reference distribution for
several reasons, and we don't want nut packages to
be split between main and non-free!
- however, if choosing GFDL, the RM won't consider
it as an RC bug (so not blocking for sarge/future stable),
- the FSF steps about modifying GFDL might not occur
before long (a year seems, according to RMS main
focus on GPL V3)
So, what are your advices about choosing a _free_
documentation licence for NUT?
Thanks for your constructive advices, and
please, don't start any flamewar as it's not
the aim of this mail.
Arnaud Quette
---
DD (nut, wmnut, knutclient)
Upstream developer Team of NUT
...
---
References:
- NUT upstream: http://www.exploits.org/nut/
- NUT Sid packages: 
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=nut&searchon=names&subword=1&version=unstable&release=all
- Debian Statement about GFDL: 
http://people.debian.org/~srivasta/Position_Statement.xhtml

3 packages for adoption

[Oliver Kurth]

Hi there,

I would like to give three of my packages for adoption:


dumpasn1

This is a useful program if you work with files using the ASN.1 syntax,
eg. X.509 cerificates. I needed this in my previous job, but not any
more.

Upstream is responsive, no bugs.


tcpreen

This is a sort of proxy. It listen on some configrable port, and
forwards net traffic to another arbitrary server and, and prints
all the information goinf back and forth.

I thought it was useful, when I packaged it, but in reality I
use ethereal.

I will orphan this in two week, if noone else wants it.

One wishlist bug, for a new version.

Upstream is very responsive.


memtester

This is (very) useful if you want to test your RAM, but want
the box to keep running, eg. if it's an important server and
you are not sure if it does strange things because of RAM failures
or other reasons.

I will keep this if noone wants it, because I sometimes use it.

Two bugs, one of them specific to large memory systems, the other
contains a patch. Shame on me...


For more nformation start at my QA page:
http://qa.debian.org/developer.php?gpg_key=451EAB1B


Greetings,
Oliver

-- 
  .''`.
 : :' :Oliver Kurth [EMAIL PROTECTED]
 `. `'   Debian GNU/Linux maintainer - www.debian.org
   `-
When sending passwords, please use my gpg key. That's what it's good for.



signature.asc
Description: Digital signature

Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86

[Mattia Dongili]

Package: wnpp
Severity: wishlist

* Package name: synaptic-touchpad
  Version : 0.12.0
  Upstream Author : Peter Österlund <[EMAIL PROTECTED]>
* URL : http://w1.894.telia.com/~u89404340/touchpad/index.html
* License : GPL
  Description : Synaptics TouchPad driver for XFree86

An XFree86 input driver to enable advanced features of the Synaptics
Touchpad including:
 * Movement with adjustable, non-linear acceleration and speed
 * Button events through short touching of the touchpad
 * Double-Button events through double short touching of the touchpad
 * Dragging through short touching and holding down the finger on the
   touchpad
 * Middle and right button events on the upper and lower corner of the
   touchpad
 * Vertical scrolling (button four and five events) through moving the
   finger on the right side of the touchpad
 * The up/down button sends button four/five events
 * Horizontal scrolling (button six and seven events) through moving the
   finger on the lower side of the touchpad
 * The multi-buttons send button four/five events, and six/seven events
   for horizontal scrolling
 * Adjustable finger detection
 * Multifinger taps: two finger for middle button and three finger for
   right button events. (Needs hardware support. Not all models
   implement this feature.)
 * Run-time configuration using shared memory. This means you can change
   parameter settings without restarting the X server

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux inferi 2.6.0-test8-1 #1 Thu Oct 23 11:35:57 CEST 2003 i686
Locale: LANG=en_GB, LC_CTYPE=en_GB

Re: A case study of a new user turned off debian

[Matt Zimmerman]

On Tue, Nov 04, 2003 at 01:11:43AM -0500, Joey Hess wrote:

> Suggested project: Create a package that, a-l-apt-move, pulls packages
> out of the apt cache and creates apt repositories from them. But make it
> create a new repository after every upgrade, by hooking into apt. And
> auto-add these repositories to sources.list, and remove old ones after a
> while, the whole nine yards.

This was more or less how I thought this should look, if it were worth
implementing.  But it should work just as well with a single repository,
pruned from time to time.  All that'd be required would be a tool to move
packages out of apt's cache and run apt-ftparchive on them.

> Eight reasons why you should be using aptitude instead of apt-get.
> 
> 1. aptitude can look just like apt-get
> 
>If you run 'aptitude update' or 'aptitude upgrade' or 'aptitude
>install', it looks and works just like apt-get, with a few enhancements.
>So there is no learning curve.

For the most common operations, there is no learning curve (and there is a
lot more power, e.g. the Y/n/? prompt).  However, aptitude doesn't quite
supersede apt-get yet, and there are two significant reasons why I'm not
quite yet able to tell users "use aptitude" as an unconditional replacement
for apt-get (which I otherwise would like to do).

1. Source package handling is not (yet?) implemented

2. aptitude in woody has some significant bugs (for example, it can't
install imp), so stable users could run into some unexpected problems

> 6. aptitude makes it easy to keep track of obsolete software
> 
>If Debian stops distributing a package, apt will leave it on your system
>indefinitly, with no warnings, and no upgrades. Aptitude lists such
>packages in its "Obsolete and Locally Created Packages" section, so you
>can be informed of the problem and do something about it.

This method of dealing with obsolete packages (dselect also does this,
right?) is much better than doing nothing, but still leaves something to be
desired.  The difference between a locally created package and an obselete
package from Debian is great, but they look the same in such a display.

-- 
 - mdz

Re: A case study of a new user turned off debian

[Andrew Suffield]

On Tue, Nov 04, 2003 at 05:53:04PM +0800, Cameron Patrick wrote:
> On Tue, Nov 04, 2003 at 03:22:10AM -0600, Chris Cheney wrote:
> | I refuse to use nvidia products, but I somehow doubt that boards based
> | on their nforce2 chipset work properly either.
> 
> I have a machine using the nforce2 chipset and the Woody installer
> doesn't recognise its IDE controller.  (Proper support is only in kernel
> versions >= 2.4.21.)

Actually it does, at least well enough to install. You need a kernel
argument to persuade it to work, and I can't remember what it was
offhand, but it's quite doable. I believe it is merely that the kernel
can't autodetect the presence of this controller in older versions.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Grsec/PaX and Exec-shield

[Ingo Molnar]

On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:

> [...] Are you so certain that Exec-shield stops execution in shared
> library bss/data? [...]

no, it doesnt, this is the main (and pretty much only) substantial
difference between exec-shield and PaX. Exec-shield will stop execution in
ET_EXEC binary's bss/data but it will not stop code injection into library
bss/data. Here is the 'protection matrix' of all the overflowable and
shellcodable virtual memory areas:

stock exec-shield PaX
  ---
  environment/argv/aux  noyes yes
  stack noyes yes
  anon mmapsnoyes yes
  malloc()  noyes yes
  binary bss/data   noyes yes
  lib bss/data  nono  yes

> [...] So I wonder what happens when someone tries to run tuxracer on a
> system that doesn't use PT_GNU_STACK?  Will Exec-shield then break
> "binary compatibility" without the presence of its self-made "standard"?

what do you mean? tuxracer runs just fine here.

If you mean exec-shield=2 then it is 'forcing' exec-shield and is only
recommended for testing purposes. Running exec-shield=1 on a system with
or without PT_GNU_STACK sections will result in a working system.  
PT_GNU_STACK itself influences nothing. Note that the Fedora kernel
defaults to exec-shield=1.

PT_GNU_STACK is a way to _automatically_ tag binaries/libraries whether
they need the stack to be executable or not. So instead of putting the
burden of 'chpax-ing broken applications' on the administrator or
distribution maker (and third party developers, and the scientific
community, and ...), this method tracks executability requirements
automatically. So you'll get a non-executable stack in like 99% of the
cases. It would be great if Debian adopted the PT_GNU_STACK changes too,
they can push the concept of non-executable stacks into the mainstream.

Ingo

Re: A case study of a new user turned off debian

[Matt Zimmerman]

On Tue, Nov 04, 2003 at 12:47:30AM -0500, Greg Stark wrote:

> So all it would take to make the tools handle this would be to somehow
> make apt aware of more revisions of packages. They're all in the pool
> after all.  Short of making some king of humongous mega-Packages file with
> every revision of every package -- which apt wouldn't scale up to anyways
> -- they're currently unavailable to APT.
> 
> The low hanging fruit here would be to have APT keep packages you had
> installed yourself in the cache rather than immediately discarding them as
> soon as they're upgraded. At a minimum keeping one extra revision would at
> least let you roll back. Something more flexible keeping old revisions for
> n days after being replaced would be even cooler.

So because it's not practical for apt to try to maintain a database of all
packages it has ever seen, in addition to the current (enormous) package
database, you're suggesting that apt try to maintain a database of all
packages it has ever installed.  This seems to have exactly the same
problem (unbounded growth) on a somewhat smaller scale.  What's more, it's
already been implemented at snapshot.debian.net.

Trying to roll back to an earlier version of a package is not a "beginner
friendly" sort of operation.  If you don't know what's going on behind the
scenes, you're in for a world of pain even if the tools made it easier for
you to do this.  Debian packages don't expect to be downgraded, and it's
rather unlikely to do the right thing for non-trivial packages.

> or perhaps a little less automatic,
> 
> apt-cache show libc6
> 
> to list the available revisions then explicitly
> 
> apt-get install libc6:2.3.2-8

Which, surprisingly enough, is already implemented by apt, using '=' where
you have written ':'.

> Actually this wouldn't really have helped my friend at all because he was
> unlucky enough that the *first* version of libc6 from unstable that he saw
> happened to be the buggy one. That doesn't really happen that often to
> libc6 so he had particularly bad luck there.

So, in other words, implementing the feature you have described wouldn't
have fixed the problem in the first place.

-- 
 - mdz

Re: A case study of a new user turned off debian

[Josip Rodin]

On Tue, Nov 04, 2003 at 11:56:37AM -0500, Greg Stark wrote:
> > > It would be helpful if Debian could even be installed on machines newer
> > > than about 2 years old.
> > 
> > It would be helpful if people wouldn't make sweeping generalizations all the
> > time. Only a part of the new machines are made with hardware that needs
> > particularly special drivers, there's plenty of it that works fine.
> 
> Sure, as long as I didn't need the network interface or access to all my hard
> drives 2.2 would have been fine.

Hey, I installed a machine recently that had a set of network cards that
didn't work with our bf24 kernel. Just as I was about to mumble something
about Debian, it turned out that the driver isn't in 2.4.22 either. I'm not
particularly bothered, workarounds are a fact of life.

-- 
 2. That which causes joy or happiness.

Re: A case study of a new user turned off debian

[Greg Stark]

Chris Cheney <[EMAIL PROTECTED]> writes:

> Er no they are not all in the pool. The only packages in the pool are
> the current versions for stable/testing/unstable/experimental. There are
> also the few packages that haven't been completely compiled on all archs
> yet and so are still left in archive while this is being done.
> snapshot.debian.net has nearly every deb since 2002/06/04, but it is not
> an official debian repo afaik.

Hm, it appears to be true that not every single revision is here. But there
are certainly more than just the unstable and testing revisions too:

 libc6_2.2.5-11.2_i386.deb   26-Sep-2002 11:32   3.2M  
 libc6_2.2.5-11.5_i386.deb   08-Jun-2003 01:32   3.2M  
 libc6_2.3.2-9_i386.deb  26-Oct-2003 21:47   3.6M  
 libc6_2.3.2.ds1-8_i386.deb  30-Oct-2003 12:17   4.6M  
 libc6_2.3.2.ds1-9_i386.deb  02-Nov-2003 11:18   4.6M  

As it turned out 2.3.2-9 was a perfectly reasonable revision to roll back to.

-- 
greg

Re: Grsec/PaX and Exec-shield

[Michael Ablassmeier]

On Tue, Nov 04, 2003 at 10:56:23AM -0500, [EMAIL PROTECTED] wrote:
> Now surely, Russell, a "security expert" such as yourself is capable of 
> copy+pasting that last reject in the file.  Doing this took one minute.  
> I would imagine this was much less time than it took for you to write 
> your ignorant mails complaining about things you don't understand or 
> haven't bothered to try yourself.

If you get down and you quarrel everyday,
You're saying prayers to the devils, I say. 
Why not help one another on the way?
Make it much easier.

> It's fun to learn new things!

Yes, it is!

bye,
- michael

Re: A case study of a new user turned off debian

[Greg Stark]

Josip Rodin <[EMAIL PROTECTED]> writes:

> On Tue, Nov 04, 2003 at 01:53:36AM -0600, Chris Cheney wrote:
> > It would be helpful if Debian could even be installed on machines newer
> > than about 2 years old.
> 
> It would be helpful if people wouldn't make sweeping generalizations all the
> time. Only a part of the new machines are made with hardware that needs
> particularly special drivers, there's plenty of it that works fine.

Sure, as long as I didn't need the network interface or access to all my hard
drives 2.2 would have been fine.

Hm...

Regardless. Having people install fresh machines with things like Postgres 7.2
is just embarrassing.

-- 
greg

Re: Grsec/PaX and Exec-shield

[spender]

> Also note that I use LSM on all my kernels, so anything that conflicts with 
> LSM is something that I have no ability to test and therefore no interest in 
> maintaining.  I'm sure I could get PaX working with LSM, but it would take 
> some work.  Anyway I'll look into this matter after I upload an exec-shield 
> package.

I've spared you your precious time and gone ahead and done this for you.  
Funny thing is that the latest version of LSM for 2.4 is still at 
2.4.20.  Trying to patch a clean 2.4.22 kernel with this results in 
rejects in 9 files.  Here're the contents of the rejects:

***
*** 329,335 
  };

  #define MAY_PTRACE(p) \
- (p==current||(p->p_pptr==current&&(p->ptrace & 
PT_PTRACED)&&p->state==TASK_STOPPED))


  static int mem_open(struct inode* inode, struct file* file)
--- 329,335 
  };

  #define MAY_PTRACE(p) \
+ (p==current||(p->p_pptr==current&&(p->ptrace & 
PT_PTRACED)&&p->state==TASK_STOPPED&&security_ops->ptrace(current,p)==0))


  static int mem_open(struct inode* inode, struct file* file)
***
*** 1418,1423 
if (!sb)
goto out;
}

ret = -EINVAL;
switch (cmds) {
--- 1421,1430 
if (!sb)
goto out;
}
+
+   ret = security_ops->quotactl (cmds, type, id, sb);
+   if (ret)
+   goto out;

ret = -EINVAL;
switch (cmds) {
***
*** 75,86 

  static kmem_cache_t * inode_cachep;

- #define alloc_inode() \
-((struct inode *) kmem_cache_alloc(inode_cachep, SLAB_KERNEL))
  static void destroy_inode(struct inode *inode)
  {
if (inode_has_buffers(inode))
BUG();
kmem_cache_free(inode_cachep, (inode));
  }

--- 76,101 

  static kmem_cache_t * inode_cachep;

+ static inline struct inode *alloc_inode(void)
+ {
+   struct inode *inode;
+
+   inode = ((struct inode *) kmem_cache_alloc(inode_cachep, 
SLAB_KERNEL));
+   if (!inode)
+   return NULL;
+   inode->i_security = NULL;
+   if (security_ops->inode_alloc_security(inode)) {
+   kmem_cache_free(inode_cachep, (inode));
+   return NULL;
+   }
+   return inode;
+ }
+
  static void destroy_inode(struct inode *inode)
  {
if (inode_has_buffers(inode))
BUG();
+   security_ops->inode_free_security(inode);
kmem_cache_free(inode_cachep, (inode));
  }

***
*** 27,32 
  #include 
  #include 
  #include 

  #include 

--- 27,33 
  #include 
  #include 
  #include 
+ #include 

  #include 

***
*** 1044,1063 

  asmlinkage long sys_sethostname(char *name, int len)
  {
int errno;

if (!capable(CAP_SYS_ADMIN))
return -EPERM;
if (len < 0 || len > __NEW_UTS_LEN)
return -EINVAL;
down_write(&uts_sem);
-   errno = -EFAULT;
-   if (!copy_from_user(system_utsname.nodename, name, len)) {
-   system_utsname.nodename[len] = 0;
-   errno = 0;
-   }
up_write(&uts_sem);
-   return errno;
  }

  asmlinkage long sys_gethostname(char *name, int len)
--- 1043,1067 

  asmlinkage long sys_sethostname(char *name, int len)
  {
+   char nodename[__NEW_UTS_LEN+1];
int errno;

if (!capable(CAP_SYS_ADMIN))
return -EPERM;
if (len < 0 || len > __NEW_UTS_LEN)
return -EINVAL;
+   if (copy_from_user(nodename, name, len))
+   return -EFAULT;
+   nodename[len] = 0;
+
+   errno = security_ops->sethostname(nodename);
+   if (errno)
+   return errno;
+
down_write(&uts_sem);
+   memcpy(system_utsname.nodename, nodename, len+1);
up_write(&uts_sem);
+   return 0;
  }

  asmlinkage long sys_gethostname(char *name, int len)
***
*** 1083,1101 
   */
  asmlinkage long sys_setdomainname(char *name, int len)
  {
int errno;

if (!capable(CAP_SYS_ADMIN))
return -EPERM;
if (len < 0 || len > __NEW_UTS_LEN)
return -EINVAL;

down_write(&uts_sem);
-   errno = -EFAULT;
-   if (!copy_from_user(system_utsname.domainname, name, len)) {
-   errno = 0;
-   system_utsname.domainname[len] = 0;
-   }
up_write(&uts_sem);
return errno;
  }
--- 1087,1109 
   */
  asmlinkage long sys_setdomainname(char *name, int len)
  {
+   char domainname[__NEW_UTS_LEN+1];
int errno;

if (!capable(CAP_SYS_ADMIN))
return -EPERM;
if (len < 0 || len > __NEW_UTS_LEN)
return -EINVAL;
+   if (copy_from_user(domainname, name, len))
+   return -EFAULT;
+   domainname[len] = 0;
+
+   errno = security_ops->setdomainname(domainname);
+   if (errno)
+   return errno;

down_write(&uts_sem);
+   memcpy(

Re: A case study of a new user turned off debian

[Josip Rodin]

On Tue, Nov 04, 2003 at 01:53:36AM -0600, Chris Cheney wrote:
> It would be helpful if Debian could even be installed on machines newer
> than about 2 years old.

It would be helpful if people wouldn't make sweeping generalizations all the
time. Only a part of the new machines are made with hardware that needs
particularly special drivers, there's plenty of it that works fine.

-- 
 2. That which causes joy or happiness.

Re: A case study of a new user turned off debian

[Marcelo E. Magallon]

On Tue, Nov 04, 2003 at 03:22:10AM -0600, Chris Cheney wrote:

 > Intel
 > -
 > i845 10 Sept 2001
 > i875 14 Apr  2003
 > i865 21 May  2003

 The last two don't have AGP support before 2.4.23-preX (not sure if X
 is 1 or not), and the on-board network cards which many of the the
 motherboards based on this chipset use aren't supported until
 2.4.23-preY (Y around 3, IIRC).  I remember having had _a lot_ of
 trouble with DMA, but IIRC the thing did boot with older kernels.

-- 
Marcelo

Re: Bug#219139: ITP: cdcat -- a graphical (QT based) catalog program

[Koke]

On Tue, 4 Nov 2003 15:45:10 +
Steve Kemp <[EMAIL PROTECTED]> wrote:

> 
>   Please apply the following patch:

Done :)


-- 
"Dios es real, a no ser que sea declarado como entero"

Jorge Bernal "Koke" http://sindominio.net/~koke/
Jabber-ID: [EMAIL PROTECTED]
<[EMAIL PROTECTED]> || <[EMAIL PROTECTED]>
.: www.augustux.org   ::pulsar.gotdns.org:.


pgpAX0tBGB2wW.pgp
Description: PGP signature

Re: Bug#219139: ITP: cdcat -- a graphical (QT based) catalog program

[Colin Watson]

On Tue, Nov 04, 2003 at 03:45:10PM +, Steve Kemp wrote:
>   Please apply the following patch:
> 
> --- config.cpp-orig 2003-11-04 15:36:58.0 +
> +++ config.cpp  2003-11-04 15:37:06.0 +
> @@ -92,7 +92,7 @@
>  #else
>if(getenv("HOME") == NULL)
>  return 1;
> -  sprintf(str,"%s/%s",getenv("HOME"),CONFIGFILE);
> +  snprintf(str,sizeof(str)-1,"%s/%s",getenv("HOME"),CONFIGFILE);
> #endif
>  
>cf = fopen(str,"r");

The return value from snprintf() should be checked, otherwise you won't
notice truncation.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bug#219139: ITP: cdcat -- a graphical (QT based) catalog program

[Steve Kemp]

On Tue, Nov 04, 2003 at 04:20:26PM +0100, Jorge Bernal (Koke) wrote:

> Package: wnpp
> Version: unavailable; reported 2003-11-04
> Severity: wishlist
> 
> * Package name: cdcat
>   Version : 0.92
>   Upstream Author : Peter Deak <[EMAIL PROTECTED]>
> * URL : http://cdcat.sf.net
> * License : GPL
>   Description : a graphical (QT based) catalog program

> It's already packaged and I will RFS. The package is at:
> 
> http://www.sindominio.net/koke/debian

  Please apply the following patch:

--- config.cpp-orig 2003-11-04 15:36:58.0 +
+++ config.cpp  2003-11-04 15:37:06.0 +
@@ -92,7 +92,7 @@
 #else
   if(getenv("HOME") == NULL)
 return 1;
-  sprintf(str,"%s/%s",getenv("HOME"),CONFIGFILE);
+  snprintf(str,sizeof(str)-1,"%s/%s",getenv("HOME"),CONFIGFILE);
#endif
 
   cf = fopen(str,"r");


  I'm not convinced that the database code is bug free, there appear to
 be a some assumptions made on the size of the tags which are not
 tested.

  I might have a look at this more thoroughly later.

Steve
--

Re: exec-shield (maybe ITP kernel-patch-exec-shield)

[Richard Braakman]

On Mon, Nov 03, 2003 at 07:42:27AM -0500, [EMAIL PROTECTED] wrote:
> Go ahead and do it.  I could frankly care less if your users get owned.  

In that case it seems safer to avoid using any software you helped
to develop.

Richard Braakman

Bug#219139: ITP: cdcat -- a graphical (QT based) catalog program

[Jorge Bernal (Koke)]

Package: wnpp
Version: unavailable; reported 2003-11-04
Severity: wishlist

* Package name: cdcat
  Version : 0.92
  Upstream Author : Peter Deak <[EMAIL PROTECTED]>
* URL : http://cdcat.sf.net
* License : GPL
  Description : a graphical (QT based) catalog program

 The cdcat is a graphical (QT based) multiplatform (Linux/Windows)
 catalog program which scan your directoryes/drives you want and
 memoryze the filesystem /including the tags of mp3's/  and store it a
 small file.  The database is stored in a gzipped XML format, so you can
 hack it, or use it if necessary :-)

It's already packaged and I will RFS. The package is at:

http://www.sindominio.net/koke/debian

or via apt at:

deb http://www.sindominio.net/koke/debian ./
deb-src http://www.sindominio.net/koke/debian ./

-- System Information:
Debian Release: Sid (unstable)
Architecture: i386
Kernel: Linux tuxland.servebeer.com 2.4.21-pre5 #13 dom jun 8 20:51:12 CEST 
2003 i686
Locale: LANG=es_ES, LC_CTYPE=es_ES

Re: Grsec/PaX and Exec-shield

[Russell Coker]

On Tue, 4 Nov 2003 19:53, Peter Busser wrote:
> > I volunteered to make a package for exec-shield because it meets the
> > Debian criteria, I have time to do it, and it interests me.  PaX would
> > take much more time so I can't do it.
>
> You cannot do it or you don't want to do it? In fact, anyone can do it
> Russell, I'm pretty sure even you can do it:

Actually I have not tried patching in PaX on it's own.  I tried GRSec and 
found that the conflicts were greater than I could fix in any reasonable 
amount of time.  During the previous discussions on grsec I had got the 
impression that PaX was the hard part of such a code merge, maybe that 
impression was incorrect.

Also note that I use LSM on all my kernels, so anything that conflicts with 
LSM is something that I have no ability to test and therefore no interest in 
maintaining.  I'm sure I could get PaX working with LSM, but it would take 
some work.  Anyway I'll look into this matter after I upload an exec-shield 
package.

> I'm not in fact trying enlist volunteers. I try to offend as many Debian
> people as possible, so that they choose exec-shield. This to ensure that
> Adamantix will has an edge in security over Debian in the future. And it
> seems to be working very well so far.

This seems to conflict with your web site.

From http://www.adamantix.org/motivation.html:
# That is why I started this project, to create a secure Linux platform and
# make it available to everyone. Yes I know OpenBSD exists and I think they do
# a great job. However, free software is all about freedom of choice and it is
# be good to be able to choose between different highly secure systems. In a
# sense my aim is also to create a reference platform, so users can ask Linux
# distribution vendors: ``Why don't you provide this?'' In the future I would
# very much like to see that this project serves no purpose anymore, because
# some or all of its ideas ended up in other (more mainstream) distributions. 

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Grsec/PaX and Exec-shield

[Lukas Geyer]

Peter Busser <[EMAIL PROTECTED]> writes:

> > I volunteered to make a package for exec-shield because it meets
> > the Debian criteria, I have time to do it, and it interests me.
> > PaX would take much more time so I can't do it.
> 
> You cannot do it or you don't want to do it? In fact, anyone can do
> it Russell, I'm pretty sure even you can do it:
> 
> apt-get install kernel-source-2.4.22
> cd /usr/src
> tar xvfj kernel-source-2.4.22
> cd kernel-source-2.4.22
> wget http://pageexec.virtualave.net/pax-linux-2.4.22-200310051430.patch
> patch -p1 < pax-linux-2.4.22-200310051430.patch
> 
> And now you can make menuconfig etc. Now, that wasn't too difficult,
> right?

If this is your idea of maintaining a package, I am glad that you are
not a Debian developer. I hope you take better care in putting
together Adamantix, otherwise I pity the poor souls who use it and
believe it is "Trusted"...

Lukas

P.S.: Why does everyone attack Russell these days? Seems to me like
the field of Linux security is populated by lots of trolls.

Re: Grsec/PaX and Exec-shield

[Tommi Virtanen]

Peter Busser wrote:
Summary: i can see no significant differences between the paxtest output -
all the differences seem to be bogus, see the details below.
Fact is: There is a difference in paxtest output between PaX and exec-shield.
And it is not a difference in exec-shield's advantage.
Peter, no one contested that there is a difference. Ingo contested the 
meaningfulnes of that difference. Now, it's your turn trying to explain
*why* the difference is meaningful; not just that it exists.

HTH, HAND.

Re: Grsec/PaX and Exec-shield

[Mario Lang]

Peter Busser <[EMAIL PROTECTED]> writes:

>> On Tue, 04 Nov 2003, Peter Busser wrote:
>> > In fact, anyone can do it Russell, I'm pretty sure even you can do
>> > it:
>> Why not volunteer to make the .deb, get a sponsor and get it uploaded
>> then?
>
> Good idea! Already did that in fact. So who do I send this new kernel-source
> .deb to?

I sincerely hope that you did not create a prepatched kernel-source
package.  OTOH, this would explain a lot about your mails on d-d.

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
| Get my public key via finger [EMAIL PROTECTED]
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

Re: Galeon 1.2.12 for Debian woody

[Christoph Martin]

Christoph Martin schrieb:
> I have build unofficial Galeon 1.2.12 packages for Debian woody based on
> the Mozilla 1.5 packages backported to woody from
> http://debian.relativ.org/.
> 
> Just add the following line to your /etc/apt/sources.list:
> 
> deb http://www.verwaltung.uni-mainz.de debian/

The sources.list line is wrong. It must read

deb http://www.verwaltung.uni-mainz.de/debian ./

> ...or download the packages directly from
> http://www.verwaltung.uni-mainz.de/debian/galeon


Christoph

-- 

Christoph Martin, EDV der Verwaltung, Uni-Mainz, Germany
 Internet-Mail:  [EMAIL PROTECTED]
  Telefon: +49-6131-3926337
  Fax: +49-6131-3922856


pgpQ06pZ8NQ5J.pgp
Description: PGP signature

Re: Grsec/PaX and Exec-shield

[Ingo Molnar]

On Tue, 4 Nov 2003, Peter Busser wrote:

> > the reply below is mostly a re-send of a mail i sent to you privately 
> > but you repeat this argument again without any apparent answer to my
> > counter-arguments.
> 
> I already suggested you to reread the PaX documentation, there are the
> answers to your questions. There is no need to copy/paste it here.

yes, i've read them, and they do not answer my questions. The PaX
documentation says:

  Non-executable pages and mprotect() restrictions are effective
  in preventing the introduction of new executable code into an
  attacked task's address space.  There remain only two venues
  for this kind of attack:

  [ write files ] [ map existing library ]

this is plainly not true. Firstly, PaX doesnt solve the "write a file and
mmap() it" problem, so what's your point? Secondly, you can eg. write a
shell-script into non-executable memory and system() it. Etc., etc.

The ability to mprotect() a page already requires good control over the
binary, at which point you can do basically whatever the application can
do normally.

Arguing for this mprotect() restriction is like arguing that "i am only a
little bit pregnant". The attacker controls the application and there are
many ways to use that control to do Bad Stuff. The mprotect() restriction
is an after-the-fact restriction that reduces system utility in a way that
by its own documentation is an admittedly non-complete protection. In fact
it adds little if any protection.

Exec-shield does not include such arbitrary policy decisions. The attacker
has broken in, he controls the app, it's just a matter of time until he
owns everything the app owns (or more) - mprotect() restrictions or not.

besides, the mprotect() change:

 Restrict mprotect()
 CONFIG_PAX_MPROTECT
   Enabling this option will prevent programs from
- changing the executable status of memory pages that were
  not originally created as executable,
- making read-only executable pages writable again,
- creating executable pages from anonymous memory.

breaks a fair number of legitimate applications, breaking binary
compatibility, which is an additional no-no too.

and this is easy. Breaking binaries and increasing security by making the
system less useful.

> > Summary: i can see no significant differences between the paxtest output -
> > all the differences seem to be bogus, see the details below.
> 
> Fact is: There is a difference in paxtest output between PaX and
> exec-shield. And it is not a difference in exec-shield's advantage.

this what i'm disputing, because those tests i criticised are arbitrary
(see above). The other tests are OK and paxtest is a useful utility, no
doubt about that!

by your argument you could add this to paxtest:

printf("PaX is inherently better\n");

there's no way exec-shield could get around this "difference in output"  
;-)

> Another fact: If you don't like this difference, you can change the PaX
> kernel configuration to lower the level of security to the same level as
> exec-shield.

my point is that CONFIG_PAX_MPROTECT is not acceptable in a generic Linux
kernel, and that there's no 'reduction in security' by not using it.  If
you can give me specific examples of exploit techniques that this disables
in a way that cannot be worked around then my point is incorrect.

Ingo

Re: A case study of a new user turned off debian

[Karsten M. Self]

on Mon, Nov 03, 2003 at 04:57:34PM -0500, Greg Stark ([EMAIL PROTECTED]) wrote:
> 
> "Julian Mehnle" <[EMAIL PROTECTED]> writes:
> 
> > First, I think what Daniel Jacobowitz said is entirely true. Why didn't you
> > start with "testing"?
> 
> Sure testing is less likely to trigger this. 

Frankly, I'd have started stable.  Moving up's tons easier than moving
down.  As you've noted.  And largely trivial.


> > Or, you could create a file /etc/apt/preferences and pin the
> > "testing" version of the package with a high enough priority. See
> > `man apt_preferences`. Then do a `apt-get dist-upgrade`.
> 
> That's about the last place I would send a new user. I read that man
> page about three times during this crisis before I decided it would be
> hopeless to try to explain this procedure online. 

Explain what?

Greg:  Grab this file, copy it to /etc/apt/preferences:
/preferences
Friend:  OK.

> This is what I meant about there not being an "interface". 

File copying, particularly for an experienced sysadmin, is a damned
useful "interface".


> If apt said "Hm, version 1.2 of libc failed to configure, would you
> like to install the previous version (1.1) from testing and hold back
> the following packages that depend on the new one (awk, grep, sed)
> [Yn]?" That would be an interface. 

Pinning can get you much of the way here.

Problem is that dependencies work forward:  you can't be sure of getting
a package in a prior release -- it may not be available.

libc is a particularly pathelogical case, for all the obvious reasons.


> Telling people, go edit this random file with to set "pin priorities"
> for things to arbitrary numbers, find out what package dependencies
> fail, add those to your list of pin priorities, etc. That's not a
> useful interface for this case.

Telling people to start off with unstable is about as useless.


> In any case having the granularity of "stable", "testing", "unstable"
> really doesn't help. All the package versions are in the pool. I want
> to be able to tell apt to try such and such version, or at least put
> back the version I had before and restore whatever other packages it
> must to satisfy dependencies.

Look:  Either KISS and stick with stable, accept the pain of testing, or
learn how to use pinning and come up with a perferences file that works.
Your friend can copy this from any given website you can access.


> I didn't say it was a good idea or that it was going to work. 
> My whole point is that that approach sucks and we should make
> something more effective rather than leave the admin stuck.

Assuming _you_ have experience with Debian, and are aware of limitations
and trade-offs, you've led your friend astray.

I spend a fair amount of time in IRC support for #debian.  Lots of n00bs
come on wanting to install Debian unstable.  The advice is consistent:
Don't.  Not if you don't know your way around tha packaging system yet.
I've had a number of friends convert to Debian -- most of them love it,
aggressively.  But to a one they all wanted to go straight to unstable.
After nearly five years, I still hold to testing with a few exceptions
handled through pins.


Peace.

-- 
Karsten M. Self http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
Bush/Cheny '04:  BU__SH__!


signature.asc
Description: Digital signature

Re: Grsec/PaX and Exec-shield

[Andreas Schuldei]

* Peter Busser ([EMAIL PROTECTED]) [031104 13:55]:
> You didn't touch the other facts in the list, because you know you don't have
> any proof to easily dismiss them. You would be my hero if you succeeded in
> improving on PaX. But in all honesty, exec-shield does not do that I'm afraid.
> In fact, there is simply no technical reason whatsoever for exec-shield to
> exist at all. None.

you seem to suffer from an accute case of hybris. i feel you are
in the position to bring proof, if you disagree with ingo. He
seems to have thought about the issue a minute or two and
dislpayed some skill in the area allready. 

Re: A case study of a new user turned off debian

[Rob Weir]

On Tue, Nov 04, 2003 at 12:47:30AM -0500, Greg Stark said
> or perhaps a little less automatic,
> 
> apt-cache show libc6
> 
> to list the available revisions then explicitly
> 
> apt-get install libc6:2.3.2-8

With a s/:/=/ and a sources.list line pointing at sid, say, two days ago
on http://snapshot.debian.net/, this would have worked.  If the Debian
Reference doesn't mention this, it certainly should, but this is
something that your friend could have solved by asking another Debian
user IRL, on debian-user or on IRC.  When people say "newbies shouldn't
use unstable", they're not (generally) being elitist, it's shorthand for
"newbies won't know about the tools they need to fix their systems when
unstable goes bad".

-- 
Rob Weir <[EMAIL PROTECTED]> | [EMAIL PROTECTED]  |  Do I look like I want a CC?
Words of the day:   colonel encryption BATF Manfurov hackers CipherTAC-2000 ANC


signature.asc
Description: Digital signature

Re: A case study of a new user turned off debian

[Arnaud Vandyck]

On Tue, 4 Nov 2003 12:18:00 +
Colin Watson <[EMAIL PROTECTED]> wrote:

> On Tue, Nov 04, 2003 at 12:54:25PM +0100, Arnaud Vandyck wrote:
> > On Tue, 4 Nov 2003 10:04:11 +
> > Will Newton <[EMAIL PROTECTED]> wrote:
> > > Er, doesn't apt-get install libc6=2.3.2-8 do exactly this?
> > 
> > No because of a conflict with (file own by) libdb1-compat.
> 
> Uh, 2.3.2-8 is well after the introduction of libdb1-compat. Are you
> sure you don't mean an earlier version?

Sorry 2.2.5, the one in stable.

-- 
  .''`.   ** Debian GNU/Linux **
 : :' :  Arnaud   Vandyck
 `. `'   http://people.debian.org/~avdyk/
   `-


pgpzc2p8ojshh.pgp
Description: PGP signature

Re: Grsec/PaX and Exec-shield

[Michael Ablassmeier]

On Tue, Nov 04, 2003 at 12:39:46PM +0100, Peter Busser wrote:
> > Why not volunteer to make the .deb, get a sponsor and get it uploaded
> > then?
> 
> Good idea! Already did that in fact. So who do I send this new kernel-source
> .deb to?

You can use the mentors service to exchange your packages with your 
sponsor. All informations how to (d)upload your packages to the Mentors 
Server are explained on the homepage[0].

After uploading it to the Server you can seek for an sponsor using
debian-mentors@lists.debian.org, this one (debian-devel), or the phpBB
forum which is also aviable at the mentors homepage.

[0] http://mentors.debian.net

bye,
- michael

Re: Grsec/PaX and Exec-shield

[Peter Busser]

Hi!

> the reply below mostly a re-sent of a mail i sent to you privately - but
> you repeat this argument again without any apparent answer to my
> counter-arguments.

I already suggested you to reread the PaX documentation, there are the answers
to your questions. There is no need to copy/paste it here.

> Summary: i can see no significant differences between the paxtest output -
> all the differences seem to be bogus, see the details below.

Fact is: There is a difference in paxtest output between PaX and exec-shield.
And it is not a difference in exec-shield's advantage.

Another fact: If you don't like this difference, you can change the PaX kernel
configuration to lower the level of security to the same level as exec-shield.

You didn't touch the other facts in the list, because you know you don't have
any proof to easily dismiss them. You would be my hero if you succeeded in
improving on PaX. But in all honesty, exec-shield does not do that I'm afraid.
In fact, there is simply no technical reason whatsoever for exec-shield to
exist at all. None.

Groetjes,
Peter Busser
-- 
The Adamantix Project
Taking high-security Linux out of the labs, and into the real world
http://www.adamantix.org/

Re: A case study of a new user turned off debian

[Colin Watson]

On Tue, Nov 04, 2003 at 12:54:25PM +0100, Arnaud Vandyck wrote:
> On Tue, 4 Nov 2003 10:04:11 +
> Will Newton <[EMAIL PROTECTED]> wrote:
> > Er, doesn't apt-get install libc6=2.3.2-8 do exactly this?
> 
> No because of a conflict with (file own by) libdb1-compat.

Uh, 2.3.2-8 is well after the introduction of libdb1-compat. Are you
sure you don't mean an earlier version?

-- 
Colin Watson  [EMAIL PROTECTED]

Re: status of Progeny projects

[Jamie Wilkinson]

This one time, at band camp, Ian Murdock wrote:
>We have ported Red Hat's Anaconda installer to Debian;

This rocks.  I have an extensive PXE+kickstart based server build system at
work and I was considering hacking d-i to read a kickstart configuration
file, this looks like it's saved me the trouble.

-- 
[EMAIL PROTECTED]   http://people.debian.org/~jaq

Re: A case study of a new user turned off debian

[Arnaud Vandyck]

On Tue, 4 Nov 2003 10:04:11 +
Will Newton <[EMAIL PROTECTED]> wrote:

> Er, doesn't apt-get install libc6=2.3.2-8 do exactly this?

No because of a conflict with (file own by) libdb1-compat.

Well, it was the problem I faced.

Best regards,

-- 
  .''`.   ** Debian GNU/Linux **
 : :' :  Arnaud   Vandyck
 `. `'   http://people.debian.org/~avdyk/
   `-


pgpzlXkz7SAQH.pgp
Description: PGP signature

Re: Grsec/PaX and Exec-shield

[Peter Busser]

Hi!

> [NB: When reponsding using the web archives, please get the References
> and In-Reply-To: correctly. You may also consider setting MFT:]

I can't post from the lists.debian.org site.

> On Tue, 04 Nov 2003, Peter Busser wrote:
> >> PaX would take much more time so I can't do it.
> > 
> > You cannot do it or you don't want to do it?

> Russell has made it adequately clear that he doesn't have the time or
> the desire to deal with PaX at this time. As a volunteer, that's
> always his prerogative. [As a side note, if you are trying to enlist
> volunteers, I strongly suggest not berating other developers while
> doing it.[1]]

Agreed, Russell is free to do what he wants.

However, other Debian developers benefit from having accurate information, to
base their opinions on. And so far I have seen statements on PaX that have been
anything but accurate.

I'm not in fact trying enlist volunteers. I try to offend as many Debian people
as possible, so that they choose exec-shield. This to ensure that Adamantix
will has an edge in security over Debian in the future. And it seems to be
working very well so far.

Besides that, I can imagine that gr-security does not work on the current
Debian kernels. But really, PaX and gr-security are two completely different
things. PaX is related to gr-security in the same way the Linux kernel is
related to Debian. It is just a part of it, but the PaX project is independent
of gr-security.

> > In fact, anyone can do it Russell, I'm pretty sure even you can do
> > it:
> Why not volunteer to make the .deb, get a sponsor and get it uploaded
> then?

Good idea! Already did that in fact. So who do I send this new kernel-source
.deb to?

Groetjes,
Peter Busser
-- 
The Adamantix Project
Taking high-security Linux out of the labs, and into the real world
http://www.adamantix.org/

Re: Grsec/PaX and Exec-shield

[Ingo Molnar]

On Tue, 4 Nov 2003, Peter Busser wrote:

>   - Running paxtest shows the differences between PaX and exec-shield.
> Everyone is invited to run paxtest to see for yourself.

the reply below mostly a re-sent of a mail i sent to you privately - but
you repeat this argument again without any apparent answer to my
counter-arguments.

Summary: i can see no significant differences between the paxtest output -
all the differences seem to be bogus, see the details below.

Here's the output of paxtest-0.9.4 under an exec-shield-G4 kernel:

 Executable anonymous mapping : Killed
 Executable bss   : Killed
 Executable data  : Killed
 Executable heap  : Killed
 Executable stack : Killed

the above ones are important, exec-shield catches these exploit
categories.

 Executable anonymous mapping (mprotect)  : Vulnerable
 Executable bss (mprotect): Vulnerable
 Executable data (mprotect)   : Vulnerable
 Executable heap (mprotect)   : Vulnerable
 Executable shared library bss (mprotect) : Vulnerable
 Executable shared library data (mprotect): Vulnerable
 Executable stack (mprotect)  : Vulnerable

i do believe the above checks are bogus, please explain to me why this
case is important to handle.

the test checks whether it's possible to execute an area after
mprotect(PROT_EXEC) has been called over it. The answer: of course it's
executable, the application asked the kernel for this!

Any exploit that can call mprotect() has free reign anyway. The ability to
execute a library call or a system-call is End Of Story. Why is it such a
big issue to inhibit mprotect() calls? Especially since not honoring
mprotect() calls breaks existing apps and specifications.

if you can call mprotect() then you can very well call munmap() and
mmap(MAP_FIXED,PROT_EXEC) as well, which is equivalent to the mprotect()
call. From whatever angle i look at this test, it's bogus.

in any case, the above restriction is trivial to add to the kernel but
still i didnt want to add it because it's simply pointless.

 Anonymous mapping randomisation test : 8 bits (guessed)
 Heap randomisation test (ET_EXEC): 14 bits (guessed)
 Heap randomisation test (ET_DYN) : 13 bits (guessed)
 Main executable randomisation (ET_EXEC)  : No randomisation
 Main executable randomisation (ET_DYN)   : 12 bits (guessed)
 Shared library randomisation test: 12 bits (guessed)
 Stack randomisation test (SEGMEXEC)  : 17 bits (guessed)
 Stack randomisation test (PAGEEXEC)  : 17 bits (guessed)

these are acceptable levels or randomization against remote attacks,
except the ET_EXEC one, but ET_DYN is used for PIE binaries so this is not
an issue.

 Return to function (strcpy)  : Vulnerable
 Return to function (strcpy, RANDEXEC): Vulnerable
 Return to function (memcpy)  : Vulnerable
 Return to function (memcpy, RANDEXEC): Vulnerable

(these can only be caught via compiler changes, clearly not a target for
PaX or exec-shield.)

 Executable shared library bss: Killed
 Executable shared library data   : Killed

these are caught by exec-shield too, and are quite important categories to
catch.

 Writable text segments   : Vulnerable

again, i think this is a bogus restriction too. Why deny writable text
segments? Control over the application at such a level is Game Over in
virtually every case.

summary: exec-shield catches all the non-bogus categories and tries to
raise the bar of exploitation, without breaking binary compatibility
arbitrarily.

Ingo

Re: A case study of a new user turned off debian

[Marco d'Itri]

On Nov 04, Andrew Suffield <[EMAIL PROTECTED]> wrote:

 >On Tue, Nov 04, 2003 at 01:53:36AM -0600, Chris Cheney wrote:
 >> It would be helpful if Debian could even be installed on machines newer
 >> than about 2 years old. Neither my KT400 based machine nor my i875P
 >> based machine could be installed using the standard Debian
 >> boot-floppies. I had to resort to using Knoppix with debootstrap.
 >> 
 >> So no Debian stable really is not an option for a large portion of
 >> users.
 >
 >I challenge the assertion that this affects a large portion of users.
I can report I had the same problem with two other KT400-based
workstations. The kernel (both plain and bf24) would panic at boot or
break shortly after.

00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400 AGP] Host Bridge

-- 
ciao, |
Marco | [2889 diFNHN2DNpWWo]


signature.asc
Description: Digital signature

Re: Grsec/PaX and Exec-shield

[Peter Busser]

Thomas Viehmann wrote:

> So, please don't start insulting and accusing people for doing good work
> and proposing to do even more of it. If there are technical reasons that
> cause you to prefer that exec-shield does not become part of Debian's
> standard kernel, just put them on the table, but save us your conspiracy
> theories.

I have seen noone accusing Russel from doing good work. The problem here is not
the good work, it is the things he says that can easilly be proven wrong.

For those who don't know, Adamantix is a Debian based distribution aiming to
create a highly secure Linux system. Most packages used in Adamantix are Debian
packages, including the kernel packages. Almost all packages have been
recompiled to make maximum use of the features PaX provides. Most programs run
fine. Only a handful of programs have problems. PaX has been a standard part of
the kernel in Adamantix for almost a year now. And it is used on mission
critical production systems with SLAs.

So what are the facts:

  - PaX works, even on Debian kernels. Adamantix proves it.
  - It provides more security than you get by installing the latest updates:

http://groups.google.com/groups?selm=20030525190037%2470c6%40gated-at.bofh.it
(Also proof that it works with Debian)
  - It takes less time to apply the patch to the Debian kernel than the time
that is wasted on this discussion.
  - The functionality can be tuned to specific needs by changing the kernel
configuration. That means, you can lower the security at a level comparable
to exec-shield if you want to.
  - I have installed an Adamantix kernel on a Sarge system and the command line
stuff worked (didn't test it thoroughly). If packages follow the current
Debian policy, they should be mostly okay, even if the most restrictive
settings are used (like in the Adamantix kernel packages).
  - You don't need to recompile if you don't want to. It only adds more
security if you do.
  - PaX is available on different platforms and not only on i386. That is,
Alpha, PowerPC, HPPA and others.
  - The design and implementation of PaX have been documented and are open to
public scrutiny: http://pageexec.virtualave.net/docs/index.html
This includes a description of limitations and design choices made, so you
can find out what trade-offs have been made (or haven't been made).
  - PaX is independent from gr-security. And can be downloaded and applied to
the kernel without having to download gr-security.
  - It is POSIX compliant. Programs that break are those who try to go beyond
the limits of POSIX. Most of them can be fixed. And those that cannot be
fixed (like the Java JDK, which is available as binary only) can be made
to run without much hassle. The package maintainer can take care of this,
it is as complicated as stripping binaries. We're talking about a handful
of programs here anyway.
  - It is possible to have a fully functional distribution running on PaX. The
OpenBSD project proves that, it has features similar to PaX in the kernel,
and you can still run all the goodies.
  - Running paxtest shows the differences between PaX and exec-shield. Everyone
is invited to run paxtest to see for yourself.

So far I have heard a lot of talk and a number of opinions on why PaX is bad.
But no proof. I can reasonably proof any of the above. But I have seen no such
proof from those who propose exec-shield so far, only opinions and cheap talk.
Opinions are like assholes, everyone has one. It is proof that counts.

Groetjes,
Peter Busser
-- 
The Adamantix Project
Taking high-security Linux out of the labs, and into the real world
http://www.adamantix.org/

Re: A case study of a new user turned off debian

[Andreas Metzler]

Chris Cheney <[EMAIL PROTECTED]> wrote:
[...]
> Regardless updating boot-floppies when new kernels come out would be a
> good idea so that newbies with recent machines can still use Debian.

Iirc Eduard Bloch (blade) provides inofficial updated boot-floppies on
people.debian.org.
  cu andreas

Re: A case study of a new user turned off debian

[Will Newton]

On Tuesday 04 Nov 2003 05:47, Greg Stark wrote:

> to list the available revisions then explicitly
>
> apt-get install libc6:2.3.2-8
>
> Actually this wouldn't really have helped my friend at all because he was
> unlucky enough that the *first* version of libc6 from unstable that he saw
> happened to be the buggy one. That doesn't really happen that often to
> libc6 so he had particularly bad luck there.

Er, doesn't apt-get install libc6=2.3.2-8 do exactly this?

man pages are a wonderful thing.

Re: Grsec/PaX and Exec-shield

[Don Armstrong]

[NB: When reponsding using the web archives, please get the References
and In-Reply-To: correctly. You may also consider setting MFT:]

On Tue, 04 Nov 2003, Peter Busser wrote:
>> PaX would take much more time so I can't do it.
> 
> You cannot do it or you don't want to do it?

Russell has made it adequately clear that he doesn't have the time or
the desire to deal with PaX at this time. As a volunteer, that's
always his prerogative. [As a side note, if you are trying to enlist
volunteers, I strongly suggest not berating other developers while
doing it.[1]]

> In fact, anyone can do it Russell, I'm pretty sure even you can do
> it:

Why not volunteer to make the .deb, get a sponsor and get it uploaded
then? Surely you have more control over where you spend your time than
how Russell spends his own?


Don Armstrong
1: See the mplayer saga for a relevant example.
-- 
Filing a bug is probably not going to get it fixed any faster.
 -- Anthony Towns

http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: A case study of a new user turned off debian

[Cameron Patrick]

On Tue, Nov 04, 2003 at 03:22:10AM -0600, Chris Cheney wrote:
| I refuse to use nvidia products, but I somehow doubt that boards based
| on their nforce2 chipset work properly either.

I have a machine using the nforce2 chipset and the Woody installer
doesn't recognise its IDE controller.  (Proper support is only in kernel
versions >= 2.4.21.)

Incidentally, wasn't there a woody 3.0r2 planned to be released a couple
of months ago with a newer kernel version and miscellaneous security
fixes?

Cameron.

Re: A case study of a new user turned off debian

[Chris Cheney]

On Tue, Nov 04, 2003 at 08:17:06AM +, Andrew Suffield wrote:
> I challenge the assertion that this affects a large portion of users.
> 
> In the past few months, I've installed woody on roughly 30-40
> different types of box, all aged 0-3 years, and only one was
> unsupported by woody (and that was freaky new apple kit).
> 
> I think you have unusual hardware.

Neither are that unusual. I suppose it may have been a little highend
for some when I first bought them, but now they are relatively cheap,
an AthlonXP Via KT400 based motherboard now is as cheap as $42 USD
and the P4 i865/i875 chipset series is as cheap as $62 USD. Perhaps all
of your 0-3 year old systems had older chipset logic in them, or perhaps
truly new systems just aren't common in your country. Via KT400 was
released 16 Aug 2002 and the i865/i875 line was released 14 Apr 2003.
Note that nearly all P4 systems with the 800MHz FSB use the i865/i875
chipsets. I refuse to use nvidia products, but I somehow doubt that
boards based on their nforce2 chipset work properly either.

Regardless updating boot-floppies when new kernels come out would be a
good idea so that newbies with recent machines can still use Debian.

Chris


Release Dates:

Intel
-
i84510 Sept 2001
i87514 Apr  2003
i86521 May  2003

Nvidia
--
nforce   4 June 2001
nforce2 16 July 2002

Via
---
KT266   20 Sept 2000
KT266A   3 Sept 2001
KT333   20 Feb  2002
KT400   16 Aug  2002
KT400A  10 Mar  2003
KT600   18 Jun  2003


signature.asc
Description: Digital signature

Re: Grsec/PaX and Exec-shield

[Peter Busser]

Hi!

> I volunteered to make a package for exec-shield because it meets the Debian 
> criteria, I have time to do it, and it interests me.  PaX would take much 
> more time so I can't do it.

You cannot do it or you don't want to do it? In fact, anyone can do it Russell,
I'm pretty sure even you can do it:

apt-get install kernel-source-2.4.22
cd /usr/src
tar xvfj kernel-source-2.4.22
cd kernel-source-2.4.22
wget http://pageexec.virtualave.net/pax-linux-2.4.22-200310051430.patch
patch -p1 < pax-linux-2.4.22-200310051430.patch

And now you can make menuconfig etc. Now, that wasn't too difficult, right?

> I worry about the security of my own machines, and that of people I know.  
> Exec-shield offers some benefits and is something I can use now.  PaX will 
> not work with the Debian kernel and no-one has volunteered to make it work.  
> Unless someone (maybe you) volunteers to get PaX working with the Debian 
> kernel then it won't be an option for most people.

So you tried to apply PaX to the Debian kernel and failed? Can you explain what
exactly you did, which kernel version you used, which PaX patch and how you
applied it? I really don't understand why an experienced kernel patcher like
you can have problems with a nobrainer patch.

I do it all the time for Adamantix kernels (which are based on the Debian
kernel source packages) and it goes in without a hitch everytime. I wish other
patches were as easy to apply. And it works. The Adamantix kernel is used on
mission critical production systems. I have installed the PaX kernel on a
Debian Sarge system and it worked. Any Adamantix user will tell you that PaX
works. I honestly do not know what you are talking about. And if I didn't know
any better, I would think you were a newbie.

You can even disable some of the PaX features to lower the level of security to
the exec-shield level.

Another thing is that exec-shield is (AFAIK) only availabe on the i386
platform. I always thought that Debian was a multiplatform distribution. PaX is
supported on Alpha, PowerPC, HPPA, Sparc, etc. (I think that AMD64 is also
supported). There is simply no technical reason to chose exec-shield. However,
there may of course be other reasons. Such as political reasons.

Anyways, I included a patch for kernel-source-2.4.22 here. It took me 10
minutes to create it (yeah, slow computers suck). I'm sure Herbert Xu knows
how to apply it. For those who don't:

apt-get source kernel-source-2.4.22
cd kernel-source-2.4.22-2.4.22
bzcat kernel-source-2.4.22+pax.diff.bz2 | patch -p1

Now that can't be too hard, can it?

Groetjes,
Peter Busser
-- 
The Adamantix Project
Taking high-security Linux out of the labs, and into the real world
http://www.adamantix.org/


kernel-source-2.4.22+pax.diff.bz2
Description: Binary data

Re: exec-shield (maybe ITP kernel-patch-exec-shield)

[Manoj Srivastava]

On Mon, 3 Nov 2003 07:42:27 -0500, spender  <[EMAIL PROTECTED]> said: 

> Go ahead and do it.  I could frankly care less if your users get
> owned.  

> There's another exploitable bug in Exec-shield that I've known of
> for months.  Maybe you'll find it after you put it into Debian.
> Maybe not.  This is what happens when you make rush judgements and
> choose to use something based solely on who developed it.  

> I've read the post regarding grsecurity and Debian, and I must say
> that I've never seen a bigger bunch of lazy whiners in my life.
> Maybe if you actually put a kernel hacker in charge of these
> patches, you'd realize you have been whining for months for no
> reason.  Did you ever think that putting someone in charge who can
> code in C might help?  

Hmm. Comparing the above rants to the emails from Russell
 Coker and Ted Ts'o, I would not lend any credence to whatever the
 poster is  saying.  Such an abysmal lack of judgement in one area
 leads one to doubt that good judgement can be exercised by him.

manoj
-- 
He who has transcended the treacherous mire of samsara and ignorance,
who has crossed over, reached the other shore, meditating, motionless
of mind, free from uncertainty, and who is at peace by not clinging to
anything - that is what I call a brahmin. 414
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: A case study of a new user turned off debian

[Chris Cheney]

On Tue, Nov 04, 2003 at 12:47:30AM -0500, Greg Stark wrote:
> So all it would take to make the tools handle this would be to somehow make
> apt aware of more revisions of packages. They're all in the pool after all.
> Short of making some king of humongous mega-Packages file with every revision
> of every package -- which apt wouldn't scale up to anyways -- they're
> currently unavailable to APT.

Er no they are not all in the pool. The only packages in the pool are
the current versions for stable/testing/unstable/experimental. There are
also the few packages that haven't been completely compiled on all archs
yet and so are still left in archive while this is being done.
snapshot.debian.net has nearly every deb since 2002/06/04, but it is not
an official debian repo afaik.

Chris


signature.asc
Description: Digital signature

Re: A case study of a new user turned off debian

[Andrew Suffield]

On Mon, Nov 03, 2003 at 03:05:56PM -0500, Greg Stark wrote:
> I finally convinced a sysadmin friend of mine that Debian was the way and the
> light.

Ah, there's your mistake.

Don't do that. Anybody who uses Debian as a result of this sort of
evangelism is going to have a similar experience, so it's
self-defeating and wastes our time. Debian requires that users have a
desire to make it work.

> All he had to do was install an older version of libc6 and every other package
> would have been happy.

Heh, yaright. Downgrading libc6 tends to break stuff, that's why it
isn't supported.

> All the infrastructure is there to do this,

...except for the bit where the packages support downgrading, which
they don't. They never have, so supporting it in the frontends is
fairly futile.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: A case study of a new user turned off debian

[Andrew Suffield]

On Tue, Nov 04, 2003 at 01:53:36AM -0600, Chris Cheney wrote:
> It would be helpful if Debian could even be installed on machines newer
> than about 2 years old. Neither my KT400 based machine nor my i875P
> based machine could be installed using the standard Debian
> boot-floppies. I had to resort to using Knoppix with debootstrap.
> 
> So no Debian stable really is not an option for a large portion of
> users.

I challenge the assertion that this affects a large portion of users.

In the past few months, I've installed woody on roughly 30-40
different types of box, all aged 0-3 years, and only one was
unsupported by woody (and that was freaky new apple kit).

I think you have unusual hardware.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: comerr-dev (>= 2.0-1.33-2)

[Joerg Jaspert]

Turbo Fredriksson <[EMAIL PROTECTED]> writes:

> Joerg> If it was a package then its available at
> Joerg> snapshot.debian.net
> Is this web only (tried both ssh and ftp)?

Yes.
But apt-able if you want.
For every single day you need. Read its webpage. :)

-- 
bye Joerg
 bignachos: the famous pornview maintainer?
 Christian: *don't* ask why he's typing so slowly
 hey, at least i thoroughly test my packages

Re: A case study of a new user turned off debian

[Chris Cheney]

On Mon, Nov 03, 2003 at 03:43:29PM -0600, Steve Greenland wrote:
> On 03-Nov-03, 14:21 (CST), Erik Steffl <[EMAIL PROTECTED]> wrote: 
> >  > is even worse than unstable>
> 
> Oh, not this crap again. Or perhaps you're contending that I've not
> gotten anything done at work in the last two years using my "useless"
> Debian stable desktop.
> 
> Hint: there's more to "useful" than running the latest version of
> everything. Particularly for a sys admin, who I'd expect to be heavily
> command line oriented, and who doesn't need the latest 3-d games or dvd
> player[1].

It would be helpful if Debian could even be installed on machines newer
than about 2 years old. Neither my KT400 based machine nor my i875P
based machine could be installed using the standard Debian
boot-floppies. I had to resort to using Knoppix with debootstrap.

So no Debian stable really is not an option for a large portion of
users. At least anyone who has a machine newer than when the kernel
on b-f was last updated in Woody's case is kernel 2.4.18 from
Feb 25 2002.

Chris Cheney


signature.asc
Description: Digital signature

Re: [debian-devel] Re: A case study of a new user turned off debian

[Magosányi Árpád]

A levelezőm azt hiszi, hogy [EMAIL PROTECTED] a következőeket írta:
> > > but I wouldn't touch Herbert's kernels with a ten-feet pole.
[]
>   a) I can do better


Please do then.

I guess having kernel-image-vanilla and/or
kernel-image-onlybugfix in debian would not hurt.

>   b) I don't do huge monolitic patches
>   c) I don't like Herbert's taste
>   d) some boxen are used for 2.6 work

I think the same about the rest, however I understand that
Herbert does the best kernel debs you can apt-get install,
and he does a very importand job no one else is willing to
do, and he does it well (but with a different approach I or
you do not do).

-- 
GNU GPL: csak tiszta forrásból

Re: A case study of a new user turned off debian

[Goswin von Brederlow]

Greg Stark <[EMAIL PROTECTED]> writes:

> I finally convinced a sysadmin friend of mine that Debian was the way and the
> light. He started a new job and showed up on his first day to set up his
> machine by installing Debian. In short, things went horribly wrong and he
> started this new job by wasting two days picking up the pieces. He's now very
> leery of suggesting using Debian on other machines at work or of using it
> himself at home.
> 
> What started the chain of events was that a fairly routine minor bug bit the
> latest libc6 release. He's an experienced sysadmin though and wasn't the least
> bit fazed by that. What drove him batty was that it was so hard to recover
> from the mess and all the obvious avenues just made the problem worse.

So he starts out on his first day of work trying out Debian for the
very first time and uses unstbale? No pitty there then.

> All he had to do was install an older version of libc6 and every other package
> would have been happy. All the infrastructure is there to do this, the old
> packages are all on the ftp/http sites, the package may even be sitting in
> apt's cache. But there's no interface for it.

apt-get libc6=version

> The only interface for rolling back is switching the entire machine to an
> earlier distribution and telling apt to try to downgrade -- which is unlikely
> to work. And worse, every time you run apt it only downloads and unpacks
> *more* packages, all of which, of course, fail as well.

snapshot.debian.net just rocks for previous versions.

> What would be really neat would be if aptitude or perhaps even apt checked for
> earlier versions of the package in the pool and offered them as options if the
> current one fails to configure.

There never are any previous versions in the pool of ftp.debian.org.
The old version is removed when the new one enters.

And debs in the cache are easily installed with dpkg if need be.

MfG
Goswin

Re: comerr-dev (>= 2.0-1.33-2)

[Turbo Fredriksson]

> "Joerg" == Joerg Jaspert <[EMAIL PROTECTED]> writes:

Joerg> Turbo Fredriksson <[EMAIL PROTECTED]> writes:
>> Where can I find '= 2.0-1.33-2' (or something around that
>> number)?  It used to be an 'attic' (morgue I think it is
>> called) on ftp-master.  This however only have files roughly
>> two months back...

Joerg> If it was a package then its available at
Joerg> snapshot.debian.net

Is this web only (tried both ssh and ftp)?
-- 
critical Ft. Bragg Soviet strategic Panama genetic congress Legion of
Doom 747 CIA Kennedy iodine BATF munitions Khaddafi
[See http://www.aclu.org/echelonwatch/index.html for more about this]

Re: comerr-dev (>= 2.0-1.33-2)

[Turbo Fredriksson]

> "Theodore" == Theodore Ts'o <[EMAIL PROTECTED]> writes:

Theodore> com-err is pretty safe and low-risk, so there should be
Theodore> no problem using the latest version in unstable.

Oki. Will do. Thanx.


-- 
fissionable radar KGB 747 Saddam Hussein iodine domestic disruption
president BATF explosion CIA FSF $400 million in gold bullion colonel
Legion of Doom
[See http://www.aclu.org/echelonwatch/index.html for more about this]

Re: A case study of a new user turned off debian

[Joey Hess]

Greg Stark wrote:
> The only interface for rolling back is switching the entire machine to an
> earlier distribution and telling apt to try to downgrade -- which is unlikely
> to work. And worse, every time you run apt it only downloads and unpacks
> *more* packages, all of which, of course, fail as well.

(I'm suprised that I need to include my attachment on this list; I
normally only post it to -user.)

Hardly true. Besides dpkg, if your friend had testing in sources.list in
addition to unstable, he would only need to open aptitude, hit enter on
libc6, and he would get a list like this (this is older unstable and
stable though):

  --\ Versions
  ih  2.3.2.ds1-8   
  
  ph  2.2.5-6

Press + on the desired version. Here it breaks 600 packages, but
presumably it would not with the libc6 in testing. And yes, aptitude
will really downgrade[1] and I'm sure this qualifies as an "interface".
Not the best possible one..

Suggested project: Create a package that, a-l-apt-move, pulls packages
out of the apt cache and creates apt repositories from them. But make it
create a new repository after every upgrade, by hooking into apt. And
auto-add these repositories to sources.list, and remove old ones after a
while, the whole nine yards.

-- 
see shy jo

[1] vis --

[EMAIL PROTECTED]:/home/joey>aptitude
Reading changelogs... Done
dpkg - warning: downgrading pdmenu from 1.2.82 to 1.2.69.
(Reading database ... 163455 files and directories currently installed.)
Preparing to replace pdmenu 1.2.82 (using .../pdmenu/pdmenu_1.2.69_i386.deb) ...
Unpacking replacement pdmenu ...
Setting up pdmenu (1.2.69) ...
Installing new version of config file /etc/pdmenurc ...
Installing new version of config file /etc/menu-methods/pdmenu ...

Press return to continue.

Reading changelogs... Done
(Reading database ... 163456 files and directories currently installed.)
Preparing to replace pdmenu 1.2.69 (using .../pdmenu_1.2.82_i386.deb) ...
Unpacking replacement pdmenu ...
Setting up pdmenu (1.2.82) ...
Installing new version of config file /etc/pdmenurc ...
Installing new version of config file /etc/menu-methods/pdmenu ...

Press return to continue.
Eight reasons why you should be using aptitude instead of apt-get.

1. aptitude can look just like apt-get

   If you run 'aptitude update' or 'aptitude upgrade' or 'aptitude
   install', it looks and works just like apt-get, with a few enhancements.
   So there is no learning curve.

2. aptitude tracks automatically installed packages

   Stop worrying about pruning unused libraries and support packages from
   your system. If you use aptitude to install everything, it will keep
   track of what packages are pulled in by dependencies alone, and remove
   those packages when they are no longer needed.

3. aptitude sanely handles recommends

   A long-standing failure of apt-get has been its lack of support for
   the Recommends relationship. Which is a problem because many packages
   in Debian rely on Recommends to pull in software that the average user
   generally uses with the package. This is a not uncommon cause of
   trouble, even though apt-get recently became able to at least mention
   recommended packages, it's easy to miss its warnings.

   Aptitude supports Recommends by default, and can be confgigured to
   support Suggests too. It even supports installing recommended packages
   when used in command-line mode.

4. use aptitude as a normal user and avoid hosing your system

   Maybe you didn't know that you can run aptitude in gui mode as a regular
   user. Make any changes you'd like to try out. If you get into a real
   mess, you can hit 'q' and exit, your changes will not be saved.
   (aptitude also lets you use ctrl-u to undo changes). Since it's running
   as a normal user, you cannot hose your system until you tell aptitude to
   do something, at which point it will prompt you for your root password.

5. aptitude has a powerful UI and searching capabilities

   Between aptitude's categorical browser and its great support for
   mutt-style filtering and searching of packages by name, description,
   maintainer, dependencies, etc, you should be able to find packages
   faster than ever before using aptitude.

6. aptitude makes it easy to keep track of obsolete software

   If Debian stops distributing a package, apt will leave it on your system
   indefinitly, with no warnings, and no upgrades. Aptitude lists such
   packages in its "Obsolete and Locally Created Packages" section, so you
   can be informed of the problem and do something about it.

7. aptitude has an interface to the Debian task system

   Aptitude lets you use Debian's task system as it was designed to be
   used. You can browse the available tasks, select a task for install, and
   then dig into it and de-select parts of the task that you don't want.
   apt-get has no support for tasks, and aptitude is better even than
   special purpose tools like