Widget White List, Alpha 1

[Argh]

Here's a Whitelist Widget, designed to be put into games (i.e., it's not a player Widget). Basically, it clobbers stuff that's not on the whitelist, then shuts down the Widget Selector so that players can't turn things back on. Stick it into a mod or game.

It's not secure by any means. Don't be fooled- this is "inconvenienceware", not "security software". 7 out of 10 hackers here could get around it in 5 minutes. But hey, it's a start, and will get improved. I had a more... serious... version running, but certain things got changed in 0.78 that broke it. I'll worry about it later.

Code: Select all

function widget:GetInfo()
  return {
	name="Widget White List",
	desc="Widgets that do not match current options are not allowed.",
	author="Argh",
	date="January 9th, 2009",
	license="Public Domain, or the least-restrictive rights in your country of residence",
	layer=0,
	enabled=true,
	handler=true,
	}
end

local WhiteList = {

--WORLDBUILDER STUFF
["Dynamic Blob Shadows"] = 0,
["Streetlamps"] = 0,

--P.U.R.E. STUFF
["Black Box"] = 0,
["Brief O' Matic"] = 0,
["Credits"] = 0,
["Help O' Matic"] = 0,
["Mine Widget"] = 0,
["P.U.R.E. Unit Status Display"] = 0,
["P.U.R.E. Team Display (ALL)"] = 0,
["P.U.R.E. Team Display (SELECTED)"] = 0,
["UI Support"] = 0,
["Select at Start"] = 0,
["Theme"] = 0,
["Tooltip Fixes"] = 0,
["Widget White List"] = 0,

--SPRING NATIVE
["ImmobileBuilder"] = 0,

--ESSENTIAL, DO NOT REMOVE THESE
["Widgets"] = 0,
["WidgetSelector"] = 0,
["Selector"] = 0,
}

local Player = Spring.GetLocalPlayerID()

function widget:GameFrame(f)
	if f == 1 then
	for name,data in pairs(widgetHandler.widgets) do
		if WhiteList[data.whInfo.name] == nil then
			Spring.SendCommands({"luaui disablewidget "..data.whInfo.name})
			Spring.Echo("Removed Widget from Player "..Player..". Widget Disabled: "..data.whInfo.name)		
		end
	end
		Spring.SendCommands({
		"unbindkeyset f11",
		"unbindkeyset  ctrl+f11",
		"bind f11 luaui unitstatus",
		})
	end
end

function widget:Shutdown()
		Spring.SendCommands({"bind f11 luaui WidgetSelector"})
end

[thesleepless]

hmm wouldn't a better way be to modify the engine to not read .spring/LuaUI/Widgets and only the Widgets from the mod archive?

[Argh]

Well, yes. And if a switch was available to do that, and it was that simple... that's what I'd do.

[el_matarife]

Well, I have no idea if Spring's hashing algorithm is at all cryptographically secure, but if it was you could just specify permitted filenames and specify a hash for that file. Apparently you can't get Spring file hashes from Lua yet?

Edit: Spring uses CRC32 which is not really cryptographically secure.

Also, Aegis pointed out faking sync was easy. If you can fake sync, you can just hack the modfile to either disable this whitelist or the flag that says "hey only read Lua widgets from the modfile" or even add the banned Lua widget to the modfile itself.

[BeefofAges]

It seems to me that trying to constrain the widgets people can use is just a bad idea.

[thesleepless]

It seems to me that trying to constrain the widgets people can use is just a bad idea.

+1

[el_matarife]

Beef is probably right. You'd essentially be starting a war on your users that you literally can't win in an open source game since there's no realistic way to prevent tampering.

[Peet]

Aside from that...I personally am not fond of the concept of constraining features of the engine. From a player's perspective, a lua whitelist is similar to a game developer's perspective on engine-side disabling of, say, s3o models.

[lurker]

Well, yes. And if a switch was available to do that, and it was that simple... that's what I'd do.

