DSUtils and BinPBO

[Doolittle 0]

Now that DSUtils and BinPBO are out, let's get the addon makers to sign their work and completely lock up these servers!! Is this possible now? Please report! Do Addon Signatures work with 1.08? What is your server.cfg?

Doolittle

[rundll.exe 12]

It works, but the changelog for 1.09 states a bugfix regarding slow addon checking. So I dont know. (anyone does/tried?)

Anyway It cant harm the addon makers to create their private key, and re-release their (quality) stuff.

All addonmakers should read this: http://community.bistudio.com/wiki/ArmA:_Addon_Signatures carefully.

Now is the time to tidy up the addon stuff, properly tag it and supply your key with it. Fix the few lastt bugs if any, and send them to the hosters.

Another good thing is: Addons that are not MP compatible, or unit replacement mods should not sign their addons, so ppl can not use them online by accident.

[Messiah 2]

reading the wiki, it sounds rather promising

*wanders off to create his own signature*

[BLSmith2112 0]

It'd be nice for an official "pack" that included all of the editing tools + addon signatures.

This way addon makers wont overlook the fact that theres a signature tool out there.

Im sure the serious addon makers will know but I mean the casual addon makers who don't usually check recent events and forums.

[cross 1]

how to guide for dummies by jerryhopper..we're back in business now..

http://www.flashpoint1985.com/cgi-bin....t=68429

[opteryx 1562]

Should terrain makers bother with this?

[cross 1]

Applies for any addon ending with .pbo...

If your addon is MP oriented and if the servers are using verifysignatures and onUnsignedData, you need to create your signature and issue the public key so that servers can put this file in their keys directory and allow the mentioned addon to operate on their servers.

If it is SP oriented there won't be a need for signature...

PS..-off topic- the signature check can be slow at times and can give "session lost" error but it generally happens when you dl the map and you can reconnect much easier once the map is in your temp folder...receiving map seems to create a time out when server is a bit loaded..

addon makers pls update your existing threads giving an update date info so that we know it is really you..

[.kju 3241]

If it is strictly SP only there won't be a need for signature...

[hoot 0]

But what is meant by saying strictly SP? I mean is anyone remembering the good old DynamicRange soundmod for Flashpoint what was considered to be a cheat the first months due to the fact, that the player who has it loaded could and can hear tanks ten kilometres away, while in standard Flashpoint you would normally hear the tank when it stands next to you or you put the volume to a max. It was definitively a clientside addon, whereas the anim mods like the one from Locke are not.

If a player joined a server that has not installed such a anim mod, and is let's say leaning around a corner, the whole server crashes because it cannot handle such movements without having the same addon installed.

So how to identify which addons are clientside only and which are not? XAM i.e is imho clientside as well, but we don't want to have someone playing with it, cause it behaves on slow machines like the graphical enhancements for Flashpoint with columns of smoke that reach the sky and therefore slow down the overall performance of a weak client, what then often results in desyncs and lagparties.

Can anyone explain me the difference? Currently i would ask all modders to better sign their addons.

[cross 1]

It is hard to explain...

I think any addon maker should sign their addon if they think will be used in MP servers at some point.

Servers cant have 1000s of signatures but will have the most respected and value adding ones on..

One doesn't need to signature or anything to use a mod in SP..

[Maddmatt 1]

But what is meant by saying strictly SP? I mean is anyone remembering the good old DynamicRange soundmod for Flashpoint what was considered to be a cheat the first months due to the fact, that the player who has it loaded could and can hear tanks ten kilometres away, while in standard Flashpoint you would normally hear the tank when it stands next to you or you put the volume to a max. It was definitively a clientside addon, whereas the anim mods like the one from Locke are not.

If a player joined a server that has not installed such a anim mod, and is let's say leaning around a corner, the whole server crashes because it cannot handle such movements without having the same addon installed.

So how to identify which addons are clientside only and which are not? XAM i.e is imho clientside as well, but we don't want to have someone playing with it, cause it behaves on slow machines like the graphical enhancements for Flashpoint with columns of smoke that reach the sky and therefore slow down the overall performance of a weak client, what then often results in desyncs and lagparties.

Can anyone explain me the difference? Currently i would ask all modders to better sign their addons.

That is why an addon should not immediately be signed. It should be signed only a while after release and people have had the chance to comment on it. Server owners also need to decide which signatures they trust.

