User: Password:
|
|
Subscribe / Log in / New account

SQL injection vulnerabilities in PostgreSQL

SQL injection vulnerabilities in PostgreSQL

Posted Jun 1, 2006 8:15 UTC (Thu) by nim-nim (subscriber, #34454)
Parent article: SQL injection vulnerabilities in PostgreSQL

Both of these problems would have been avoided if there was a development culture where i18n is not an afterthought and software writers validated their code with something else that english ASCII.

The year-2000 bug was a joke, the we've-developped-in-english-ascii-then-turned-i18n-on bug will continue striking for years.

And the worst part people are writing code *today* which assumes one char=one byte, and language=english. Even with a clear example of the consequences of this attitude your article manages to completely skip over this aspect.

i18n is *not* a translator problem.

(Another example of the way our software culture is profoundly conservative is the way GUI writers still think in terms of pixels and 75/96 dpi screens, while Dell and friends are maddly shipping whidescreen LCDs.)


(Log in to post comments)

afterthought i18n and the conservative software culture

Posted Jun 1, 2006 17:43 UTC (Thu) by rfunk (subscriber, #4054) [Link]

The problem is that the vast majority of Americans don't deal with
anything but English (and Anglicized spellings) in their everyday lives,
so i18n truly is an afterthought. Worse, most of them can't read or
write any other languages either.

As for a conservative software culture, part of it is developers who
don't (have time to?) keep up with current issues, but there's also a
strong culture of backward-compatibility. Enough people have old stuff
that developing for the latest and greatest isn't necessarily a good
idea. The trick is to be able to develop for both old and new at once,
and that's often difficult (requiring even more learning than for just
the new) or impossible.

afterthought i18n and the conservative software culture

Posted Jun 1, 2006 18:21 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

So what ? You don't need to speak other langages to make the effort to learn and understand their technical requirements. Developpers have their software interact with hardware and software with much stranger and complex needs.

The problem is 100% cultural, and I don't mean cultural in the sense americans don't speak other langages, I mean cultural in the sense the software community collectively decided not to tackle some problems. The nationality of the software writer matters very little - they all code from the same textbooks which all present computers as manipulating strings of mono-byte characters. Likewise GUI writers all use the same reference material which assumes screen pixel density is a known stable variable. (Of course the fact a lot of these textbooks are written by people immersed in the american english-only worldview does not help.)

afterthought i18n and the conservative software culture

Posted Jun 2, 2006 21:16 UTC (Fri) by tjc (guest, #137) [Link]

The problem is 100% cultural, and I don't mean cultural in the sense americans don't speak other langages, I mean cultural in the sense the software community collectively decided not to tackle some problems.
It's mostly a motivation problem. The people to whom it matters most are apparently not motivated enough, or insufficient in number, to do something about it. The reason that most free/open source software only supports the ISO-Latin-1 character set is because that's what most developer's use themselves.

Just wanting to be PC isn't very motivating for most people. The same goes for listening to other people bitch about what one ought to be doing with one's free time.

afterthought i18n and the conservative software culture

Posted Jun 3, 2006 8:50 UTC (Sat) by nim-nim (subscriber, #34454) [Link]

> Just wanting to be PC isn't very motivating for most people.

I don't see where the PC angle is when it ends up in security bugs (and this is not an isolated case). You're just confirming what I wrote.

afterthought i18n and the conservative software culture

Posted Jun 3, 2006 15:59 UTC (Sat) by tjc (guest, #137) [Link]

Yeah, you're right about the security aspect.

I was referring to the big political war that has dogged Unicode. It got ugly. It probably still is, but I don't seem to care anymore.

SQL injection vulnerabilities in PostgreSQL

Posted Jun 2, 2006 0:41 UTC (Fri) by dlang (subscriber, #313) [Link]

frankly I want software that doesn't require i18n to be turned on. processing multi-byte characters is slower then processing single byte characters (for a number of reasons). I don't want to pay that overhead for systems that don't need it (and face it, most systems really don't need it, that's why the world survived with ascii for so long)

as for the gui folks, it's not the pixles that are the issue, but the assumption that the gui software has the right to take the entire screen. if they didn't assume that they had the entire screen then the shape of that screen wouldn't matter

internationalisation

Posted Jun 2, 2006 2:33 UTC (Fri) by xoddam (subscriber, #2322) [Link]

> frankly I want software that doesn't require i18n to be turned on.

If the software supports internationalisation at all, then 'just ASCII
thanks' is one particular localisation, and there's nothing to switch
off. A little extra optimisation for this case wouldn't be a bad idea
though.

> processing multi-byte characters is slower then processing
> single byte characters (for a number of reasons).

UTF8 helps with this as long as the vast majority of your characters are
in the ASCII range. But UTF8 has its own minor performance headaches,
particularly in Eastern Asian locales where a 16-bit character is much
more convenient.

A significant annoyance and performance issue is when such things as
font-measuring have per-character primitive methods that take a UCS32
parameter, and the string must be expanded repeatedly to its individual
characters (or cached as an array of 32-bit values). Bringing the whole
UTF (8 or 16) string right down to the lowest level might eliminate some
of that overhead.

> that's why the world survived with ascii for so long

The world? For 'so long'? For how long exactly was the *American*
Standard the sole character set encoding in *any* non-English-language
environment? The earliest Japanese derivatives of ASCII began to be
*standardised* in 1969 (JIS C 6220), while the US computing community was
still worrying about converting between ASCII and ECBDIC.

SQL injection vulnerabilities in PostgreSQL

Posted Jun 2, 2006 7:45 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

You would be right but for the internet.

When systems were not interconnected, or the interconnect was slow and limited, local encodings worked fine. Nowadays with dataflows all over the world local-encoding-only systems are the exception not the norm (show me an ascii-only system and I'm almost sure any serious investigation will find users frustrated by its encoding limitations)

And anyway optimising for the ascii case when you end up turning i18n anyway is wrong on so many levels (speed, security) I won't expand on it.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds