Extensions

This topic is about the dlls addons may supply, that a mission or addon may use with the callExtension script command. This command is available from an arma2 post-1.60 beta. Thus the first stable version that will support it is arma2 1.61

(Reportedly this will be available in TakeOnH and Arma3 as well)

For end users

DLLs are natively executed code. It has access to the computer as the user account arma is running as. Anything you can do to the computer (without invoking a UAC prompt, the yellow/blue shield) the dll can do.

Prior to extensions, an addon maker was quite limited in what harm he could cause to the system. About the worst is bad effects to gameplay whenever the addon is loaded - stop loading it and all will again be fine. With extensions, this is no longer quite the case.

Defending against malicious extensions

Establish that the extension writer has reputation on the line. If it's somebody nobody ever heard of, who could just disappear again without a lot of people noticing, then the risk is higher. Even if he were to be exposed, it would happen at no cost to him.

Make sure the sources are provided. Even if you can't read them, someone else can, and there is a reasonable chance someone will find any backdoors. This increases the risk of getting the crimes exposed; see above.

Whoever compiles the sources into a dll can add whatever they want, last minute, in a separate copy from the sources added. You'll be trusting whoever compiles them for you, trustworthy or not. (They can also be tampered with after the dll has been built, but this is harder. Forensics should be able to tell the difference.)

The easy way out is to simply trust the people involved, and take the fall if/when you do get hacked from it. Problem is, you might not know.

Defending against vulnerable extensions

Another concern is when the extension is vulnerable. Security vulnerabilities have plagued a lot of software. An extension may well have buffer overflows and other problems which an attacker can exploit to gain access to your system.

If the sources are available, it's possible to see if the programmer has employed coding practices which decrease the risk of buffer overflows and similar basic bugs. This provides no guarantee, but can inspire confidence. By default, we should assume that such practices are not used: most tutorials, university courses, etc teach the new programmer to do it in the worst possible way. (I'll spare you the rant.)

For server admins

The above concerns wrt the end user is also the case for servers. For any server doing a "persistent world" (*life rpgs come to mind), the above will be even more important.

Your choice will only get more important when your choice of addons will affect what your users need to install. If you require your users to install an addon containing a malicious or vulnerable extension, you're putting your users at risk.

At the time of writing, linux servers do not yet support it - beyond not producing an error for code that uses it.

For mission makers

A few notes in no particular order

• Depending on what that feature is, it may be desirable to make it optional - if the extension is not available, the mission would still work, but without that feature.
• Given that linux servers do not -yet- support this, means these servers will act as if the server does not have the extension installed.
• Using an extension adds a dependency on that extension. At the outset this is no different from a dependency on an addon, except this dependency is never automatically checked unless you're using objects from that addon as well.
• A user may have an addon downloaded, but not have the extension enabled even though it's supposed to come as part of that addon.

Scripting

See callExtension.

For addon makers

TODO. Suggestions? How to make? (List of relevant biki pages?)