* lockluaui
* change most includes and loadfiles in luaui.lua, main.lua, and widgets.lua to all be VFS.ZIPONLY, and turn off the vfs.raw dirlist

It's a lot cleaner than shutting off the widgets after they have already loaded, and you have to really go out of your way to bypass it.

[KDR_11k]

Yeah, whitelists don't make sense anyway, just include all you want to allow and lock everything else out, that way everyone has the widgets that are allowed and you can't just e.g. have a modified version of an allowed widget that does something else (e.g. renaming the autoskirmish into advanced player list).

Me, I'm more interested in a widget blacklist that would disable the listed widgets so you can set it to remove ones that fail to work with the mod or interfere otherwise (e.g. defense range in THIS would be silly because there is no static defense but the selector icons overlay the buildbar and immobile uilders tends to break a lot as well).

[Argh]

I'm more interested in a widget blacklist

Just reverse the logic of this application, it works both ways

[Pxtl]

Beef is probably right. You'd essentially be starting a war on your users that you literally can't win in an open source game since there's no realistic way to prevent tampering.

In fact, a cheater in Spring could maphack trivially with a source mod. Not to mention various AI tricks he could do.

However, this widget whitelist is good for cases where most of the widgets players are running are totally inappropriate for the game that our modder has designed. In that case, disabling a bunch of things that will at best clutter a UI that isn't designed for them and at worst crash the Lua system, it's a good idea.

However, for that purpose I wouldn't use a whitelist but a tagging convention for the widgets - any widget that includes a member called "pure-friendly" could be used by Pure, for example.

[smoth]

However, this widget whitelist is good for cases where most of the widgets players are running are totally inappropriate for the game that our modder has designed. In that case, disabling a bunch of things that will at best clutter a UI that isn't designed for them and at worst crash the Lua system, it's a good idea.

I have widgets break gundam other widgets make no sense with the econ or even others will cause undesirable effects. The other projects are not TA Skins, they have their own rules and functionality that can be entirely divergent from ta things. I would rather do what kdr suggest or even re-write widgets just to prevent users inadvertently breaking the game.

[lurker]

I've always felt tagging was the way to go.

[zwzsg]

No widget maker will ever check his widget compatilibity with every other mod.

However most "big mod" makers have to check that there isn't any popular widget breaking their mod.

So tags in widget won't ever work.

[Pxtl]

No widget maker will ever check his widget compatilibity with every other mod.

However most "big mod" makers have to check that there isn't any popular widget breaking their mod.

So tags in widget won't ever work.

Why not? Widget maker doesn't care to test his widget with Gundam, so he doesn't include the "Gundam" tag on his widget. Gundam's widget-tag-checker gadget looks for the "Gundam" tag, doesn't find it, and knows that the widget wasn't designed with Gundam support in mind.

Widget fails.

Now, 99% of widgets won't include the Gundam tag, and so they won't work with Gundam, even though they theoretically could. However, I'm sure Smoth would rather play on the safe side, and keep these un-tested widgets blocked. Smoth can then either release a pack of Gundam-tested widgets (with the tag added), or otherwise harass the developers of compatible widgets to add his tag.

Either way, the modders obviously want to err on the side of caution with widgets, considering that they live outside of the BA universe that the widgets are designed for. Tagging allows them to do that - I doubt anybody would *lie* about their widget's support for Gundam.

See?

Personally, I think this is a much more sensible approach than a whitelist - a whitelist is an invitation to be hacked, and creates an arms race. This, on the other hand, is a polite request.

Thinking it over, both is best. If a modder tests that a widget is supported by his mod, he includes it in the whitelist. If a widgeteer tests that a mod is supported by his widget, he gives it the mod tag. That way either side can say "yes, I am designed to work with that".

[KDR_11k]

I think the widgets that work vastly outnumber those that don't and just keeping a kill list at hand would be sufficient.

[SpikedHelmet]

Or simply a disclaimer: "Any widgets not included with this mod are not guaranteed to work. Use external widgets at your own risk."

[lurker]

But that includes widgets bundled with spring that can interfere.