I see I need to be more explicit...
- Dealing with concurrency correctly is hard. Lifting it to the language level makes it easier to handle.
- Dealing with security correctly is hard. Lifting it to the language level makes it easier to handle.
I must be missing your point. I keep hearing the mantra "Security is a Process". Well coping with security in the language domain makes our "process" more explicit and enforces our policies so we can't violate them willy-nilly. I just don't understand the reluctance to even consider enhancing security through the language. Is it mostly because it is a new some-what foreign idea? When I see Theo de Raadt lamenting...
It was so subtle, that type of bug, that we realized that this was no longer an API-type of programmer mistake, but that people don’t actually understand the C programming language, or even basic arithmetic with restricted-size variables.
This integer overflow thing is really scary because as programmers, we really can’t spot them; we can read the code, and they’ll just go right over our heads. We can’t even spot them, even if we know what we’re doing.
I think to myself, "Ah, another way our languages help defeat security". Same goes for 99% of all security breaches. Could have been avoided or rendered harmless by using better languages. Its one thing to put up with crappy languages in the present. But why do we insist on punshing ourselves forever by not exploring greener pastures? Sigh.
| [reply] |
I said, at the very beginning of this discussion, that language features can most certainly help with security. I pointed to automatic memory management as making buffer overflows a thing of the past.
The point I'm attempting to make is that you seem to be touting language features as the next step. That isn't the next step. We have language features in Perl for nearly every security hole out there. SQL Injection? DBI placeholders. XSS? Taint. And on and on. The problem is that they go unused.
Do you know the easiest way to break into a computer system? Just ask the person you want to break in as for their password. It's a 50-50 chance that they'll just give it to you if you pose as someone from the helpdesk. This goes for every single person in a company, CEO and CTO down. (Yes, CTO's have been caught by this, too.)
Do you know the most common source of corporate breakins? Disgruntled ex-employees.
Do you know the most common source of security holes in Perl CGI scripts? SQL injection and XSS, both of which have been solved by language features for years.
Except, you cannot force people to use placeholders for all variable substitution because of:
my $sql = <<"__END_SQL__";
SELECT $obj->{name_col} AS name
,$obj->{val_col} AS value
FROM $obj->{table_name}
WHERE $obj->{id_col} = ?
__END_SQL__
Did I expose myself to a SQL injection? Can you prove either side? I couldn't, yet that kind of SQL is correctly all the time.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply]
[d/l] |
I guess we will have to agree to disagree. But in the interest of finding common ground, I think we can all agree that using strings as a lowest common denominator is vastly inferior to using a proper data structure. (oh, and just to clarify, I don't want these language features because I think the dullards out there need training wheels. I want better languages so that *I* can use them)
| [reply] |