Re: Gaps in security coverage?
On Tue, Nov 06 2018, Paul Wise wrote: > On Mon, Nov 5, 2018 at 10:29 PM John Goerzen wrote: > >> Hi folks, > > FTR, in case you were trying to contact the Debian Security Team > directly I suggest using secur...@debian.org or > t...@security.debian.org instead, debian-security is more of a general > security discussion list than a Debian Security Team list. Hi Paul, Thanks - I did intend it to go here, understanding that difference; I had no particular reason to make it more private. [ snips ] > Personally, I think running debsecan, looking at each item, pinging > bug reports and maintainers, doing stable updates and unstable NMUs, > pushing patches upstream etc would be a great help. That is good advice, thanks. I've been a DD for a long while, but it's been awhile (years) since I've been involved in the security process and wasn't quite sure what the flow was anymore. > Also, debsecan itself could use a lot of help, the maintenance of it > and addition of new features currently falls on already-busy security > team folks. > > In addition some more automation of ingestion of security info into > the security tracker would free up security team time that is > currently spent on manually updating the security-tracker data. What kind of automated sources are you talking about here? Where do I find the source that might be relevant? I might be able to pitch in here. Thanks again, John
Gaps in security coverage?
Hi folks, So I recently started running debsecan on one of my boxes. It's a fairly barebones server install, uses unattended-upgrades and is fully up-to-date. I expected a clean bill of health, but didn't get that. I got pages and pages and pages of output. Some of it (especially kernel related) I believe may be false positives, but not all. Some of it simply isn't patched yet. Diving into it a bit, it seems that somehow we fell down a bit with stretch. The first hit on my list is this one: https://security-tracker.debian.org/tracker/CVE-2011-5325 Marked fixed in jessie, vulnerable in stretch. And indeed when looking at the bug report 802702, I don't see any such changelog entries pertaining to this in my stretch version. So, the questions - 1) Is this a symptom of a bad process or of not enough volunteers? In other words, could we have marked these security bugs fixed in jessie as RC for stretch somehow until they were also fixed there? 2) Is there a need for more help with security in general? If so, what kinds of volunteering would be appreciated? Thanks, John
Re: Should we be alarmed at our state of security support?
On 02/19/2015 05:31 PM, Paul Wise wrote: On Fri, Feb 20, 2015 at 12:40 AM, John Goerzen wrote: Right now, the security tracker has, apparently, three status for each version of Debian: not vulnerable vulnerable fixed What if we add a fourth: not worth fixing This could more clearly communicate what is being said by the no DSA comments, as well as allow debsecan to be improved with this sort of information. What do you think? no DSA means will probably not be fixed via security.debian.org or will only be fixed via a point release by the maintainer or anyone who cares, not not worth fixing. Quite. But that is a freeform text field. I'm just suggesting we move/add it to the database so it is useable by automatic tools like debsecan and visible to people that are using the tracker. Does that sound doable? I would be willing to pitch in and help convert no dsa comments to use the new db field option too. John -- 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/54e76039.5060...@complete.org
Re: Should we be alarmed at our state of security support?
On 02/19/2015 12:25 AM, Michael Gilbert wrote: On Wed, Feb 18, 2015 at 9:11 AM, John Goerzen wrote: On this machine, it found 472 vulnerabilities. Quite a few of them fit into the remotely exploitable, high urgency category. Many date back to last year, some as far back as 2012. I've included a few examples at the end. I'm not sure what your approach to counting is, but if it is simply debsecan | wc -l then you are sorely over-counting, not to mention that vulnerability counting itself is a road to madness: https://www.blackhat.com/us-13/briefings.html#Martin Indeed, I understand that. I perhaps used imprecise language. 472 *REPORTED* vulnerabilities then. However, part of what I was trying to figure out here is: do we have a lot of unpatched vulnerabilities in our archive? Whether there were 472 or 100 issues on my particular machine is somewhat beside the point. At the moment, I am not really sure what the answer is. Perhaps none of those issues are unpatched vulnerabilities. However, debsecan is a very useful concept, but if it sends me an email every day listing 472 things that I do not need to pay attention to, then the utility of the tool is *completely* ruined. Not to mention, we have misleading information in the security tracker. Several of the things we've discussed people are saying are not really issues in wheezy. Perhaps there are even comments in the security-tracker to that effect. But the security-tracker lists wheezy as vulnerable on the webpage and the database behind it. Either the comments are wrong or the database is. So some of this may just be a policy issue of what do we put in the database? Maybe we need a field saying vulnerability exists in source but is not exploitable in binaries as shipped or something. Now, it is possible with some of these that the security-tracker database ought to be updated to reflect that there is not a true vulnerability. However, many of them seem to be existing issues that just got forgotten somehow. I've traced a few through bug reports and such. If you follow the secure-testing-commits list for a day, you'll see the herculean effort the security team puts in to keeping up with the constant deluge of new and ongoing security issues: http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/secure-testing-commits So to suggest that not enough is being done is disingenuous and insulting. Whoa, hold on a second there. That doesn't make any sense. I know that it is a tremendous effort to keep up with all this stuff, and I have a tremendous respect and appreciation for everyone that does this. But it is possible that even though everyone is working extremely hard, STILL not enough is being done. It may mean that the team needs more manpower, or better tools, or whatever. I find it very puzzling that you would say that just because people are working very hard, therefore it is insulting to question whether enough is being done, as if whenever someone is working very hard they don't need any more help. You will note that I very carefully made sure to put no blame on anyone in my original message, and also explicitly asked if there are areas where people need help. Are we already aware of these issues? If it's in the security tracker, then of course it is known. I meant, are we already aware that debsecan reports hundreds of vulnerabilities on patched systems? And that this does not appear to be a bug in debsecan. Do we have plans to fix them? Of course everything is intended to be fixed, but without a sufficient number of interested volunteers doing that, how is it supposed to happen? OK, Do we know what would be helpful to fix them? More volunteers actually doing the hard and constant day to day work that is security upkeep. Fewer distracting and obviously ill-researched blog and mailing list posts would also be nice. You know, Mike, *explicit* in my original email was a question of what help is needed. I was willing to pitch in and help. I may still be. But how else is someone going to learn that when security-tracker says vulnerable, in hundreds of instances, that may be wrong, other than by asking? I didn't find this documented anywhere. To be insulting to someone that asked a polite question about why does debsecan show hundreds of vulnerabilities on an up-to-date system -- a GOOD question -- is frankly astonishing. Rather than insulting those that might jump in to help, you might send links to information on how to pitch in and be of assistance. Frankly if the security team is going to be this prickly, the costs of dealing with personalities will eat up too much of my time and drain the satisfaction out of doing something useful for me. John -- 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/54e5e539.2010...@complete.org
Re: Should we be alarmed at our state of security support?
On 02/19/2015 08:24 AM, Michael Stone wrote: On Thu, Feb 19, 2015 at 07:29:29AM -0600, John Goerzen wrote: However, part of what I was trying to figure out here is: do we have a lot of unpatched vulnerabilities in our archive? Yes. Every system (not just debian) has unpatched vulnerabilities. In some cases those vulnerabilities are known, and in some cases those vulnerabilities are unknown. Fixing all of the vulnerabilities in general purpose software is effectively impossible. So the real question is, are there unfixed vulnerabilities worth fixing? The answer to that depends on the level of risk one is willing to take, and may include patching only vulnerabilities that are likely to be exploited, applying all potentially security-related patches, or intensively auditing the code and trying to fix all vulnerabilities. The question is made more difficult by the fact that applying patches can introduce new vulnerabilities--so fixing all low-risk vulnerabilities could potentially make things worse rather than better. So, let's put aside the vulnerabilities that are unknown for the purposes of this discussion. Right now, the security tracker has, apparently, three status for each version of Debian: not vulnerable vulnerable fixed What if we add a fourth: not worth fixing This could more clearly communicate what is being said by the no DSA comments, as well as allow debsecan to be improved with this sort of information. What do you think? There are no good answers, and the better answers all require a great deal of effort. Debian may be able to do a better job of communicating why certain bugs are prioritized over others, but what really should matter to you is whether the assumptions used to prioritize each bug are valid for your particular environment. (That is, you need to review each bug at length.) For most people that level of effort isn't justified, and they are content to accept whatever is prioritized by their vendor. If there are specific cases where you think that the debian made the wrong call, it's reasonable to bring those up for discussion--people do make mistakes. But do understand that we will never get to zero bugs. Understood. I am just looking, then, for the security-tracker to reflect this reality in a way that can be automatically understood by tools like debsecan and more clearly communicated to users. John 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/54e611f4.3060...@complete.org
Re: Missing tiff3 patch in security repo
On 02/18/2015 08:53 AM, Thijs Kinkhorst wrote: Hi John, On Wed, February 18, 2015 14:51, John Goerzen wrote: CVE-2013-1961 Stack-based buffer overflow in the t2p_write_pdf_page... http://security-tracker.debian.org/tracker/CVE-2013-1961 - libtiff4 (remotely exploitable, high urgency) The reason is explained when you follow this link you quote above: [wheezy] - tiff3 no-dsa (the changes that [a]ffect the library are just hardening, converting uses of sprintf to snprintf. those can be rolled into the next tiff3 update, but a separate dsa isn't needed) I saw that too, though the bug report says something different, the DSA note is probably correct. But then why is wheezy listed as vulnerable? Do they think that sprintf is safe? John -- 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/54e4d0ed.90...@complete.org
Re: Should we be alarmed at our state of security support?
On 02/18/2015 08:44 AM, Thijs Kinkhorst wrote: Yes, we know about those issues. That's why debsecan reports them to you in the first place. A good place to learn more about an issue is to actually follow the links you pasted at the bottom of your email. There you can e.g. see a motivation for why libtiff4 is not that urgent to fix, similar for php5 and the useful note that clamav will be fixed through wheezy-updates and not wheezy-security (it's currently in the srm queue). If you are alarmed by the output of debsecan, it may be because the tool lacks the nuance that is represented in the tracker and does not expose the information above. Of the many issues coming in every day, there's many shades of impact and priority. Perhaps what we need then is for more nuance in the tracker? For instance, https://security-tracker.debian.org/tracker/TEMP-000-244FCB says php5 is vulnerable; however, the security impact is unimportant. But under Status, it just says vulnerable. Well, is it vulnerable to a real issue or not? It seems to me they are saying it is not vulnerable to a /security/ issue. Should that status then be not vulnerable or perhaps even some other status? Regarding the python2.6 one you were saying wasn't a big deal -- there's a proof of concept exploit for it https://www.trustedsec.com/february-2014/python-remote-code-execution-socket-recvfrom_into/ . Why would the tracker say that such a thing wasn't important enough to fix? John
Should we be alarmed at our state of security support?
Hi folks, So I recently downloaded and installed debsecan on several of my machines. These are all fully up-to-date machines, running either wheezy or jessie. For now I'll just focus on wheezy since it's where our security focus should go. On this machine, it found 472 vulnerabilities. Quite a few of them fit into the remotely exploitable, high urgency category. Many date back to last year, some as far back as 2012. I've included a few examples at the end. Now, it is possible with some of these that the security-tracker database ought to be updated to reflect that there is not a true vulnerability. However, many of them seem to be existing issues that just got forgotten somehow. I've traced a few through bug reports and such. I wonder: Are we already aware of these issues? Do we have plans to fix them? Do we know what would be helpful to fix them? Thanks, John CVE-2013-1961 Stack-based buffer overflow in the t2p_write_pdf_page... http://security-tracker.debian.org/tracker/CVE-2013-1961 - libtiff4 (remotely exploitable, high urgency) CVE-2014-1912 Buffer overflow in the socket.recvfrom_into function... http://security-tracker.debian.org/tracker/CVE-2014-1912 - python2.6, python2.6-minimal (remotely exploitable, high urgency) CVE-2014-9656 The tt_sbit_decoder_load_image function in... http://security-tracker.debian.org/tracker/CVE-2014-9656 - libfreetype6 (remotely exploitable, high urgency) CVE-2015-0231 Use-after-free vulnerability in the... http://security-tracker.debian.org/tracker/CVE-2015-0231 - php5-cgi, php5-gd, php-pear, php5-curl, php5-common, php5-pspell, php5-mcrypt, php5-cli, php5, php5-ldap, php5-imap, php5-mysql, php5-intl (remotely exploitable, high urgency) CVE-2015-1462 ClamAV before 0.98.6 allows remote attackers to have... http://security-tracker.debian.org/tracker/CVE-2015-1462 - clamav, libclamav6, clamav-freshclam, clamav-base, clamav-daemon (remotely exploitable, high urgency) CVE-2010-5312 Cross-site scripting (XSS) vulnerability in... http://security-tracker.debian.org/tracker/CVE-2010-5312 - libjs-jquery-ui (remotely exploitable, medium urgency) -- 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/54e49da6.7050...@complete.org
Missing tiff3 patch in security repo
Hi folks, I've been going through the output of debsecan on my systems (more on that later). For the moment, I have discovered something odd regarding a tiff advisory. Debsecan noted this on my wheezy machine: CVE-2013-1961 Stack-based buffer overflow in the t2p_write_pdf_page... http://security-tracker.debian.org/tracker/CVE-2013-1961 - libtiff4 (remotely exploitable, high urgency) According to https://www.debian.org/security/2014/dsa-2965 there was a patch in wheezy to tiff 4.0.2-6+deb7u3. But tiff3 remains unpatched. There is a grave bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712840 which mentions that the fix for this CVE could be easily ported to the tiff3 package for wheezy. However, it was never uploaded to wheezy. Any ideas how to fix this? John -- 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/54e498ff.7000...@complete.org
Re: Debian Live CD - unsecured ssh open by default
Great news, thanks! On 01/31/2015 07:01 PM, Evgeny Kapun wrote: This should be fixed in the latest version. See https://bugs.debian.org/741678. On 01.02.2015 03:09, John Goerzen wrote: Hello, A friend of mine pointed out to me recently that the Debian Live CD has ssh open to the network by default, and the user account -- which has passwordless sudo to root privileges -- has a password that is well-known and easily found via Google. This poses some nasty surprises for people that might be using it to repair systems on their LAN, and even worse surprises for people that might install the Live CD image to their system. I have seen a few mentions of this online, but it doesn't seem that people are thinking of it as a security risk. What is the best way to get this fixed? Thanks! -- John -- 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/54ce1385.40...@complete.org
libapache2-mod-fcgid in lenny vulnerable to hole for weeks
Hi folks, I reported bug #605484 regarding a security hole in lenny. I believe the security team was CC'd. Prior to my report, http://security-tracker.debian.org/tracker/CVE-2010-3872 said that Debian/stable was not vulnerable. I also notified them to correct this issue. My question here is: who's got the ball on security issues? It seems that this issue didn't trigger any bugs being created or any bugs being filed in Debian when it came out. When I did what I thought was appropriate, it also didn't trigger much. The maintainer was interested in it, but AFAICT there are, as yet, no new packages. This is not an attack on any person/team, just a question about whether we have an organizational problem we need to correct. Thanks, -- John Goerzen -- 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/4d10d149.5000...@complete.org
Re: Linux infected ?
On Thu, Jan 29, 2009 at 09:04:46AM -0200, Eduardo M KALINOWSKI wrote: Rodrigo Hashimoto wrote: Hi, I received a file via e-mail and tried to open it, then the iceweasel did nothing. I tried again and I realized the iceweasel was trying to user the wine to open a file .com. Then I run the command file and I realized this is king of a virus to Windows and not Linux. This is a security risk to my debian lenny ? Even if it was a virus, the most it can do is affect your Wine files of the pseudo-Windows installation. Even so, I'm not sure it will be much Uhmm you are aware that you can mount $HOME in Wine, right? ISTR it even does this by default. -- John effective. Even if it wrote to the registry an entry to start-up automatically, I'm not sure Wine honors this. If you are in doubt, just wipe you wine files (I think they are in ~/.wine, but I haven't used Wine in years) and start again. -- Eduardo M KALINOWSKI edua...@kalinowski.com.br http://move.to/hpkb -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What's going on with advisory for phpmyadmin?
On Fri, Oct 28, 2005 at 04:26:43PM +0100, Steve Kemp wrote: This seems to be a very frequent problem going on for awhile now. Could someone from the security team comment on what the problem is? The problem is that we receive a lot of reports, each of which may involve a significant amount of time to attend to. Well, that's a symptom. Isn't the root problem not enough people on the team in this case? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please allow drupal 4.5.3-1
On Fri, Jun 03, 2005 at 10:56:47AM +0200, Hilko Bengen wrote: Steve Langasek [EMAIL PROTECTED] writes: So, you are not accepting my drupal_4.5.3-1 (or -2) package into sarge because 4.5.3 fixes more than cited security issue? Why are you not using the simple patch available at http://drupal.org/drupal-4.6.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Richtig swappen
On Fri, Jan 28, 2005 at 10:46:24AM +0100, martin f krafft wrote: also sprach Demonen [EMAIL PROTECTED] [2005.01.28.1036 +0100]: Stop the german. Ha! Naturlich! Nodingkt kan stop ze German! I feel a call to dict blinkenlights coming on... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: [ox-en] Walther
On Wed, Feb 25, 2004 at 06:50:50PM +0200, Martin Hardie wrote: the differnce is guys is that Debian and free software professes to be based upon a community and a community that believes in sharing and respect and thus must have the guts to move beyond the inane ... no discrimination statement ... freedom rhetoric and stand up for and make political decisions That *is* a political statement, and it sounds like you are arguing for yourself the very strange position of being anti-racist yet pro-discrimination and anti-free speech. I support free speech. I disagree vehemently with the racists and their rhetoric, but I also vehemently support their right to say it. Perhaps one day someone will disagree vehemently with what I want to say, yet support my ability to say it, too. This is called tolerance, and it's a shame you don't have more of it. And the operating system they use to do it is completely irrelevant. Debian says no discrimination and WE MEAN IT. What good is a mail reader if its license only allows you to legally express opinions that the author agrees with? That's silly, and a crimp on people that are saying unpopular but correct things. Software is politics, IP is politics, free software is blatantly political in its anti IP posiitons ... or pretends to be ... or is it just another way of doing business and fuck the fallout. You might notice that virtually every bit of software in Debian is copyrighted and licensed. I am not sure where you are getting the anti IP rhetoric from. It would be better to say responsible IP. We dont say you should stop him from using your software ... but you should shun people with such views and who use the product of your community to promote such views, you should shun them from your community. its is not about discrimination Pardon me, but that is *exactly* what you are saying: We should treat people with certain views differently than other people. It doesn't take a copy of the Oxford English Dictionary to work out that this is a prime example of discrimination. Note too that the Debian Free Software Guidelines -- from which the no discrimination line originates -- apply to software licenses and not to actions of the Project. In other words, we have committed ourselves to distributing software that has no onerous restrictions, but we do not compel any Debian user or developer to associate with someone whom they find distasteful. In the end, freedom of association is preserved for the individual. People can make their own choices about whom they associate with, and trying to lecture some ill-defined community with no real boss is an exercise in futility. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: [ox-en] Walther
On Wed, Feb 25, 2004 at 06:02:22PM +0200, Martin Hardie wrote: so the use of debian products for rascist work is ok for debian Yes, it is. Our Debian Free Software Guidelines enforce a mandate of no discrimination. Software included in Debian does not discriminate on people based on their opinions or any other factor, including employer, race, gender, ethnicity, etc. You may note that Windows also does not prohibit one from using it to disseminate unpopular and incorrect opinions. by using debian he associates debians products with rascism That is a very far stretch. I fail to see how that works. Does Playboy associate Sun's products with pornography because their server runs Solaris? [1] Would I associate Microsoft's products with Free Software if I were to port PyGopherd to Windows? [1] http://uptime.netcraft.com/up/graph?site=playboy.com
Re: Fwd: Re: [ox-en] Walther
On Wed, Feb 25, 2004 at 06:50:50PM +0200, Martin Hardie wrote: the differnce is guys is that Debian and free software professes to be based upon a community and a community that believes in sharing and respect and thus must have the guts to move beyond the inane ... no discrimination statement ... freedom rhetoric and stand up for and make political decisions That *is* a political statement, and it sounds like you are arguing for yourself the very strange position of being anti-racist yet pro-discrimination and anti-free speech. I support free speech. I disagree vehemently with the racists and their rhetoric, but I also vehemently support their right to say it. Perhaps one day someone will disagree vehemently with what I want to say, yet support my ability to say it, too. This is called tolerance, and it's a shame you don't have more of it. And the operating system they use to do it is completely irrelevant. Debian says no discrimination and WE MEAN IT. What good is a mail reader if its license only allows you to legally express opinions that the author agrees with? That's silly, and a crimp on people that are saying unpopular but correct things. Software is politics, IP is politics, free software is blatantly political in its anti IP posiitons ... or pretends to be ... or is it just another way of doing business and fuck the fallout. You might notice that virtually every bit of software in Debian is copyrighted and licensed. I am not sure where you are getting the anti IP rhetoric from. It would be better to say responsible IP. We dont say you should stop him from using your software ... but you should shun people with such views and who use the product of your community to promote such views, you should shun them from your community. its is not about discrimination Pardon me, but that is *exactly* what you are saying: We should treat people with certain views differently than other people. It doesn't take a copy of the Oxford English Dictionary to work out that this is a prime example of discrimination. Note too that the Debian Free Software Guidelines -- from which the no discrimination line originates -- apply to software licenses and not to actions of the Project. In other words, we have committed ourselves to distributing software that has no onerous restrictions, but we do not compel any Debian user or developer to associate with someone whom they find distasteful. In the end, freedom of association is preserved for the individual. People can make their own choices about whom they associate with, and trying to lecture some ill-defined community with no real boss is an exercise in futility. -- John
Re: Which Distro?
Hum, this message was also sent to ipv6. It looks like it may be some sort of spammer or something... apparently its HTML part it strange... On Fri, Feb 06, 2004 at 06:08:47AM -, K.K. Senthil Velan wrote: Hello all, Iam new to Debain this great community. Now Iam working as a Information Security engineer. My domain of Work will be in C, C++, Java Linux, Windows. We majorly do Implementation of Cryptographic algorithms, Network packet analyzers, Vulnerability assessment etc... So i wud like to know how far Debian will be useful to me in Development environment. I need the entire nuts bolts usefuls of Debian. nybody here to help me? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Which Distro?
Hum, this message was also sent to ipv6. It looks like it may be some sort of spammer or something... apparently its HTML part it strange... On Fri, Feb 06, 2004 at 06:08:47AM -, K.K. Senthil Velan wrote: Hello all, Iam new to Debain this great community. Now Iam working as a Information Security engineer. My domain of Work will be in C, C++, Java Linux, Windows. We majorly do Implementation of Cryptographic algorithms, Network packet analyzers, Vulnerability assessment etc... So i wud like to know how far Debian will be useful to me in Development environment. I need the entire nuts bolts usefuls of Debian. nybody here to help me?
Re: More hacked servers?
On Sun, Nov 23, 2003 at 01:09:27AM -0500, Jim Hubbard wrote: After the Linux kernel server got hacked a few weeks ago, and now this successful attack at Debian, my confidence is shaken. I hope we'll see full I'm curious: why would this serve to shake your confidence? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More hacked servers?
On Sun, Nov 23, 2003 at 01:09:27AM -0500, Jim Hubbard wrote: After the Linux kernel server got hacked a few weeks ago, and now this successful attack at Debian, my confidence is shaken. I hope we'll see full I'm curious: why would this serve to shake your confidence? -- John
Re: Firewall Informer
On Sun, Feb 23, 2003 at 05:47:18PM -, Matt Foster wrote: Just to let you know Firewall Informer transmits network traffic between two network cards on a standard windows PC, this allows So why would you be bothering us with some piece of crap that requires us to install the non-free Windows operating system to use? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall Informer
On Sun, Feb 23, 2003 at 05:47:18PM -, Matt Foster wrote: Just to let you know Firewall Informer transmits network traffic between two network cards on a standard windows PC, this allows So why would you be bothering us with some piece of crap that requires us to install the non-free Windows operating system to use?
Re: Removing stupid HTTP methods from Apache
This is what people suggest for Subversion: Location /test AuthType Basic AuthName Subversion repository AuthUserFile /usr/local/etc/apache2/svn-pass LimitExcept GET PROPFIND OPTIONS REPORT Require valid-user /LimitExcept DAV svn SVNPath /var/svn/test /Location On Tue, Dec 03, 2002 at 01:27:36PM -0800, Anne Carasik wrote: Hi all, I'm running Apache on a Woody machine, and I can't figure out for the life of me how to disable certain insecure HTTP methods like PROPFIND and PUT. Can someone please help me out? I've been searching through the docs and google, and I'm hoping I just overlooked something obvious. TIA, -Anne -- .-.__.``. Anne Carasik, System Administrator .-.--. _...' (/) (/) ``' gator at cacr dot caltech dot edu (O/ O) \-' ` -==.', Center for Advanced Computing Research ~`~~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing stupid HTTP methods from Apache
This is what people suggest for Subversion: Location /test AuthType Basic AuthName Subversion repository AuthUserFile /usr/local/etc/apache2/svn-pass LimitExcept GET PROPFIND OPTIONS REPORT Require valid-user /LimitExcept DAV svn SVNPath /var/svn/test /Location On Tue, Dec 03, 2002 at 01:27:36PM -0800, Anne Carasik wrote: Hi all, I'm running Apache on a Woody machine, and I can't figure out for the life of me how to disable certain insecure HTTP methods like PROPFIND and PUT. Can someone please help me out? I've been searching through the docs and google, and I'm hoping I just overlooked something obvious. TIA, -Anne -- .-.__.``. Anne Carasik, System Administrator .-.--. _...' (/) (/) ``' gator at cacr dot caltech dot edu (O/ O) \-' ` -==.', Center for Advanced Computing Research ~`~~
Re: Good Day -- RR and rbl
On Tue, Jul 02, 2002 at 12:13:30PM -0700, Rafael wrote: It sure will, but being this the security list, let's say someone found a root crack in let's say, the inetd server. And their post gets thrown out because no RR. Hmmm, no one gets warned and some worm starts going around and their goes the internet. Well, alright, an extreme example, but that's one reason of not using RR for mail. That's too silly a reason to take it seriously. No, it's a perfectly valid reason. Just because other admins do not perfectly mirror your opinions does not mean that they are stupid. Not only that, but there are a number of Debian users and developers that, for various reasons, find themselves listed in things like DUL or rfc-ignorant, despite the fact that they are using services for legitimate purposes. Debian mail servers are secure and accept standard e-mail via SMTP. The lists are run on the assumption that readers are intelligent. Perhaps you seek to disprove this assumption, but that is not our problem. Filtering mail going into lists is a dangerous proposition, and doubly so with this list. No spam filter is perfect, and false positives are inevitable. Thus it is improper to blanket spam-filter a list such as this. However, you are welcome to install tools like procmail and use it for yourself. You just want to come up with all kinds of excuses for lame (email) users. If the guys finds a serious security problem he'll be able to send the message one way or the other. No need to do it from unprofessionaly setup MTAs. Perhaps if the problem is serious enough, yes. But what if the person doesn't even know that his message hasn't gotten through? The sender might never retry, never knowing some ignorant admin set up the Debian lists to automatically blackhole spam. I know you won't lose much when I get tired of spam [1] and unsubscribe from debian lists. Being a long time Redhat admin I wanted to switch to debian for some time. We will lose a lot more if we try to force thousands of readers to accept your definition of spam than we will if you spare us your ranting for lack of ability to install procmail and leave. Since I do not tolerate any level of spam I consider it immature to run a If you do not tolerate any level of spam, you are not using e-mail. Sorry, but spam exists. I hate it, you hate it, we all hate it. But it's a fact of life with e-mail. If you go into a nervous breakdown everytime you get a spam because you just can't emotionally cope with another unsolicited e-mail today, then seek therapy. Really. professional mailing list like debian security so that it can be abused by the most stupid script kiddie. Sorry but the impression I got so far There is no security breach involved here. Please watch what you say. is semiprofessional. Cannot recommend it for use at work when people don't want to run serious/professional mailing lists. That is the stupidest thing I've ever seen. What exactly is the correlation between quality of the code and the configuration of the mailing lists, when the two are TOTALLY SEPARATE? This is getting too silly so I'll stop here. Thanks, I was feeling the same. Maybe you'd like to avail yourself of the below: 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: Good Day -- RR and rbl
Ironically enough, Rafael's server rejected my message for the sole reason that Savvis broke reverse DNS for the colo facility my box is at 2 weeks ago and has been slow to fix it. Shows you right away why these restrictions are bad. -- John Goerzen [EMAIL PROTECTED] www.complete.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unsubscribe
This won't work. Have you noticed how EVERY MESSAGE says exactly how to do it, and how you didn't do that? You need to sent the message to [EMAIL PROTECTED] On Wed, Jun 26, 2002 at 09:34:09PM +0200, [EMAIL PROTECTED] wrote: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- John Goerzen [EMAIL PROTECTED]GPG: 0x8A1D9A1Fwww.complete.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package/Mirror integrity?
Christian Hammers [EMAIL PROTECTED] writes: As far as I know there's no possibility to actually apply such a binary signature to a .deb yet. If I'm wrong please point me someone to the relevant docs :) Christian, There exist several tools out there for the purpose of handling cryptographically-signed .debs. These tools are: 1. debsigs; 2. debsig-verify; 3. dpkg plus verification patches; 4. apt-checksigs. These tools are being developed jointly by Progeny and Debian developers. Here is what the tools do: 1. debsigs This package is used to add, delete, list, etc. signatures on .deb packages. Its primary purpose, though, is to add signatures. It comes with a separate program, debsig-autosign, that can add signatures in cases where this needs to be done automatically, though that tool is still somewhat immature. 2. debsig-verify This is the signature verification component. Given a .deb, it will look up policy documents that describe what sort of signatures are expected to be present, from whom, and various other criteria that must be met to consider the package to be cryptographically verified. By using separate policy files for each .deb distributor, the user can successfully verify, on a single system, packages from multiple origins -- eg. Progeny and Debian. 3. dpkg plus verification patches In its current form, this means several things: * If debsig-verify is installed, dpkg will try to verify the signature on each deb when performing an install (-i). If the signature check fails, dpkg will abort without installing the package. * dpkg-dev is modified to include a hook to call debsigs to add a cryptographic signature to the .deb at build time, though this facility is still rudimentary. * dpkg has two new options: --force-missing-sigs and --force-bad-sigs, which force installation of packages without any signatures and those bearing bad signatures, respectively. 4. apt-checksigs This tool is to allow the end user to control signature checking on a per-repository basis. Basically, that means that --force-missing-sigs can get passed on to dpkg automatically for those repositories that do not carry signed .debs. While the security implications of doing such a thing should justifiably give people significant pause, apparently there is significant demand for it nonetheless. This should also have the advantage that the signatures get checked before being passed to debconf for preconfiguring, which would otherwise be one avenue of attack. Progeny is aggressively working on implementing these features. To date, I haven't seen lots of discussion in Debian about it. Where to find code? Well, right now, since it's still being aggressively developed, it's scattered. debsig-verify is in Debian's dpkg CVS and non-us as module debsig and debsig-verify, respectively. debsigs is in non-us. dpkg diffs should be floating around on mailing lists somewhere. Progeny has applicable policy files and keyrings ready to verify our packages in the Progeny package progeny-keyring, in our archive on archive.progeny.com/progeny. Testing code can be found at http://www.indy.progeny.com/~branden/repository/, which includes debsigs, debsig-verify, dpkg, and apt-checksigs. A technical overview, such as it exists, of the system can be found at gopher://gopher.quux.org:70/11/devel/debian. This is somewhat outdated, and incorrect in several respects by now, but is the best that currently exists. The system is extremely flexible, and each site implementing it will want to come up with its own guidelines for what signatures get applied and by whom, and what constitutes a verified package. The principle people working on projects are: (others work on them too) debsig-verify: Ben Collins debsigs: John Goerzen dpkg patches: John Goerzen apt-checksigs: Branden Robinson integration testing: Branden Robinson and the Progeny QA team Hope this helps! -- John Goerzen [EMAIL PROTECTED] www.complete.org Sr. Software Developer, Progeny Linux Systems, Inc.www.progenylinux.com #include std_disclaimer.h [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
