How bad could a "cyberattack" really be, if we're living through the current levels of crap?
All powerstations are down for days, lots of people die at hospitals all over the country. Others people die due to no light/AC/heat/water "even worse"... billions lost due to companies that can't do anything, noone can travel due to gas stations not having power (thus no food gets to stores), stocks go down the toilet bringing even more economic damage.
But, yeh, fuckit... you've got virus protection right for your porn sites, what more could be needed?
And if they aren't rare, how would you know? That was my point. A leaky application that allocates 3MB on startup, leaks 1KB an hour, but never gets run for more than 5 days at a time, will probably never get fixed, because it's likely nobody will ever notice there is a problem.
Nice circular argument. a) leaks are a huge problem. b) I never see them. a) but that's why they are a problem.
IMO if nobody ever notices there is a problem, there isn't a problem. Also the application that leaks the most on the desktop is written in Python, which has reference counting and garbage collection.
As for your claim that applications 'rarely' use malloc(), that is not my experience.
RAII requires allocating from the stack, and a _lot_ of C++ uses that design pattern. malloc() is much more used in C (which I prefer)... but I still almost never see memory leak problems (and, yes, my code counts the memory and complains at exit if I've leaked something).
For point 2, look, people currently use strcpy, strcat, sprintf (snprintf if there are sensible), so they need secure replacement for all these function: you don't change habits so easily.
Yes, some people currently use str*cpy() and str*cat() in C... my general point is that those that do are generally writting worthless buggy crap, and only fixing a tiny amount of the problem by providing strlcpy() and strlcat() isn't a sane solution. It would have been worth it in 1980, but not 20 years later when it's blatantly obvious to anyone, who's looked at the data, that string APIs can be just as "fast" and much less prone to programer error.
Yes, strlcpy is a better interface than strncpy... but no, IMO, it isn't enough as it's only going to solve maybe 10% of the problems that are very easy to find anyway. 100% solutions exist, so settling for less isn't worth it.
As for the comments that it's "free" to add to glibc anyway, so why not get any benifit we can... the problem is that as soon as something is in libc people want "superfast" asm versions of it. Esp. things in string.h. This is even more fun combined with the lack of knowledge of what the functions should in the corner cases. Also not having those functions and people asking for them being told "no, go use a real string API" might well do more good than that simple 10%.
If glibc had included strlcat, strlcpy, there is a real possibility that the C99 would have added them to the standard C library..
Riiight, the strlcat "paper" was presented in late 1999 at Usenix... C99 (as you might guess from the name) was released in 1999, and was basically feature frozen for at least 2 years before that. So unless Ulrich has a time machine that I don't know about, I find it unlikely he could do what you suggest.
And if it's still needed for the next C standard, because people still use interfaces that look anything like it, god help us all.
Right now we are seeing binary packag installers check for stdint.h so they it can guess that the right version of some libraries is in a different place - just so it works across RHES, Fedora, Suse and Debian. Not nice.
Riiight, you have apps. that are checking for an include file in a specific location, which is _also_ provided by dietlibc... and I can guarantee they can't use that.
Instead of say just running/lib/libc.so.6 and comparing the version (which, of course, isn't ideal and it could even be done using the output of LD_DEBUG/ldd to work even if libc wasn't in/lib).
Hell given the "portability" requirements, they could just test the output of: "rpm -q glibc || dpkg -l libc6"
Your problem isn't going to be solved by LSB, even if LSB was actually amazingly well done.
And while he happens to be right in this case, I don't think very highly of him.
[...]
Drepper however has repeatedly refused to include them (strlcpy/strlcat) because they work and they make it too easy to not code buffer overflows (no this is not a joke).
While Ulrich has his faults, the above is completely false. The reason they weren't accepted into glibc was IIRC: 1) They are non-std. and did not have a usable standard like definition apart from the implementation and had no tests (Solaris implemented them slightly differently, for example, and Input Validation in C and C++ from oreilly also screwed it up -- and that was written by people selling a Secure codeing in C book).
2) It doesn't solve the problem better than asprintf() which had been around for years (although also non-standard), as you still have problems with truncation (and both APIs have the problem of requiring the programer to correctly pass around the meta data about the string -- Ie. it's size/length).
3) Given the above, and the fact the implementation is "free" then anyone wanting to use them can just include the source in their apps. and rely on autoconf (and they'll also be guaranteed to have the "correct" implementation).
I'd think of it a bit like buying "cleaning services" for 10 cents a year, sure in aggregate that might be worthwhile for someone to do (if they can get 2 million victims, say)... but if some super-new virus happens that takes out %1 of their userbase, they sure as hell aren't going to care.
For that kind of "price" it's going to be all automated software, which a bunch of companies already do... for not significantly more, per. customer, and are much more likely to not want bad press with problems of even a 1% margin.
Bittorrent is the second fastest way that I've seen for downloading large content files...
The fastest way to download something is via the newsgroups. Yup, the oldest way is still in some cases the best (it's not P2P, but it fits in my rant anyway). The downside here is for good news service, you have to pay, while the other methods are free.
Then you haven't measured it properly, Netnews has to encode everything to 7bit ASCII which adds about 40% overhead. Yes, this is often _really_quick_ to download, esp. over a modem... but you are downloading 40% more of it, so you can't just compare wire speed.
There's also the "slight" problem of missing chunks. The one advantage it does have is that you are pretty much guaranteed to have a local to you peer, which is probably the biggest problem with bittorrent as currently implemented (it trades speed for fairness).
The point is that it's never worked well to install vanilla kernels into production (unless you floow lkml very closely and do the same kind of work Red Hat etc. do), they've always had problems and missing features... the only difference now is that due to development changes everything is happening much faster.
If you are driving with your eyes closed and no seat belt no, and it kind of worked ok when doing 2MPH the fact you are now doing 20MPH isn't the problem and slowing down again isn't the solution.
Clearly you just wish to prove you're right. Really you have absolutely no idea what you're talking about.
I had assumed that you were saying that the io-*.c stuff was wrappers that linked to imlib the exact quote is "Gnome-terminal has the added advantage of using imlib2" (which I knew to be false), why else mention where the imlib source is located if you weren't implying gtk links against it? And why mention imlib2 at all?
Even though they may not be actually using the imlib library (which I said might be the case), the fast graphics code comes nearly verbatim from imlib (which is also exactly what I said)
You may have meant that, but I don't think you said it. But, yes, I can see now that you are correct that some gdk_pixbuf code certainly started inside Imlib (although it is misleading that the copyright statements don't reflect that).
Also...
% ll io-*.c | wc -l 10 % ll *.c | wc -l 30 % egrep -i imlib *.c gdk-pixbuf-xlib-drawable.c:/* copied from Imlib */ io-tiff.c:/* Following code (almost) blatantly ripped from Imlib */ io-xbm.c: ripped from Imlib'' */
...so out of 10 io-*.c files there are two that are said to be from imlib (and that doesn't include the big ones like png, jpeg, gif or xpm). The other hit suggests that drawable_is_pixmap() is copied from Imlib as well (which is only 10 lins of code).
Personaly I wouldn't say this qualified "Gnome-terminal has the added advantage of using imlib2", even if you qualify that to mean "uses fast bits of code that are in imlib2 and also in gdk_pixbuf". But, given that raster isn't listed as an author/copyright owner anywhere in io-xbm.c I am more suspicious and could see how anyone could draw a different conclusion.
Here's a clue, it's not imlib. gtk/gnome have never used imlib2 (which is what E17 etc. uses), and they moved from using libimlib a _long_ time ago. Random links:
Pretty much, and atm. Ubuntu isn't one of them. Yes, distro. watch likes to pretend otherwise and they are free to live in their webpoll fantasy world. But that doesn't change the real world.
But modifying your code or adding to it and relicensing it does not restrict any freedoms to your code
This is not true, there are many examples where companies have taken liberally licensed code like X or BIND and just included it wholesale with almost no "extra" code... and the whole thing is then proprietary. Yes, in some cases you can argue that adding a graphics driver etc. is an addition... but putting an introduction onto a novel doesn't make it a new novel.
People have to share their modifications in return for using it in their application. That is a form of payment. Sorry.
It is not a form of payment. If I let people live in my house "for free", but then kick them out if they steal my things or punch me in the face... "not punching me" would not be considered a form of payment by any sane person. Good manners, an obvious condition, sure... but payment, no.
Yeh, I think that's the main point the above posters have missed. If you normally "work" at a seperate location, then trying to work at home is going to be a bad experience... much like the couple of times a year I have to goto an office, my chair; desk; computer; everything is wrong.
The same with the "I only work 40 hrs a week, so don't work at home" reply... sure, so do I (on average), but I never do 40 hours by working 9-5, 5 days a week, with an hour for lunch -- in other words, being able to work 1-3am is only a benifit if it means you can not work 1-3pm.
So I welcome the compatibility but I'd like to see an independant standards body regulat the XML DTD.
Given the rest of your message, what would this achieve? The only way anything will get better is if a significant number of people push back at stds. non-compliance... and then it doesn't matter who created/maintains the std.
The obvious place for this to happen is government bodies, and non-US ones are starting to imply they will do this. How much they push back remains to be seen.
Hmm. So there's this limit called PATH_MAX, and instead of using it we'll just type the number in? Not to mention that nothing stops something passing strings bigger than that to your application, PATH_MAX is just the max size you can pass to open() etc. Oh, but it gets better:
% egrep PATH_MAX/usr/include/linux/limits.h /usr/include/linux/li mits.h:#define PATH_MAX 4096/* # chars in a path name including nul */
Muhahhahaha. It's an article written by someone with no clue, about an API that noone uses.../. says: +8 insightful.
...but 1) noone does that (due to it being horribly ugly). and 2) If "X" exists and is a namedpipe, which blocks, and the user does a C-c you'll get the same problem with a KeyboardInterrupt exception.
What about the readers who knew MACRO32, where they blasted with lots of redundant (and possibly inconsistent) comments when they read the original code?
Yeh, the I ported code I didn't understand story didn't make me think "ooh, I should comment more" but "Ohh, someone needs to take a hammer to someone's fingers, for the sake of the rest of us". Here's a free clue to the OP, when you translate X into Y, you do not start off with Z which is a different translation of X (esp. given that there is no assurance that Z is an accurate translation).
GNOME is the predominate desktop among the big distros aimed at commercial organisations
Nice troll. Let's look at the top ten distros over on DistroWatch.com
1 Ubuntu (GNOME)
2 Mandriva (KDE)
Err, here's a free clue... Ubuntu and Mandriva are not the most used "big distros aimed at commercial organisations", ergo. distrowatch.com is not measuring what you are implying they are measuring.
Another way of looking at it is this, using the above "results" the "number 1" distro. is dpkg based... this in stark contrast to packaging for LSB or basically any commercial application.
The harsh reality is that RHEL is by far the number 1 commercial distribution, with SuSE comming in second with about a 10th of the customers (worldwide, germany may well be different). However I have heard non-staistical evidence that there are significant numbers of people using RHEL, but using KDE which would suggest it's significantly better in some way as they are manually changing to it (see you can argue your position without misleading people)... on the other it all seems like vi vs. xemacs to me, and thus. a complete waste of time and energy.
A good number of OSS zealots (of which a good number are found here) have the need to believe that OSS is always better, in every case, and part of that is not admitting faults. You admit faults, you admit the possibility something else could be done better.
OSS != Apache-httpd, yes apache-httpd is OSS... but there is more than one OSS httpd server. Indeed, I disliked apache-httpd so much I wrote my own you is OSS. Part of the benefit of OSS is that a single organisation cannot say "thou shalt always use the one true httpd server".
Secondly, yes, apache-httpd has it's faults... but everything I heard about IIS, Java Sun ONE server etc. is that they have much more of them. And, if you want to fix/audit apache-httpd you can... right now, free of charge. Want to do the same with ISS, yeh, good luck with that.
And processors basically do operate flawlessly, because we demand that from them. But Operating Systems and other pieces of software do not.
You'd better tell AMD that they can take their errata document for the Opteron down then.
Software and hardware is "bad" because noone is willing to pay for "good", NASA's JPL make software that is as close to perfect as anyone can do... and they spend a huge amount of money to do so.
No. They're on the web site of the distribution that you used.
Let's stick to debian instead of pretending that all distributiuons are the same (although, AFAIK, no distributions allows what you claim they all do).
So, with debian, you can boot into knoppix. There is no general tool to say "I'm booted into knoppix, please verify/mnt/foo which is a debian installation with wesite bar using gpg key XYZ".
So, what can you do... you can have a trusted version of debsig-verify, and a trusted version of lftp on the knoppix CD... you can download what is currently available from the debian repositories NOTE: this isn't necessarily the same as what you had installed, that isn't possible in the general case (again, just talking about debian). It's also not possible to only download just the packages you need... but you have a trusted lftp, and so you can do an lftp mirror and get all packages (now wait X hours for that to happen).
Now you have all packages, you can setup/run debsig-verify and prove all those packages are correct. Then you have to extract the checksums from the packages, as I said earlier with debian checksums for files aren't part of policy, debsums -l shows "at" as an obvious candidate that doesn't have any debsums. So you'll need to manually unpackage all of the packages that you think you have installed, and then generate checksums for all the files (again, there is no tool to do this -- get your vim/perl out).
So, yes, you've now generated a complete checksum of all files that come directly from packages. And you can now write another tool that will check what is installed on/mnt/foo against that list. You will get a significant number of hits for config. files (both in/etc and those in other places like/var/spool/cron/crontabs), or files you have in/home/, or package generated files like/etc/fstab (not forgetting things like debconf files). The only option is to manually inspect all of these files.
Oh, and remember... after writing all these custom tools, doing all this work and eventually falling back to inspecting 10s or 100s, or even 1000s of files by hand... this is all if you are lucky, if you are unlucky you'll have something installed that isn't on the main repositary sites anymore (for instance, you had a security update of package foo that has had another update -- only the latest update will be available).
Or, you could just reinstall the OS and import the data from backups.
No, seriously, how is someone going to sneak something by you in fstab?
For someone asking if I understand what a checksum is you are now acting pretty stupid. fstab is obviously not the only package generated file. For fstab explicitly, I'm not sure you could do something bad that would be stealthy... but you could certainly do unstealthy things like have loopback mounts with setuid helpers (possibly hiding under other loopback mounts, so nothing will see them until a non-privilaged app. does a umount on the first loopback).
The point is you have to manually audit all of these types of files to _prove_ that you are safe... as against just reinstalling the OS and importing the data.
#1. Why would I not trust "the OS+libc+package-manager"? It's Knoppix. I booted the system clean.
#2. On Debian, I can check all the files on the whole disk (not just/usr) and it will tell me what files belong to what packages and which do not.
Here's the first step for you.
cd/usr
dpkg -S * >/root/usr.info.txt
Sure it will. Every file there should be part of a package. All you have to do is have the system check which package each file belongs to.
Any files that don't belong to a package, you delete.
[...]
And those mod's are instantly identifiable because they won't have the same checksum as the originals.
And where are the package content checksumss kept? That's right, on your compromised system. I'm not even sure debian mandates MD5 checkums on all it's pacakge files yet.
Also there are more than a few files that don't belong to a package (like/etc/fstab -- and very much do bad things with this) or are config. files (like all of/etc/init.d/* in debian).
Even if you could somehow trust the OS+libc+package-manager there's no Linux package-manager that will do a full check (Ie. tell me of all files in/usr that "don't belong" there), or check against a verifiable remote resource. tripwire and it's ilk can do some of this, if you take the pain to set it up and maintain it.
Yes, with rpm/dpkg you can get yourself out of a simple compromise if you assume a lot of things... but the only way to be sure if re-install, and import the data.
You're trying to tell me complete songs come to you as devine insperation?... I think not.
You try to write music a bar or two at a time and you're going to wind up with a mess.
You try to write software a line or two at a time, and the obvious argument in the other direction is that more than a few "commercially successful" songs have been based on a couple of bars.
It's not as obvious that all music has to be free right now, but musicians can certainly do better than "here's a CD, please pay $15"... even if it's just live recordings or "b sides" for free download. Saying "I want to make a living", is not the same as "give me all your money".
* Commercial domains.
* Non-profit organisations, and personal-use domains.
How do you do this? What about is someone starts a company, and uses it for personal info.... and then closes the company. What about when someone has a personal domain, and then starts making money (hello slashdot.ORG). The.org/.com difference isn't useful or enforcable.
Slashdot Mirror
All powerstations are down for days, lots of people die at hospitals all over the country. Others people die due to no light/AC/heat/water "even worse" ... billions lost due to companies that can't do anything, noone can travel due to gas stations not having power (thus no food gets to stores), stocks go down the toilet bringing even more economic damage.
But, yeh, fuckit ... you've got virus protection right for your porn sites, what more could be needed?
Nice circular argument. a) leaks are a huge problem. b) I never see them. a) but that's why they are a problem.
IMO if nobody ever notices there is a problem, there isn't a problem. Also the application that leaks the most on the desktop is written in Python, which has reference counting and garbage collection.
RAII requires allocating from the stack, and a _lot_ of C++ uses that design pattern. malloc() is much more used in C (which I prefer) ... but I still almost never see memory leak problems (and, yes, my code counts the memory and complains at exit if I've leaked something).
Yes, some people currently use str*cpy() and str*cat() in C ... my general point is that those that do are generally writting worthless buggy crap, and only fixing a tiny amount of the problem by providing strlcpy() and strlcat() isn't a sane solution. It would have been worth it in 1980, but not 20 years later when it's blatantly obvious to anyone, who's looked at the data, that string APIs can be just as "fast" and much less prone to programer error.
Yes, strlcpy is a better interface than strncpy ... but no, IMO, it isn't enough as it's only going to solve maybe 10% of the problems that are very easy to find anyway. 100% solutions exist, so settling for less isn't worth it.
As for the comments that it's "free" to add to glibc anyway, so why not get any benifit we can ... the problem is that as soon as something is in libc people want "superfast" asm versions of it. Esp. things in string.h. This is even more fun combined with the lack of knowledge of what the functions should in the corner cases. Also not having those functions and people asking for them being told "no, go use a real string API" might well do more good than that simple 10%.
Riiight, the strlcat "paper" was presented in late 1999 at Usenix ... C99 (as you might guess from the name) was released in 1999, and was basically feature frozen for at least 2 years before that. So unless Ulrich has a time machine that I don't know about, I find it unlikely he could do what you suggest.
And if it's still needed for the next C standard, because people still use interfaces that look anything like it, god help us all.
Riiight, you have apps. that are checking for an include file in a specific location, which is _also_ provided by dietlibc ... and I can guarantee they can't use that.
Instead of say just running /lib/libc.so.6 and comparing the version (which, of course, isn't ideal and it could even be done using the output of LD_DEBUG/ldd to work even if libc wasn't in /lib).
Hell given the "portability" requirements, they could just test the output of: "rpm -q glibc || dpkg -l libc6"
Your problem isn't going to be solved by LSB, even if LSB was actually amazingly well done.
While Ulrich has his faults, the above is completely false. The reason they weren't accepted into glibc was IIRC:
1) They are non-std. and did not have a usable standard like definition apart from the implementation and had no tests (Solaris implemented them slightly differently, for example, and Input Validation in C and C++ from oreilly also screwed it up -- and that was written by people selling a Secure codeing in C book).
2) It doesn't solve the problem better than asprintf() which had been around for years (although also non-standard), as you still have problems with truncation (and both APIs have the problem of requiring the programer to correctly pass around the meta data about the string -- Ie. it's size/length).
3) Given the above, and the fact the implementation is "free" then anyone wanting to use them can just include the source in their apps. and rely on autoconf (and they'll also be guaranteed to have the "correct" implementation).
I'd think of it a bit like buying "cleaning services" for 10 cents a year, sure in aggregate that might be worthwhile for someone to do (if they can get 2 million victims, say) ... but if some super-new virus happens that takes out %1 of their userbase, they sure as hell aren't going to care.
For that kind of "price" it's going to be all automated software, which a bunch of companies already do ... for not significantly more, per. customer, and are much more likely to not want bad press with problems of even a 1% margin.
Then you haven't measured it properly, Netnews has to encode everything to 7bit ASCII which adds about 40% overhead. Yes, this is often _really_quick_ to download, esp. over a modem ... but you are downloading 40% more of it, so you can't just compare wire speed.
There's also the "slight" problem of missing chunks. The one advantage it does have is that you are pretty much guaranteed to have a local to you peer, which is probably the biggest problem with bittorrent as currently implemented (it trades speed for fairness).
The point is that it's never worked well to install vanilla kernels into production (unless you floow lkml very closely and do the same kind of work Red Hat etc. do), they've always had problems and missing features ... the only difference now is that due to development changes everything is happening much faster.
If you are driving with your eyes closed and no seat belt no, and it kind of worked ok when doing 2MPH the fact you are now doing 20MPH isn't the problem and slowing down again isn't the solution.
I had assumed that you were saying that the io-*.c stuff was wrappers that linked to imlib the exact quote is "Gnome-terminal has the added advantage of using imlib2" (which I knew to be false), why else mention where the imlib source is located if you weren't implying gtk links against it? And why mention imlib2 at all?
You may have meant that, but I don't think you said it. But, yes, I can see now that you are correct that some gdk_pixbuf code certainly started inside Imlib (although it is misleading that the copyright statements don't reflect that).
Also...
...so out of 10 io-*.c files there are two that are said to be from imlib (and that doesn't include the big ones like png, jpeg, gif or xpm). The other hit suggests that drawable_is_pixmap() is copied from Imlib as well (which is only 10 lins of code).
Personaly I wouldn't say this qualified "Gnome-terminal has the added advantage of using imlib2", even if you qualify that to mean "uses fast bits of code that are in imlib2 and also in gdk_pixbuf". But, given that raster isn't listed as an author/copyright owner anywhere in io-xbm.c I am more suspicious and could see how anyone could draw a different conclusion.
Here's a clue, it's not imlib. gtk/gnome have never used imlib2 (which is what E17 etc. uses), and they moved from using libimlib a _long_ time ago. Random links:
http://developer.gnome.org/feature/archive/gdk-pihttp://developer.gnome.org/arch/imaging/gdkpixbuf
http://developer.gnome.org/doc/API/2.0/gdk-pixbuf
Errr... no. gnome-terminal uses gnome/gtk/gdk/gdk_pixbuf/etc.
Pretty much, and atm. Ubuntu isn't one of them. Yes, distro. watch likes to pretend otherwise and they are free to live in their webpoll fantasy world. But that doesn't change the real world.
This is not true, there are many examples where companies have taken liberally licensed code like X or BIND and just included it wholesale with almost no "extra" code ... and the whole thing is then proprietary. Yes, in some cases you can argue that adding a graphics driver etc. is an addition ... but putting an introduction onto a novel doesn't make it a new novel.
It is not a form of payment. If I let people live in my house "for free", but then kick them out if they steal my things or punch me in the face ... "not punching me" would not be considered a form of payment by any sane person. Good manners, an obvious condition, sure ... but payment, no.
Yeh, I think that's the main point the above posters have missed. If you normally "work" at a seperate location, then trying to work at home is going to be a bad experience ... much like the couple of times a year I have to goto an office, my chair; desk; computer; everything is wrong.
The same with the "I only work 40 hrs a week, so don't work at home" reply ... sure, so do I (on average), but I never do 40 hours by working 9-5, 5 days a week, with an hour for lunch -- in other words, being able to work 1-3am is only a benifit if it means you can not work 1-3pm.
Given the rest of your message, what would this achieve? The only way anything will get better is if a significant number of people push back at stds. non-compliance ... and then it doesn't matter who created/maintains the std.
The obvious place for this to happen is government bodies, and non-US ones are starting to imply they will do this. How much they push back remains to be seen.
Hmm. So there's this limit called PATH_MAX, and instead of using it we'll just type the number in? Not to mention that nothing stops something passing strings bigger than that to your application, PATH_MAX is just the max size you can pass to open() etc. Oh, but it gets better:
Muhahhahaha. It's an article written by someone with no clue, about an API that noone uses ... /. says: +8 insightful.
Yes, as in cryptic for the user. The following is roughly what I see in the wild, when using python vs. almost anything else:
...yes, in theory, the python program could do:
...but 1) noone does that (due to it being horribly ugly). and 2) If "X" exists and is a namedpipe, which blocks, and the user does a C-c you'll get the same problem with a KeyboardInterrupt exception.
Yeh, the I ported code I didn't understand story didn't make me think "ooh, I should comment more" but "Ohh, someone needs to take a hammer to someone's fingers, for the sake of the rest of us". Here's a free clue to the OP, when you translate X into Y, you do not start off with Z which is a different translation of X (esp. given that there is no assurance that Z is an accurate translation).
Err, here's a free clue ... Ubuntu and Mandriva are not the most used "big distros aimed at commercial organisations", ergo. distrowatch.com is not measuring what you are implying they are measuring.
Another way of looking at it is this, using the above "results" the "number 1" distro. is dpkg based ... this in stark contrast to packaging for LSB or basically any commercial application.
The harsh reality is that RHEL is by far the number 1 commercial distribution, with SuSE comming in second with about a 10th of the customers (worldwide, germany may well be different). However I have heard non-staistical evidence that there are significant numbers of people using RHEL, but using KDE which would suggest it's significantly better in some way as they are manually changing to it (see you can argue your position without misleading people) ... on the other it all seems like vi vs. xemacs to me, and thus. a complete waste of time and energy.
OSS != Apache-httpd, yes apache-httpd is OSS ... but there is more than one OSS httpd server. Indeed, I disliked apache-httpd so much I wrote my own you is OSS. Part of the benefit of OSS is that a single organisation cannot say "thou shalt always use the one true httpd server".
Secondly, yes, apache-httpd has it's faults ... but everything I heard about IIS, Java Sun ONE server etc. is that they have much more of them. And, if you want to fix/audit apache-httpd you can ... right now, free of charge. Want to do the same with ISS, yeh, good luck with that.
You'd better tell AMD that they can take their errata document for the Opteron down then.
Software and hardware is "bad" because noone is willing to pay for "good", NASA's JPL make software that is as close to perfect as anyone can do ... and they spend a huge amount of money to do so.
Let's stick to debian instead of pretending that all distributiuons are the same (although, AFAIK, no distributions allows what you claim they all do).
So, with debian, you can boot into knoppix. There is no general tool to say "I'm booted into knoppix, please verify /mnt/foo which is a debian installation with wesite bar using gpg key XYZ".
So, what can you do ... you can have a trusted version of debsig-verify, and a trusted version of lftp on the knoppix CD ... you can download what is currently available from the debian repositories NOTE: this isn't necessarily the same as what you had installed, that isn't possible in the general case (again, just talking about debian). It's also not possible to only download just the packages you need ... but you have a trusted lftp, and so you can do an lftp mirror and get all packages (now wait X hours for that to happen).
Now you have all packages, you can setup/run debsig-verify and prove all those packages are correct. Then you have to extract the checksums from the packages, as I said earlier with debian checksums for files aren't part of policy, debsums -l shows "at" as an obvious candidate that doesn't have any debsums. So you'll need to manually unpackage all of the packages that you think you have installed, and then generate checksums for all the files (again, there is no tool to do this -- get your vim/perl out).
So, yes, you've now generated a complete checksum of all files that come directly from packages. And you can now write another tool that will check what is installed on /mnt/foo against that list. You will get a significant number of hits for config. files (both in /etc and those in other places like /var/spool/cron/crontabs), or files you have in /home/, or package generated files like /etc/fstab (not forgetting things like debconf files). The only option is to manually inspect all of these files.
Oh, and remember ... after writing all these custom tools, doing all this work and eventually falling back to inspecting 10s or 100s, or even 1000s of files by hand ... this is all if you are lucky, if you are unlucky you'll have something installed that isn't on the main repositary sites anymore (for instance, you had a security update of package foo that has had another update -- only the latest update will be available).
Or, you could just reinstall the OS and import the data from backups.
For someone asking if I understand what a checksum is you are now acting pretty stupid. fstab is obviously not the only package generated file. For fstab explicitly, I'm not sure you could do something bad that would be stealthy ... but you could certainly do unstealthy things like have loopback mounts with setuid helpers (possibly hiding under other loopback mounts, so nothing will see them until a non-privilaged app. does a umount on the first loopback).
The point is you have to manually audit all of these types of files to _prove_ that you are safe ... as against just reinstalling the OS and importing the data.
You
And where are the package content checksumss kept? That's right, on your compromised system. I'm not even sure debian mandates MD5 checkums on all it's pacakge files yet.
Also there are more than a few files that don't belong to a package (like /etc/fstab -- and very much do bad things with this) or are config. files (like all of /etc/init.d/* in debian).
Even if you could somehow trust the OS+libc+package-manager there's no Linux package-manager that will do a full check (Ie. tell me of all files in /usr that "don't belong" there), or check against a verifiable remote resource. tripwire and it's ilk can do some of this, if you take the pain to set it up and maintain it.
Yes, with rpm/dpkg you can get yourself out of a simple compromise if you assume a lot of things ... but the only way to be sure if re-install, and import the data.
You're trying to tell me complete songs come to you as devine insperation? ... I think not.
You try to write software a line or two at a time, and the obvious argument in the other direction is that more than a few "commercially successful" songs have been based on a couple of bars.
It's not as obvious that all music has to be free right now, but musicians can certainly do better than "here's a CD, please pay $15" ... even if it's just live recordings or "b sides" for free download. Saying "I want to make a living", is not the same as "give me all your money".
How do you do this? What about is someone starts a company, and uses it for personal info. ... and then closes the company. What about when someone has a personal domain, and then starts making money (hello slashdot.ORG). The .org/.com difference isn't useful or enforcable.