As soon as it sees the domain resolves to the same address it can move on.
Each one of those addresses can be another virtual host. For example, bsd.slashdot.org and yro.slashdot.org are both handled by the wildcard DNS entry, but you get different content when you type the URL into a browser. It would be difficult to write a computer program to differentiate between "real" virtual hosting with wildcard domains like this and random stuff like verisign-sucks.slashdot.org.
Moreover, you can have pages generated dynamically based upon the hostname used. Something as simple as adding a footer "Thanks for using xxx.slashdot.org" could create problems.
now tell me whiz kid, how can you as a citizen audit a closed source program to ensure that it offers the correct results?
That's certainly more difficult without source but not necessarily impossible.
If you speak of "results" there would generally be some calculation to verify. It's pretty trivial to verify that a word processor offers correct results - you can measure what appears on a printed page. If there is some serious calculation, you would surmise that the basic functions of the package behave as defined and anything you add on top of it can be verified since you have source for what you write.
Say we're talking about Matlab, Stata or Mathematica. There's a pretty good chance that matrix multiplication works correctly in Matlab, as it would otherwise be a useless product and thousands of researchers would be in serious trouble. These three products are good examples as they are extremely powerful and the open source equivalents don't yet approach them. Try explaining to the scientists at Sandia, LLNL or Argonne that they can't use Matlab because Congress decided proprietary software is unethical.
Now if you can't trust that the basic functionality of any piece of software works as intended, you would have a hard time writing large classes of programs. For a "hello world" program in C, you'd need to completely audit GCC, libc and your kernel. If you're willing to rely on the analysis of the thousands of people who have worked with these sources, why are you not willing to rely on the analysis of tens or hundreds of people who have worked with the Solaris libc or
the QNX kernel? It's only a question of numbers of eyeballs if you don't have time to validate your kernel's source.
If you're writing something that absolutely requires complete validation at all levels, then you would indeed need source. However, these situations are rare. Say you're writing a control unit for a nuclear power plant or the next space shuttle; if you decide to use VxWorks, you'll probably get access to the source for someone under NDA (I understand this is how it usually works). Quite honestly, I'd rather that the neighborhood nuclear power plant uses VxWorks rather than Linux shoe-horned into an RTOS role.
I'm not, and never was, denigrating open software. My point is that there are certain cases where proprietary softare makes sense. Say you want to take your organization from using traditionally-keyed doors to a card-swipe system. Are you willing to spend hundreds of thousands of dollars to design an electronic lock, code its firmware, and then write the accompanying card-encoding software? Probably not. (For comparison, current proprietary card-swipe systems cost less than $20000 for an unlimited software license and less than $500 per lock hardware.) Since this is a security device, anyone in their right mind would choose the commercial system that offered its firmware and accompanying software under an open license, but, I can tell you with some certainty that there is no such offering. If you believe that without exception all proprietary software is illegitimate (as the FSF does), you'll be stuck re-chambering the locks in all your buildings whenever an employee leaves, or you'll take sizable amounts of money away from some other budget to fund an engineering and software team (and you'll continue re-chambering locks in the months or years it takes to develop your "free" electronic locks). If your company chooses to do this, that's fine, but I don't agree that the Department of Agriculture or the local DMV should be spending their time (that is, my money) like this.
Let me part with the following question: do you drive a vehicle? If yes, do you have access to the firmware source for your vehicle's fuel-injection computer? If no, why are you willing to entrust your life to proprietary software?
All I'm saying is that there are some institutions that now turn away from closed-source out of principle.
This is fine - private institutions can do whatever they want.
However, governments cannot do whatever they want. They're spending our money.
Let's say the state needs some program to perform a specific function. Say, they need a complex statistical analysis program to compile something out of census data. Let's say they have two choices: they can write their own program (and then open up the source for it) or they can buy a proprietary system. Say the proprietary system costs $10000 for this one-time calculation. Say developping an equivalent program requires $1000000 (and, to belay further arguments, we'll say the system they develop
will only be useful for them and only this one time with their particular census data in that particular year).
Now, which is more important? The "freedom" from opening the source for their own program, or $990000? You might say the "freedom" is more important, but it's not - part of that $990000 comes out of my salary and I do not approve of this quixotic endeavor; I question the usefulness of making such a specialized (eg, useless) program "free" (whatever is meant by that word).
Now, I agree that in general goverments are the ideal place to replace proprietary software with open systems. But this is because most open systems cost less in the long run and I demand that my money is spent efficiently (the census data example was specifically concocted as a example of where proprietary software is less costly). If everyone (or a majority) agreed with the FSF's idea of "freedom" then governments would be obliged to migrate from proprietary systems. In certain situations, this is already the case: most people, if properly informed, would demand that all the source for any electronic voting system must be publically available with no restrictions. However, as long as the majority of people disagree with the FSF and believe that proprietary software can be legitimate, goverments are under no such ethical or political obligation and the only factor determining their choice in software should be cost.
I take great amusement out of telling this to
people. That network and netmask defines exactly
what's permissible on my home network, so only
the two/24s defined by the above will work with my NAT box. This confuses a great
many people.
I wouldn't put it past the marketing department to consider something like that.
I've been looking through my mail and I realize that you are absolutely right. Most of these messages contain the product name in the subject line.
Funny thing is, whenever I see one of these messages, I think: "OK, Norton AntiVirus SuperGate 5000 must be written by dimwits if they didn't think to include full headers; thus, I should stay away from all Symantec products."
mysql_query("select * from USERS where USERID=$USERVAR");
If php-nuke contains lots of code like this, it
should absolutely refuse to run if
magic_quotes_gpc.
is OFF. This setting will not, of course, protect
against the problem you described, but if the
code contains this kind of stuff, almost all SQL statements could do much nastier stuff.
Also, I hope php-nuke does not rely upon register_globals (your example makes it look like it does).
I'm looking for some kind of message board system similar to php-nuke, but it needs to be rock-solid since it will be running in a sensitive environment. I'm willing to write my
own, but don't have lots of time so I might be hiring someone to do it (idea is that it's much
easier to carefully audit 100% of the code if it follows my spec and contains only those features I need). This sounds like a trivial project to write, but as I spec it out, it ends up being a lot of code.
Anyone have any suggestions? It needs to be modular code as I will be ripping out and replacing chunks of it (logins will go to our LDAP server, groups and boards will come from our existing SQL databases), it does not need spurious features, it needs to look very polished and professional, but most importantly, it needs to be very careful, audited code. I would prefer php or python over perl.
A possible reason for this is the number of excellent microbrew pubs in Boulder.
I visited a friend who was a grad student in Boulder. In one night, we visited five bars, each of which brewed its own beer. The beer was great; the next day wasn't.
Most of the auto-responders I've seen simply send a note with the subject of the message to the From: address. A few might include part of the body of the message.
These are absolutely useless as you can't figure out what machine originally sent out the message without the full Received headers. I've not seen one virus auto-responder include the full Received headers. The right thing to do would be to include the entire message as an RFC 2047 MIME attachment.
My reasoning is that these auto-reply messages occasionally get to the right person: namely, me. I then look at the infected IP address and if it's one of ours, send someone out to fix it. This is what I do for messages that get sent to undeliverable addresses where the remote site sends a bounce containing the full original message. A lot of these end up coming to one of my addresses since my addresses are widely advertised within our organization and are likely in many people's web cache and address books.
Past this, I don't see any reason for the auto-replies. They'll never get back to the person whose machine was infected, but they might get to me. It's easier to find out about the problem from some bounce and fix it immediately than it is to have some end-user from some other organization complain to you and then having to explain to this person how to send a message containing full headers (which is actually difficult and non-intuitive in most Windows MUAs).
Another (slightly devious) possibility: send a specially-crafted email to sorc3r3r@sorc3r3r.org. The email is HTML and contains an image link to some web server you own.
More fun: google for sorc3r3r. First few links are for someone who registered with a number of dating services in New Zealand. Next you have some IRC activity in Romanian. Then you have some caches of rooted web pages, and sorc3r3r gets a shoutout along with a bunch of other Romanian nicknames (mafiotu (mafia man), dulcica (sweet girl), beculetz (light bulb)).
This is google's cache of a Romanian web server's stats page. Note that sorc3r3r.org accessed this page, but the DNS entry was a different IP at the time (traceroutes to Australia or New Zealand). This ties together the sorc3r3r.org domain name with New Zealand and Romanian, so it corroborates the rest of the links.
So we have our man. A lonely Romanian in New Zealand who I'm guessing runs Windows XP and plays Counter-Strike. He's also interested in script kiddie games on IRC, so the spammer email trick may just work if you're clever with the subject line (to trigger a preview). (Look up some Romanian greetings, that should do the trick:).
For the curious: yes, I'm Romanian (that's how I can read the IRC logs and whatnot). And no, we aren't all little script kiddies, although that's what it looks like if you're ever on IRC (so I have no sympathy for this guy - when I tell fellow network security guys about my origins, the first thing that pops into their heads is the IRC nonsense).
This paragraph is crap for the lameness filter (apparently, you have to insert crap at the beginning, not end, of your post if you want to post a program listing or command-line session). Skip to the next paragraph. This paragraph is crap for the lameness filter (apparently, you have to insert crap at the beginning, not end, of your post if you want to post a program listing or command-line session). Skip to the next paragraph. This paragraph is crap for the lameness filter (apparently, you have to insert crap at the beginning, not end, of your post if you want to post a program listing or command-line session). Skip to the next paragraph. This paragraph is crap for the lameness filter (apparently, you have to insert crap at the beginning, not end, of your post if you want to post a program listing or command-line session). Skip to the next paragraph.
You generally have to provide a real phone number or something identifiable to get a recognized SSL cert, so this is always worth a try:
kalashnikov% openssl s_client -showcerts -connect sorc3r3r.org:443 CONNECTED(00000003) depth=0/C=US/ST=CA/L=Mt Shasta/O=Finest Planet/OU=Service/CN=www.finestplanet.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0/C=US/ST=CA/L=Mt Shasta/O=Finest Planet/OU=Service/CN=www.finestplanet.com verify error:num=27:certificate not trusted verify return:1 depth=0/C=US/ST=CA/L=Mt Shasta/O=Finest Planet/OU=Service/CN=www.finestplanet.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=CA/L=Mt Shasta/O=Finest Planet/OU=Service/CN=www.finestplanet.com i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority -----BEGIN CERTIFICATE----- [snipped for lameness filter] -----END CERTIFICATE----- --- Server certificate subject=/C=US/ST=CA/L=Mt Shasta/O=Finest Planet/OU=Service/CN=www.finestplanet.com issuer=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- No client certificate CA names sent --- SSL handshake has read 1317 bytes and written 320 bytes --- New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA Server public key is 1024 bit SSL-Session: Protocol : TLSv1 Cipher : EDH-RSA-DES-CBC3-SHA Session-ID: AE5A02407FE137D27EDEA6C315B87DC83C4E9D137D3C09E2DB 1D3A7B3698CF4C Session-ID-ctx: Master-Key: C0701DD1BA02110163248E2CD8B9016099002A0FD597317BB3 A3C83C872F1A2250A9CC1736C6B1846EAFDDD534285867 &n bsp; Key-Arg : None Start Time: 1061096037 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- HEAD / HTTP/1.0
HTTP/1.1 302 Found Date: Sun, 17 Aug 2003 04:52:03 GMT Server: Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6b PHP/4.0.6 mod_auth_pam_external/0.1 FrontPage/4.0.4.3 mod_perl/1.25 Location: https://www.finestplanet.com/ Connection: close Content-Type: text/html; charset=iso-8859-1
closed kalashnikov%
You got this:
lake% host 216.98.146.249
249.146.98.216.IN-ADDR.ARPA domain name pointer 4t146249.aspadmin.net
See this:
kalashnikov% host www.finestplanet.com
www.finestplanet.com has address 216.98.146.249
This is the same Cobalt machine you noted (perhaps a web farm). Looks like a mom-and-pop dialup ISP. Most likely some innocent third-party seeing as how this looks like a legit business. If it's not legit, you could contact Equifax to get real contact information. They have a number of contact numbers and email addresses on their page, so someone should contact them and point them to this thread because they'll be seeing lots of strange stuff in their logs.
My opinion: this guy registered an IP pointing to this machine. This IP is irrelevant
Hey, no problem. I am of course exaggerating. GTK 1.2 is not that bad, but GTK 2 is near-impossible to get working on non-Linux/BSD systems. It's nothing fundamentally wrong with GTK, but any huge piece of software that uses
all the latest gizmos and APIs and has lots of dependencies from unrelated parties will likely be less portable. Sometimes it saves man-hours to simply write some bogus thing directly in XLib rather than figuring out how to get some library to compile on some esoteric *nix (and then duplicating that for each of your users).
Xlib really isn't so bad - it's actually quite nice (compared to, say, Platform SDK), but it's very low-level so you have to write all your own widgets which, for most of us, will look like ass. But writing your own widgets from scratch is fun (at least it's fun the first time you do it).
Perhaps fltk could be useful in these circumstances: it looks like it can compile with just X11, no external libraries. Never really played with it but it looks very nice (especially since it's designed to make static linking feasible).
Include GTK 1.2 and then have your install check if it is needed, if it is install it.
Yes...and also include Pango, gettext, GNU Make, pkg-config, glib, ATK, GNU iconv, libjpeg, libtiff and libpng. Then you can figure out via a very simple configure script which ones are installed and which ones need to be installed. And none of those nine dependencies or any of their dependencies will have a bug in their autoconf scripts that prevents them from compiling via a simple./configure && make on AIX or HP/UX or Irix.
Of course, you also include the dependencies for each of the above nine dependencies, so you end up having perhaps fifteen or twenty libraries that you distribute, compile and statically link to your little server program so it can show a configuration dialog box.
While you're at it, you might as well include util-Linux (or whatever) for the build process so you don't have to deal with a funny version of sed (not a big deal since your software already uses non-standard gmake extensions, requiring it to build with only GNU Make), and you might as well include GNU awk if you require GNU sed. Of course, you'll need to include GNU bash since somewhere in one of those dependencies, some programmer used a non-standard bash extension rather than plain Bourne in his autoconf script.
And, of course, you have to deal with GNU C extensions in those dependencies such as non-standard variable-argument macros or the "typeof" operator, or zero-length arrays and you don't want to force your dependency developers to have to deal with HP's buggy compiler. So you might as well include GCC and its dependencies such as binutils. While you're at it, go ahead and include glibc so you don't have to modify some dependency to use pthreads correctly rather than relying upon some bug or inadvertantly exposed interface in glibc.
By this time, you've surely run into some network library that looks for "struct udp" in <linux/udp.h> or forgets to include sys/types.h before unistd.h. You might as well include a copy of the Linux kernel, since all the above depencies are known to work well on Linux (after all, that's almost exclusively the system used for their development).
Hell, you might as well just give your clients a Redhat CD. Screw those people who choose to use something else.
Could this have something to do with readline being GPL'd, and Oracle not wanting to release sqlplus under it?
Most likely.
The readline folks are real fanatics. They've continually denied requests to put readline under LGPL - they want to make sure the only things that use readline are GPLed. That is, they're doing this on purpose.
Because of this debacle, the *BSD camp was forced to come up with the editline library for all their stuff. And then you have stuff like Sun's dbx that has its own readline replacement. And Oracle's SQL client, and Sybase's isql, and sqsh,....
Now, it's not quite trivial to write a readline replacement because you have to deal with all sorts of crufty, non-portable *nix terminal arcana, but it's also not difficult. The problem is that all readline replacements are incompatible with each other. You can customize readline applications through.inputrc - this is really cool because you can make one binding and it works in bash, gdb, your (GPLed) console mp3 player, etc. However, these bindings won't carry over to FreeBSD's cdcontrol program or Sun's dbx.
The GPL also means that I can't use readline for some program I write for a client because these programs are usually internal company things that the company owns and can license however they want - they won't pay me if I stipulate that the code I wrote (which belongs to them) must be licensed under GPL for such a trivial reason. Since my clients won't be too happy paying me to write stupid terminal IO routines, I'm forced to either use plain old fgets or use editline, which (IMHO) is not as nice as readline.
The fanaticism is costing the *nix community some useful functionality, which is kind of sad.
This is useless for the purpose the original poster needed. He wants to verify the sender's identity. I can just inject fake headers into any message and have that bounced about. The headers remain: MTAs simply add other headers at the top and you can't specify that only certained Received: paths are valid (such as those that don't leave your company network) because someone will inevetably relay mail externally.
You might specify that "authenticated" mail only comes through one central relay and the Received header to use is the latest one. What use is this, however, if it requires either non-existent client-side support or sufficiently technical users that they can grok mail headers? If you're making client-side requirements, PGP is a far more useful feature to add/require, and if you have sufficiently technical users, they can understand public-key crypto and they can use PGP-aware clients.
SMTP AUTH is an alternative to running an open relay: you have travelling employees that might be on any network but need to send outgoing mail, hopefully without modifying their MUA settings. When combined with SSL/TLS, SMTP AUTH solves this problem. Most graphical MUAs now support AUTH and SSL, so this works acceptably, but also requiring SMTP only after POP or IMAP logins also works just as well with no special client-side support.
Funny thing about Kerio is that it works by hooking calls into wsock32.dll. You can write a simple program that does not use winsock and it bypasses Kerio.
Download winpcap. Unlike Unix libpcap, it includes both functions to create packets as well as capture them. It does not use winsock but rather installs an NDIS driver that sits lower in the TCP stack. You can then write a simple program that listens for packets and then manually constructs packets with UDP/TCP headers and sends them out. Completely bypasses Kerio.
If you'd like, I can post the code. I tested this about a month ago and it worked against the latest version of Kerio Personal Firewall. Took about an hour of work for a proof-of-concept program. You could get really crazy and implement a TCP stack in userspace and then write all kinds of trojans that would bypass TPF. Only works with privileged accounts since you need permissions to install an NDIS driver, but outside of controlled corporate environments, all Windows users use the Administrator account anyway.
Sygate and ZoneAlarm both install low-level NDIS drivers and are not susceptible to this attack. (At least I couldn't figure out how to bypass them - it may be possible to install a TDI hook which sits below NDIS, but this looks like months of work.)
Other than that, TPF really is much nicer than Sygate or ZoneAlarm, but this is a pretty gaping hole. I'd recommend Sygate over ZoneAlarm.
The "default" link is so you can manage multiple versions of the same package.
In addition to/usr/local/bin, do the same for/usr/local/lib and you never again have to deal with "ldconfig", "ld.so.conf", "--with-whatever=/path/to/whatever", etc. Same with "sbin", "etc", "libexec", "include" and so on ("man" directories are a bit different but the same idea).
Next step is to put all the symlinking into a simple script which is run after installing packages or upgrading/downgrading (eg, changing the "default" link).
Been doing this for years - works great on all systems (Linux, Solaris, *BSD, even MacOS X). Things always compile right out of the box and you can maintain multiple versions of the same library if needed. Only problem is that occasionally a package author assumes that ${prefix}/bin already exists and does not create it on "make install" but that's pretty trivial to fix.
No need to modify the shell. If you start messing with PATH, you also have to start messing with MANPATH, setting different paths for superuser ("sbin"), and then changing your compiler/linker so "include" and "lib" work. And then you have to worry about stuff like "libexec" which contains binaries that may be called from different packages (eg, postfix/qmail/etc replacement for sendmail binary). Just use symlinks and everything just works.
It would be nice if the system were somehow "built-in" so it would automatically download and install dependencies prior to compile from some distributed mirror system (like ports), but that's probably asking for too much.
With Java, I can write two functions
foo(int a);
foo(int a, int b);
...and the runtime would be able to route calls to the right function. Is this not how PHP works?
No, php does not work like that. You cannot define two different functions using the same identifier in the same namespace and I imagine this isn't going to change for PHP5. This is a good thing. This makes it absolutely clear which function your code is calling, which vastly improves maintainability.
In addition, php functions can have default arguments, unlike Java. Your example would work like this in PHP:
function foo($a, $b = -1)
{...
}
If -1 is a legitimate value for $b (and $b can take on any integer value), you make the $b argument an object with a "set" and "unset" state (Java way) or you simply add another optional argument which specifies whether or not $b is valid (php way). This is not a nasty hack: you see a function call and you can immediately tell which function definition is used without examining any object hierarchy.
In addition, php is dynamically typed, so function overloading makes no sense at all because a function's signature is simply the function's identifier. Look at other dynamically typed languages like Scheme and you will see that they do not implement the type of overloading that you speak of.
There are two reasonable uses of C++-like function overloading: 1. simulating optional arguments, like this person wanted (first hit from google on "Java optional arguments"); and 2. behaving differently based upon the type of the argument, like this:
void foo(int a); void foo(double a);
As you can see, the second reason is useless with a dynamically-typed language. In addition, it can lead to all sort of problems in C++ and Java and should be avoided. Example: what if your program now has to deal with another type - say "BigInt" arbitray-precision integers, in addition to ints and doubles? You cannot subclass "int" since it is a primitive non-object, so you will have to modify all your code that uses "int a" and make "BigInt a" versions of the functions. If you can foresee the problem, you can use a wrapper object (Java's "Integer") while initially writing your function "foo" but you cannot fix existing code: if you have a library that uses "int" you need to re-write portions of it when your program grows past 32-bit integers.
You may have been confused by the php5 example on the website:
Class Hello { function __call($name, $args) { echo "Hello $name!\n"; } }
This has nothing to do with the C++ or Java notion of "overloading." The word "overloading" means something completely different in each language, and you won't get anywhere if you expect C++-like constructs in PHP.
Unlike Java or C++ or most of the other C-syntax based procedural languages (with the notable exeption of Objective C), PHP has a dynamic run-time type system, which means it can implement dynamic run-time binding. What the php5 __call construct allows you to do is to bind identifiers at run-time. If you've studied Lisp or Scheme, you will understand the power of this. However, from the presentation, I do not see any way to define code at run-time (Lisp's lambda or perl's "sub {...}"), so it won't allow you to do functional programming. What (I believe) it will allow you to do is dynamic binding, like Objective C or Smalltalk. I can't quite figure out why this would be useful in php, however:)
Thus, the analogy must be deemed to fail. There is no "sharing" going on here, because the software was sold to end users.
Not quite true. You don't buy Microsoft software - you lease it. You pay for the privilege of using it and you own the media on which it came. Since you own the CD, you can do whatever you want with it (frisbee, funny hat, etc.), but MS EULAs make it quite clear that your use of the software is restricted.
Not that big a deal - it's just text, so I can fix any munging that some MUA does. If it's just my mail, then I don't care, but if I have to set up other people's mail, then I go with qmail + courier. I agree that it's a better way of dealing with mail, but lots of MUAs still don't grok it.
I assume that you're trolling. An email client is so lightweight--mostly GUI and waiting for sockets-- that you could write it in *anything* and even on 200MHz Pentium, and it would be just fine.
Wrong.
My preferred mail client used to be vm. This is a mail client written in Lisp. I loved it because it was extremely easy to hack - almost anything you would want to change not only had a setting, but most things had various callbacks, hooks, etc., so you would plug in your code to modify its behaviour. If you found something that didn't have a hook, it was trivial to figure out where the function was defined (C-h f) and change it on-the-fly.
The problem was that it was too slow. Reading a 1M+ mailbox would take up to a minute on my workstation. I have lots of those.
I'm now using mutt because it's fast. It only takes maybe two seconds to parse a 10M+ mailbox ("parse" = look for mbox boundries, set up an index in memory so you can jump to any message instantly).
I'm sure you'll reply that vm needed to do something more "clever" to be faster - like keeping around indeces on disk or using a mailbox format other than mbox. The problem is that us Unix folks do things with mail outside of the MUA. Like edit it directly or run it through perl scripts or use multiple MUAs. This becomes a PITA if you don't use mbox and persistent indexing is pointless since the index would have to be rebuilt any time I did something to the mailbox (which is often enough that indexing wouldn't help).
The basic problem was that file i/o is slow in Emacs Lisp. VM was absolutely high-quality code and you can't disagree with that until you've studied the code.
What MUA do you use? Are you willing to eat your own dog food? If your MUA is written in C, are you willing to write one in some HLL? What about your web browser? Are you willing and able to write a web browser in a HLL, complete with asynchronous DNS, plugins and multiple language encodings?
Once I picked up a couple of really cheap no-brand 10/100 cards that had the same MAC address..
I've seen this three times. Twice with some no-name tulip clones and once with a couple of really old Macs with built-in ethernet.
If you keep the machines on separate subnets, you'll never know about it (unless you record MAC addresses). However, once you put them on the same subnet, mighty strange things start hapenning - one machine works while the other doesn't - seemingly random intermittent behaviour. Really hellish to diagnose. I figured out the Macs pretty easily as they were sitting right next to each other (go to one, ping out, some packets get through, same story with the other one, but try to ping each other and nothing goes through - then I ran a bpf sniffer and it became clear (Macs were running NetBSD)). The tulip clones were in a large i386 Linux environment and were quite difficult to figure out.
Real PITA. Should have recorded the vendor prefix, but I wasn't so wise back then.
Have you ever looked at MySQL's online documentation? It's wonderful...
I think the online documentation sucks.
Until only a couple versions ago, it was one huge file that took forever to load unless it crashed your browser. It was also impossible to search because your search would always get you irrelevant stuff (search for some select function gets you lots of hits in the installation and admin sections).
Even now it still sucks. It either loads immense pages with "chapters" which are still too big to search and take too long to load, or it loads only one tiny bit with user comments, which I really don't care about.
Why is the installation, administration, C language API information in the same book as the actual sql language specification? I have to scroll halfway down the page to get to the sql specification part.
They really need to hire an editor or a technical writer - they don't publish the book in a format that users can use.
How would you typically use this book? You might look at the installation bit if you have problems installing it. You might browse the administration bit when you write a backup script to ensure you're not doing anything stupid. However, the main way you use this book is when you're writing some application and you need to look up the syntax for some sql function - in which case you don't care about the administration or installation chapters. I don't use DATE_ADD(x, INTERVAL 3 DAY) often enough that I would remember the syntax. When I do need to remember the syntax, I find it's easier to grep for it in some earlier project's code than it is to look in the actual manual. It's as if the manual were written for browsing rather than quick reference (indeed, I imagine the mysql authors would only browse through the book rather than use it for reference - thus the value of a third-party technical writer). It may be organized OK for a dead-tree form (where you want all that information in the same book so user's don't have to buy six different books), but it's no good as online reference documentation.
Even the sections themselves (once you find the relevant one) are poorly organized.
Slashdot Mirror
Each one of those addresses can be another virtual host. For example, bsd.slashdot.org and yro.slashdot.org are both handled by the wildcard DNS entry, but you get different content when you type the URL into a browser. It would be difficult to write a computer program to differentiate between "real" virtual hosting with wildcard domains like this and random stuff like verisign-sucks.slashdot.org. Moreover, you can have pages generated dynamically based upon the hostname used. Something as simple as adding a footer "Thanks for using xxx.slashdot.org" could create problems.
That's certainly more difficult without source but not necessarily impossible.
If you speak of "results" there would generally be some calculation to verify. It's pretty trivial to verify that a word processor offers correct results - you can measure what appears on a printed page. If there is some serious calculation, you would surmise that the basic functions of the package behave as defined and anything you add on top of it can be verified since you have source for what you write.
Say we're talking about Matlab, Stata or Mathematica. There's a pretty good chance that matrix multiplication works correctly in Matlab, as it would otherwise be a useless product and thousands of researchers would be in serious trouble. These three products are good examples as they are extremely powerful and the open source equivalents don't yet approach them. Try explaining to the scientists at Sandia, LLNL or Argonne that they can't use Matlab because Congress decided proprietary software is unethical.
Now if you can't trust that the basic functionality of any piece of software works as intended, you would have a hard time writing large classes of programs. For a "hello world" program in C, you'd need to completely audit GCC, libc and your kernel. If you're willing to rely on the analysis of the thousands of people who have worked with these sources, why are you not willing to rely on the analysis of tens or hundreds of people who have worked with the Solaris libc or the QNX kernel? It's only a question of numbers of eyeballs if you don't have time to validate your kernel's source.
If you're writing something that absolutely requires complete validation at all levels, then you would indeed need source. However, these situations are rare. Say you're writing a control unit for a nuclear power plant or the next space shuttle; if you decide to use VxWorks, you'll probably get access to the source for someone under NDA (I understand this is how it usually works). Quite honestly, I'd rather that the neighborhood nuclear power plant uses VxWorks rather than Linux shoe-horned into an RTOS role.
I'm not, and never was, denigrating open software. My point is that there are certain cases where proprietary softare makes sense. Say you want to take your organization from using traditionally-keyed doors to a card-swipe system. Are you willing to spend hundreds of thousands of dollars to design an electronic lock, code its firmware, and then write the accompanying card-encoding software? Probably not. (For comparison, current proprietary card-swipe systems cost less than $20000 for an unlimited software license and less than $500 per lock hardware.) Since this is a security device, anyone in their right mind would choose the commercial system that offered its firmware and accompanying software under an open license, but, I can tell you with some certainty that there is no such offering. If you believe that without exception all proprietary software is illegitimate (as the FSF does), you'll be stuck re-chambering the locks in all your buildings whenever an employee leaves, or you'll take sizable amounts of money away from some other budget to fund an engineering and software team (and you'll continue re-chambering locks in the months or years it takes to develop your "free" electronic locks). If your company chooses to do this, that's fine, but I don't agree that the Department of Agriculture or the local DMV should be spending their time (that is, my money) like this.
Let me part with the following question: do you drive a vehicle? If yes, do you have access to the firmware source for your vehicle's fuel-injection computer? If no, why are you willing to entrust your life to proprietary software?
This is fine - private institutions can do whatever they want.
However, governments cannot do whatever they want. They're spending our money.
Let's say the state needs some program to perform a specific function. Say, they need a complex statistical analysis program to compile something out of census data. Let's say they have two choices: they can write their own program (and then open up the source for it) or they can buy a proprietary system. Say the proprietary system costs $10000 for this one-time calculation. Say developping an equivalent program requires $1000000 (and, to belay further arguments, we'll say the system they develop will only be useful for them and only this one time with their particular census data in that particular year).
Now, which is more important? The "freedom" from opening the source for their own program, or $990000? You might say the "freedom" is more important, but it's not - part of that $990000 comes out of my salary and I do not approve of this quixotic endeavor; I question the usefulness of making such a specialized (eg, useless) program "free" (whatever is meant by that word).
Now, I agree that in general goverments are the ideal place to replace proprietary software with open systems. But this is because most open systems cost less in the long run and I demand that my money is spent efficiently (the census data example was specifically concocted as a example of where proprietary software is less costly). If everyone (or a majority) agreed with the FSF's idea of "freedom" then governments would be obliged to migrate from proprietary systems. In certain situations, this is already the case: most people, if properly informed, would demand that all the source for any electronic voting system must be publically available with no restrictions. However, as long as the majority of people disagree with the FSF and believe that proprietary software can be legitimate, goverments are under no such ethical or political obligation and the only factor determining their choice in software should be cost.
Bah, that was supposed to be 172.16.42.0/21. Eh, no sleep.
Why?
I've been looking through my mail and I realize that you are absolutely right. Most of these messages contain the product name in the subject line.
Funny thing is, whenever I see one of these messages, I think: "OK, Norton AntiVirus SuperGate 5000 must be written by dimwits if they didn't think to include full headers; thus, I should stay away from all Symantec products."
Yeah, thanks. Have you never heard of Godwin's law?
So where do I pay my license fees?
If php-nuke contains lots of code like this, it should absolutely refuse to run if magic_quotes_gpc. is OFF. This setting will not, of course, protect against the problem you described, but if the code contains this kind of stuff, almost all SQL statements could do much nastier stuff.
Also, I hope php-nuke does not rely upon register_globals (your example makes it look like it does).
I'm looking for some kind of message board system similar to php-nuke, but it needs to be rock-solid since it will be running in a sensitive environment. I'm willing to write my own, but don't have lots of time so I might be hiring someone to do it (idea is that it's much easier to carefully audit 100% of the code if it follows my spec and contains only those features I need). This sounds like a trivial project to write, but as I spec it out, it ends up being a lot of code.
Anyone have any suggestions? It needs to be modular code as I will be ripping out and replacing chunks of it (logins will go to our LDAP server, groups and boards will come from our existing SQL databases), it does not need spurious features, it needs to look very polished and professional, but most importantly, it needs to be very careful, audited code. I would prefer php or python over perl.
A possible reason for this is the number of excellent microbrew pubs in Boulder.
I visited a friend who was a grad student in Boulder. In one night, we visited five bars, each of which brewed its own beer. The beer was great; the next day wasn't.
These are absolutely useless as you can't figure out what machine originally sent out the message without the full Received headers. I've not seen one virus auto-responder include the full Received headers. The right thing to do would be to include the entire message as an RFC 2047 MIME attachment.
My reasoning is that these auto-reply messages occasionally get to the right person: namely, me. I then look at the infected IP address and if it's one of ours, send someone out to fix it. This is what I do for messages that get sent to undeliverable addresses where the remote site sends a bounce containing the full original message. A lot of these end up coming to one of my addresses since my addresses are widely advertised within our organization and are likely in many people's web cache and address books.
Past this, I don't see any reason for the auto-replies. They'll never get back to the person whose machine was infected, but they might get to me. It's easier to find out about the problem from some bounce and fix it immediately than it is to have some end-user from some other organization complain to you and then having to explain to this person how to send a message containing full headers (which is actually difficult and non-intuitive in most Windows MUAs).
If you're still playing with this, you can make the email's subject "xxeBayxx" (this is the subject line of the emails sent via the form).
If you get any hits, did they come from New Zealand by any chance?
More fun: google for sorc3r3r. First few links are for someone who registered with a number of dating services in New Zealand. Next you have some IRC activity in Romanian. Then you have some caches of rooted web pages, and sorc3r3r gets a shoutout along with a bunch of other Romanian nicknames (mafiotu (mafia man), dulcica (sweet girl), beculetz (light bulb)).
The most interesting link:
here
This is google's cache of a Romanian web server's stats page. Note that sorc3r3r.org accessed this page, but the DNS entry was a different IP at the time (traceroutes to Australia or New Zealand). This ties together the sorc3r3r.org domain name with New Zealand and Romanian, so it corroborates the rest of the links.
So we have our man. A lonely Romanian in New Zealand who I'm guessing runs Windows XP and plays Counter-Strike. He's also interested in script kiddie games on IRC, so the spammer email trick may just work if you're clever with the subject line (to trigger a preview). (Look up some Romanian greetings, that should do the trick :).
For the curious: yes, I'm Romanian (that's how I can read the IRC logs and whatnot). And no, we aren't all little script kiddies, although that's what it looks like if you're ever on IRC (so I have no sympathy for this guy - when I tell fellow network security guys about my origins, the first thing that pops into their heads is the IRC nonsense).
Have fun. Don't steal. Keep off IRC.
You generally have to provide a real phone number or something identifiable to get a recognized SSL cert, so this is always worth a try:
You got this:
lake% host 216.98.146.249 249.146.98.216.IN-ADDR.ARPA domain name pointer 4t146249.aspadmin.net
See this:
kalashnikov% host www.finestplanet.com www.finestplanet.com has address 216.98.146.249
This is the same Cobalt machine you noted (perhaps a web farm). Looks like a mom-and-pop dialup ISP. Most likely some innocent third-party seeing as how this looks like a legit business. If it's not legit, you could contact Equifax to get real contact information. They have a number of contact numbers and email addresses on their page, so someone should contact them and point them to this thread because they'll be seeing lots of strange stuff in their logs.
My opinion: this guy registered an IP pointing to this machine. This IP is irrelevant
Perhaps fltk could be useful in these circumstances: it looks like it can compile with just X11, no external libraries. Never really played with it but it looks very nice (especially since it's designed to make static linking feasible).
Yes...and also include Pango, gettext, GNU Make, pkg-config, glib, ATK, GNU iconv, libjpeg, libtiff and libpng. Then you can figure out via a very simple configure script which ones are installed and which ones need to be installed. And none of those nine dependencies or any of their dependencies will have a bug in their autoconf scripts that prevents them from compiling via a simple ./configure && make on AIX or HP/UX or Irix.
Of course, you also include the dependencies for each of the above nine dependencies, so you end up having perhaps fifteen or twenty libraries that you distribute, compile and statically link to your little server program so it can show a configuration dialog box.
While you're at it, you might as well include util-Linux (or whatever) for the build process so you don't have to deal with a funny version of sed (not a big deal since your software already uses non-standard gmake extensions, requiring it to build with only GNU Make), and you might as well include GNU awk if you require GNU sed. Of course, you'll need to include GNU bash since somewhere in one of those dependencies, some programmer used a non-standard bash extension rather than plain Bourne in his autoconf script.
And, of course, you have to deal with GNU C extensions in those dependencies such as non-standard variable-argument macros or the "typeof" operator, or zero-length arrays and you don't want to force your dependency developers to have to deal with HP's buggy compiler. So you might as well include GCC and its dependencies such as binutils. While you're at it, go ahead and include glibc so you don't have to modify some dependency to use pthreads correctly rather than relying upon some bug or inadvertantly exposed interface in glibc.
By this time, you've surely run into some network library that looks for "struct udp" in <linux/udp.h> or forgets to include sys/types.h before unistd.h. You might as well include a copy of the Linux kernel, since all the above depencies are known to work well on Linux (after all, that's almost exclusively the system used for their development).
Hell, you might as well just give your clients a Redhat CD. Screw those people who choose to use something else.
Most likely.
The readline folks are real fanatics. They've continually denied requests to put readline under LGPL - they want to make sure the only things that use readline are GPLed. That is, they're doing this on purpose.
Because of this debacle, the *BSD camp was forced to come up with the editline library for all their stuff. And then you have stuff like Sun's dbx that has its own readline replacement. And Oracle's SQL client, and Sybase's isql, and sqsh, ....
Now, it's not quite trivial to write a readline replacement because you have to deal with all sorts of crufty, non-portable *nix terminal arcana, but it's also not difficult. The problem is that all readline replacements are incompatible with each other. You can customize readline applications through .inputrc - this is really cool because you can make one binding and it works in bash, gdb, your (GPLed) console mp3 player, etc. However, these bindings won't carry over to FreeBSD's cdcontrol program or Sun's dbx.
The GPL also means that I can't use readline for some program I write for a client because these programs are usually internal company things that the company owns and can license however they want - they won't pay me if I stipulate that the code I wrote (which belongs to them) must be licensed under GPL for such a trivial reason. Since my clients won't be too happy paying me to write stupid terminal IO routines, I'm forced to either use plain old fgets or use editline, which (IMHO) is not as nice as readline.
The fanaticism is costing the *nix community some useful functionality, which is kind of sad.
You might specify that "authenticated" mail only comes through one central relay and the Received header to use is the latest one. What use is this, however, if it requires either non-existent client-side support or sufficiently technical users that they can grok mail headers? If you're making client-side requirements, PGP is a far more useful feature to add/require, and if you have sufficiently technical users, they can understand public-key crypto and they can use PGP-aware clients.
SMTP AUTH is an alternative to running an open relay: you have travelling employees that might be on any network but need to send outgoing mail, hopefully without modifying their MUA settings. When combined with SSL/TLS, SMTP AUTH solves this problem. Most graphical MUAs now support AUTH and SSL, so this works acceptably, but also requiring SMTP only after POP or IMAP logins also works just as well with no special client-side support.
Download winpcap. Unlike Unix libpcap, it includes both functions to create packets as well as capture them. It does not use winsock but rather installs an NDIS driver that sits lower in the TCP stack. You can then write a simple program that listens for packets and then manually constructs packets with UDP/TCP headers and sends them out. Completely bypasses Kerio.
If you'd like, I can post the code. I tested this about a month ago and it worked against the latest version of Kerio Personal Firewall. Took about an hour of work for a proof-of-concept program. You could get really crazy and implement a TCP stack in userspace and then write all kinds of trojans that would bypass TPF. Only works with privileged accounts since you need permissions to install an NDIS driver, but outside of controlled corporate environments, all Windows users use the Administrator account anyway.
Sygate and ZoneAlarm both install low-level NDIS drivers and are not susceptible to this attack. (At least I couldn't figure out how to bypass them - it may be possible to install a TDI hook which sits below NDIS, but this looks like months of work.)
Other than that, TPF really is much nicer than Sygate or ZoneAlarm, but this is a pretty gaping hole. I'd recommend Sygate over ZoneAlarm.
./configure --prefix=/opt/package/package-1.3 ...
/opt/package /usr/local/bin
/usr/local/bin, do the same for /usr/local/lib and you never again have to deal with "ldconfig", "ld.so.conf", "--with-whatever=/path/to/whatever", etc. Same with "sbin", "etc", "libexec", "include" and so on ("man" directories are a bit different but the same idea).
cd
ln -s package-1.3 default
find default/bin -type f -exec ln -s {}
The "default" link is so you can manage multiple versions of the same package.
In addition to
Next step is to put all the symlinking into a simple script which is run after installing packages or upgrading/downgrading (eg, changing the "default" link).
Been doing this for years - works great on all systems (Linux, Solaris, *BSD, even MacOS X). Things always compile right out of the box and you can maintain multiple versions of the same library if needed. Only problem is that occasionally a package author assumes that ${prefix}/bin already exists and does not create it on "make install" but that's pretty trivial to fix.
No need to modify the shell. If you start messing with PATH, you also have to start messing with MANPATH, setting different paths for superuser ("sbin"), and then changing your compiler/linker so "include" and "lib" work. And then you have to worry about stuff like "libexec" which contains binaries that may be called from different packages (eg, postfix/qmail/etc replacement for sendmail binary). Just use symlinks and everything just works.
It would be nice if the system were somehow "built-in" so it would automatically download and install dependencies prior to compile from some distributed mirror system (like ports), but that's probably asking for too much.
foo(int a); foo(int a, int b);
No, php does not work like that. You cannot define two different functions using the same identifier in the same namespace and I imagine this isn't going to change for PHP5. This is a good thing. This makes it absolutely clear which function your code is calling, which vastly improves maintainability.
In addition, php functions can have default arguments, unlike Java. Your example would work like this in PHP:
function foo($a, $b = -1) { ...
}
If -1 is a legitimate value for $b (and $b can take on any integer value), you make the $b argument an object with a "set" and "unset" state (Java way) or you simply add another optional argument which specifies whether or not $b is valid (php way). This is not a nasty hack: you see a function call and you can immediately tell which function definition is used without examining any object hierarchy.
In addition, php is dynamically typed, so function overloading makes no sense at all because a function's signature is simply the function's identifier. Look at other dynamically typed languages like Scheme and you will see that they do not implement the type of overloading that you speak of.
There are two reasonable uses of C++-like function overloading: 1. simulating optional arguments, like this person wanted (first hit from google on "Java optional arguments"); and 2. behaving differently based upon the type of the argument, like this:
As you can see, the second reason is useless with a dynamically-typed language. In addition, it can lead to all sort of problems in C++ and Java and should be avoided. Example: what if your program now has to deal with another type - say "BigInt" arbitray-precision integers, in addition to ints and doubles? You cannot subclass "int" since it is a primitive non-object, so you will have to modify all your code that uses "int a" and make "BigInt a" versions of the functions. If you can foresee the problem, you can use a wrapper object (Java's "Integer") while initially writing your function "foo" but you cannot fix existing code: if you have a library that uses "int" you need to re-write portions of it when your program grows past 32-bit integers.You may have been confused by the php5 example on the website:
This has nothing to do with the C++ or Java notion of "overloading." The word "overloading" means something completely different in each language, and you won't get anywhere if you expect C++-like constructs in PHP.
Unlike Java or C++ or most of the other C-syntax based procedural languages (with the notable exeption of Objective C), PHP has a dynamic run-time type system, which means it can implement dynamic run-time binding. What the php5 __call construct allows you to do is to bind identifiers at run-time. If you've studied Lisp or Scheme, you will understand the power of this. However, from the presentation, I do not see any way to define code at run-time (Lisp's lambda or perl's "sub {...}"), so it won't allow you to do functional programming. What (I believe) it will allow you to do is dynamic binding, like Objective C or Smalltalk. I can't quite figure out why this would be useful in php, however :)
Not quite true. You don't buy Microsoft software - you lease it. You pay for the privilege of using it and you own the media on which it came. Since you own the CD, you can do whatever you want with it (frisbee, funny hat, etc.), but MS EULAs make it quite clear that your use of the software is restricted.
Not that big a deal - it's just text, so I can fix any munging that some MUA does. If it's just my mail, then I don't care, but if I have to set up other people's mail, then I go with qmail + courier. I agree that it's a better way of dealing with mail, but lots of MUAs still don't grok it.
Wrong.
My preferred mail client used to be vm. This is a mail client written in Lisp. I loved it because it was extremely easy to hack - almost anything you would want to change not only had a setting, but most things had various callbacks, hooks, etc., so you would plug in your code to modify its behaviour. If you found something that didn't have a hook, it was trivial to figure out where the function was defined (C-h f) and change it on-the-fly.
The problem was that it was too slow. Reading a 1M+ mailbox would take up to a minute on my workstation. I have lots of those.
I'm now using mutt because it's fast. It only takes maybe two seconds to parse a 10M+ mailbox ("parse" = look for mbox boundries, set up an index in memory so you can jump to any message instantly).
I'm sure you'll reply that vm needed to do something more "clever" to be faster - like keeping around indeces on disk or using a mailbox format other than mbox. The problem is that us Unix folks do things with mail outside of the MUA. Like edit it directly or run it through perl scripts or use multiple MUAs. This becomes a PITA if you don't use mbox and persistent indexing is pointless since the index would have to be rebuilt any time I did something to the mailbox (which is often enough that indexing wouldn't help).
The basic problem was that file i/o is slow in Emacs Lisp. VM was absolutely high-quality code and you can't disagree with that until you've studied the code.
What MUA do you use? Are you willing to eat your own dog food? If your MUA is written in C, are you willing to write one in some HLL? What about your web browser? Are you willing and able to write a web browser in a HLL, complete with asynchronous DNS, plugins and multiple language encodings?
I've seen this three times. Twice with some no-name tulip clones and once with a couple of really old Macs with built-in ethernet.
If you keep the machines on separate subnets, you'll never know about it (unless you record MAC addresses). However, once you put them on the same subnet, mighty strange things start hapenning - one machine works while the other doesn't - seemingly random intermittent behaviour. Really hellish to diagnose. I figured out the Macs pretty easily as they were sitting right next to each other (go to one, ping out, some packets get through, same story with the other one, but try to ping each other and nothing goes through - then I ran a bpf sniffer and it became clear (Macs were running NetBSD)). The tulip clones were in a large i386 Linux environment and were quite difficult to figure out.
Real PITA. Should have recorded the vendor prefix, but I wasn't so wise back then.
I think the online documentation sucks.
Until only a couple versions ago, it was one huge file that took forever to load unless it crashed your browser. It was also impossible to search because your search would always get you irrelevant stuff (search for some select function gets you lots of hits in the installation and admin sections).
Even now it still sucks. It either loads immense pages with "chapters" which are still too big to search and take too long to load, or it loads only one tiny bit with user comments, which I really don't care about.
Why is the installation, administration, C language API information in the same book as the actual sql language specification? I have to scroll halfway down the page to get to the sql specification part.
They really need to hire an editor or a technical writer - they don't publish the book in a format that users can use.
How would you typically use this book? You might look at the installation bit if you have problems installing it. You might browse the administration bit when you write a backup script to ensure you're not doing anything stupid. However, the main way you use this book is when you're writing some application and you need to look up the syntax for some sql function - in which case you don't care about the administration or installation chapters. I don't use DATE_ADD(x, INTERVAL 3 DAY) often enough that I would remember the syntax. When I do need to remember the syntax, I find it's easier to grep for it in some earlier project's code than it is to look in the actual manual. It's as if the manual were written for browsing rather than quick reference (indeed, I imagine the mysql authors would only browse through the book rather than use it for reference - thus the value of a third-party technical writer). It may be organized OK for a dead-tree form (where you want all that information in the same book so user's don't have to buy six different books), but it's no good as online reference documentation. Even the sections themselves (once you find the relevant one) are poorly organized.