A mod such as XAM should be signed once there is no cheat possibility (not saying there is, I don't know), and only servers using XAM should allow it because of the effects it has on non-XAM servers.

I'll consider signing my mod, if servers want to allow it.

[cross 1]

It's up to the servers to decide which addon/mod to allow or not.

Server admin/owner can allow certain mods to be run on the server and offer signature files to their members and/or visitors (no matter if the addon maker signs it or not)

Best practice is to use the universal signature and .bikey provided by the addon maker.

[hoot 0]

Why not signing it immediately? I mean just generate the keys and release it with the mods. The admins of the server would then however put the keys to the server or not, so if anyone is connecting with let's say the XAM mod and there is no key present on the server, a kick will follow.

I guess it behaves like the 'equalmod' setting already known from Flashpoint and still available in ArmA and can be used a similar way, but is based on a more reliable principle -> signatures.

Or am i completly wrong here?

[Maddmatt 1]

Why not signing it immediately?...

Because the mod should be tested properly first. What if you sign a mod and realise it has a bug such as causing weapons to have no recoil? Or people find an exploit that can be used as a cheat? An addon should meet certain standards before it is signed.

Of course you could create a new key if you accidentally signed a cheat or something. But it's still something you would want to avoid.

I have already asked for comments in my mod's thread about signing it, just to make sure there are no problems.

[hoot 0]

Roger, you mean QA. But that of course should happen before the mod or addon is released in a final state, what requires proper testing beforehand

Concerning the mass of betas around you're right.

[suma 8]

I have somewhat updated http://community.bistudio.com/wiki/ArmA:_Addon_Signatures to address some concerns and questions raised hear.

Feel free to discuss it here or to improve it straight in the Wiki - this is what Wiki-s are for.

[jerryhopper 285]

Should terrain makers bother with this?

Yes you should!

This will release the serveradmins from having unsecured servers.

My server, 'Jerry Hoppers Hideout' runs with Signature verification on.

It means that only with the ORIGINAL files ( or signed addons ) you can enter the server.

Opterix, Lets say : your 'tag' is 'OPTX'

you create a priv and pub-key for that tag.

With that private key, you sign your island, and redistribute the two essential files.

island.pbo

island.bisign

the Public key, you put on your homepage - or public key repository.

Now lets say, i - as a server owner- like your addons. you make good stuff, no nonsense.

i will install the public key in the servers /keys/ directory.

Next, i download your 'signed' island put in the addons directory of the server, and start the server.

Every CLIENT that connects, HAS to have the exact addon as the server has installed.

The only thing you should do now, is sign your PBO's from this point on.

I wonder who the first 'signed' pbo brings... ( one that matters actually )

[.kju 3241]

@Hoot:

I said "there is no need".

I didn't say he should not. Actually i agree that every addon

should be signed.

---

Like stated here. It is up to the server admin to decide whether

to allow the key file / an addon or not (see my detailed explanations below).

It doesn't matter if an addon can be consider a cheat or not.

It should be signed all the time.

With not using the key file the server admin can disallow it.

On the other hand you cannot force users to have an addon

via the signature system. It has to be done via "requiredAddons"

on the mission side.

See my detailed explanations below why every addon should

be signed with a different key most likely.

If this will be done, there will be no need for a test phase of

an addon. Server admins can just not allow (disallow) the

specific version of the addon.

---

@Hoot

What will happen, if an addon is not signed / no key file available

for it on the server / or it has been modified etc is up to the

server's settings via server side scripting.

---

from another topic.. its better suited here anyway..

--

The signature system is meant actually quite different (as far

as my understanding goes of course).

Every addon which can be used in MP should have a public

signature from the original author.

The key file should be bundled to the addon (in the download /

zipped file) itself or only be available on trusted sites (gathering

CRC sums for signatures would be a good idea IMHO to verify

the authenticity of the signature file. Maybe OFPEC would be a

good place for gathering those).

Now with the signature file every server admin can dedice

whether he wants to explizitly allow the addon/every file signed

with the given key on his server (by putting the key on his

server) or not (by not doing it).

Via server side scripting one should be able to do additional

logic on unsigned data, like "if addon name == xyz, no action,

else kick user" etc.

(onUnsignedData - params: user id, file name)

---

So from my understanding a few thoughts:

1) If an addon maker signs his xxx different addons with the

same key, they can be allowed and disallowed only as a whole.

So it seems better to have one key pair for every addon.

2) Once you update an addon, you could just use the original

private key to sign it again. However this sounds like a bad idea

to me. If you sign the addon with a new key, a server admin

could disallow (= not allow // not having the key file on the

server) outdated versions of an addon and allow only the latest

