Slashdot Mirror

PHP+Apache2 is "working OK"...

Just not well enough to sign off an enterprise solution on...

Check out these links for more details...
PHP-Dev Mailing list discussion
Discussion on PHP buglist
as well as a more tongue-in-cheek reply...

From what I understand, PHP 5 will not include a bundled version of the MySQL libraries, with the licensing issue being one of the causes. MySQL finally granted exceptions to some licenses (PHP included), but the whole argument turned some people off to MySQL. Of course, this doesn't mean that the MySQL API is not supported, it simply means that you'll have to install the MySQL libraries separately before you can build PHP 5 with MySQL support.

what has ESR brought to the Open Source community ?

The Jargon File comes to mind. I owe quite a bit of my knowledge of computer history to its print form, the New Hacker's Dictionary.

He also brought us the infamous Aunt Tillie Builds a Kernel lkml thread.

-jim

This exploit, as well as the mremap ones, were derived from intimate examination of the source.

Some might disagree. This bug was discovered here and was later posted and analysed on the lkml.

This e-mail might help you out.

The example code's bogus
asm is generating an FPU fault in frstor in its signal handler, that's
bumping us into math_error -> force_sig_info ->
specific_send_sig_info. Then we hit:

if (LEGACY_QUEUE(&t->pending, sig))

which decides we don't need to send the signal after all and we bail
all the way back out and recurse.

The example code's bogus
asm is generating an FPU fault in frstor in its signal handler, that's
bumping us into math_error -> force_sig_info ->
specific_send_sig_info. Then we hit:

if (LEGACY_QUEUE(&t->pending, sig))

which decides we don't need to send the signal after all and we bail
all the way back out and recurse.

Yes, here.

Subject: Re: no more apache updates
From: Henning Brauer

let me add one more thing.

it is of course possible to install an apache 1.3.31 or future ones
from source on OpenBSD.

however, doing so is one of the dumbest things you can do.

there is a number of serious security problems in apache that we have
fixed, and that have been offered them back, and they refused.

selfmade apache upgrade = security downgrade, ok?

thttpd is a simple, small, portable, fast, and secure HTTP server.

Simple:
It handles only the minimum necessary to implement HTTP/1.1. Well, maybe a little more than the minimum.

Small:
See the comparison chart. It also has a very small run-time size, since it does not fork and is very careful about memory allocation.

Portable:
It compiles cleanly on most any Unix-like OS, specifically including FreeBSD, SunOS 4, Solaris 2, BSD/OS, Linux, OSF.

Fast:
In typical use it's about as fast as the best full-featured servers (Apache, NCSA, Netscape). Under extreme load it's much faster.

Secure:
It goes to great lengths to protect the web server machine against attacks and breakins from other sites.

It also has one extremely useful feature (URL-traffic-based throttling) that no other server currently has. Plus, it supports IPv6 out of the box, no patching required.

no kidding!

Since I'm subscribed to the mailing list I've gotten to read all about it for the last couple days. Here's a link to the mailing list archive....here

A page to actually read more on this is here.

FreeBSD is not good at scaling at all. Even their development branch that has been focusing on SMP improvements for the past 4+ years cannot scale past one CPU on a dual Opteron (ie. a very scalable CPU and bus architecture). Seehere/a.

see here for an example of his adolescent attitude.

On MySQL seems to be pretty bad. Sometimes less than half of what Linux can do on a dual Opteron. FreeBSD can even get better results with a uniprocessor kernel. Hmm maybe all their scalability boasts are referring to being the leaders in negative scalability?

Give me a break ... where do the disclaimers stop? I mean, the software's being given away for free for non-commercial use, and I think it's of interest to other techies. Notice I didn't submit anonymously.

And don't start spouting "open-source this, open-source that" to me ... I do my bit there as well. But noone cares about that stuff, so why bother talking about it instead of stuff I think is fun?

Give me a break ... where do the disclaimers stop? I mean, the software's being given away for free for non-commercial use, and I think it's of interest to other techies. Notice I didn't submit anonymously.

