On Sun, 27 Nov 2005 14:15:26 +0100, Robbert Haarman <[EMAIL PROTECTED]> wrote:
>Dear JCR, > >> To the rest of list users; Please pardon another long email from me on >> this. Helping reasonable people like Robbert understand why many people >> consider "HOWTO's" to be harmful is hopefully worth the added noise and >> bandwidth. > >If this is a concern, why don't we take the discussion off-list? Also, I >don't want to waste anyone's time with this discussion, so if you are >tired of this discussion, just tell me to stop it and I will. > Long posts and repeated back-and-forth on the list are things I prefer to avoid, since every post we make on list does carry the associated cost of many people, including a lot of the developers, reading and scrutinizing it. I find you, your opinions and the discussion itself interesting, but moving it off list after this post will probably be best. I was originally going to send this to you off list but Michael Quaintance requested to continue the discussion in public. A tough call ether way but capitulating with his request on one last lengthy volley into the ether seems fairly reasonable. I hope it seems like a reasonable plan to you. >> >> If end-users are lazy and want to take the easy way out, they should >> >> go back to using linux and MS-Windows. They are not welcome here. >> > >> >That's a pity. I personally think OpenBSD is the _only_ operating system >> >that takes security as seriously as it should be taken, and it would be >> >in everybody's (well, almost everybody's) best interest if they used it. >> >There is nothing wrong with the project not wanting certain users, but >> >it leaves these users with a choice among evils, which is a pity. >> > >> >> The pity is not whether or not some users are welcome. The real pity is >> current technology has yet to produce a computer that the average user >> can, own, operate and maintain without either significant knowledge of >> their own or significant resources to pay professionals to do the dirty >> work. > >I disagree. A Linux distro (forgive my blasphemy) Linux is not blasphemy. It's just one of the many a flavors of UNIXish operating systems. The various flavors of UNIX are just like people; we all have our own set of problems and personality quirks. Oddly enough, there's a powered off RedHat8 box currently being used by my feet as a footstool. Though I can't say I really support linux very much, I can say linux supports my feet fairly well. ;-) >like Ubuntu is easy >enough for computer illiterates to use and even maintain, since security >patches are automatically announced and installed with a click of the >mouse. I've never tried Ubuntu. Is it fun? -The reason why my only linux box is an ancient RedHat8 is due that version being the only "supported" version of linux for Cadence software suite. I have to test on it, as well as SPARC-Solaris, PARISC-HPUX, POWER-AIX and others. >If only Ubuntu had the advanced security mechanisms of OpenBSD, >it would be a very secure system, even if the users didn't know much >about computers. > >As it stands, OpenBSD is the only operating system I am aware of that >has had the full base system completely audited and has buffer overrun >and other protections enabled for all software on it. This, by itself, >makes it more secure than other systems, regardless of what users do >with it. Even in the worst case, where users actively degrade the >security of the system, I would imagine OpenBSD's security would at >least not be _worse_ than that of another system. > As you know, reducing the secure/insecure argument to absolutes of black and white does not work but contrary to popular belief, trying to differentiate based on shades of gray also fails miserably. There are just too many possibilities, too much work and too many assumptions to make any solid case based on particular shades of gray. To put it a bit more directly, I believe you are grasping at straws with this line of reasoning because we both know there's really no way to prove or disprove whether your assumptions are correct or incorrect. On the bright side, I think you deserve bonus points for a beautiful use of rhetoric. ;-) Adding security features tends to break existing software. It's just a fact of life but on the flip side, it does allow new classes of bugs to be found and fixed. When software refuses to compile or run due to some new security feature, the result is increasing the level of expertise required of "normal" users to do a "normal" tasks. What I'm saying is, the Ubuntu/Windows approach of trying to make things easy for the end-user is diametrically opposed to the addition of disruptive security technology. Yes, in time, the bugs found by a new security feature get fixed and the effect on required knowledge is reduced but in the mean time, you've got a bunch of angry users out for blood because they can't do their job. Security itself is actually a myth because nothing is ever completely secure. Calling it a "relative term" and playing the shades of gray game is really just a cop out since the work required to completely prove the relation and distinction never actually gets done. Any generalized comparison, like the ones you've made, such as stating OpenBSD is "more secure" or "less secure" than something else is simply fallacious and unsubstantiated claim because it would take decades to gather all the data required to logically prove it either way. If you are willing to pay the tab for a ton of top security people to spend many decades doing low level analysis of every bit and byte, please let me know when your done generating the mountain of results, since if you get done soon enough, I might actually get around to reading them while I'm alive. The most clean and logical way to view the myth of "security" is as a risk management problem. This leaves you with the difficult task of defining what you personally consider to be acceptable risk but it gets you away from using vague and unprovable comparisons like "more secure" or "less secure" as well as the associated holy wars they always seem to provoke. Adding buffer overflow protection simply decreases risk by a somewhat measurable degree based upon both its tested effectiveness at it's job and the probability of buffer overflow bugs in the code you run. It's math. For this one piece, within the given bounds, you can clearly define it's over all effect as having a high probability of reducing risk by some degree. The problem with assigning a risk metric to something as esoteric as end-user security degrading misconfigurations is there are just too many possible misconfigurations with too many degrees of security degrading effects to account for a reasonable number the possibilities. Some misconfigurations are innocuous others are absolutely deadly. Worst of all, you can not completely prevent them. The only thing you can say for certain is misconfigurations *do* have a very high probability of occurring and *can* pose very substantial risk. The best option in such a no-win situation is reduce the number of configuration tasks and options to a minimum, known set and then validate them through testing and auditing. Once again, you're looking at a lot of work which most people will never do. How many experienced users do you know that follow such a procedure? How about new users? Regardless of the operating system that's being used, if you give a new guy root on his own box and combine it with a lack of knowledge and procedure when configuring and installing things, the end result is always the same; a box with a very high potential risk of compromise. You can not avoid this particular risk exposure. No one can. Not even the OpenBSD team, and they have done more due diligence in testing and auditing their default configuration than any other publicly known development team. Maybe you read all the news/marketing about all the cool new security features added in OpenBSD and that is where your concentration seems to be. Take a look at the other, unpromoted side; the OpenBSD team also actively removes features, buttons, knobs and other unnecessary and risky nonsense. Either way, if end-user misconfiguration is possible, you end up with Murphys' Law on the majority of systems owned by inexperienced and reckless users regardless of the deterrents you put in place. Every time you make something more idiot proof, the world produces a more effective idiot, so the very best you can ever do to combat this fact of life is manage your own risks accordingly. All of this, in a strange sense, gets us back to correctness. With effort and detail, you can define what you personally consider correct and at least to some degree, you can test to make sure of compliance with your definition. When you ponder it, yep, you're looking at risk management once again. The thing to remember is risk can never be completely eliminated, it is only managed within the bounds of available knowledge and resources. The risk management effort covers the whole enchilada from trying to limit user inflicted misconfigurations, to correct operation of code, to accurate and useful documentation, to copyright issues from bad licenses, to legal threats from patents, to the inability to compete in the operating system market due to closed hardware docs and so on and so forth perpetually. As you can see, in total risk management is a *HUGE* problem and the only answer is to weigh and manage the various risks to the best of your ability with the knowledge and resources you have available. >> >The reason I wrote the HOWTO is that, in my opinion of course, the >> >manpages don't make it clear how to set things up. Searching the >> >archives for more information came up with some contradictory messages, >> >and some instances of people being misled by the way things worked and >> >the way things were described in the manpages. My HOWTO is an effort to >> >gather the relevant information in one place, and provide clear steps >> >for getting things working. >> >> Therein lies a significant difference of opinion between you and I. The >> steps provided by HOWTO documents do not give clarity, > >They do. They explain some of the things that people were having >problems with, such as the fact that labeling doesn't work the same way >as it does for real disks (which Mickey says I got wrong - but can you >blame me, given that the manpages don't say anything about it?). > Can I blame you? -No, not really. There are really only two possibilities here; (1) you overlooked, misread or failed to read something or (2) you found an issue in the docs that many people will consider a bug. Considering you are taking the time and investing the effort, I'm personally betting on door number two. >No matter how much you compare my HOWTO to blindfolding people and >possibly sending them off in wrong directions, it's a fact that the >documentation that existed before it has led people in wrong directions >and left them confused. For some people, possibly many, yes, you are correct. >The HOWTO is my attempt to provide instructions >that work and don't leave people confused. Perhaps, instead of arguing >back and forth about whether I did well to write the HOWTO, we should be >working together to fix the mistakes and turn it into a document that >provides correct and sufficient information? > Exactly. (more on this later) >> You are legally able to copy the OpenBSD man pages, so there is really >> nothing stopping you from quoting them a chunk at a time and adding your >> own insight, explanations and experience. By privately contacting the >> authors and maintainers of both the code and man pages, you can easily >> double check your work to prevent spreading misinformation. Provide >> explanations of the steps you took as well as explanations of all the >> other possible steps a user might want or need to take. > >There's something to that, too. I didn't want to bug the developers, >afraid as I was that the questions I had would annoy them, and result in >a pointer back to previous misc@ threads at best. Instead, I decided to >figure out for myself how I could get things to work, and document the >steps, so that others might benefit. It seems that, in doing so, I've >annoyed people even more. Again, I must apologize. This was not my >intention. > (again, see below) >> better than a HOWTO that claims to be a short-cut way to set up >> mirroring but actually provides the steps needed to possibly fry your >> disks through misconfiguration. > >Honestly, I think that's a stretch. I'm sure you can destroy your data >with ccd, but frying your disks with a pure software feature? > Actually I meant frying your data but yes, it is *very* possible to fry hardware with software and sometimes it can be a lot of fun. Search the Internet for "Hard Drive Races" and you'll see what I mean. And no, I'm not talking about "race conditions" I'm talking about taking a "hard drive" the size of a washing machine and writing a program to make it "walk" across a finish line as fast as possible via sequences of seeks and writes. ;-) Some things never change... even today the greatest threat to expensive, working hardware is a bored geek with a bit of imagination. >> There might be other good ways to go about making things more accessible >> to users but the methods you are currently using are really a disservice >> to others in spite of your good intentions. > >That's assuming that my directions really do lead users in the wrong >direction. If they let users set up ccd and everything works fine, I >don't see the problem. Note, also, that the HOWTO does include a section >that describes (albeit briefly) how ccd works, and that I have >incorporated improvements suggested by the discussions here. I'm >_trying_. > Your effort is admirable. The same is true for Daniel Ouellet and some of the others who agree with and exercise your HOWTO methods. >> How would you feel if some newbie found your original HOWTO through >> google, never read your mailing list post asking for validation and >> followed your instructions only to lose all of his data due to your >> mistakes? > >If that happens, too bad. The instructions work for me, so I can only >assume they work for others. I'm incorporating new information as I >learn. I do warn that making backups is a necessinty, and anyone with >enough common sense should know to make backups before messing around >with the partitioning of their harddisks. > Admittedly, I've been more than a little harsh while harping on the potential of data loss caused by incorrect instructions in your HOWTO but this is with good reason. People around here care about the correctness of what they do and care enough to post on this list to help others do things as correctly as possible. OpenBSD may be an unimportant hobby for you personally so it's no big deal if you crash your box, but there are many people who count on OpenBSD in order to put bread on the proverbial table. If your packets pass through an OpenBSD system for any professional purpose, guess what, you are one of the people who is counting on things being done right. Everything around here gets scrutinized for correctness. The most beneficial thing you and other HOWTO writers have done is prove there is a viable and valid need for increased clarity and accessibility in the docs on top of the usual correctness. If the ccd man page was more than just correct but was also clear and comprehensible to the average person, you and everyone else would have perfectly working ccd mirrors without all this fuss and discussion. The only possible down side I can see to having improved clarity in the docs, is I never would have had the opportunity to get to know you a bit. >> Though I'm generally considered extremely good with information systems, >> I know damn well that mickey@ could geek-slap me into tomorrow without >> breaking a sweat. Trying to argue with him about your mistake only shows >> your inexperience and unwillingness to do things correctly such as >> actually researching the topic upon which you are trying to enlighten >> others. > >Excuse me, but from what I can see, Mickey was wrong. The c partition is >configured as 4.2BSD before one can run disklabel, and using that >partition for data storage does work for me and others. This has nothing >to do with insulting Mickey's intelligence or abilities as a developer, >but I am not going to assume things are as he says when the facts >contradict him. > >Just to be on the safe side, I have updated the HOWTO to tell users NOT >to use the c partition. However, I am still not convinced that there is >an actual problem, until I read enough of the source code to convince >myself, or someone explains to me exactly how things would go wrong, why >things appear to work fine for me, and why the tools set things up in a >way that can (according to Mickey) destroy the partitioning on your >physical drive. > Ya know, that last paragraph of yours hits on something very prevalent in OBSD; proving your case. Debating things into the ground on the public lists is an absolutely pointless waste of time but proving your case with facts, tests and source code is very much welcome and appreciated. Just state your case with proof and if possible, provide a fix. 1.) I think this is a bug 2.) This is why I think it is a bug 3.) This is how to test for the bug 4.) This is a proposed fix for the bug. 5.) Is there a better way to fix it? 6.) I AM WILLING TO DO THE WORK. 7.) Do the work. 8.) ? 9.) PROFIT! Of course, you can skip #8 and #0 if you want ;-) but all of the other points are subject to debate and are just standard operating procedure for both bugs in code and bugs in documentation. >> If correctness was extremely important to you and you had extended the >> time and effort to ensure the greatest degree of correctness you could >> in your code and docs, would you be offended if I came along with an >> erroneous and lethargically tossed together "HOWTO" about your hard >> work? > >If the docs had been clear and correct, I and others would not have >followed the allegedly wrong steps I documented in my HOWTO. If Mickey >is right and using the c partition is disastrous, the code that sets it >up as a 4.2BSD partition isn't correct. > >To answer your question, if somebody had written an errorneous HOWTO >about my hard work, I would probably point out the mistakes and suggest >improvements. I would expect them to correct the mistakes and >incorporate the improvements. To the extent that improvements have been >suggested, I have incorporated them. > >> How about if I wanted to publicly argue with you that I'm right and >> you're wrong? > >As long as your arguments made sense, I would respond to them by >pointing out why I think I'm right and you're wrong. > It seems you're missing the underlying point that I was trying to drive you towards. Usually one of two possible real problems exist if you are faced with an erroneous HOWTO about your work: (1) the HOWTO author is an ignoramus or (2) you've failed to supply adequate documentation for your work. There is the third possibility of both #1 and #2 but it's rare. The best answer is to fix and improve your documentation so there is no need for a HOWTO. If you hadn't guessed already, I've known mickey for a while and I both like and respect him a great deal. In other words, I'm highly biased. Making sense of the things mickey writes takes a bit of effort and practice, usually including looking more things up in the man pages and source code. English is not his first language but after a while you'll realize he's got a rather cool style of English that's all his own... Like the fact he tilts his head the other way to smile (-; and in real life like his typing, he doesn't have a nose (; Though there may be some idiosyncratic things about the responses you get from mickey, he's really just like the rest of the developers; his responses are brief, often cryptic and usually painfully so. When you don't know what the heck they are talking about and their arguments don't make sense, the onus is upon you to do the work required to figure it out. If you start shooting back immediately without further educating yourself, you're hosed. You'll just be ignored. >> In a nutshell, what you have done is perform sacrilege multiple times, >> on multiple fronts and against multiple people. Your insistence on >> keeping your "HOWTO" publicly available on the Internet indicates both >> your apologies and your claims of security being important are not >> sincere. Unless you are at least dedicated to, if not obsessed with, >> correctness your good intentions and amiable goals will continue to do >> more damage than good. > >I think I have good reasons not to share that point of view. If you >(all) don't appreciate my efforts, that's fine with me. I see your point >of view. I just don't share it. > I think some of the reasoning behind my aggressiveness and the aggressiveness of others on the list may not be entirely evident. Surprisingly enough it's not an ego trip on my part or the any of the others who have responded. Long time users and developers have to deal with a lot of kooks every year on the lists; people who are a bit unbalanced, a bit unstable or even a bit nuts. On occasion we get people who are outright malicious, such as when during "rush" week at MIT, a group of students there descended on misc@ with the sole purpose of starting a verbal riot as some kind of prank (i.e "Chuck Buckely"). Also, you unknowingly hit a real sore spot by authoring your own HOWTO since many regard it as the wrong way to address the problem. Worse yet some of the other HOWTO authors in the past turned out to be crazy braggarts just looking for attention. I honestly never expected you to reply as you did and I was really expecting yet another foul mouthed flame from a nut job but thank you for the pleasant surprise. Having someone try to push a few of your buttons should always be expected on the list. Having someone you don't know, like me, pointedly and even rudely question you on darn near everything, is also to be expected. It's the most direct path for scrutinizing possibly erroneous information but it also does a great job on unveiling the nut jobs. Hopefully you realize I'm not actually a hyper-critical and condescending asshole in real life, well, at least not all of the time but I do occasionally play one on TV, or at least the OpenBSD equivalent of TV. Read the list long enough, get to know some of the people off list, and you'll realize I'm not the only one with a highly jaded approach to the whole thing. Now lets get back to the most important stuff, copied from above: >> You are legally able to copy the OpenBSD man pages, so there is really >> nothing stopping you from quoting them a chunk at a time and adding your >> own insight, explanations and experience. By privately contacting the >> authors and maintainers of both the code and man pages, you can easily >> double check your work to prevent spreading misinformation. Provide >> explanations of the steps you took as well as explanations of all the >> other possible steps a user might want or need to take. > >There's something to that, too. I didn't want to bug the developers, >afraid as I was that the questions I had would annoy them, and result in >a pointer back to previous misc@ threads at best. Instead, I decided to >figure out for myself how I could get things to work, and document the >steps, so that others might benefit. It seems that, in doing so, I've >annoyed people even more. Again, I must apologize. This was not my >intention. > I think you would be absolutely amazed how available, accessible and friendly the majority of the OpenBSD developers and long time users are to anyone who sincerely wants to help and is willing to work and learn. They are some really great people on this list and they care about what they are doing. In spite of being a bit more than rough at first, you'll find they are normal, regular, every-day people. Many of them have their personal kook-filters finely tuned from dealing with the public and until you actually have a history of doing useful things for the project, you'll be considered all talk and no action. The tough thing for most people to grasp is your personal definition of useful to the project is in no way a consensus many people with differing backgrounds and expertise. As I've said from the start, I believe your intentions are admirable but I also believe your methods are flawed. Since neither you nor I alone can be considered a consensus, we've got to look at what others are saying. Hopefully I can at least explain why I hold the opinions that I do. Though my reasoning is my own, there are many here who hold the same opinions I do. In some ways one can say I learned the opinions here on this list and in other ways, I learned how to back up the opinions I already had. The man pages are the authoritative documentation for the project and they exist on every default installation of the operating system. When something is less than correct, less than clear or less than comprehensible in the man pages, the place to fix the problem is at the source. Treat the disease not the symptoms. Putting correct but unofficial documentation scattered across the Internet might prove useful for those who finally find it but the best answer is still to incorporate the needed clarifications into the authoritative documentation that comes with the operating system. The goal of a manual is to explain things correctly. If the explanation is being lost because it is either incorrect, incomplete or even unclear, that is a bug. Plain and simple. Developers appreciate patches but with documentation proving a "bug" in it can often be very subjective, so just ask. None the less, the process is basically the same as before: 1.) I think this is inconsistent/unclear and might be a bug. 2.) This is why I think it might be a bug. 3.) This is my proposed solution. 4.) Is this bug something you want fixed? 5.) Is there a better way to fix it? 6.) I AM WILLING TO DO THE WORK. 7.) Do the work. Do the discussion of the bug on misc@ and when finished, send patches to tech@ and cc the maintainer. On small things attach a patch with your proposed change, on large things, save you effort until you get a consensus. I did this myself a day or two ago on misc@ regarding a lack of consistency (clarity) on the usage of "file system" and "filesystem" across all the documentation. The possible issue was very subjective in nature and would involve a lot of changes, so I asked for opinions of people who know a lot more about than I do, and received opinions of a few exceedingly well informed people like jmc@ among others. By following this method you are not idolizing the developers, pandering to the egocentric or prostrating yourself in front of false gods or any other such nonsense. Instead, your goal is simply consensus with other people that, in total, have a lot more combined experience and insight than you could ever have on your own. There's no requirement to agree, but it's wise to try learning and leveraging other perspectives and the reasoning behind them. If you appreciate the generally high quality of OpenBSD, at least you know *HOW* the quality was achieved. As you've pointed out, there are still plenty of places where the project still needs more help to make the authoritative documentation more clear and accessible. By working with the authors and maintainers of both the code and the docs to increase clarity and accessibility, you are not only helping both the project and the next guy who is trying to solve the problem that you just solved but you also stand to learn a lot from the process of interaction... -even if you are only a bystander just silently watching the interaction of others take place. (again from above) >we should be >working together to fix the mistakes and turn it into a document that >provides correct and sufficient information Yes, exactly but I will not work on third party documentation for the reasons I've detailed above. If I'm going to spend my time improving docs I'll be putting my effort towards solving the root of the problem in the authoritative documentation. Though I have hopefully been somewhat helpful in explaining the harsh reactions you received, how things get done around here and most of all, why, I actually lack the experience to be of much use on clarifying the specific ccd documentation. Heck, I probably know less about ccd code than you do. If you choose to make a sincere effort to solve the root of the problem in the man pages, you will get help from people who know that code far better than both of us combined. You'll no longer be a one man army working alone on HOWTO's to save the unindoctrinated masses, instead you'll be working with all other people trying to cope with various facets of the *HUGE* risk management problem faced by everyone. The irony of your last name Haarman translating to "harr" which means "army" and "man" meaning "man" was not lost on me. The only question left standing is whether you insist on trying to be a one man army or if you decide to combine your efforts with others. It's your choice and time will tell as it always does. Lastly, I hope I have not discouraged you from doing your own experimentation to learn things on your own and prove what you can. At times an experiment like writing a HOWTO is the only way to learn why you should not be writing one. Personally, I've seen this particular experiment fail in the past, namely watching new people writing on topics they do not fully understand. In the good/bad old days of UNIX, when the new (cheap) guy at the company was told to write about systems he did not understand, they used to call it "documentation" for the product. It was occasionally better than nothing but not by much. The brutal irony of lifes' lessons is the lessons are always repeated until learned. Considering I'm too tired to proof read all this, it looks like I'll be repeating a lesson I should have learned a long time ago. ;-) Kind Regards, JCR post scriptum: If I'm slow to respond to your private reply, it's because my hands hurt from doing far too much typing over the last week and they need a few days rest.
