Symphonious

Brad comments on my condemnation of root login being enabled in the default SSH config for Debian systems (noting again that SSH is disabled by default).

Debian’s SSH package explicitly asks if you want to run the ssh daemon, and by choosing to do so, you take a certain level of responsibility into your hands.

Granted - Sandra acknowledged this and I acknowledged this.

I don’t agree that its the software’s fault more than the users - as a maintainer you make some assumptions, some of which will not match the users requirements, and its up to the end user to ensure that it meets their needs.

The assumptions should always err on the side of security. It is trivial for a user to turn something on if they discover it is missing - it is effectively impossible for them to (knowingly) turn something off if they don’t realize it’s turned on. Microsoft is very often criticized for leaving unneeded services on by default and not being configured securely by default - Linux should receive the same criticism when it falls into the same trap.

These assumptions are very clearly documented in the README.Debian file that’s distributed with the package, and by the wording the maintainer has had some fairly lengthy conversations with people about it and feels quite strongly about it. He also quite clearly explains how to change this if you disagree with his choice, including paths to these supposed “arcane config files” and the exact line to change and how to do it.

None of which is displayed in the installation. There are 8710 packages in the Debian distribution, hundreds of which would be installed to make a working system. It is unreasonable to expect a user to read every single README.Debian file that results from installing all those packages.

There are often reasons to do so - perhaps the machines are being used in a secure location, perhaps they’re tightly locked down via ssh keys and hosts, there are plenty of situations where people may wish to login as root. You can never say never about a configuration setting, there will always be someone to point out where it is entirely sensible to do so.

None of these reasons justify making root logins enabled by default as in the most common situation for the software it is insecure and unnecessary. I did not suggest that the configuration setting would never be useful, merely that it should never default to on.

Because you’re being paid to fix the customer’s problem in the first place, and not necessarily in the second with open source software. A lot of open source software is done by someone with an itch to scratch - Debian certainly falls into this situation - and they may not take the time to consider each and every situation that the software may be used in.

I would take this to suggest that open source software is necessarily inferior and should not be depended upon because it’s “done by someone with an itch to scratch”. That is definitely not my view of open source software, nor is it something I would like to have reflected upon the small amount of open source work I have had occasion to perform. The open source community has been struggling to dispel such myths for some time and is beginning to see some great successes as it gains mainstream acceptance. Lowering the standards because something is free completely defeats this effort and drastically reduces the value of open source software. What’s worse however is that it detracts from the talents, commitment and achievement of those who contribute to open source projects.

I refuse to make excuses for the software I develop - if something is poor quality for whatever reason I’m the first to admit it. It is through acknowledging the problems that improvements are made and it is through holding your work to a higher standard than any other work that you achieve great things.

Fewer excuses, higher quality software.

With the real planet humbug down, I’m only occasionally checking the temporary planet humbug since it’s not coming through my RSS feeds at the moment. While I wasn’t looking, there seems to have been a little bit of a stink kicked up about Linux’s security.

The story as far as I can tell seems to be that Sandra Mansell had her Debian router compromised because the root password was a dictionary word, ssh was available to the world and root logins were allowed. She took responsibility for the compromise pointing out that it was “lazy” (I would have said careless or possibly even crazy) to use a dictionary word as the root password and then complained that Debian’s default settings were to allow root logins over SSH.

Brad Mashall and Greg Black then provided some useful advice on setting up SSH and security in general. However, from both posts (particularly Brad’s) I got the impression that this was entirely the users fault. I’d very strongly disagree with that. Was the user at fault? Absolutely, and Sandra acknowledged that. Was the software more at fault? Absolutely.

It is very common knowledge that allowing root logins via ssh is an unsafe practice and should be avoided. It’s completely inexcusable for the Debian developers to have root logins enabled by default and even worse that it (apparently) doesn’t even display a warning about this. It is simply not good enough for an OS to ship with insecure settings and expect ordinary users to perform a full security audit and know all about arcane config files to make their system secure. The OS installer should always make the system as secure as possible given the features the users have indicated they need. Specifically, the installer should have disabled SSH by default (I think it did) then when told that SSH was required, it should have left root logins disabled. Better yet, it could have asked which accounts were required, from which networks and hosts and whether or not it could generate a key pair to be used for authentication and disable password authentication.