And don't start spouting "open-source this, open-source that" to me ... I do my bit there as well. But noone cares about that stuff, so why bother talking about it instead of stuff I think is fun?

First off, my presentation was about making the case for Passive Network Discovery Systems (PNDS), a "new" technology that I created over at Sourcefire. The basic idea of a PNDS is to discover the composition and topology of your network via a mix of passive OS fingerprinting and passive application layer protocol discovery and the other information that you can infer from that data, such as network topology and asset vulnerabilities. I sought to show how that technology could improve a variety of network security technologies by using the example of how Snort (and other IDS) works today and how it could be improved by integrating the information that comes from a PNDS.

Sourcefire has developed a product called RNA that performs the PNDS functions that I outlined during my talk. Note that it is a proprietary technology that we developed commercially and it is a completely separate product from Snort or the Sourcefire IDS sensors. We are not going to be integrating the functionality of RNA into Snort, we're going to be modifying Snort to take advantage of the information that a system like RNA can generate. In the best case scenario, RNA has a very different deployment profile than an IDS.

I said that IDS has had trouble in the market because of its complexity and the requirement that users perform extensive tuning of IDSes in general in order to get maximum benefit from them. There are a lot of things that factor into this problem, but the root cause of almost all IDS problems today is that we don't have automated methods for provisioning them nor do we have effective methods of data reduction available that are automated, persistent and real-time. PNDS addresses that problem head on in a way that is appropriate for real-time processes like IDS in ways that traditional scanning technologies have a very tough time providing.

I then went on to say that we're planning on making changes to Snort to enable it to leverage the information that a system like RNA provides and make it into a true target-based IDS, redefining how IDS operates and hopefully revitalizing it as a technology. Snort will still be available for free and will still operate in "classic" mode where it doesn't leverage this info for people who don't have passive discovery technologies (or even active ones) so that they can still continue to use it.

Snort is not going to be doing the configuration policy enforcement (i.e. the "block OS X on my network" function), RNA is. RNA is capable of seeing devices on the network and discovering their attributes in real-time and communicating that data to our management console where it can be analyzed for policy compliance and where appropriate remediation responses can be executed. Not to get too deep into the marketing, but there are good engineering reasons for wanting to do this that include worm/virus containment, real-time IDS policy updates and some other really useful mechanisms for performing policy enforcement.

We're making mods to Snort because we believe that we can make a truly next-generation IDS capability that is easier to deploy, manage and get valuable information out of due to the effect of RNA. This approach directly addresses all the arguments of the "IDS is dead" crowd while at the same time making IDS a much more impactful technology while greatly reducing the overhead requirements on users.

I hope this clears things up for people!

To quote Linus Torvalds:

People have been pretty good (understatement of the year) at debunking those claims, but the fact is that part of that debunking involved searching kernel mailing list archives from 1992 etc. Not much fun.

Unlike early post BSDi development of the "free" BSD's, almost all of the Linux kernel development took place in the open and over the internet.

In comparison Microsoft has "lost" the source to MSDOS and "deleted" CEOs email from it's servers. There is NO real public provenance to the source code to most of Microsoft's products. If this is, like the threat from patents is an issue then Linux is in a better postion than its competitors in the market.

...as Tony says, in the BSD thread, in partial reply to Theo:

QUOTE
What's very amusing is reading section 5 of the draft, wherein the author distributes credit to a number of parties. If Cisco were to file a patent at this point and not include those parties (including other companies), the patent validity would be at risk by reason of excluding a contributor. If Cisco does include all of those other companies in the patent, then all of them must also present the IETF with relevant IPR statements.
Frankly, this is yet another PR blunder by Cisco. If they had simply said nothing or formally put their contribution into the public domain, they wouldn't look so egregiously greedy.
ENDQUOTE

From the 10EAST archive, as quoted in kerneltrap...Theo has some choice comments about the US Patent System and the IETF, too.

IOW, yet again, Cisco trying to cash in on Open Source, in order to desperately prop up their miserable recent record of development, innovation and security, as well as theft from the Open Source Community, in order to keep their stock price up and keep from being listed on F'd Co., where they belong.

