I've been wondering about (ab)using DNS for FreeBSD Update -- the idea being that when you're updating a system which is not up to date with security fixes, you might want to be behind a draconian firewall. (The caching benefits of DNS are a non-issue; updating a year-old RELEASE takes only a couple MB.)
In the end, I decided that it would be more trouble than it's worth; but if someone else has written code I can borrow (I haven't looked in detail) then I might reconsider this.
When it comes to internet-based attacks, my yellow stickies are the securest files on my system!
Well, you'd want to make sure they weren't stuck somewhere visible to random passers-by.
But you always have to keep in mind that any form of security is only as strong as its user interface; if someone can access a password stickied to the bottom of your keyboard, they can probably attach a keylogger as well.
Note that this is different from the name being inserted into the CVS tree -- 5.2-BETA is now available for installation via all the usual mechanisms (ISO image, FTP install, etc), without requiring a preexisting system.
I'm looking at using it on the old 133 mhz sitting next to me. Wondering if that is a good idea? Probably would just serve web pages or something minimal.
A 133MHz box won't do very well for many GUI desktop applications, but for serving purposes it will do fine. You'll probably want to use FreeBSD Update (see sig) to keep it updated with security fixes, though, since rebuilding everything on that box would be rather slow (and you might not be able to spare 700MB for src+obj trees, either).
Building updates requires a box which doesn't object to having its clock shifted forwards by 400 days from time to time. Having people use the updates you build requires that people trust you.
When I get the code written -- which is probably going to be about a year from now -- that last requirement will be dropped, since it will be possible for several buildboxes to cross-verify and cross-sign. (This is the primary reason I'm keeping FreeBSD Update out of the base system for now.)
But feel free to download the build code and try it out -- I haven't tested it on non-i386 systems, but it should work (and if it doesn't, I'd be very happy to hear about it).
FreeBSD Update doesn't care what you're running. But you're mostly right -- nobody is publishing updates for anything other than i386 4.(7|8|9)-RELEASE.
In the near future (next week, maybe the week after) I'll start publishing updates for i386 5.x as well; non-i386 platforms... well, I haven't heard from anyone interested in using FreeBSD Update on those, so that will probably wait until FreeBSD Update becomes part of the base system (around 5.5-RELEASE, maybe?) and the Project takes on the task of building the updates.
If nobody reads those "great old papers" any more, there's probably a reason. Sometimes the ideas have been superceeded; sometimes they weren't any good to begin with; often the papers are simply really hard to understand. The fact that people seriously suggest reading "great papers" reflects on the immaturity of the field; in a field like mathematics, hardly anyone ever reads the original papers (even for work done in the 20th century), instead opting to read someone else's simplification/clarification of the ideas.
We speak of the TAoCP as "the bible", but I'm not sure if there are any "new" ideas there; rather, the value of TAoCP is as a compilation and exposition of all the best ideas other people have produced.
Learn about great algorithms; don't worry about reading great papers.
Given how carefully governments watch for missile launches, I doubt that would really be an issue. People might assume that the detonation was nuclear, but in the absence of detected launches, it would probably be attributed to a terrorist attack of unknown origin.
Ok, many of those people haven't had much experience with computers. But even if you just look at the US, Canada, Japan, Hong Kong, South Korea, Singapore, Australia, New Zealand, and the EU, you've still got easily enough people to make the lack of US success attributable to chance.
The only improvement to the FreeBSD installer I would like to see is the ability to run it over an ssh session (since serial ports are becomming less common).
If you want to install via SSH, you'll need to either create customized install images or allow anyone on the same network to run the installer as well.
In the end, some naferious super genious at Intel, or Western Digital could generate an evil piece of hardware specifically designed to subvert gcc and linux at the hardware level. Granted it be nearly impossible to pull off...
Actually, it wouldn't be hard at all. Add logic into the L1 (data) cache which computes the MD5 sum of each cache line loaded; if it is equal to a predetermined value, the address of that line is loaded into the instruction pointer.
Presto, immediate backdoor which can be exploited by anyone who can load arbitrary data into address space (anywhere) and access it. The most obvious approach would be to send an IP packet with the exploit code -- the exploit would run as soon as the packet reached the IP stack -- but you could access it via a compiler as well.
The author is looking at the rate of IPv4 address allocation, and extrapolating future growth based on the current rate. This is a severely flawed methodology, because it does not take into account efficiency of utilization.
Ten years ago, as the author notes, most networks used around 1% of their allocated IP addresses. Now, networks are expected to use over 50% of their addresses before they can receive a larger allocation. As a result, while the number of *allocated* addresses has not been growing rapidly, the number of *used* addresses certainly has.
Unfortunately, utilization efficiency is bounded -- it's hard to use more than 100% of your allocated IP addresses. As a result, the rate at which IP addresses are allocated is likely to take a sharp turn upwards, as organizations which until now have been making efficiency improvements, find that they really do need a larger address allocation.
Apache isn't quite as much of a monocrop as it might seem at first. While a newly discovered security hole is likely to affect a large proportion of the world's web servers, differences in how Apache is linked and loaded will mean that any exploit is going to be specific to one operating system. For example, there was an Apache/FreeBSD worm some time back; the security hole existed in all (unpatched) Apache installations, but the worm was only able to exploit it on FreeBSD.
So I guess I'm going to have to migrate to Debian or something instead ?
Switch to FreeBSD, and you'll get a choice of the "always up to date but sometimes unstable" -CURRENT, the "mostly up to date and generally stable" -STABLE, or the "completely stable, security fixes only" -RELEASE branches. All of which allow you to rebuild the entire system whenever you like.
Binary security updates are available for the -RELEASE branches (see.sig), and it's all completely free. Of course, I wouldn't mind getting some money -- it would allow me to upgrade the build hardware, and release the binary updates more quickly -- but even $5 from everyone using FreeBSD Update would be an impressive amount.
Slashdot Mirror
I've been wondering about (ab)using DNS for FreeBSD Update -- the idea being that when you're updating a system which is not up to date with security fixes, you might want to be behind a draconian firewall. (The caching benefits of DNS are a non-issue; updating a year-old RELEASE takes only a couple MB.)
In the end, I decided that it would be more trouble than it's worth; but if someone else has written code I can borrow (I haven't looked in detail) then I might reconsider this.
Quoth the article:
Space and zero gravity offer challenges for food preparation.
On the other hand, zero gravity offers unique advantages for food preparation: If you're careful, you never need to run out of counter space.
When it comes to internet-based attacks, my yellow stickies are the securest files on my system!
Well, you'd want to make sure they weren't stuck somewhere visible to random passers-by.
But you always have to keep in mind that any form of security is only as strong as its user interface; if someone can access a password stickied to the bottom of your keyboard, they can probably attach a keylogger as well.
I'm in the UK, and I haven't noticed any problems. I've even had a realaudio stream running without interruption.
A couple hours ago, 5.2-BETA was officially released.
Note that this is different from the name being inserted into the CVS tree -- 5.2-BETA is now available for installation via all the usual mechanisms (ISO image, FTP install, etc), without requiring a preexisting system.
I'm looking at using it on the old 133 mhz sitting next to me. Wondering if that is a good idea? Probably would just serve web pages or something minimal.
A 133MHz box won't do very well for many GUI desktop applications, but for serving purposes it will do fine. You'll probably want to use FreeBSD Update (see sig) to keep it updated with security fixes, though, since rebuilding everything on that box would be rather slow (and you might not be able to spare 700MB for src+obj trees, either).
A small nitpick regarding your terminology: two organisms that are able to breed to produce offspring are by definition the same species.
That may be the geneticist's definition, but it isn't common usage. Most people consider lions and tigers to be different species.
Building updates requires a box which doesn't object to having its clock shifted forwards by 400 days from time to time. Having people use the updates you build requires that people trust you.
When I get the code written -- which is probably going to be about a year from now -- that last requirement will be dropped, since it will be possible for several buildboxes to cross-verify and cross-sign. (This is the primary reason I'm keeping FreeBSD Update out of the base system for now.)
But feel free to download the build code and try it out -- I haven't tested it on non-i386 systems, but it should work (and if it doesn't, I'd be very happy to hear about it).
FreeBSD Update doesn't care what you're running. But you're mostly right -- nobody is publishing updates for anything other than i386 4.(7|8|9)-RELEASE.
In the near future (next week, maybe the week after) I'll start publishing updates for i386 5.x as well; non-i386 platforms... well, I haven't heard from anyone interested in using FreeBSD Update on those, so that will probably wait until FreeBSD Update becomes part of the base system (around 5.5-RELEASE, maybe?) and the Project takes on the task of building the updates.
This isn't really a big deal -- if you don't want to rebuild things yourself, you can just use FreeBSD Update.
If nobody reads those "great old papers" any more, there's probably a reason. Sometimes the ideas have been superceeded; sometimes they weren't any good to begin with; often the papers are simply really hard to understand. The fact that people seriously suggest reading "great papers" reflects on the immaturity of the field; in a field like mathematics, hardly anyone ever reads the original papers (even for work done in the 20th century), instead opting to read someone else's simplification/clarification of the ideas.
We speak of the TAoCP as "the bible", but I'm not sure if there are any "new" ideas there; rather, the value of TAoCP is as a compilation and exposition of all the best ideas other people have produced.
Learn about great algorithms; don't worry about reading great papers.
Given how carefully governments watch for missile launches, I doubt that would really be an issue. People might assume that the detonation was nuclear, but in the absence of detected launches, it would probably be attributed to a terrorist attack of unknown origin.
is outside the U.S.?
Ok, many of those people haven't had much experience with computers. But even if you just look at the US, Canada, Japan, Hong Kong, South Korea, Singapore, Australia, New Zealand, and the EU, you've still got easily enough people to make the lack of US success attributable to chance.
The only improvement to the FreeBSD installer I would like to see is the ability to run it over an ssh session (since serial ports are becomming less common).
If you want to install via SSH, you'll need to either create customized install images or allow anyone on the same network to run the installer as well.
Which option do you prefer?
Doubters have to be able to scrutinize the way the system works.
Private citizens are generally not allowed to scrutinize (paper) ballot counting. Normally each candidate can send representatives, but that's all.
Of course, that situation is still vastly better than the Diebold fiasco, where *nobody* can scrutinize the ballot counting...
US is still up a bit over the last 10 years tho.
As of yesterday, the USD:CAD ratio is exactly where it was 10 years ago.
s%s/Company's/Companies%s/Company's/Companies/%
You forgot the terminating slash.
what else would we use?
How about libc?
I don't understand this. I keep on hearing people complaining about glibc; yet for some reason, people keep on using it.
Why?
You're right: It isn't irony.
On the other hand, it is preaching to the converted.
I've been waiting with held breath for this one. I just wish it would ship a few days early!
Let's put it this way... if you're holding your breath, and it doesn't ship a few days early, you're not going to get a chance to see it.
In the end, some naferious super genious at Intel, or Western Digital could generate an evil piece of hardware specifically designed to subvert gcc and linux at the hardware level. Granted it be nearly impossible to pull off...
Actually, it wouldn't be hard at all. Add logic into the L1 (data) cache which computes the MD5 sum of each cache line loaded; if it is equal to a predetermined value, the address of that line is loaded into the instruction pointer.
Presto, immediate backdoor which can be exploited by anyone who can load arbitrary data into address space (anywhere) and access it. The most obvious approach would be to send an IP packet with the exploit code -- the exploit would run as soon as the packet reached the IP stack -- but you could access it via a compiler as well.
Lies, damn lies, and statistics.
The author is looking at the rate of IPv4 address allocation, and extrapolating future growth based on the current rate. This is a severely flawed methodology, because it does not take into account efficiency of utilization.
Ten years ago, as the author notes, most networks used around 1% of their allocated IP addresses. Now, networks are expected to use over 50% of their addresses before they can receive a larger allocation. As a result, while the number of *allocated* addresses has not been growing rapidly, the number of *used* addresses certainly has.
Unfortunately, utilization efficiency is bounded -- it's hard to use more than 100% of your allocated IP addresses. As a result, the rate at which IP addresses are allocated is likely to take a sharp turn upwards, as organizations which until now have been making efficiency improvements, find that they really do need a larger address allocation.
Apache isn't quite as much of a monocrop as it might seem at first. While a newly discovered security hole is likely to affect a large proportion of the world's web servers, differences in how Apache is linked and loaded will mean that any exploit is going to be specific to one operating system. For example, there was an Apache/FreeBSD worm some time back; the security hole existed in all (unpatched) Apache installations, but the worm was only able to exploit it on FreeBSD.
So I guess I'm going to have to migrate to Debian or something instead ?
.sig), and it's all completely free. Of course, I wouldn't mind getting some money -- it would allow me to upgrade the build hardware, and release the binary updates more quickly -- but even $5 from everyone using FreeBSD Update would be an impressive amount.
Switch to FreeBSD, and you'll get a choice of the "always up to date but sometimes unstable" -CURRENT, the "mostly up to date and generally stable" -STABLE, or the "completely stable, security fixes only" -RELEASE branches. All of which allow you to rebuild the entire system whenever you like.
Binary security updates are available for the -RELEASE branches (see