Re: Debian Archive Automatic Signing Key 2005
also sprach DePriest, Jason R. [EMAIL PROTECTED] [2005.02.18.0530 +0100]: Since no one has responded to this recently. http://lists.debian.org/debian-security/2005/01/msg00188.html wasn't enough? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: using sarge on production machines
--- kurt kuene [EMAIL PROTECTED] wrote: All of my 3 webservers (apache php mysql java tomcat). on two other webserver I run woody with some packages from sarge (apt-pining) and the mail relay servers (spamassasin amavisd postfix clamav). I run sarge because I need more recent packages and I do not want to use an other distro because I dont trust them as I trust the debian project. I do not want to complain about sarge not being released, this is not the place to do that. but my users (I work for a university of art and do linux based web and mailserver there) want newer packages. so somehow I was forced to upgrade to a newer version of debian. Some people have already said it. Use stable with backports. Where this absolutely won't do use UML and chroot it and run sarge in it. This is what I'm doing[0]. Harry [0] Not necessarily a positive recommendation ;) = Harry Join team plico. http://www.hjackson.org/cgi-bin/folding/index.pl __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please help test Snort 2.3.0 (experimental) packages
On Wed, Feb 09, 2005 at 08:48:20AM +0100, Javier Fernández-Sanguino Peña wrote: Hi everyone, I've recently uploaded (to experimental only) new Snort 2.3.0 packages (based on the release made by the Snort team last January 25th). One of the main reasons I've uploaded this to experimental (and not sid) is that I've introduced /etc/default/snort and made /etc/snort/snort.common.parameters obsolete. (...) I've received no feedback so I will probably make an upload to sid real soon now. If you are using Snort in your sid system and something breaks when you upgrade please reports the bugs in the BTS. Regards Javier signature.asc Description: Digital signature
Re: using sarge on production machines
On Fri, Feb 18, 2005 at 02:25:17AM -0800, Harry wrote: use UML and chroot it and run sarge in it. What does this gain you? A compomised uml is as bad as a compromised system. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
On Fri, Feb 18, 2005 at 04:40:56AM -0800, Harry wrote: --- Marc Haber [EMAIL PROTECTED] wrote: What does this gain you? A compomised uml is as bad as a compromised system. I can wipe the UML if the host has not been compromised. This saves me a journey to the location where the host is stored and ?75 quid to get to the machine to reinstall the host. If I have ten customers running various falvours of Debian in their UML its sods law that eventually one of them is going to be cracked. If I can prevent (as much as feasbly possible) this from spilling onto the host then it saves me a lot of work. Nice idea. However, if somebody roots one of the UML installation, that somebody can probably escape out of the UML and gain user privileges on the host system and then use one of the numerous kernel vulnerabilities (I have long lost track of them) to escalate to root on the host system. I am quite sceptical about using UML to allow security flaws in UMLled system components. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
--- Marc Haber [EMAIL PROTECTED] wrote: On Fri, Feb 18, 2005 at 02:25:17AM -0800, Harry wrote: use UML and chroot it and run sarge in it. What does this gain you? A compomised uml is as bad as a compromised system. I can wipe the UML if the host has not been compromised. This saves me a journey to the location where the host is stored and £75 quid to get to the machine to reinstall the host. If I have ten customers running various falvours of Debian in their UML its sods law that eventually one of them is going to be cracked. If I can prevent (as much as feasbly possible) this from spilling onto the host then it saves me a lot of work. Harry __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
Marc == Marc Haber [EMAIL PROTECTED] writes: Marc Nice idea. However, if somebody roots one of the UML Marc installation, that somebody can probably escape out of the Marc UML and gain user privileges on the host system and then use Marc one of the numerous kernel vulnerabilities (I have long lost Marc track of them) to escalate to root on the host system. Marc I am quite sceptical about using UML to allow security flaws Marc in UMLled system components. How pray tell do they do that ? A minimal UML chroot requires one file - the user mode linux binary. Check out the following :- http://user-mode-linux.sourceforge.net/slides/ists2002/umlsec.htm which discusses how UML can help with security and mentions chroot. Since this paper was written many people have used chrooted UMLs with great success. And just because one wants to use newer versions of packages on another machine (in theis case a virtual machine) doesn't mean that the physical host is left running old versions of packages with security holes in it. The original poster never mentioned leaving the machine unsecured. Sincerely, Adrian Phillips -- Who really wrote the works of William Shakespeare ? http://www.pbs.org/wgbh/pages/frontline/shakespeare/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel security advice
On Fri, Feb 18, 2005 at 05:07:40PM +1100, [EMAIL PROTECTED] wrote: I like using non-modular kernels to prevent LKMs Of course, running a non-modular kernel doesn't prevent kernel rootkits. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
--- Marc Haber [EMAIL PROTECTED] wrote: Nice idea. However, if somebody roots one of the UML installation, that somebody can probably escape out of the UML and gain user privileges on the host system and then use one of the numerous kernel vulnerabilities (I have long lost track of them) to escalate to root on the host system. I can't guarantee 100% security but I can make it harder for someone to do it, its a trade off. As for gaining user rights on the host. Each user has passwords disabled and is in a chroot jail. The kernel is statically linked so there are 2 files in the jail, the kernel and the filesystem. It might not be bullet but then I have yet to hear of anything that is. I am quite sceptical about using UML to allow security flaws in UMLled system components. Thats not what I am doing, I offer UML accounts because people want root on a machine. I am certainly not about to give them all root on the host. Harry __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
* kurt kuene: so what strategies to use if you are forced to work with a distro other then woody? I used to run unstable with irregular updates, and manually backport upstream security fixes to the version in unstable (especially if a new Debian packages was not available in unstable). From time to time, there was quite a lot of significant breakage (especially when we weren't as close to the release as we are now), but as I didn't have to fulfill any SLAs, it was typically no big deal to sort out the issues when they arose. A different model uses unstable and periodic updates (say on a fixed day of the week), and security updates from unstable. This works reasonably well, too, although I wouldn't recommend to follow this model after the sarge release (because unstable will probably be less stable for a few months; there are some quite significant transitions that have been delayed so far because of the release). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
hi first thanks a lot. you all helped me very much. apparently running stable with backports is best. so I made the wrong decision upgrading my systems to sarge. :( I did this because I thought it will come out soon and It is safe enough to use it. This was six month ago. If I could turn back time I would use backports. Florian Weimer [EMAIL PROTECTED] From time to time, there was quite a lot of significant breakage (especially when we weren't as close to the release as we are now), but as I didn't have to fulfill any SLAs, it was typically no big deal to sort out the issues when they arose. so you think unstable with an eye on problems is still better than testing? I don't know. (especially when we weren't as close to the release as we are now) close to the release? this was what I thought 6 month ago (changed to testing) and it may take an other six month. if only the security team would start working *sigh*. From: Harry [EMAIL PROTECTED] use UML and chroot it and run sarge in it. UML is no option for me because my users do not need root. on some machines they have ftp only without shell on the oder they have a shell user account without ftp. if uml gets hacked I need to use my backup anyway. naturally I have a complete backup of the systems. so if something bad happens I can play back everything, plug the hole and go back online. this would cost me some time, but more nerves. :| From: Marc Haber [EMAIL PROTECTED] It is better to have a broken service. If you know exactly what you're doing, and take a close look at changelogs, this might be a good option. Maybe don't track unstable closely, but only update every - say - two weeks, while keeping a close look at new uploads' changelogs to spot security issues. what I do no understand is why this should be more secure than running testing? so nobody here is using sarge on productive systems?? -- some use stable. this is best. -- if they need newer packages, using backports is best. I would do this if i could downgrade from sarge. but this is a pain in ... -- others use sid and makes updates only every two weeks if no security issue appear. -- I am always told that sarge comes soon. so why use sid? if sarge is coming soon why worry? summary: I would use backport if I could go back. I would not use sid because of stability. apt-pining gives a false security feeling. so pining is deceptive. -- Nobody is using Sarge? Am I the only one running Sarge on Servers? why? thats what I get to hear... no one uses sarge for important things? it is quite stable. but how to make it secure? at least some people know what I mean: http://secure-testing.alioth.debian.org/ fact is: I am using Sarge! :/ are there strategies in Securing Sarge that I have missed? Or would someone suggest me to downgrade, because it is far too dangerous using sarge on servers, or even on machines that are on the net? again thanks a lot for all the help :) regards kuene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
On Fri, Feb 18, 2005 at 03:28:11PM +0100, kurt kuene wrote: so you think unstable with an eye on problems is still better than testing? I don't know. Unstable is fine if you know exactly what you're doing and can fix a broken system yourself. unstable is potentiall unstable (surprise), but more secure since security-related updates go into unstable immediately. if only the security team would start working *sigh*. afaik, the security team is ready, but the infrastructure is not. From: Marc Haber [EMAIL PROTECTED] It is better to have a broken service. If you know exactly what you're doing, and take a close look at changelogs, this might be a good option. Maybe don't track unstable closely, but only update every - say - two weeks, while keeping a close look at new uploads' changelogs to spot security issues. what I do no understand is why this should be more secure than running testing? You can immediately install a package that received a security update on an unstable system. If you do the same on testing (installing a package from unstable on a testing system), you will pull in libraries from unstable, potentially introducing breakage. so nobody here is using sarge on productive systems?? Well, I am not. I am always told that sarge comes soon. so why use sid? if sarge is coming soon why worry? Currently, the sarge security infrastructure is missing. Thus, you will have a mandatory delay to wait for a fixed package to migrate from unstable to testing. apt-pining gives a false security feeling. so pining is deceptive. Well, pinning was never intended to allow mixded-distribution systems. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel security advice
Greetings, Am Freitag, 18. Februar 2005 04:51 schrieb JM: Hello, * Besides grsecurity patch, pax etc...What other recommendations are there to patch a kernel on a woody or sarge production server? * Any experiences/opinions with the debian-hardened kernels? * Is it that terrible running X if access is not allowed from the network, only locally? I recently had some trouble with pax (gresecurity) and java (sun). Thus if you use tomcat etc., pax won't be an option. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel security advice
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): I like using non-modular kernels to prevent LKMs http://www.phrack.org/phrack/58/p58-0x07 In this paper, we will discuss way of abusing the Linux kernel (syscalls mostly) without help of module support or System.map at all, so that we assume that the reader will have a clue about what LKM is, how a LKM is loaded into kernel etc. If you are not sure, look at some documentation (paragraph 6. [1], [2], [3]) Imagine a scenario of a poor man which needs to change some interesting linux syscall and LKM support is not compiled in. Imagine he have got a box, he got root but the admin is so paranoid and he (or tripwire) don't poor man's patched sshd and that box have not gcc/lib/.h needed for compiling of his favourite LKM rootkit. So there are some solutions, step by step and as an appendix, a full-featured linux-ia32 rootkit, an example/tool, which implements all the techinques described here. [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
Marc Haber schrieb am Friday, den 18. February 2005: On Fri, Feb 18, 2005 at 04:40:56AM -0800, Harry wrote: --- Marc Haber [EMAIL PROTECTED] wrote: What does this gain you? A compomised uml is as bad as a compromised system. Nice idea. However, if somebody roots one of the UML installation, that somebody can probably escape out of the UML and gain user privileges on the host system and then use one of the numerous kernel vulnerabilities (I have long lost track of them) to escalate to root on the host system. I am quite sceptical about using UML to allow security flaws in UMLled system components. Have a look at vservers (http://linux-vserver.org/), designed specifically to fix the problems that can be circumvented with chroots, take up significantly less resources than UMLs, and are really quite cool. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Archive Automatic Signing Key 2005
Am Freitag, 18. Februar 2005 09:44 schrieb martin f krafft: also sprach DePriest, Jason R. [EMAIL PROTECTED] [2005.02.18.0530 +0100]: Since no one has responded to this recently. http://lists.debian.org/debian-security/2005/01/msg00188.html wasn't enough? Yes it was enough. I was really surprised that the new key didn't exist at that time and the problem with the empty Release.gpg. Thank you! A lucky Debian user -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel security advice
On Fri, Feb 18, 2005 at 08:11:28AM -0500, Michael Stone wrote: On Fri, Feb 18, 2005 at 05:07:40PM +1100, [EMAIL PROTECTED] wrote: I like using non-modular kernels to prevent LKMs Of course, running a non-modular kernel doesn't prevent kernel rootkits. yes - and I have been the victim of one of these (the 'suckit' rootkit). But at least using non-modular kernels prevents one class of attacks... Campbell Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel security advice
On Sat, 19 Feb 2005 [EMAIL PROTECTED] wrote: On Fri, Feb 18, 2005 at 08:11:28AM -0500, Michael Stone wrote: On Fri, Feb 18, 2005 at 05:07:40PM +1100, [EMAIL PROTECTED] wrote: I like using non-modular kernels to prevent LKMs Of course, running a non-modular kernel doesn't prevent kernel rootkits. yes - and I have been the victim of one of these (the 'suckit' rootkit). But at least using non-modular kernels prevents one class of attacks... other (secure) kernel options .. http://Linux-Sec.net/Kernel some are too much for me to understand its benefits vs running generically - i usually also install libsafe in some attempt to prevent buffer overflow of apps ( if that works as advertised ) - i usually take 1 min to patch the generic kernel with openwall - i usually turn on all the security options at the end of the make xconfig /tmp, /proc, .. - i usually change kernel params for syncookies - do more network, system and suser hardening which i think is more important than the kernel security tweeking(addon) options ? - endless list of hardening .. how much is good enough ?? - if it's simple to understand and takes 30 seconds to implement, it'd be a good thing to do c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsubscribe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 687-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze February 18th, 2005 http://www.debian.org/security/faq - -- Package: bidwatcher Vulnerability : format string Problem-Type : remote Debian-specific: no CVE ID : CAN-2005-0158 Ulf Härnhammar from the Debian Security Audit Project discovered a format string vulnerability in bidwatcher, a tool for watching and bidding on eBay auctions. This problem can be triggered remotely by a web server of eBay, or someone pretending to be eBay, sending certain data back. As of version 1.3.17 the program uses cURL and is not vulnerable anymore. For the stable distribution (woody) this problem has been fixed in version 1.3.3-1woody1. For the unstable distribution (sid) this problem will be fixed soon. We recommend that you upgrade your bidwatcher package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1.dsc Size/MD5 checksum: 637 2a65bc6cbed81466721793318948aed4 http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1.diff.gz Size/MD5 checksum: 3368 b36c63ae2e6a5c42bb13c506f980e1ba http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3.orig.tar.gz Size/MD5 checksum: 136679 2094c233fa21c80f65d5dce1bf4fb133 Alpha architecture: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1_alpha.deb Size/MD5 checksum:95574 dc1f1c5581af8526fe916ea0246fec8e ARM architecture: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1_arm.deb Size/MD5 checksum:85060 6dff37d2dbb68c869553b4008b47f7df Intel IA-32 architecture: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1_i386.deb Size/MD5 checksum:82152 49d709d2f5a81dcfd8b462d60af5218b Intel IA-64 architecture: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1_ia64.deb Size/MD5 checksum: 103978 874237be875f51817240c7ce79a96732 HP Precision architecture: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1_hppa.deb Size/MD5 checksum: 109292 b164a9dc42b40a2eda85896dfec8d310 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1_m68k.deb Size/MD5 checksum:79942 7d101eb867927c88d5ec2fd127494497 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1_mips.deb Size/MD5 checksum:81562 f0f65a2f84feef4dc4afa5cb82126350 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1_mipsel.deb Size/MD5 checksum:80606 1e2786878f126a90e26c6894d44f7d35 PowerPC architecture: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1_powerpc.deb Size/MD5 checksum:81478 19128bd956597ed8ed7c6780b09ee15d IBM S/390 architecture: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1_s390.deb Size/MD5 checksum:80902 d4d892f6ffb796106bdcb09c8ed3181a Sun Sparc architecture: http://security.debian.org/pool/updates/main/b/bidwatcher/bidwatcher_1.3.3-1woody1_sparc.deb Size/MD5 checksum:80802 d5882fbca7b6a7b2205a1fb8b5c76112 These files will probably be moved into the stable distribution on its next update. - - For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce@lists.debian.org Package info: `apt-cache show pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCFh7aW5ql+IAeqTIRAjjLAJ41DHcqCxgorvj2YOZQ1THak4eaKgCdFwoy
Re: Kernel security advice
On Sat, Feb 19, 2005 at 09:42:48AM +1100, [EMAIL PROTECTED] wrote: yes - and I have been the victim of one of these (the 'suckit' rootkit). But at least using non-modular kernels prevents one class of attacks... Sure. At a fairly high cost in administrative overhead you can prevent one fairly narrow category of attack (one which I've seen fail in the field a *lot* because the kiddies run into problems of compatability between kernel versions). I have yet to see a convincing argument that the dubious benefit justifies the cost. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
hi David Ehle [EMAIL PROTECTED] wrote: IF, I had, say late last year heard that Sarge was going stable REAL SOON, and was trying to decide if I was going to go through the hoops being described, or just do an early upgrade, since there WAS at the time a working security repository for sarge, I might have, Hypothetically, moved some of my production systems to Testing. If that had occurred, I might be able to tell you that things have gone relativly painlessly and safely. But as was pointed out earlier, doing something like that IS kind of iffy, so of course, I couldn't do such a thing... this is exactly my situation! you described it better then me :) so there WAS really a security team at that time. I eventually have thought that I had only dreamed or misunderstood something. but this is not debian-like. I have thought that if they run security updates they will not just stop them again. however the situation is as it is. not good for me. but I have been very lucky because nothing special happened to my systems until now. I touch wood that the systems remain secure until the security-team begins its work again :) but this might not be enough. also the trust that I put in the debian project might not be enough. although debian sarge is called testing it is relatively stable and most of the time also secure comparing to other distros or even operating systems. but this is not enough. If debian sets up a security team for a distro, this persuades admins to upgrade. but then the work is stopped or has to be stopped for what reason does not matter. I believe that there are very good reasons for the stop (infrastructure issue). however I think that the debian project should develop a security concept that covers such problems at least partly. I think even that there are approaches: for example the priority with which a package transits from unstable to testing. Do packages with important security problems (for example: remote execution of arbitrary code) change faster from unstable to testing? I think this is so but I am not sure... Are there other debian related sources about securing sarge besides of this? http://secure-testing.alioth.debian.org/ How does debian deal with the problem? and specially because of this: Running unreleased software on production systems is a touchy issue. Most system administrators simply won't admit it. so, if admins do not admit it. no one talks about it. if no one talks about some thing, does this improve security?? I know that debian has a stable and very secure release but what resources does the debian project give to admins who have done the mistake of running sarge too early, because of reasons described above. what strategies are applied to deal with the problem? I talk like this because I trust the debian project very much and I also expect very much from it. the expectations are very high because debian does a very good job. so there must be some idea around ... thanks a lot again for the interesting feedback. It has clarified a many things. regards kuene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