You might be looking for this.

As you can read in this message, this is not a release but a Release Candidate. It was posted in the /dev/dist directory so testers can have at it.

Now, if all of you want to download and test this release, and report your findings back to the httpd-dev mailinglist, by all means go for it.

But this is not a release yet.

Here is the answer from Linuxant. They claim it wasn't a mistake, just a way to suppress potentially confusing warning messages.

Linuxant has added a note about this issue to their site, with a link to their response on the Linux kernel mailing list.

Actually, we also have no desire nor purpose to prevent tainting. The purpose of the workaround is to avoid repetitive warning messages generated when multiple modules belonging to a single logical "driver" are loaded (even when a module is only probed but not used due to the hardware not being present). Although the issue may sound trivial/harmless to people on the lkml, it was a frequent cause of confusion for the average person.

Read the entire email for the whole picture. Whether you agree or not, it is important to understand why they partially circumvented the license check.

Linuxant responds and explains why they did what they did. It was mostly to supress multiple messages when loading multi module drivers rather than some sort of circumvention.

On the otherhand I think everyone's eyes are open to possible malicious use of this and simular tricks.

LinuxAnt have responded.

Yeek... let's try that again:

Response

*yay for not using preview!*

1. Part of every attempt to legislate (which the kernel's interrogation of drivers is) should include the question "how will people cheat, and how can we stop this". Otherwise this kind of game is inevitable.

I agree, though remembering how I solve security problems where people work-around security procedures leads me to think that what Willy Tarreau wrote looks like a good first start;

1. What would be smarter would be to try to understand why they do this. At the moment, it seems to me that their only problem is to taint the kernel. Why ? I don't this that any old modutils/module-utils found in any distros don't load properly such modules. So perhaps they only want not to taint the kernel because it appears dirty to their customers who will not receive any more support from LKML. So perhaps what we really need is to add a new MODULE_SUPPORT field stating where to get support from in case of bugs, oopses or panics on a tainted kernel. Thus, the module author would be able to insert something such as "support_XXX@author.com" which will be displayed on each oops/panic/etc... Even if this is a long list because the customer uses connexant, nvidia, checkpoint and I don't know what, at least he will get 3 email addresses for his support. And it might reassure these authors to know that the customer will ask them before asking us with our automatic replies "unload your binary modules...".

If it turns out this is also ignored, then make it more restrictive.

Linus' 2 cents undoubtedly cost the hoster of his message more than that in /.ed bandwidth.

There hasn't been any significant security issue with BIND 9. Period.

So Dan's comments about BIND 9 having 672 bugs in its history up to 9.2.2rc1 in 2002/08/08 don't warrant attention? How can anything have 672 bugs in somethat that should be so simple and not one of them be a possible security issue? Granted some of the "bugs" are "added another root server" which is more like a request. #1318 "libbind: Remote buffer overrun"

Dan mentions Bug 1252 which is "Dig, host and nslookup were not checking the address the answer was coming from against the address it was sent to." I suppose that's not a security risk where someone could easily forge DNS replies. I see a race condition #1523

The problem isn't just with linux distributions as can be seen here.

... at packet sniffing. In other news, FreeBSD
sucks
at
everything
else

From the recent tests performed by a BSD advocate, and linked here, we see Linux 2.6 has TRIPLE the exec throughput of FreeBSD 5.2, TRIPLE the context switch speed, less than half the system call overhead, and all, of course while being far more scalable.

I suggest that if you really have the need to show that FreeBSD is better than Linux, then you should concentrate on something other than performance. Stability might suit you better, because it is far more difficult for someone to get evidence either way to counter your FUD.

Have a nice day.

... at packet sniffing. In other news, FreeBSD
sucks
at
everything
else

From the recent tests performed by a BSD advocate, and linked here, we see Linux 2.6 has TRIPLE the exec throughput of FreeBSD 5.2, TRIPLE the context switch speed, less than half the system call overhead, and all, of course while being far more scalable.

I suggest that if you really have the need to show that FreeBSD is better than Linux, then you should concentrate on something other than performance. Stability might suit you better, because it is far more difficult for someone to get evidence either way to counter your FUD.

Have a nice day.

The lack of detail, is intentional.

what they need is a new section 'google mailing lists'

You mean like The Mail Archive or MARC?

Or if you like a newsgroup view of mailing lists there is always Gmane

I would feel pretty confident that it's an error in some part of their distribution/quality control... maybe something as simple as a barcode incorrectly put into the database or something of that sort.

I might beleive this for our single case. But having seen a post of it happening elsewhere, I would tend to beleive that their profit margins are good enough for them to occasionally just take a little less profit to keep the customer happy. Especially on something like a rack mount server (1650), which might indicate to Dell that this customer could potentially buy more server gear and maybe even pallet loads of desktop gear during the next desktop upgrade session.

What else do you think these companies use the company info forms that you fill out for? If you filled out that you are an "ISP" then they might be less inclined to "make you happy" as they would had you filled out "legal firm" with "500-1000 staff". Cha ching! To them, keeping the IT department and purchasing happy is merely an investment for their (Dell) future.

Here is that mailing list post that I promised...

"Thanks, turns out to be a usless question now though, Dell is throwing in second CPU's for free :) No doubt cleaning out stock for the new 3Ghz chips."

PS, I don't know why I thought this happened in another country, I don't seem to be able to see anything in that post to make me beleive that. I'm sure I read more than this but can find it right now. Perhaps it went off list, I can't recall.

Hi,

Random number generation is a bit of a hobby of mine, though not "real" random numbers but pseudo.

I read that link. It does not sound very authoritive. Using zener diodes as a white noise source works, but it's all too easy to come up with "some great idea" in crypto type areas (true and strong pseudo random number gen, encryption schemes, one way hash algorithms, etc) only to find the great idea fails basic tests or analysis by real cryptanalyst experts.

The tone of the writings on that page, sound like they're all students experimenting with ideas. Which is absolutely wonderful. However, nobody can say, "here is THE proper way to make a random bit", especially when it's a link to an untested idea.

I mean no offense, BTW. I've just been around long enough to see ideas that even the experts all agree looks good but which fails sooner or later.

I was recently reading the documentation of an independent test conducted for Via's new C3 Nemiah CPU (which contains dedicated AES instructions, allowing the most incredible AES performance!) which includes a hardware "true" random number generator. The generator uses 3 oscillators of varying frequencies, the outputs of which are XOR'ed. Assumingly, the frequency difference between these 3 oscillators and their drift cause the XOR output to be "random". It used a von Neumann corrector which reduces biases towards a given bit.

The end result was, that the quality of random number generation varied between sample cores and varied between software controllable circuit bias settings. With the corrector switched OFF, the generation was quite poor (with respect to what you'd expect for crypto), with it ON, it was impressive indeed. There was a bias settings which was the best across each CPU tested however, but they did still differ slightly, as you would expect from an analog source.

A zener, an op-amp and a trim-pot is not going to cut it. Certainly not for "THE proper way to make a random bit".

Actually, NES gamepads for the Newton might become reality.

There's one thing that makes VIA CPUs very interesting performance-wise: the xcrypt instruction. Using it the VIA CPUs just beat - and beat badly - anything else in certain task.

Check out Theo de Raadt's little benchmark:
http://marc.theaimsgroup.com/?l=openbsd-misc&m=107 577297024182&w=2

No problem in BSD land?

What's with the people making these announcements? I read the comments by XFree86's David Dawes a while back - he only wrote about 2 lines or so, and hardly replied when people started asking for clarification.

Then Theo of OpenBSD in this thread writes a quick response rejecting the whole thing, again with absolutely no explaintation as to why, and what the specific problems are.

Then check out the posts in that thread from Darren Reed, getting shot down as a troll straight away for inquiring what the problem with it actually is!

This kind of discussion and attitude floating around turns me off OSS a little. The last thing I want to see is multiple implementations of X servers in wide use, different ones on different distributions, some doing some things, others doing things a little differently. And of course yet more duplication of effort, re-writing code, etc. Seems a shame. Seems like we just have more fragmentation to look forward to.

If you're having problems with input devices, search the LKML archives for Vojtech Pavlik's 2.6 input FAQ (he's the maintainer of the kernel's input system). You can find a list of searchable archives at the LKML home/FAQ page.

Err, I'm feeling generous, here: 2.6 input drivers FAQ ^_^;

You may be confusing the "USB event subsystem" (of which I'm really not sure you're talking about) with the generic input system.

Here is the lkml announcement

Linus' announcement

and the guy who named it here

Nick

When I see things like this. It really doesn't give me a good feeling as to ESR's technical understandings of SPF.

I'm sure Wietse and Claus have a pretty good grip on SPF as well. You may want to have a look at the postfix-users archives to confirm that for yourselves.

Before looking at SPF you may want to read what Claus Assmann, and Wietse Venema have to say on the subject.

If you don't know who these two people are, I seriously hope you're not someone who's making decisions affecting SMTP on the Internet.

Before looking at SPF you may want to read what Claus Assmann, and Wietse Venema have to say on the subject.

If you don't know who these two people are, I seriously hope you're not someone who's making decisions affecting SMTP on the Internet.

Keith Moore, an author/co-author of a number of RFCs on IPv6 and other topics, posted the following to the IETF mailing list, regarding what IPv6 will enable and can be used for.

The comment was in response to somebody's claim that residential users would be happy with NAT, and non-globally routable IP addresses for their "internal" networks.

That's like saying residential telephone users don't need to have a phone number at which they can be reached. (after all, the purpose of their residential phones is to call businesses for the purpose of obtaining services, right?)

There are lots of apps that would be valuable to residential users if residential users had reachable IP addresses. check the status of your alarm system, or your roast in the oven, or your freezer's inventory. Grab a picture from your baby-cam while you're out for dinner and have left the kid with the baby sitter. Reset the thermostat if you're going to be out of town longer than you thought. Do all of these from your portable phone/PDA which is running guess what? -- IPv6.

Also, don't assume that IPv6 addresses will be used by people or their personal computers. IPv6 enables lots and lots of individually addressable devices which don't have to be associated with individuals. Every km of highway can have an addressable traffic sensor so that police and emergency crews know exactly when and where a traffic accident happened. Every streetlight can be monitored to see if it is functioning properly or if it needs service. Every traffic signal can be made individually controllable so that they can dynamically adapt to changes in traffic patterns. For reasons like this, the demand for IPv6 addresses won't be determined by some linear multiple of the number of humans on the planet.

Finally, don't assume that IPv6 devices will require the support burdens we associate with PCs. PCs as we currently know them are dinosaurs. Appliances that talk to the network aren't going to need the same kind of technical hand-holding that PCs do (because they'd never succeed if they did), and neither will the devices that replace what we now think of as personal computers.

IPv6 will eventually replace IPv4, but it's misleading to think of IPv6 as just a replacement for IPv4. By the time IPv6 replaces IPv4, we won't recognize the IPv6 network as something that resembles what the IPv4 network is used for today. Even though the underlying technology is very similar, IPv6 is really a new kind of network, one that enables things that were really never possible with IPv4 on a large scale.

Link

It won't be ready...until BIND stops rejecting unknown types.

So, three years ago, then?

From an announcement for BIND 9.1.0: "BIND 9.1.0 also includes experimental implementations of a number of DNS protocols extensions still under development in the IETF. These include transparent processing of unknown RR types..."

BIND 9.1.0 was released on January 18th, 2001

It won't be ready...until BIND stops rejecting unknown types.

So, three years ago, then?

From an announcement for BIND 9.1.0: "BIND 9.1.0 also includes experimental implementations of a number of DNS protocols extensions still under development in the IETF. These include transparent processing of unknown RR types..."

BIND 9.1.0 was released on January 18th, 2001