Hi. On Sun, 27 Sep 2015 10:06:37 +0300 Eliezer Croitoru <elie...@ngtech.co.il> wrote:
> Hey Reco, > > I must admit that this is not the first time I was confused as a > trolling creature. For the record - I did not 'confuse' you as a troll and did not call you one. I could not care less about it, actually. > And responding to the above mentioned arguments\ideas\thoughts. > I know some might disagree with me about my point of view and I do not > have any obligations to change my mind but I can clarify my thoughts. > > You have asked if I am a windows user and the answer is that I do use > windows and I find it a very nice piece of software. Dear Eliezer. I don't *need* to ask you whenever you're using Windows or not. E-mail headers 'User-Agent' and 'Content-Type' from your e-mails leave me absolutely no doubt about you use Windows. Also I must apologize in advance if I mistook your last name for the first one. No offense meant. > But I will need to clarify couple things since I am almost sure you > misinterpreted what I was writing. > > There are couple things to consider with software. > Like any other job the programmers need money and software authors are > not obligated to publish their work to be available to all humanity(or > at-least these parts of humanity that are connected to the WWW). True. To reduce free software concept to the availability of the source code is gross oversimplification (and misses the point almost completely btw), but we'll leave it here for a moment. > The above is something I think is right and it is right especially for > security and health related software. False. Please take your time to research 'Bugtraq' and 'Full-Disclosure' maillists to observe the falsehood of this statement. Security by obscurity never works, and to promote such point of view means to deny the truth. > As opposed to what some think that software should be available for all > I am on the side which thinks that secrecy or confidentiality is a value > which is either required or wanted by people. Here you've got it all wrong. You do not attach 'confidentiality' (let along 'secrecy') labels to the software itself. You need to attach said labels to the data which the software in question deals with. > So the above doesn't implies that anyone should use any software. And > also in any case of software usage there is a great need to consider the > pros and cos and to see if it matches the requirements and needs. > I am not writing and talking about debian specifically since this is not > the question(at-least from my side of the glass). > > If some vendors supply compiled software that was audited by their > programmers, QA team and security personnel it is OK for me. ... And in real life that's not enough at all. Internal security audit is a must, I agree. But unless the software in question is only used internally by completely trusted personel - good, secure software should be audited externally. Inability to access the source code of said software is a serious disadvantage in such a case. Inability to *change* the source of said software equals inability to use security-fixed software for large amounts of time (can be sometimes remedied with assorted klugdes, true). Inability to *deploy* the changed software (aka tivoized software) means the same. > If I pay for the software then it's fine from my side to get a packaged > product. Ok. No arguments here. Note that free software does not equals zero cost or lack of said 'packaged product'. Case study - Red Hat. > I had a talk with a friend about the dangerous things on the Internet > and the conclusion was that some might not understand that the Internet > is just a "reflection" of the real world and there is no magic there. > The same crooks can be found both in the real world and the Internet. Ok. No arguments here too. > In a case that a software vendor is suspected to be violating basic > security requirements intentionally it would black list the name brand > and the software. False. There are numerous examples of the contrary. Starting with the Microsoft, but not ending here. > If we are talking about a complex piece of software then it is possible > that flaws do exist and it is also applies to any Linux and open source > software the same way(statistically) as non open source. Oh, do I see 'They are bad too' argument here, right? > Since I do have some experience with health care related programming > subjects and I do also have couple medical facilities that runs a > software with critical code I wrote and designed I can give a scenario. > When a sysadmin decides on what software to use for these mission > critical human life related systems he needs to fully understand the > weight of using software(open source and non open source, free or non-free). > He needs to be able to run a command such as "apt-get install squid" > without any fear that human life's would be affected by it. > It means that he will have someone that he can trust to test it > externally and verify it fits the purpose or that the software was > tested enough by the developers and by the distribution team. > Free and non Free, open source or non open source is not the question at > all in this case. False. See above. > For some, when looking at a non-free software in banking or health care > the question is not if it is more dangerous since the main question and > almost only question is "is this piece of software fit for this role I > requrie?" and it contains kind of "recursively" security and operations > sides. That only means that said 'some' are unfit to do their role. > The only dangerous software is a "dangerous" software! > The definition of dangerous is not by free or non free, open source or > none open source. > It's a subject by itself that requires a new definition in any software > adoption steps. > Would a bug in exim, a fatal one, makes exim a dangerous piece of > software? The answer is that in some cases it would indeed do that but > in other cases it would be dangerous the same way as postfix or MS exchange. By itself - no, such bug does not make exim bad or good. The amount of such bugs for period of time, the amount of time which took fix said bugs, and last, but not least - the ability to check software for a similar bugs, and correctness of the fix - these things do make the software good or bad. And (see above) - free software clearly wins here. With some inevitable exceptions sadly (PHP anyone?). As for that parody for MTA called Exchange - no sane human being should use that human-powered blackbox. As a side note - you clearly did the right thing by choosing Postfix :) > You can have arguments about a specific vendor\provider\programmer > software or a repository based on it's characteristics and statistically > it might fit debian non-free repo but it cannot make all non-free > software out-there to be dangerous and it's not an argument from debian > non-free to other software or from other software to debian non-free. On the contrary - it can. Every time a person installs (or gets installed, it's no different here) a non-free software - a person inevitably lowers overall security of installation. And it brings a certain amount of suffering, the way it should. > A part of the health care facility sysadmin duties is to make sure that > he can maintain the software or at-least to make sure that there are > out-there developers, testers and others who can answer the facility > requirements. Hint one. Here it's considered *very rude* to imply that all sysadmins are male only. Political correctness and stuff ;) Hint two. By such statement you imply that sysadmin in question should willingly give up the control of administered software, just because. A controversial point of view, to say the least. > The above is one of the main reasons that many sysadmins prefer to use > RedHat and Windows despite the fact that both companies cannot always be > aware of very critical bugs. Oh. Now you put the Red Hat Enterprise Linux in the non-free category. May I ask why you did so? > This is not what makes these companies and their software dangerous. > > If you do feel that this is what makes software dangerous indeed it's an > argument but it might not meet reality or reality requirements in many > facilities. > > Then, what do you mean by dangerous? it was not really clear from your > words. Lack of control is dangerous. Undeclared capabilities of the software are dangerous. Unknown quality of code (without the ability to evaluate it at least) is dangerous. Reco
