Re: Your help is needed: Please help us fund a replacement for ga@'s stolen laptop
On Mon, 2008-05-19 at 21:04 +0200, Marc Balmer wrote: If you think you can step in and help oga and the project, then please contact me off-list. We can accept donations by wire, Visacard and Mastercard (creditcard fees are covered by my company). I am flat ass broke. If you can provide a URL with donation links, I will ensure that everyone I know stumbles, diggs, reddits, slashdots and (all the rest of those things) it, which should help replace the laptop. That really $(*# stinks. Hopefully no uncommitted code was on it :( I started myself by tossing in CHF 200 (approx $ 200). As a matter of principle I live in self imposed poverty, but perhaps I could help a bit. Please create a page. (And any excess money would go as a donation to OpenBSD, btw.) I could give a rat's ass where excess money goes. Anyone who 'donates' should feel the same way. Helping someone under scrutiny is stupid. The point is he needs some help, since we can (even without donating), we should. Since we should we must. Cheers, --Tim -- Monkey + Typewriter = Echoreply ( http://echoreply.us )
Re: Debian libssl security (Cause???)
On Sat, 2008-05-17 at 08:36 +0200, Otto Moerbeek wrote: Yeah, using tools such as valgrind can help a lot, but the danger side is that it will cause actions to be taken by people who do not understand the code, just to silence valgrind. Since valgrind flags the location of the use of uninialized mem, and--of course--not the root cause, developers can easily be mislead and apply the wrong fix. I think we have a clear demonstration of the danger of using a tool without proper understanding of the code here. In addition, the vague posts from both sides on openssl-dev mailing lists did not help too. -Otto This might be a good example. I'm working on a CLI which is rapidly turning into a mini-shell. I'm not using readline, or other commonly used things to gather input, for the purposes of my own learning and keeping code portable I've elected to write my own functions. Every time I make major changes, I run the program through valgrind. Example results: ==10858== ==10858== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1) ==10858== malloc/free: in use at exit: 48 bytes in 5 blocks. ==10858== malloc/free: 12 allocs, 7 frees, 4,182 bytes allocated. ==10858== For counts of detected errors, rerun with: -v ==10858== searching for pointers to 5 not-freed blocks. ==10858== checked 63,724 bytes. ==10858== ==10858== LEAK SUMMARY: ==10858==definitely lost: 37 bytes in 3 blocks. ==10858== possibly lost: 0 bytes in 0 blocks. ==10858==still reachable: 11 bytes in 2 blocks. ==10858== suppressed: 0 bytes in 0 blocks. ==10858== Use --leak-check=full to see details of leaked memory. As you can see, my program is in its infancy and not much is allocated. I have a leak due to some input stuff not freeing things that are strdup()'ed (I know about this) and I have done a pretty good job of being defensive so far. If something I inherit from libc leaks or throws errors, I quickly know and can explain it. Its not my program, its stuff I used from xxx function. Valgrind is something that is (ideally) used as you go. If you screw up, it will tell you. It should not be dismissed like trivial compiler warnings, but it should also not invoke some kind of knee jerk reaction. Its not exactly the world's best auditing tool for someone who is not used to using it every step of the way. Taking something you are unfamiliar with and trying to correct whatever valgrind complains about is asking for trouble beyond trivial warnings. What amazes me about this whole mess is that at least 1/3 of the GNU core utilities issue many complaints but they are ignored. When you package software, the only reason for squelching the valgrind results of other people's work is to keep those who install your package from asking about those warnings. Like I said in previous posts, shit happens. Nobody needs to be nailed to a cross for this. The lesson to be learned is: Q. Why does your x-y-z package throw so many warnings? A. I am not quite sure, I'm going to ask the developers who wrote it. Well, I know why its happening, but I can't quite be sure why the code that causes it is in there. Cheers, --Tim -- Monkey + Typewriter = Echoreply ( http://echoreply.us )
Re: DNS Question.
On Sat, 2008-05-17 at 18:21 -0700, Lord Sporkton wrote: 2008/5/17 Dark Nebula [EMAIL PROTECTED]: Hi all, Is possible perform a DNS query, that gives me all A records from one ip, (without using the reverse DNS) ? Thanks a lot Are you asking to find all the forward A records for a given IP? If so, there is no way to do that, not even with rDNS There are services that track IP usage and correlate them to domains. The tools allow you to find out (approximately) what A records point to any given IP. This one is relatively accurate: http://www.myipneighbors.com/ I would not treat its output as gospel. It gives a decent indicator of how many virtual hosts are pointed at any given IP and shows you who they are. Note, this only tracks A records, not MX records and is easily confused by CNAMEs. There is no way to query for this, you would have to get a list of all FQDN's in use on the Internet and continuously dig them to record their IP. I don't know of any service that does this and offers free automated queries via some kind of text client, most insist that you use their web interface. This makes them handy for manual look ups but useless in any kind of automated tool. Cheers, --Tim -- Monkey + Typewriter = Echoreply ( http://echoreply.us )
Re: Debian libssl security (OpenSSH safe?)
On Thu, 2008-05-15 at 06:31 -0700, Darrin Chandler wrote: Can you explain why that's not effective? Do you know ssh-vulnkey (or the Perl script) does not reliably detect bad keys? Just to ensure I have facts separated from co-workers just going on paranoid tangents, I checked again and asked those who noted it did not work exactly what happened now that the 'knee jerk' syndrome is over. 2 people might have botched the install (not a reliable indicator) 3 Did not have ordinary configurations (again, not a reliable indicator) 1 Reported weak keys weren't detected. So, I guess I can't be sure. I know that it didn't work for some but that might be due to human error. Things go badly when rushing :) What does seem correct is that the utility can't guess beyond the typical locations and names. Sorry for the ambiguity, --Tim -- Monkey + Typewriter = Echoreply ( http://echoreply.us )
Re: Time for OBSD everywhere?
On Fri, 2008-05-16 at 10:21 +0100, Tomas Bodzar wrote: http://blog.wired.com/defense/2008/05/air-force-mater.html That reminds me of a story where investigators were stumped for 3 months trying to get data off a 1541 5.25 drive connected to a Commodore 64. I wish I could find the link to it. I'm not so worried about that particular project (for obvious reasons), but I have been putting together a plan to move anything that talks to the world to OBSD. Cheers, --Tim -- Monkey + Typewriter = Echoreply ( http://echoreply.us )
Re: Time for OBSD everywhere?
On Fri, 2008-05-16 at 23:26 +0200, Rico Secada wrote: On Fri, 16 May 2008 22:35:00 +0200 chefren [EMAIL PROTECTED] wrote: I know at time it was said that OpenBSD is not for everything, but so far, I still haven't find anything that I need that OpenBSD can't shine doing. I can almost second that except for the few cases in which we really need to update stuff without fuzz, then we use Debian. I'm probably going to keep desktops / laptops Debian(ish). I've been working with it for years, I'm extremely used to it and I need to remain productive. My plan is to replace most servers with OBSD while really refining skills at writing stuff to be portable. Once I get that down, I'm going to start replacing firewalls, load balancers and other appliances with OBSD. Its probably going to take a year, but I think the result will be a nice example of putting each OS to its best use. -- Monkey + Typewriter = Echoreply ( http://echoreply.us )
Re: Debian libssl security (OpenSSH safe?)
On Thu, 2008-05-15 at 10:02 +0100, Dave Ewart wrote: Debian (and thus also Ubuntu) have released updated openssh packages which include a new tool called ssh-vulnkey which can be used to check the running system[1] for vulnerable keys: ssh-vulnkey works similarly to the Perl script in the Debian announcement. That is not 100% effective (afiak). Its still advised that you toss any key that you are not 100% certain came from a non-effected system for every user. They can always go back in once your sure that they are safe. I believe the original assessment was correct: *all* systems running SSH ought to check for these vulnerable keys, not just those systems running Debian or derivatives. Correct, It is a user propagated issue. Its best to just chuck all keys for now and put them back as you're sure that they did not come from a buggy keygen. Yes, it's Debian's fault, but we all have to manage the consequences. Shit happens :) -- Monkey + Typewriter = Echoreply ( http://echoreply.us )
A list of non-free compliant companies?
First, Theo, thank you for your work to keep non-free drivers out of free operating systems. I am a die-hard GNU, however I really respect your work and applaud you for giving you time. Every push counts. Does someone have a list of companies (model numbers included) that have produced free drivers for their hardware? I'm making yet (another) fork of Ubuntu named Gridnix, for those who want a completely free server OS that lends well to virtualization and clustering. I hope to say on our website, if you use such and such, our OS won't work for you, go away and complain to your hardware manufacturer. My hope is that my ideals do not get in the way of productivity. I don't re-license code, I don't preach and I don't argue. I'm just hoping to gather some information. 2/3 of the patches that I've submitted (and were accepted) have been under the modified BSD license. Hopefully, someone can help :) -- Monkey + Typewriter = Echoreply ( http://echoreply.us )
