Forgot your password?

typodupeerror

Comment: Re:For the love of it? (Score 1) 48

by Korin43 (#40194833) Attached to: Liberated Pixel Cup Art Contest Launches

The one place where free software game development really needs to improve is in realistic business models. I don't actually know of any full games (rather than engines) built on a free software model that are profitable. With business software, you can charge for support, but with games you can't.

It's entirely possible to open source games while still selling them. The trick is that you only make the source available to people who buy the game. The GPL is even set up to handle this -- it only requires you to make source code available to anyone you distribute binaries to. Several Humble Indie Bundle games have done this and it hasn't seemed to hurt them (especially since people have ended up helping them port those same games).

I think the big problem is the phrase "free software", which (to normal people) means "software you give away for free", when what free software advocates really care about is "software you can use without being permanently tied to the author".

Comment: Re:Yes, blame the developers! (Score 1) 135

by Korin43 (#40188277) Attached to: The Cost of Crappy Security In Software Infrastructure

They should be reading some kind of docs before choosing tool / function they use for the job... the more powerful the language the more you need to know.

This is the exact opposite of how normal people describe powerful languages. The most powerful languages let you get the most work done while fighting your language the least. With a language like Java or Python, I can generally *guess* what the correct function to do a task is, and it tends to work (although if you do this in Java, you tend to get the worst possible implentation -- but it will work correctly). In PHP, you need to read the full documentation for every function you call, then Google it to make sure the documentation isn't lying or leaving something important out (like "calling this function will call the interpreter to crash", or "using this function will expose remote execution vulnerabilities").

In your example the developers should be the ones that build the BAD CAR with the exploit in it that was sold, they where not the poor end users that purchased it.

I agree. You might notice that the BAD CAR represent PHP (the thing which I'm saying sucks), and I *do* blame the developers, not users.

Comment: Re:Yes, blame the developers! (Score 1) 135

by Korin43 (#40186935) Attached to: The Cost of Crappy Security In Software Infrastructure

Say someone sells a car where there's three pedals: a gas pedal in the normal place, a brake pedal in an unusual place, a pedal that functions like a brake normally, but swerves into oncoming traffic if you're going over 50 mph. Is it the users fault that suddenly they're all crashing? The manual clearly states, "don't ever use the pedal where the brake pedal used to be, because you might swerve into oncoming traffic". But still, isn't it mainly the manufacturer's fault for including that pedal at all?

Comment: Re:Yes, blame the developers! (Score 3, Interesting) 135

by Korin43 (#40184777) Attached to: The Cost of Crappy Security In Software Infrastructure

- They parse or merge database commands (SQL injection)

I would argue that this one is sometimes the fault of the tool. In most database APIs, there's a function like:


run_sql(String command, Object[] data)

But the language that most amateur programmers use only has:


mysql_query(String command);

Looking at that function signature, who's the know that you're supposed to also use mysql_real_escape_string. Even if you know what you're doing, you might accidentally use addslashes or mysql_escape_string. Or forget it for one parameter.

Interestingly, the language that does this best, is also the second worst language ever invented (after PHP). In ColdFusion, if you do this:

select * from cats where cat_name = '#catname#'

It's perfectly safe, since ColdFusion detects that catname is inside of quotes, so it automatically escapes it. You can still use variables inside of SQL, since it only escapes them when they're inside quotes.

Comment: Re:If microsoft controls the 'keys' (Score 1) 765

by Korin43 (#40181345) Attached to: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions

It'd also need to be resigned and reissued - a massive undertaking, requiring every user by a new motherboard - for every single kernel version.

You can use the same key multiple times. As long as your key isn't compromised, you could theoretically sign all kernel releases for all time with one key. If this were true, Microsoft would have to ship a new motherboard with every Windows update.

You couldn't just sign GRUB - that would render the system pointless, as GRUB can then go on to launch something else. No, you'd have to sign a specially modified build of GRUB that only boots a single kernel.

Yes, the post also mentions that they're going to make some changes to GRUB 2 so that in secure boot mode, modules are disabled and it will only boot signed kernels (using any key loaded in EFI). FTA:

What about grub? We've already switched Fedora 18 over to using grub 2 by default on EFI systems, but it still needs some work before it's ready for secure boot. The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled.

The only two things that motivate me and that matter to me are revenge and guilt. -- Elvis Costello

Working...