Torrent tracker problem
These torrents are not working with the Debian tracker. http://cdimage.debian.org/debian-cd/7.6.0/source/bt-cd/debian-update-7.6.0-source-CD-1.iso.torrent http://cdimage.debian.org/debian-cd/7.6.0/source/bt-cd/debian-update-7.6.0-source-CD-2.iso.torrent Torrent Editor and also my Torrent software says that the tracker has not seen these torrents and is not working with them. Check for yourself at these links: http://torrenteditor.com/edit.php?url=http%3A%2F%2Fcdimage.debian.org%2Fdebian-cd%2F7.6.0%2Fsource%2Fbt-cd%2Fdebian-update-7.6.0-source-CD-1.iso.torrent http://torrenteditor.com/edit.php?url=http%3A%2F%2Fcdimage.debian.org%2Fdebian-cd%2F7.6.0%2Fsource%2Fbt-cd%2Fdebian-update-7.6.0-source-CD-2.iso.torrent I am only seeding the i386, amd-64, powerpc and source media ISO's. Not sure if there are problems with other media.
Re: concrete steps for improving apt downloading security and privacy
Thanks, but if you will notice, I have that link already listed at the bottom of my message. Also, you should not respond directly to people unless they specifically ask you to do so. I did not ask. On Wed, Jul 9, 2014 at 11:52 PM, Reid Sutherland r...@vianet.ca wrote: https://www.debian.org/ Go to CD ISO Images, then Verify. On Jul 10, 2014, at 12:24 AM, Kitty Cat realizar.la@gmail.com wrote: Thanks. I'm new here. I was not on this list then. However, I just read the thread: https://lists.debian.org/debian-security/2011/01/msg2.html I saw that some of my concerns were mentioned there about obtaining and verifying installation media, MITM attacks, etc. I have previously verified installation media via the methods described in the FAQ, downloading GPG keys, etc. and still had an issue of having aptitude telling me that all available packages are from untrusted sources. (This was some years ago when I had this issue) I seem to remember being offered security updates for the kernel, OpenSSL, SSH, etc. where my only option was to download untrusted packages. I would get warning messages from aptitude about installing security updates. Maybe there should be written a document that describes in detail in easy to understand language what steps to take to verify keys and verify that apt has not been compromised in an already installed system. And also verifying that GPG has not been compromised. It is the job of the NSA to be able to compromise systems. We should make that task as difficult as possible at every level and also be able to easily verify that our system has not been corrupted. I think having a good guide to checking your installed Debian system would be of use. Particularly useful would be instructions to check to see if your system has been compromised by validating all already installed packages. MS Windows has an option to check installed Windows components. Some relevant links that I have previously discovered: https://wiki.debian.org/Keysigning https://wiki.debian.org/Keysigning/Coordination http://www.debian.org/CD/verify http://www.debian.org/CD/faq/#verify On Wed, Jul 9, 2014 at 8:11 PM, Michael Stone mst...@debian.org wrote: On Wed, Jul 09, 2014 at 06:29:09PM -0600, Kitty Cat wrote: For years I have been concerned with MITM attacks on Debian mirrors. We discussed this literally within the past couple of months on this list, at length. Have you read the archives, including the posts about how to establish a trust path to the ISOs? Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140710021124.ga27...@mathom.us
Re: concrete steps for improving apt downloading security and privacy
For years I have been concerned with MITM attacks on Debian mirrors. I think the only valid solution would be to individually sign EACH package with a valid GPG signature from a trusted source. I think EACH official package from Debian should be GPG signed by both package maintainers and also signed by official Debian release people. For example... What is secure about this download link? http://cdimage.debian.org/debian-cd/7.5.0/i386/iso-cd/debian-7.5.0-i386-netinst.iso Sure I can also download and check the signatures from here: http://cdimage.debian.org/debian-cd/7.5.0/i386/iso-cd/ However, what if http://cdimage.debian.org/ is actually an NSA mirror site and not the real one? Lets say that I want download anything from http://cdimage.debian.org/ http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/ My downloader resolves http://cdimage.debian.org/ http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/ to NSA mirror site through DNS cache poisoning or some other means. So, whatever I am downloading is already compromised. All signatures are valid but are from the NSA. So there is no way for me to actually check that I have downloaded valid files if everything that I see is actually faked! If I go edit apt sources list and manage to get an actual real Debian server update, then apt tells me that all packages available to download are security compromised. Or lets say that I get a real install ISO disc and then later on my apt mirror site is redirected to NSA mirror. Apt will tell me that all packages available to download are security compromised. One of the two scenarios above has actually happened to me!!! I don't know if it is actually the NSA but it DID happen to me. Aptitude was telling me that every single package available for download was compromised! Think about this for a minute. If my ISP or upstream provider is secretly cooperating with the NSA and the NSA wants to compromise my machine, they can make it so that everything that I download is through an NSA source! *Remember, the NSA can create VALID SSL certificates for any website on the fly.* Your web browser trusts many certificate authorities and which ones are cooperating with the NSA? So how can we really be sure that our Debian install has not been compromised from the beginning? On Thu, Jul 3, 2014 at 8:44 PM, Hans-Christoph Steiner h...@at.or.at wrote: After the latest revelation about NSA tracking all Tor downloads[1] (with source code!) and the whole Debian mirrors and MITM redux, I think we should start talking about concrete steps that we can take to improve the situation. The first things that came to mind would be quite easy to do: * include apt-transport-https by default in Debian * include existing HTTPS mirrors wherever Debian mirrors are listed * https://www.debian.org/mirror/list * netselect-apt * http://http.debian.net/ * apt-get's mirror:// * make http://cdn.debian.net/ have an only-HTTPS version * encourage mirror operators to set up a Tor Hidden Service There is already a good collection of HTTPS mirrors to choose from (not-counting all the ones that have HTTPS enabled without a proper certificate). https://mirror.i3d.net/pub/debian/ https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/ https://mirror.cse.unsw.edu.au/debian/ https://mirrors.kernel.org/debian/ https://the.earth.li/debian/ https://mirror.vorboss.net/debian/ https://ftp.arnes.si/pub/packages/debian/ https://ftp.iitm.ac.in/debian/ https://ftp.uni-erlangen.de/debian/ https://ftp-stud.hs-esslingen.de/debian/ https://mirrors.ustc.edu.cn/debian/ https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/ https://dennou-q.gfd-dennou.org/debian/ https://dennou-k.gfd-dennou.org/debian/ https://dennou-h.gfd-dennou.org/debian/ .hc [1] http://daserste.ndr.de/panorama/aktuell/nsa230_page-1.html -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b6150a.3000...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
Thanks. I'm new here. I was not on this list then. However, I just read the thread: https://lists.debian.org/debian-security/2011/01/msg2.html I saw that some of my concerns were mentioned there about obtaining and verifying installation media, MITM attacks, etc. I have previously verified installation media via the methods described in the FAQ, downloading GPG keys, etc. and still had an issue of having aptitude telling me that all available packages are from untrusted sources. (This was some years ago when I had this issue) I seem to remember being offered security updates for the kernel, OpenSSL, SSH, etc. where my only option was to download untrusted packages. I would get warning messages from aptitude about installing security updates. Maybe there should be written a document that describes in detail in easy to understand language what steps to take to verify keys and verify that apt has not been compromised in an already installed system. And also verifying that GPG has not been compromised. It is the job of the NSA to be able to compromise systems. We should make that task as difficult as possible at every level and also be able to easily verify that our system has not been corrupted. I think having a good guide to checking your installed Debian system would be of use. Particularly useful would be instructions to check to see if your system has been compromised by validating all already installed packages. MS Windows has an option to check installed Windows components. Some relevant links that I have previously discovered: https://wiki.debian.org/Keysigning https://wiki.debian.org/Keysigning/Coordination http://www.debian.org/CD/verify http://www.debian.org/CD/faq/#verify On Wed, Jul 9, 2014 at 8:11 PM, Michael Stone mst...@debian.org wrote: On Wed, Jul 09, 2014 at 06:29:09PM -0600, Kitty Cat wrote: For years I have been concerned with MITM attacks on Debian mirrors. We discussed this literally within the past couple of months on this list, at length. Have you read the archives, including the posts about how to establish a trust path to the ISOs? Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140710021124.ga27...@mathom.us
Re: Debian owned by the NSA
Don't be alarmed, these are your overlords. Pay no attention. Go about your business as usual as they try to take over the world. https://www.youtube.com/watch?v=c9NAiojPzro
Re: Spam fighting
On Mon, Jul 05, 2010 at 02:23:03PM +0200, Wojciech Ziniewicz wrote: Personally i get 0-5 spam messages per month from the debian-isp and debian-security list that are not filtered and appear as non-spam messages. Moreover i see that in my spam folder i have like 3-7 spam messages per hour. I'm 600 short of 100,000 pieces of spam since 26/1/2010. :) This isn't just from debian lists, though. It's all-up. This does not take into account the false negatives. I'm pretty sure I'm over 102,000 with those. That may seem a tad high to some but imo a false negative is better than a false positive. On top of this there are 2,300 virus laden emails over the same time period. What's the problem actually ? Unrealistic expectations, I'd say. -- A search of his car uncovered pornography, a homemade sex aid, women's stockings and a Jack Russell terrier. - http://www.news.com.au/story/0%2C27574%2C24675808-421%2C00.html -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100705203151.gr2...@zip.com.au
openssh lockup after blacklist hits
I got connections from an unknown IP to openssh today. openssh logged: Public key ... blacklisted (see ssh-vulnkey(1)) 19 times, each time with a different key and then ssh would not respond any more and connections to it froze like so: $ ssh [EMAIL PROTECTED] -v OpenSSH_4.3p2 Debian-9etch1, OpenSSL 0.9.8c 05 Sep 2006 debug1: Reading configuration data /home/.../.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to ... [...] port 22. debug1: Connection established. debug1: identity file /home/.../.ssh/identity type -1 debug1: identity file /home/.../.ssh/id_rsa type 1 debug1: identity file /home/.../.ssh/id_dsa type -1 ssh_exchange_identification: Connection closed by remote host Admittantly, not running etch2 but there's nothing in the changelog that deals with this so I don't think that would've helped. This is running on a 64bit intel box. -- Police noticed some rustling sounds from Linn's bottom area and on closer inspection a roll of cash was found protruding from Linn's anus, the full amount of cash taken in the robbery. - http://www.smh.com.au/news/world/robber-hides-loot-up-his-booty/2008/05/09/1210131248617.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssh lockup after blacklist hits
On Tue, May 20, 2008 at 12:52:54AM -0600, Michael Loftis wrote: MaxStartups. Ah. That'd do it. First time I hit that. Thanks and sorry for the noise. On the down side it seems people are already starting to exploit the blacklisted keys. -- Police noticed some rustling sounds from Linn's bottom area and on closer inspection a roll of cash was found protruding from Linn's anus, the full amount of cash taken in the robbery. - http://www.smh.com.au/news/world/robber-hides-loot-up-his-booty/2008/05/09/1210131248617.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssh remote upgrade procedure?
On Tue, May 20, 2008 at 08:20:04AM +0100, Alexandros Papadopoulos wrote: + I enabled password authentication in sshd_config (PasswordAuthentication yes) + aptitude update aptitude dist-upgrade, which updated the packages and restarted the openssh daemon + shortly thereafter my SSH connection was terminated + I tried to login to the machine, but never got the chance: ... I can't understand what's wrong - would very much like to see a howto detailing what the upgrade procedure is for people maintaining servers remotely. While not of much help now, the main step in your procedure that you missed is between step 1 and 2 above. That is, to test to make sure that you can still log in, on the offchance something goes whacky. -- Police noticed some rustling sounds from Linn's bottom area and on closer inspection a roll of cash was found protruding from Linn's anus, the full amount of cash taken in the robbery. - http://www.smh.com.au/news/world/robber-hides-loot-up-his-booty/2008/05/09/1210131248617.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh-vulnkey and authorized_keys
On Thu, May 15, 2008 at 09:03:24AM -0400, Noah Meyerhans wrote: On Thu, May 15, 2008 at 11:08:58AM +0300, Mikko Rapeli wrote: I think, and hope, Debian openssh packages will be updated too. Yes, expect it within hours. I'm curious... is there a way to get ssh-vulnkey to print out the line number of the keys it speaks of in the known_hosts file? The information it currently provides, unless I'm missing something, doesn't really help in identifying the known bad keys... :/ -- Police noticed some rustling sounds from Linn's bottom area and on closer inspection a roll of cash was found protruding from Linn's anus, the full amount of cash taken in the robbery. - http://www.smh.com.au/news/world/robber-hides-loot-up-his-booty/2008/05/09/1210131248617.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thanks to Debian OpenSSL developers
On Fri, May 16, 2008 at 07:47:31AM +0200, Yves-Alexis Perez wrote: On jeu, 2008-05-15 at 23:38 +0200, Steffen Schulz wrote: or what its worth...I see 3.5 problems that accumulated into this mess: - OpenSSL is complex and critical but the code is little documented. Code pieces like the ones in question should have warning-labels printed all over them and a distinguished place and interface. There was a #ifndef PURIFY just before the instruction commented by #if 0. /* Uninitialised memory used intentionally to add entropy */ That, I believe, speaks volumes. #ifndef PURIFY says very little. Most, if not all languages provide the ability to enter in comments for a reason. -- Police noticed some rustling sounds from Linn's bottom area and on closer inspection a roll of cash was found protruding from Linn's anus, the full amount of cash taken in the robbery. - http://www.smh.com.au/news/world/robber-hides-loot-up-his-booty/2008/05/09/1210131248617.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1576-1] New openssh packages fix predictable randomness
On Wed, May 14, 2008 at 12:17:14PM +0200, Jan Luehr wrote: 1. Install the security updates This update contains a dependency on the openssl update and will automatically install a corrected version of the libss0.9.8 package, and a new package openssh-blacklist. Once the update is applied, weak user keys will be automatically rejected where possible (though they cannot be detected in all cases). It might be helpful to know, in what cases weak keys can / cannot be detected. I think the only clearcut thing you can say is that unless you're 100% sure your key is safe, it isn't and you should regen. In my case, I was sure of one key and unsure of 250+ god-foresaken others. Now I'm sure of them all. I'm also cranky, tired and hoping I never have to do that again. Tomorrow the 50+ self-signed and purchased SSL certs... Life is filled with joy. -- Police noticed some rustling sounds from Linn's bottom area and on closer inspection a roll of cash was found protruding from Linn's anus, the full amount of cash taken in the robbery. - http://www.smh.com.au/news/world/robber-hides-loot-up-his-booty/2008/05/09/1210131248617.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1576-1] New openssh packages fix predictable randomness
On Wed, May 14, 2008 at 07:33:43PM +0200, Jan Luehr wrote: To check all your own keys, assuming they are in the standard locations (~/.ssh/id_rsa, ~/.ssh/id_dsa, or ~/.ssh/identity): ssh-vulnkey I took a look at it and found two large blacklist containing lots of keys - but no info on how these lists are generated - that makes me wonder: Afair DSA keys ought to be considered compromised, even if they aren't generated by a broken libssl - so what's the sense in here? For the RSA part: Is it possible that file contains non-broken keys or that broken keys are not listed? What's the criteria for RSA-keys to be listed? Indeed. After all the hassle I went through to make sure I'm sorted I'm now lumped with two lookup lists which might generate false positives and are just generally useless. I can't even not install the package because it's in the Depends line rather then Recommends or Suggests or whatnot. :/ -- Police noticed some rustling sounds from Linn's bottom area and on closer inspection a roll of cash was found protruding from Linn's anus, the full amount of cash taken in the robbery. - http://www.smh.com.au/news/world/robber-hides-loot-up-his-booty/2008/05/09/1210131248617.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis G?mez wrote: IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? rsync where you want to keep userid/groupid info. -- GOVERNMENT ANNOUNCEMENT - The government announced today that it is changing its mascot to a condom because it more clearly reflects the government's political stance. A condom stands up to inflation, halts production, destroys the next generation, protects a bunch of pricks and finally, gives you a sense of security while you're being screwed! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Layne (was: Re: Is ident secure?)
On Fri, Aug 31, 2001 at 11:52:07PM -0400, Paul Visscher wrote: Ed Street [EMAIL PROTECTED] said: Hello, Already sent mail to the list admin on the bottom of each email. I just submitted his address in at http://www.debian.org/MailingLists/unsubscribe to be unsubscribed, hopefully that will work... He'll probably have to confirm and not do it. -- CaTAs you can expect it's really affecting my sex life. I can't help it. Each time my wife initiates sex, these ejaculating hippos keep floating through my mind. - Mohd. Binatang bin Goncang, Singapore Zoological Gardens
Re: HARASS ME MORE.........
On Sat, Sep 01, 2001 at 12:44:15AM -0400, Layne wrote: I ASKED YOU MORONS NOT TO SEND ME ANYMORE E-MAIL BUT HERE YOU GO AGAIN. IS THERE ANY INTELLIGENT PEOPLE THERE OR IS THE PLACE RUN BY BABOONS. i'M Oook? To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- CaTAs you can expect it's really affecting my sex life. I can't help it. Each time my wife initiates sex, these ejaculating hippos keep floating through my mind. - Mohd. Binatang bin Goncang, Singapore Zoological Gardens
Re: Layne (was: Re: Is ident secure?)
On Fri, Aug 31, 2001 at 11:52:07PM -0400, Paul Visscher wrote: Ed Street [[EMAIL PROTECTED]] said: Hello, Already sent mail to the list admin on the bottom of each email. I just submitted his address in at http://www.debian.org/MailingLists/unsubscribe to be unsubscribed, hopefully that will work... He'll probably have to confirm and not do it. -- CaTAs you can expect it's really affecting my sex life. I can't help it. Each time my wife initiates sex, these ejaculating hippos keep floating through my mind. - Mohd. Binatang bin Goncang, Singapore Zoological Gardens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: HARASS ME MORE.........
On Sat, Sep 01, 2001 at 12:44:15AM -0400, Layne wrote: I ASKED YOU MORONS NOT TO SEND ME ANYMORE E-MAIL BUT HERE YOU GO AGAIN. IS THERE ANY INTELLIGENT PEOPLE THERE OR IS THE PLACE RUN BY BABOONS. i'M Oook? To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- CaTAs you can expect it's really affecting my sex life. I can't help it. Each time my wife initiates sex, these ejaculating hippos keep floating through my mind. - Mohd. Binatang bin Goncang, Singapore Zoological Gardens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: red worm amusement
On Sun, Jul 22, 2001 at 12:40:11AM -0700, Jacob Meuser wrote: On Sat, Jul 21, 2001 at 10:26:38PM -0800, Ethan Benson wrote: On Sat, Jul 21, 2001 at 09:02:54PM -0700, Jacob Meuser wrote: Oh, I guess anyone can say something like Four years without a remote hole in the default install! on the internet, where anyone is free to that quote is pure marketing. Marketing? OpenBSD has about as much of an adversising dept as does Debian. None. You don't need a marketing department to practice the 'art' of marketing. they don't count the recent ftpd remote root hole in that `four years' because they stopped activitating ftpd in the default install of OpenBSD 2.7, which was released only a very short time before the hole was discovered. And so the default install was not vulnerable to remote attacks. Like Debian's default install is not vulnerable to attacks either. Your point? -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: red worm amusement
On Sat, Jul 21, 2001 at 08:51:23PM -0700, Jacob Meuser wrote: On Sun, Jul 22, 2001 at 12:54:49PM +1000, CaT wrote: You know. You're right. We should make it as difficult as possible to install software. Right down to removing makefiles from source repositories and rot13ing the source code because the harder it is to install a piece of software, the more secure a box is. No, I'm simply saying not to start services immediately. I mean really, That wasn't what you were saying before. You were saying that the ease of install you get with apt-get is bad. This is a rather different issue. who in their right mind starts a service without looking at the config files? How hard is it to add the links from /etc/rc?.d to /etc/init.d (isn't there script to do this anyway)? Some packages already practice safety-first. You need to remove an echo and an exit from the init.d once you're good and ready. This just has to become more widespread. Then again, most of the time I install a service (90%) I want it to start running immediately. apache, ftp etc I compile by hand. And then the computer you just spent a few grand on will be about as useful as a toaster without heating elements. That's better than them getting sued for a hell of a lot more than they paid for their machine because someone launched an attack from their machine, and they can't prove they didn't to it. No machine is 100% secure, except those machines that do not exist. Anyone who thinks their box is 100% secure has rocks in their heads, regardless what OS they are running. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: red worm amusement
On Sun, Jul 22, 2001 at 01:37:29AM -0700, Jacob Meuser wrote: For the last time: I am saying that apt-get install should not immediately start a service, and it should not install the startup links in /etc/rc?.d. Then stick to that. I could give a rats @$$ about what is Debian's base system. Those aren't installed with apt-get install anyway. I could give two $#1+$ about whether or not an OS is secure out of the box. This is not a question about OSes, it's a question about installing packages that install services. Please don't try to steer me off course, and then say I keep changing my position. It's simply not polite, and rather silly. Noone is steering you offcourse. You're doing just that. You mention that OpenBSD has been secure out-of-the-box for 4yrs and then when ppl aren't impressed you chuck a hissy fit. *shrug* -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: red worm amusement
On Sun, Jul 22, 2001 at 01:38:23AM -0700, Magus Ba'al wrote: quoteNo machine is 100% secure, except those machines that do not exist. Anyone who thinks their box is 100% secure has rocks in their heads, regardless what OS they are running./quote Don't mean to sound like an annoyance, but I have a 100% secure computer. It's currently dissasembled, with the parts stored in different containers, and no OS on the hard drive. Crack that! *grabs HD and installs it into another pc* ;) Sorry, just a poor stab at humor. While I've always been proud that the debian list has pretty much been better than any other list at keeping flame wars to a minimum, today is an exception. At times this latest thread has become well, my cock is bigger, so I'm more right than it's starting to feel that way. you!. Yes, maybe daemons should ask to be started during startup, or prompt to be configured like exim. But who's to say that a new user won't choose an option that leads them to be vulnerable. When I first well. that'll be a concious choice by the user instead of an automated one I guess. started I *know* I made some big mistakes. Maybe Debian should have some mistakes are what we learn from the best. unfortunately they tend to have the nastiest of sideeffects at times (but I guess that's why they are such great teachers) firewall rules that are run to block vulnerable services when they are installed and then tell you how to unblock them. Maybe a billion different ways it could be, but it's not. I must commend the Debian team for maintaining the best distro, IMNSHO. I thought the Debian community aye. we're dumping redhat/slackware boxes for debian. one of the primary reasons is the ease with which you can keep the box uptodate and secure. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: red worm amusement
On Sun, Jul 22, 2001 at 12:40:11AM -0700, Jacob Meuser wrote: On Sat, Jul 21, 2001 at 10:26:38PM -0800, Ethan Benson wrote: On Sat, Jul 21, 2001 at 09:02:54PM -0700, Jacob Meuser wrote: Oh, I guess anyone can say something like Four years without a remote hole in the default install! on the internet, where anyone is free to that quote is pure marketing. Marketing? OpenBSD has about as much of an adversising dept as does Debian. None. You don't need a marketing department to practice the 'art' of marketing. they don't count the recent ftpd remote root hole in that `four years' because they stopped activitating ftpd in the default install of OpenBSD 2.7, which was released only a very short time before the hole was discovered. And so the default install was not vulnerable to remote attacks. Like Debian's default install is not vulnerable to attacks either. Your point? -- CaT ([EMAIL PROTECTED]) *** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000
Re: red worm amusement
On Sat, Jul 21, 2001 at 08:51:23PM -0700, Jacob Meuser wrote: On Sun, Jul 22, 2001 at 12:54:49PM +1000, CaT wrote: You know. You're right. We should make it as difficult as possible to install software. Right down to removing makefiles from source repositories and rot13ing the source code because the harder it is to install a piece of software, the more secure a box is. No, I'm simply saying not to start services immediately. I mean really, That wasn't what you were saying before. You were saying that the ease of install you get with apt-get is bad. This is a rather different issue. who in their right mind starts a service without looking at the config files? How hard is it to add the links from /etc/rc?.d to /etc/init.d (isn't there script to do this anyway)? Some packages already practice safety-first. You need to remove an echo and an exit from the init.d once you're good and ready. This just has to become more widespread. Then again, most of the time I install a service (90%) I want it to start running immediately. apache, ftp etc I compile by hand. And then the computer you just spent a few grand on will be about as useful as a toaster without heating elements. That's better than them getting sued for a hell of a lot more than they paid for their machine because someone launched an attack from their machine, and they can't prove they didn't to it. No machine is 100% secure, except those machines that do not exist. Anyone who thinks their box is 100% secure has rocks in their heads, regardless what OS they are running. -- CaT ([EMAIL PROTECTED]) *** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000
Re: red worm amusement
On Sun, Jul 22, 2001 at 01:37:29AM -0700, Jacob Meuser wrote: For the last time: I am saying that apt-get install should not immediately start a service, and it should not install the startup links in /etc/rc?.d. Then stick to that. I could give a rats @$$ about what is Debian's base system. Those aren't installed with apt-get install anyway. I could give two $#1+$ about whether or not an OS is secure out of the box. This is not a question about OSes, it's a question about installing packages that install services. Please don't try to steer me off course, and then say I keep changing my position. It's simply not polite, and rather silly. Noone is steering you offcourse. You're doing just that. You mention that OpenBSD has been secure out-of-the-box for 4yrs and then when ppl aren't impressed you chuck a hissy fit. *shrug* -- CaT ([EMAIL PROTECTED]) *** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000
Re: red worm amusement
On Sun, Jul 22, 2001 at 01:38:23AM -0700, Magus Ba'al wrote: quoteNo machine is 100% secure, except those machines that do not exist. Anyone who thinks their box is 100% secure has rocks in their heads, regardless what OS they are running./quote Don't mean to sound like an annoyance, but I have a 100% secure computer. It's currently dissasembled, with the parts stored in different containers, and no OS on the hard drive. Crack that! *grabs HD and installs it into another pc* ;) Sorry, just a poor stab at humor. While I've always been proud that the debian list has pretty much been better than any other list at keeping flame wars to a minimum, today is an exception. At times this latest thread has become well, my cock is bigger, so I'm more right than it's starting to feel that way. you!. Yes, maybe daemons should ask to be started during startup, or prompt to be configured like exim. But who's to say that a new user won't choose an option that leads them to be vulnerable. When I first well. that'll be a concious choice by the user instead of an automated one I guess. started I *know* I made some big mistakes. Maybe Debian should have some mistakes are what we learn from the best. unfortunately they tend to have the nastiest of sideeffects at times (but I guess that's why they are such great teachers) firewall rules that are run to block vulnerable services when they are installed and then tell you how to unblock them. Maybe a billion different ways it could be, but it's not. I must commend the Debian team for maintaining the best distro, IMNSHO. I thought the Debian community aye. we're dumping redhat/slackware boxes for debian. one of the primary reasons is the ease with which you can keep the box uptodate and secure. -- CaT ([EMAIL PROTECTED]) *** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000
Re: red worm amusement
On Sun, Jul 22, 2001 at 02:08:36AM -0700, Jacob Meuser wrote: On Sun, Jul 22, 2001 at 06:35:34PM +1000, CaT wrote: On Sun, Jul 22, 2001 at 01:37:29AM -0700, Jacob Meuser wrote: For the last time: I am saying that apt-get install should not immediately start a service, and it should not install the startup links in /etc/rc?.d. Then stick to that. Please, quote me on where I have contradicted that. Right below. Noone is steering you offcourse. You're doing just that. You mention that OpenBSD has been secure out-of-the-box for 4yrs and then when ppl aren't impressed you chuck a hissy fit. I mentioned that OpenBSD has a policy of not starting services by default. Ethan Benson went off on how OpenBSD is rubbish. As an OpenBSD user, I felt I should point out that he was the one full of rubbish. I really don't care whether people think it's If you only wanted to talk about apt-get you should've stuck to it. a good idea or not. I just wish they'd discuss the issue I'm talking about. I mean really, Ethan claimed I never installed OpenBSD. How could he have ever known whether or not that is true? Someone called ME a troll!?!?!?!?! don't care. remember, this is meant to be about apt-get only? anyways. i'm bowing out. -- CaT ([EMAIL PROTECTED]) *** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000
Re: red worm amusement
On Sat, Jul 21, 2001 at 07:52:02PM -0700, Jacob Meuser wrote: I think a lot of people are just curious, and they install things they don't need, or really have any idea of what it does. The only reason they are able to get it to run is because it's easy. They may not have any idea that /etc/rc?.d exists. They very well may not expect it to be running the next time they reboot. well people need to learn. you can't treat computers like toasters anymore. deal with it. And whose going to teach them? Certainly not an OS that makes it as easy as 'apt-get install apache' ! You know. You're right. We should make it as difficult as possible to install software. Right down to removing makefiles from source repositories and rot13ing the source code because the harder it is to install a piece of software, the more secure a box is. And then the computer you just spent a few grand on will be about as useful as a toaster without heating elements. The trick is not to make installation of software more difficult. The trick is in informing the user about what they just did and what consequences it may have for them. -- CaT ([EMAIL PROTECTED]) *** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000
Re: Mac most secure servers?
On Thu, Feb 22, 2001 at 03:09:36PM -0900, Ethan Benson wrote: several years ago there was a silly `Crack a Mac' contest and someone managed to exploit a cgi script and deface the web site served by the Mac. in most cases such an attack would never allow site defacment on unix since the site is not owned by the webserver UID that the cgi script generally runs as. Point of note... cgi scripts for a site are generally setup to run as the user who owns the site so that if a cgi script is hacked, the damage is restricted to said site and not the webserver itself or the system as a whole. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mac most secure servers?
On Thu, Feb 22, 2001 at 03:09:36PM -0900, Ethan Benson wrote: several years ago there was a silly `Crack a Mac' contest and someone managed to exploit a cgi script and deface the web site served by the Mac. in most cases such an attack would never allow site defacment on unix since the site is not owned by the webserver UID that the cgi script generally runs as. Point of note... cgi scripts for a site are generally setup to run as the user who owns the site so that if a cgi script is hacked, the damage is restricted to said site and not the webserver itself or the system as a whole. -- CaT ([EMAIL PROTECTED]) *** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000
Re: I want to secure hard disk. How ?
On Wed, Oct 04, 2000 at 10:35:32AM +0100, Artur wrote: Hi Debian Gurus ! Is there a way to secure hard disk (with linux partition) to not mount on the other PC ? I mean encryption or any other thing to be safe after i.e. hard disk robbery. Any comments will be very very helpfull. http://www.kerneli.org/ -- CaT ([EMAIL PROTECTED]) 'He had position, but I was determined to score.' -- Worf, DS9, Season 5: 'Let He Who Is Without Sin...' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I want to secure hard disk. How ?
On Wed, Oct 04, 2000 at 10:35:32AM +0100, Artur wrote: Hi Debian Gurus ! Is there a way to secure hard disk (with linux partition) to not mount on the other PC ? I mean encryption or any other thing to be safe after i.e. hard disk robbery. Any comments will be very very helpfull. http://www.kerneli.org/ -- CaT ([EMAIL PROTECTED]) 'He had position, but I was determined to score.' -- Worf, DS9, Season 5: 'Let He Who Is Without Sin...'
Re: possible security flaw in screen 3.9.5-9
On Fri, Sep 08, 2000 at 02:06:15PM +0100, Tim Haynes wrote: CaT [EMAIL PROTECTED] writes: [snip sensible stuff] As such I reckon it's best if the screen directory is left in /tmp where the authors initially put it. It's inconvenient but doesn't cause the problems above. No indeed, but you have problems with folks who periodically clean out their /tmp directories, especially based on age of files... choice of two evils. Well, I'd rather the one without the hole in it. :) But also, on this vein: $ ll /tmp total 19 1 drwxrwxrwt6 root root 1024 Sep 8 19:18 . 1 drwxr-xr-x 20 root root 1024 Sep 7 11:28 .. 1 -r--r--r--1 root root 11 Sep 7 11:31 .X0-lock 1 drwxrwxrwt2 root root 1024 Sep 7 11:31 .X11-unix 1 drwxrwxrwt2 root root 1024 Sep 7 11:31 .font-unix Same problem would happen with X. You could make it somewhat inconvenient to remove it by making the dir .screens. That's the solution I used on my box at home. Something else I was wondering. The problem was with a setuid version of screen. I have: zsh, potato 2:04PM # ll `which screen` -rwxr-sr-x1 root utmp 216380 Sep 2 16:52 /usr/bin/screen* zsh, potato 2:04PM # The impossible question, someone tell me I'm an idiot: is there anything exploitable through being setgid-utmp? :] I'm not gonna pretend to have enough clue to be able to answer this. ;) -- CaT ([EMAIL PROTECTED]) 'He had position, but I was determined to score.' -- Worf, DS9, Season 5: 'Let He Who Is Without Sin...' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible security flaw in screen 3.9.5-9
On Fri, Sep 08, 2000 at 10:07:37PM -0400, Matthew W Miller wrote:
{Big Snip}
How would a quota stop the user from stuffing /var to its limit? Isn't
that part of the problem where the user could stuff /var and hemorrage the
logs?
Through not allowing the user full access to the free space. Possible holes
are:
a. many users could accidentally or otherwise smurf the free space anyhow
b. an opportune moment may happen where the free space left on /var is less
then the quota allows.
You could make the quota insanely small, but that may break what you're
trying to do in allowing users /var access and it feels more of a little
dutch boy solution. (picutre 5 yr old kid with finger stuffed in a hole
of a dam, trying to stop it leaking :)
::more headaches for /tmp cleaners and it does not solve any of the
::above problems. to solve the above problems enforce quotas on /var
::(which can be much smaller then /home quotas, say 5 or 10 MB) that is
::what i do.
::
::--
::Ethan Benson
::http://www.alaska.net/~erbenson/
--
CaT ([EMAIL PROTECTED])
'He had position, but I was determined to score.'
-- Worf, DS9, Season 5: 'Let He Who Is Without Sin...'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
possible security flaw in screen 3.9.5-9
After installing this utility (which has to be amongst my very favourite) I noticed something interesting int he way it behaves. Basically, screen does what I first thought of when compiling it for myself, which is to put its pipes in /var/run/screen. What screen does there is to create subdirs which are then used to hold a users pipes. Now these subdirs are owned by the user that runs screen. The hassle with this is that it gives the user a. a possible way around quotas set on /home b. a method of fully filling up /var, thereby potentially causing log entries to be lost which, in turn, gives the user anice, untracable way of then doing naughty things without those naughty things getting logged. Said user can then rm the large file they created and noone would be any the wiser. As such I reckon it's best if the screen directory is left in /tmp where the authors initially put it. It's inconvenient but doesn't cause the problems above. -- CaT ([EMAIL PROTECTED]) 'He had position, but I was determined to score.' -- Worf, DS9, Season 5: 'Let He Who Is Without Sin...'
Re: possible security flaw in screen 3.9.5-9
On Fri, Sep 08, 2000 at 09:12:38AM -0400, Michael Stone wrote: On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote: a. a possible way around quotas set on /home b. a method of fully filling up /var, thereby potentially causing log entries to be lost which, in turn, gives the user anice, untracable way of then How would this be different from putting things in /var/tmp, Make /var/tmp a seperate partition. I've already seen /var/tmp severly screwup a system when it was part of /var. (I also always make /tmp a seperate partition) /var/lock, etc.? Hmmm. Interesting. Why is it so? Redhat at least doesn't appear to have it globally writeable (at least the systems I just checked) so does it really need to be? (don't take this as a redhat vs debian thing but more of a 'I've got an example to the contrary' thing :) -- CaT ([EMAIL PROTECTED]) 'He had position, but I was determined to score.' -- Worf, DS9, Season 5: 'Let He Who Is Without Sin...'
Re: possible security flaw in screen 3.9.5-9
On Fri, Sep 08, 2000 at 02:06:15PM +0100, Tim Haynes wrote: CaT [EMAIL PROTECTED] writes: [snip sensible stuff] As such I reckon it's best if the screen directory is left in /tmp where the authors initially put it. It's inconvenient but doesn't cause the problems above. No indeed, but you have problems with folks who periodically clean out their /tmp directories, especially based on age of files... choice of two evils. Well, I'd rather the one without the hole in it. :) But also, on this vein: $ ll /tmp total 19 1 drwxrwxrwt6 root root 1024 Sep 8 19:18 . 1 drwxr-xr-x 20 root root 1024 Sep 7 11:28 .. 1 -r--r--r--1 root root 11 Sep 7 11:31 .X0-lock 1 drwxrwxrwt2 root root 1024 Sep 7 11:31 .X11-unix 1 drwxrwxrwt2 root root 1024 Sep 7 11:31 .font-unix Same problem would happen with X. You could make it somewhat inconvenient to remove it by making the dir .screens. That's the solution I used on my box at home. Something else I was wondering. The problem was with a setuid version of screen. I have: zsh, potato 2:04PM # ll `which screen` -rwxr-sr-x1 root utmp 216380 Sep 2 16:52 /usr/bin/screen* zsh, potato 2:04PM # The impossible question, someone tell me I'm an idiot: is there anything exploitable through being setgid-utmp? :] I'm not gonna pretend to have enough clue to be able to answer this. ;) -- CaT ([EMAIL PROTECTED]) 'He had position, but I was determined to score.' -- Worf, DS9, Season 5: 'Let He Who Is Without Sin...'
Re: possible security flaw in screen 3.9.5-9
On Fri, Sep 08, 2000 at 05:52:42PM -0800, Ethan Benson wrote: On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote: What screen does there is to create subdirs which are then used to hold a users pipes. Now these subdirs are owned by the user that runs screen. The hassle with this is that it gives the user a. a possible way around quotas set on /home b. a method of fully filling up /var, thereby potentially causing log entries to be lost which, in turn, gives the user anice, untracable way of then doing naughty things without those naughty things getting logged. Said user can then rm the large file they created and noone would be any the wiser. users have write permission to /var unless you really make alot of changes, on my system i have: /var/lock /var/tmp ## for me this is a sep partition /var/lib/texmf/* /var/mail/user For my system: [13:09:22] [EMAIL PROTECTED]:/root find /var -perm +o+w -mount [13:09:26] [EMAIL PROTECTED]:/root I've not had problems. :) Still, why does /var/lib/texmf/* need to be publically writeable? That's a package I don't have installed. if your worried about users messing with /var put quotas on /var. If that's the only solution then yes, but why do we need global write access to /var in the first place? As such I reckon it's best if the screen directory is left in /tmp where the authors initially put it. It's inconvenient but doesn't cause the problems above. more headaches for /tmp cleaners and it does not solve any of the above problems. to solve the above problems enforce quotas on /var Well it does... Logging will go on etc. As for /tmp cleaners, somehting like tmpwatch is a good start, but it'd be nice if it had an exclusion list to the global timeout. It'd make it much more useful. :) -- CaT ([EMAIL PROTECTED]) 'He had position, but I was determined to score.' -- Worf, DS9, Season 5: 'Let He Who Is Without Sin...'
Re: possible security flaw in screen 3.9.5-9
On Fri, Sep 08, 2000 at 10:07:37PM -0400, Matthew W Miller wrote:
{Big Snip}
How would a quota stop the user from stuffing /var to its limit? Isn't
that part of the problem where the user could stuff /var and hemorrage the
logs?
Through not allowing the user full access to the free space. Possible holes
are:
a. many users could accidentally or otherwise smurf the free space anyhow
b. an opportune moment may happen where the free space left on /var is less
then the quota allows.
You could make the quota insanely small, but that may break what you're
trying to do in allowing users /var access and it feels more of a little
dutch boy solution. (picutre 5 yr old kid with finger stuffed in a hole
of a dam, trying to stop it leaking :)
::more headaches for /tmp cleaners and it does not solve any of the
::above problems. to solve the above problems enforce quotas on /var
::(which can be much smaller then /home quotas, say 5 or 10 MB) that is
::what i do.
::
::--
::Ethan Benson
::http://www.alaska.net/~erbenson/
--
CaT ([EMAIL PROTECTED])
'He had position, but I was determined to score.'
-- Worf, DS9, Season 5: 'Let He Who Is Without Sin...'
Re: possible security flaw in screen 3.9.5-9
On Fri, Sep 08, 2000 at 06:33:01PM -0800, Ethan Benson wrote:
On Sat, Sep 09, 2000 at 01:16:19PM +1100, CaT wrote:
For my system:
[13:09:22] [EMAIL PROTECTED]:/root find /var -perm +o+w -mount
[13:09:26] [EMAIL PROTECTED]:/root
I've not had problems. :)
you have removed /var/lock? and i presume made /var/tmp its own
No. It's just not globally writeable.
partition.
Actually, I've not come across a use for it yet. From memory it is
there for things like editor temp files so that you can resurrect
your work after a crash. Basically, temp files which are not temp
enough to not survive a botoup. No need for it on my system (things
like vim, which is the only editor installed on my box, have been
configured to keep tmp files in a dir in the users home dir).
If I did have a need for it though, I'd make it a seperate partition,
yes.
Still, why does /var/lib/texmf/* need to be publically writeable?
design flaws in tetex. see the BTS for a long discussion about it.
BTS?
its not trivial to fix unfortunatly.
doh. what do those files do? (if you know offhand)
That's a package I don't have installed.
most people do since its priority standard.
aye. I'd say it needs fixing also then. :)
if your worried about users messing with /var put quotas on /var.
If that's the only solution then yes, but why do we need global
write access to /var in the first place?
/var/lock i am not sure about, i don't usually see anything in there,
though right now i see a
-rw-r--r--1 root root 11 Sep 8 18:10 LCK..ttyS0
which belongs to pppd, but it runs as root.
Yes. That's all I have in there also.
/var/lock is cleaned on boot.
more headaches for /tmp cleaners and it does not solve any of the
above problems. to solve the above problems enforce quotas on /var
Well it does... Logging will go on etc. As for /tmp cleaners, somehting
like tmpwatch is a good start, but it'd be nice if it had an exclusion
list to the global timeout. It'd make it much more useful. :)
like this (from /etc/cron.daily/tmpreaper):
Ooo!
# ! Important ! Please read the manual regarding the --protect option.
#The pattern *MUST* be surrounded by single quotes.
nice -n10 tmpreaper --mtime-dir --symlinks 7d \
--protect '/tmp/.X*-{lock,unix,unix/*}' \
--protect '/tmp/.ICE-{unix,unix/*}' \
--protect '/tmp/.iroha_{unix,unix/*}' \
--protect '/tmp/.ki2-{unix,unix/*}' \
--protect '/tmp/.font-unix' \
--protect '/tmp/lost+found' \
--protect '/tmp/quota.user' \
--protect '/tmp/quota.group' \
/tmp
I'll be grabbing this when my HD stops getting roasted.
still i don't think its good to overload /tmp with this kind of
garbage more then necessary or that list could get rediculous.
Yes it could but then I think that's better then the alternative...
and if you REALLY wanted to, you could have a .debian or whatnot
dir in there to store all such things (or most of them/some of them)
FHS may answer some of these questions too.
FHS? :)
--
CaT ([EMAIL PROTECTED])
'He had position, but I was determined to score.'
-- Worf, DS9, Season 5: 'Let He Who Is Without Sin...'
Re: possible security flaw in screen 3.9.5-9
On Fri, Sep 08, 2000 at 07:00:01PM -0800, Ethan Benson wrote: BTS? Bug Tracking System http://www.debian.org/Bugs i don't remember which tetex package has the long conversion about the issue though... Ahh. Thanks. I looked there initially to see if this was reported for screen but found naught. Will have a look at tetex later I think but atm the sun appears to be demanding worship... doh. what do those files do? (if you know offhand) i don't remember exactly tex is totally broken unless they are writable by all though. Doh. :/ most people do since its priority standard. aye. I'd say it needs fixing also then. :) agreed but it will probably need fixing upstream, the changes are really too much for debian to do themselves. *nod* still i don't think its good to overload /tmp with this kind of garbage more then necessary or that list could get rediculous. Yes it could but then I think that's better then the alternative... and if you REALLY wanted to, you could have a .debian or whatnot dir in there to store all such things (or most of them/some of them) this is becoming a question for debian-devel or perhaps debian-policy. Yup. It was just a sidethought at any rate. FHS may answer some of these questions too. FHS? :) Filesystem Hierarchy Standard http://www.pathname.com/fhs/ Ahh yes. Now I remember. Many thanks. :) -- CaT ([EMAIL PROTECTED]) 'He had position, but I was determined to score.' -- Worf, DS9, Season 5: 'Let He Who Is Without Sin...'