All of that however does make the installation more complex so there’s a balance to be reached, but since there’s almost never a reason to allow remote root logins I’d be quite prepared to criticize the developer responsible for that configuration being the default. I’d then set about making sure that the users understands where they went wrong and how to avoid similar problems in the future (most likely by pointing them at Brad and Greg’s comments, which I definitely suggest you read).

Why is it that in commerce the customer’s always right but in software the user’s always wrong?

Byron continues on the ampersand issue:

I’m not going to accept your argument that it’s not harmful to produce invalid HTML. What would your code produce for:

http://example.com/entities.cgi?entity=&

The requirements are that it should produce exactly that since that will work in all known browsers and would break in all known browsers if the ampersand wasn’t escaped. Since I didn’t personally write the code I can’t be certain that it does output that, but that’s what it should do. It should output whatever it is that makes things the most compatible so our users are the most happy.

I seem to recall someone or something in this discussion mentioned using a character other than ampersand entirely. If the links you’re producing are for programs within your control, it may be appropriate to use semi-colons, not ampersands. Of course, this approach will often be impractical or impossible.

Impractical, impossible and highly incompatible. There are a vast number of pre-existing frameworks that assume GET parameters are of the form name=value&name2=value2. Using anything but an ampersand would break all those frameworks and existing libraries. Besides, as an HTML editor we don’t get to decide what the link should be - the user does.

There are some other questions I’d like to see you answer. Is it OK to use ampersands incorrectly in an XML document because one particular parser isn’t conformant to the standard?

No, this would greatly decrease the compatibility with real world situations and make life more difficult for our users, thus it would be unacceptable. Were it the case that all known XML parsers handled an unescaped ampersand but one didn’t correctly handle an escaped ampersand then my answer would be different. The technology is irrelevant here, the answer is always to do what best meets the user’s requirements.

Is it OK to expect every parser to let you violate the XML standard to support bugs in others?

Yes. Any HTML parser which can’t handle unescaped ampersands in a document is not going to particularly useful unless all the HTML documents have been previously cleaned with something like Tidy. The state of the real world is that unescaped ampersands is the least of the problems an HTML parser is expected to deal with - incorrectly nested tags are much more difficult to deal with but most parsers still get them right.

I am facing the exact problem under discussion right now: a piece of HTML I wish to parse misuses ampersands. The library I am using does not tolerate malformed attribute values. Do you consider this a bug in the library I am using?

That depends. If the library claims to be able to parse only fully validating HTML then I would call it a critical limitation but not a bug. The parser would still be useful for parsing documents that have someone been confirmed to be completely valid (ie: a help function in a program that uses HTML as its help pages). If however the library claimed to be able to parse HTML I would definitely consider it a bug. The most common use of the term “HTML” refers to documents that vaguely comply with the HTML standard (but rarely a fully conforming) so I would expect any parser that claimed to parse HTML to handle these malformed documents. Where you draw the line at how messed up the document can be will entirely depend on your requirements.

Personally, I do not consider it a bug in the library, since it parses HTML just fine. A document with a raw ampersand in an attribute value is not, strictly (or pedantically) speaking, HTML.

Bug or not, it’s failing to meet your requirements and causing your program to fail. That is a bad thing and if you have real world users they should (and most likely will) expect you to fix it.

It is worth noting that if people wanted the HTML they took in to be highly compliant and simple to parse, they should use XHTML as it not only makes parsing easier (can be done with any XML parser given the right DTD) and XHTML documents tend to conform to the standard much more regularly than HTML documents do (and browsers generally have a separate mode for XHTML which expects the documents to be well-formed so the browser behavior is more predictable).

When all is said and done the point of software is to get a job done, not to comply with standards. If the software accomplishes its job and the users are happy that’s all that really matters. Life happens in the real world, users pay money for real world results, expecting HTML to be well formed is a pipe dream.