version of the addon.

3) Even server admins could sign addons for themselves for their

server and only allow their modded/signed version on their

server.

This doesn't seem like good practice, but should be possible

nevertheless.

Could be a good option to private groups in certain rare cases.

4) Based on the patching topic a nice addition to the system

would be a disallowKey folder on the server, where an admin

could move the outdated keys of outdated addons.

By this one could handle any addon specificly. Otherwise for now

the system works on not putting the key file on the server and

disallow every unsigned addon or use server side scripting for

that (if its possible at all). So this idea would help to manage

outdated and unwanted _signed_ addons very much!

reference:

http://community.bistudio.com/wiki/ArmA:_Server_Side_Scripting

http://community.bistudio.com/wiki/ArmA:_Addon_Signatures

PS: We haven't done testing on this yet. So this is just

assumtion on my side based on the info available.

No guarantee on my statements though!

Sorry for any unlogical or bad thinking on my side.

PSS: Certain aspects of best cheat protection and handling is

still to be developed.

[hoot 0]

Thanks a lot Q for that hefty explanation!

Referring to your thoughts:

1st and 2nd: I do absolutely agree here, enclosure is always good practise.

3rd: ...but sounds fine for some squad related stuff.

4th. You mean a combined black- and whitelisting? I would second that. But i fear that's a part of ArmA2 because of the calculation of effort and benefits for BI and ArmA

Edit: I am a noob in scripting the BI scripting engine, but went recently to the wiki and landed on the page that is describing serverside scripting. Although i know what eventhandlers are and stuff i asked myself whether or not it is possible to not only kick or ban a fellow soldier, but also to send him the message why he has been kicked, or, to carry it to the extremes, to send a more detailed one like this or that addon is not allowed here.

I am asking it because the wiki says:

Quote[/b] ]The scripting language shares the core (overall structure and syntax, arithmetic operations, control structures) with the scripting used in the game. The are a few commands specific to Server Side Scripting:

What would mean to me:

- same syntax

- +-/* and equivalence mul, pow, add whatever

- if, switch, while-do, do-while, for and whatever

plus some specific commands for serverside scripting.

Does it actually mean, that sending messages through the chatlines is possible to give customised feedback to a player, as the 'specific' implies? I.E the counterpart to sprintf(); in the BI scripting language

Edit: Well i know its possible to send such texts, i mean relating to server side scripting. But maybe there is a stanard errorbox showing such an error message, like 'session lost' or so.

[suma 8]

The signature should be bundled to the addon (in the download /

zipped file) itself or only be available on trusted sites (gathering

CRC sums for signatures would be a good idea IMHO to verify

the authenticity of the signature file. Maybe OFPEC would be a

good place for gathering those).

No CRC files for signature files are needed. Signatures are verified against the public key which was used to create them, which is the strongest authentication you can get, and there is no need to perform anything weaker on them.

What is important is to properly validate the KEYS - those are the weakest point in the link.

[suma 8]

Quote[/b] ]So it seems better to have one key pair for every addon.

While this is a possible usage scenario, I think the burden this would impose on server admins is too high. See Beta keys for my proposal how to deal with this (and also see my explanation in Create your own keys).

(Ofcourse, what I write are only my proposal - it is up to you what you do on your server, and my role is not to dictate anything here, only to explain best what the tools can do and how. You decide.)

[zyklone 1]

Would it be possible in the future to allow multiple keys to sign the same addon?

The reason I'd like to se that is that we could have 'signing projects'. These would be dedicated to reviewing addons for say multiplayer compatibility.

This would let server owners add only one key to cover multiple addons.

It looks like this could be done already but since only one key is allowed for each addon that'd break once the addon maker releases his key.

[jerryhopper 285]

OFPEC UPDATE!

People who have a OFPEC tag, can host their PUBLIC KEYS there.

Since ofpec has the Tags Database, i added the possibility for Addon groups to add their PUBLIC key there.

OFPEC Tags Database:

http://www.ofpec.com/index.php?option=com_tags&task=info

regards,

Jerry

[suma 8]

Would it be possible in the future to allow multiple keys to sign the same addon?

You already can. This is fully supported, and even some usage scenarios for this described on the docs. page Ihavealreadylinkedtomanytimes/andIamtoolazytosearchfortheURLnow.

[Junker 0]

Ihavealreadylinkedtomanytimes/andIamtoolazytosearchfortheURLnow.

broken link :P

good work, this may be the thing to stop all the hacks