CSS - Community sign server

Abstract

To avoid addon abuse in Multiplayer one needs to have the signature system active.

Currently every addon creator is meant to create his key and sign files to be

used by the players and server admins.

Instead an automated system to create the necessary files and provide them

to the players and admins could make everyone's life much easier.

Why?

• Addon makers do sign their addons at times.
  
• The process is complicated and annoying.
  
• One mass download and upload source for end users.
  
• No need to mess with the files. Just press dl all/update.
  
• Only need to add this one additional Modfolder with zillion of bisign files on the client.
  

Basic concept

• There is a server or set of server one can send any pbo to.
  
• The upload process would be best to open to anyone. If abuse is a problem,
  probably restricted ability to a given group of people might be the alternative.
  
• The server automatically looks into his database if the addon was already processed.
  
• If not the server generates a new key file based on the pbo name and signs the pbo with it.
  
• The pbo file is dropped. So this server does NOT act as a pbo download server.
  
• Instead the server ONLY provides the key and sign files.
  
• Now there is a client application to download all sign files in a very simple
  process. That is all for the client. He only needs to sync with the server
  before every game session (in which he wants to use addons).
  
• The server administrators have an access to the CSS to easily filter, select
  and download or sync the key files of their choice with their server.
  

Summary

• Client: Can easily download all sign files for any addon out there (and
  signed by the CSS). As sign files are very small, there is no problem to download thousands or more of em.
  
• Server: Admins have a central place to look for key files and easy access.
  
• Addon creator: There is no longer the need to worry about the sign process.
  Only needs to submit his work to the CSS for every release.
  

Challenges

• The CSS server. The server hardware to host the system.
  
• As sign and key files are very small, the download traffic should be minimal.
  
• The upload interface could be a bottleneck and abuse needs to be ruled out.
  
• The sign process is simple, however it needs CPU power. That said the
  number of PBOs is limited. So mainly spikes in CPU use, not overall huge load.
  
• Group of people to code the upload interface.
  
• Group of people to code the server admin interface to find, filter, select and
  download the key files of choice.
  
• For the client Yoma Addon Sync or Sickboy's git updater are already available.
  
• Group of people to code the backend processing
  
  • filter out already known PBOs via a hash check
    
  • dump the information about known pbos into a DB (hash, name, date, sign and key file)
    
  • interaction to upload interface and admin key file interface
    

Additional thoughts

• Both pbo has and file name could be used to find PBO files at community download sites.
  
• This system does NOT handle the problem of addons needed by a server or
  mission. This is a separate problem. Tools are in development to allow this.
  

FAQ

To be asked first.

Thoughts, feedback and participation in the CSS project is very welcome!

I'd add also on the server CSS the original addonmakers keys, for players who would not use this tool but have keys installed, so that servers are correctly updated

So how should that work - automated upload of key by anyone or a internal team to do

that or just to accept or deny keys?

After all a key by cheater X can make all his modified addons and pbo based cheats available.

Mmhh, in this vein, what prevents a hacker to upload his hacked .pbo for having the key generated by the server itself?

Nothing prevents him. The system works different.

It creates an unique key for each pbo.

So the clients can download all sign files (very small) and update easily. Nothing else to worry for em.

Server admins have a central server to pick keys from.

They still need to verify the pbo is not hostile themselves.

Either by looking at the content, by asking for other expert advice, to compare hash of

the pbo vs official release, by comment system etc.

Possible implementation details

Design wise I think it is wise to start simple and still keep possible extensions in mind to a degree.

Pretext:

A very simple client side app could improve the system in the way to create a hash client side and

ask the server if the PBO was already signed.

If not, it could 7z the file before uploading to safe traffic / time. This could replace the web-front-end

altogether.

For the front-end indeed a simple web system should do the job:

1) Upload one pbo. Select the file located on your HDD.

2) Not sure if possible to do a client side hash generation. The hash in general is to compare if the file

was already uploaded. If not possible to do client side, the upload probably always has to happen.

Or do you have ideas - the name itself isn't sufficient.

3) If not done, generate a hash on the server for the pbo.

4) Compare the generated hash with all hashes, saved in a SQLiteDB / some DB of choice.

5) If already available, drop PBO and notify the uploader about the existing key.

6) The key is named just like the PBO along with a date tag. I think the day itself is enough like:

myPbo_2009_20_08

7) If has is not found, the system calls DSUtils\DSCreateKey.exe creates the key based on the said schema.

8) (Might be done later - just to get the idea) Move the created public key in a location accessible

to the common user. A location available via FTP might be the simplest solution.

This part can be extended though. Meaning either HTTP, or a web-front end to search and filter for

available keys.

For the location probably it might be a good to have .\bikey\datetag\myPbo_2009_20_08.bikey

Maybe the datetag folder level is unnecessary though.

9) We now use the created private key to sign the PBO:

Usage: dsSignFile private_key_filename file_to_sign_filename

This creates a bisign file in addition to PBO. Very small that is. Just a few bytes (306).

10) Check if the creation was successful.

Usage: dsCheckSignatures checked_dir keys_dir

So it is wise to have the PBO, its bisign file alone in a temporary folder during this process to avoid

complexity if another PBO is the reason for the app to fail.

If PBO, bisign and public key fit, the app will return nothing. On error it will report a message.

11) If successful (should be always the case unless PBO is corrupt?), drop the private key.

It is no longer needed and only used once to sign this one very PBO.

12) Create a hash for each PBO, sign and public key, put the hash, their filename and maybe more

information in the DB.

13) Depending on the server, drop the PBO or keep it available for download.

End user download probably would be way too huge traffic. It could serve as a master server for

other servers to mirror it though.

This part might be for a second/later phase to expand.

At least an API to get the hash of PBO for the respective key and/or sign file is possible.

This way an addon download server could query this one to get the key and sign file for the PBO.

14) Move the sign file to a folder with date tag, like .\bisign\2009-08-20\myPbo_2009_20_08.bisign.

15) At this point either have six installer or YAS create the file repository they need to deliver the files.

Both tools allow a very simple install and update system for the end user.

As stated the end user should always only download and update all. As the sign files are so small,

there is no problem to even download thousands of these.

Done.

The core element is to make the admins job easy to look through the available key files for him

to decide, find the one(s) he wants, and easily transfer them to his pc or maybe even server.

The key files are also very small. xxx bytes.

Hi,

I have some questions:

Can your system somehow automatically update server key files for client side addons?

AFAIK, a client side addon does not need to be installed on the server (for example, simple interface changes like this).

Please correct me if I am wrong.

The #1 issue with addons is that the server admin actually has to decide which addons are "ok" and which are "not ok", so you're going to need at least some kind of a comment system so people can comment on which addons are good and which are not, and even that probably won't cut it as you will still have most people wanting to use these "small addons that most people don't use and didn't have anyone comment on them" and not be able to because no admin should take the chance of approving unknown addons.

At the end, it seems like even if that system goes into a fully functional mode, it'll still be way too much work for admins to keep people happy.

It's not really about keeping people happy, but about facilitating server management. I can see quite a lot of harmless, client side only addons that should be allowed. The problem here is that currently, for each of these addons a server admin must keep the keys up to date, even though he doesn't have to update any actual pbo files on the server.

For server side addons, this system is slightly overkill since you already HAVE to download the updated pbo files and then can just copy the key file.

A server admin only needs key files, unless the addon introduce new classes or affects

AI behavior.

It is not the all-perfect-solution, yet its a doable one.

The design goal is to automate all aspects as much as possible.

We operate a similar system on a private basis. It works quite well.

There are only a small percentage of problematic addons.

Just out of curiosity..why duplication? why not team up with OFPEC on this?

They already have the TAG database and many addon/mod makers can post their bikeys there already.

Don't they want to extend their scope to include your setup?

At least I find the OFPEC system currently very cumbersome.

You don't see if a TAG has a key, there is no view of all keys,

there is no easy download of (all) keys. It relies on the authors to

submit the keys.

At the same time a sign it all server system has little relation

to what OFPEC does now, has it?

The point is more no one seemed interested anyway..

We use the a very similar system for ourselves just fine now.

OK I see where you are coming from..

Couple of points from me...

What I gathered from your posts is, you'll assign a different bikey for each pbo during the automated process.

This create huge number of keys and will make tracking impossible. I for one wouldn't want hundreds of keys in my server_key folder as it will be impossible for me keep it under control.

Another point is private keys are personal_property. This process negates that.

Not only you need to sign every pbo, you also need to create a privatebikey on a public server.

Third...many addon makers has their tags in their bikey or may even have single bikey and sign all final addons with the same key unless has some MP/error concerns.

Fourth....If I want to allow 90 % of addons, I disable sign check in the server. We usually allow the ones we check ourselves first for security, performance & quality reasons. I sure don't want to allow anything which can generate GBs of error in the RPT file or crash the server. The more an admin loses control over what is allowed or not, harder it is to find the culprit addon crashing the server.

Fifth...from the addon maker POV, I'll upload 700 MB of data the whole day on a crappy ADSL upload speed, for it to get deleted after a 15 second process, which I can do on my computer.

I suggest the following..

1-Create a simple GUI with the tools for signing the addon/mod. The process is simple enough for anyone who can deal with modeling/scripting. Even a bat file should do it, but better to have a GUI. AddonSync can do it very easily...should be OK if screen simplified a bit for signing process only.

2-You host addonmaker accounts in your server.

3-After signing the addon, this interface asks whether they want to upload their public bikey to their account to be hosted on your server.

If they don't care to upload, means they don't care whether it is allowed on public servers too.

4-With a login screen, this interface uploads the addon/mod name and the relevant bikey for it.

5-Now as a serveradmin, I can go thru filter options like addon makers' folders, addons, mods, mod groups (for example like weapons, vehicles, packs, conversions etc..) and download any key I'd lke to allow. Of course you compare my keys folder and show ones I have and download ones necessary. Sort of on a screen like Yoma's GameSpy query screen combined with download addons screen

Although I suport the effort, this makes more sense to me.

cheers

crawler75 lets first start with your suggestion.

From experience I believe this is not the right approach and won't work.

The key is to

• automated everything as much as possible
  
• make getting sign files for end users very simple (download/update all)
  
• reduce the effort for server admins to a minimum
  

The server admin is the guy with skills, he is the guy to judge addon author

or the addon itself.

Of course a comment system helps doing that.

What problem do you have with multiple keys?

A key needs to be evaluated once and added to the server. If you want to

ban an addon for whatever reason, you look for it from the addon naming.

It cannot be more simple than that. Sorry to say, to me it sounds like you

fail to think of real world application.

Currently our server has 71 keys from the original authors. So what?!

A private key is trust. Nothing else. An automated system is neutral.

So only the addon content is to judge and not the key source, like it is

currently. Any private key from addon authors can be abused by anyone

with access to their private key.

To restrict a private key to one addon along with an automated system

makes it as safe as this BI system of key and sign files can be.

If you disable verifySignatures, any cheater can used his personal addons.

Sorry your argument completely fails here. The percentage is not

measurement at all. The point is that currently most addons do not conflict,

do not contain cheats, do not create unfair benefits. This is what is about,

nothing else.

On your last point, you seem to fail to understand the whole concept, if you

want to argue that the upload is in vain.

Of course this can be done by fast lines with server to server transfer.

We don't really need to discuss the basics, do we?

So again, to me it seems like you got a very wrong idea of the suggested

system and how the key-sign system works in practice.

Don't worry I know what I am talking about. Otherwise I wouldn't be posting. You did not get my point..re-read my post.

What I'm saying is, community sign server is good idea for server admins and you should do it. I always thought we should have had such a repository. But for players not so great (or needed) IF you are not hosting the pbo file in this system...be it on your box or another. They can get the bisign files along with the updated pbo.

BUT make the signing process thru a local program, which then uploads the .bikey for the addon/mod along with necessary supplementary info.

You don't need to force people to upload the whole bunch of pbos. Only the mod, maker info and related bikey should be enough IF you are not going to host the addon/mod pbos.

Servers will still get the bikeys from CSS server.

The best thing would be to have it as a one stop shop. Not only the bikeys but the addons as well. Maybe something together with download servers like armaholic etc..

Upload is not necessary because you said files will get deleted yourself in your 1st post..

# The pbo file is dropped. So this server does NOT act as a pbo download server.

# Instead the server ONLY provides the key and sign files.

Now if you are saying that files will be transferred to a download site such as armaholic, thats something else, and it makes sense.

I support CSS ;)

cya

Okay we are getting closer. That's good. :)

The upload is needed as the server key the pbo to sign a file with his key for the given pbo.

Again:

• The system has to be as much automated as possible. The key creation,
  signing and making both available are key parts of this.
  
• Reality shows not everyone PBO is signed, while it should be. Again rather to
  rely on addon authors, the concepts is based on automation.
  
• To rule out misuse of privatekeys, a neutral source is the way to go.
  The trust is the only and main asset of an automated process - in addition to
  simply big time the process for all parties involved.
  

---------- Post added at 12:33 ---------- Previous post was at 12:31 ----------

Just a follow up. We host the addons in addition for our system,

yet as no major addon site is interested, I see no chance to realize this.

The only way would be make it fully based on torrents in the backend.

They won't be interested because this will divert traffic from their site...totally understandable. Unfortunate for this project.

A local program in contact with the CSS server doing the below is a good solution IMO;

-Yoma's tool does the signing and does it locally so it is achievable.

-Distribute the signining tools with this pack.

-Force them to open/login to their account online on your server thru this program.

-Ask the user to browse to the addon folder.

-Possible to impose a naming format if you want or add the date automatically

-If you want you can even generate a unique identifier serverside (after the user logs in using this little program or even to the site) and add it to the bikey/privatebikey name.

-Generate privatebikey.

-Sign pbos and generate server bikey.

-Upload the infos and bikey to the server.

-Done.

-Addonmaker uploads the folder to any mirror/server they want. It now has all the pbos signed and have the bikey copied there too.

-Serveradmins download any bikeys they want from your server.

Sorry but I really don't understand the good in uploading the pbos UNLESS you are going to host/transfer pbos to a download site. So maybe we should not discuss about it.

Thanks for the discussion cross!

Still we still talk not on the same level, it seems to me.

The key-sign system primarily to keep cheaters out.

More specially, you may want to disallow specific game modifications (via addons).

You can also just block certain mods (for compatibility or unfair advantages reasons or

as they are known to cause issue).

You should only trust yourself. So actually every server admin should have his own key(s)

and sign any addons he wants to permit himself. The tricky part is to offer these sign

files, YAS does a fair job here, yet really an autodownload by the game engine would

be possible and needed, and the addons - again YAS makes this fairly doable.

To make this work better BI would need to create an interface to disable specific

addons or automate this, if you join a server by asking the user.

We are nowhere this level of security for these and more reasons.

The current level is that, if server admins do care about security and keys, normally

they just use any key provide by some addon author.

Most likely they dont have the time nor skill to check the actual addon for malicious

code, or code quality or causing other issues. At best forum feedback is the way to go.

In any rate, practically you could easily download a key that is used to cheat or causes

trouble (via addons signed by it).

Next most addon authors sign all their work with just one key.

This is bad as you can only allow all or none of his work. Sometimes a game tweak is

just too unfair, while his other work would be okay.

Even more that way you cannot disallow older, possible buggy, addons.

Lastly, no every addon is signed - while every should be. After all only by putting a key

on a server you may open a backdoor. Yet for the start the presumption of innocence

is to be taken as granted.

Unsigned and/or no key, an addon is simply unusable by every server using verifySigs.

So in summary only an automated system to sign addons can ensure unbiased and no

backdoor use of generated keys.

Even more it ensures every, submitted, addon to have a key and sign file available.

And a different key for every addon and new release.

The ultimate and needed flexibility for a caring server admin.

---------- Post added at 22:17 ---------- Previous post was at 22:11 ----------

Your approach is doable, yet it is very simplistic has almost no relation to a CSS.

What you suggest is simply a key server with maybe a more advanced interface.

IMHO you fail to understand the crucial aspects with this system does not work.

It does not work now, so why should basically the same system with a little better

tools and interface.

So again the CSS is going a way longer road with ensuring a working solution to

achieve multiple goals.

To combine it with an auto download system would be nice, yet is unrealistic to achieve

at this current state of the community.

Last words. I am very much convinced the the new sites, as almost everyone are

primarily interested in building a community. They fail to understand or accept that

downloading a file is not part of that in the end. The presentation, the discussion,

the group of people and the site are.

So an automated download system is not a threat at all to their core goals.

Next most addon authors sign all their work with just one key.

This is bad as you can only allow all or none of his work. Sometimes a game tweak is

just too unfair, while his other work would be okay.

Even more that way you cannot disallow older, possible buggy, addons.

Yes every addon MUST have its own bikey for each version.

If an addon is modular like Proper or Heinbloeds for example, every standalone pbo MUST have its own bikey for each version.

Lastly, no every addon is signed - while every should be. After all only by putting a key on a server you may open a backdoor. Yet for the start the presumption of innocence is to be taken as granted. Unsigned and/or no key, an addon is simply unusable by every server using verifySigs.

So in summary only an automated system to sign addons can ensure unbiased and no backdoor use of generated keys. Even more it ensures every, submitted, addon to have a key and sign file available. And a different key for every addon and new release. The ultimate and needed flexibility for a caring server admin.

So you are saying you are going to ensure that CSS will NEVER sign a malicious code?

If this is not the case and if one decides to use the his key as a backdoor to servers, all he has to do is to release another addon (with his trusted/neutral name) and have his code in the file. It will get signed and distributed as usual. And I, as server admin, will download & allow it because I allow all the addons of this guy.

As you said for max security, every server signs every allowed file on their server and clients download those bisigns but this is not possible as you can imagine. So it will always be authors (or CSS) signing and servers allowing.

What I gather from your posts is, the process is still the same;

-Authors upload their files.

-CSS signs them.

-Author downloads bisigns back to his local and adds them to his addon pack.

-Author uploads the files to megaupload/filefront etc..

-Servers get the addon from filefront if serverside.

-Servers download bikeys from CSS for Keys folder.

-Players download the addon from filefront.

Tell me if you have a different general CSS workflow in mind.

As for the current system, the reason why it is not widely used is;

1- It is not infested enough by haxors...yet. When/if they start to fuck up 60/70 % of servers they WILL use signature verification.

2-Servers using sig verification usually only allow requested or mostly known addons/mods. For the rest it is not possible for a server admin to download every single addon/mod just to get the bikey. THIS is why it is NOT working. THIS is the Number 1 reason for poor signature usage. Servers need a single location from where they can filter & download keys.

3-None cares to read the Signatures wiki. I don't buy it. I don't believe how any addons maker (16 years old or 30 years old) cannot open command prompt and write a single line to sign their addons unless they have severe ADD.

My suggestion is no different than yours except having the signing process on the client machine rather than on the server.

This does not make it more simple, actually makes the process more complex but avoids unnecessary upload of files to the server. I can see the merit in generating and keeping the private keys within CSS for security's sake BUT unless you can ensure identification of malicious codes within addons/scripts, it is no better than leaving the privatekey with the author.

I think my suggestion may serve as a spring board. Your CSS Program, having real time connection to the CSS Server will perform the signing process locally but interactively. I don't want to repeat what I wrote above.

I suspect it is quite a bit of a challenge but you don't have to leave the privatekey with the user, you can upload it the CSS and delete the local copy.

CSS serverside will still be doing lots of stuff. From keeping the DB to generating unique identifiers that will be transferred to the program before signing process.

You cannot force people to use something but if the program is easy enough to use and if you can manage the CSS serverside good so that server admins can filter & download bikeys easily, then it might get used. It will definitely used by servers who are using sig verification. As for the other insensible servers which don't care to use it, they'll need some haxors fckin up their server to switch over.

If we are to force signatures on the community, then it should be BIS doing it, by a very simple method. ArmA2.exe or the engine should check signature verification...ie all the addons vs their bisigns and bikeys DURING game launch.

This should ensure all the custom files HAVE signatures, hence forcing all the addon makers to sign their releases, to be able to have them in-game.

Posts are getting longer :D

Next most addon authors sign all their work with just one key.

This is bad as you can only allow all or none of his work. Sometimes a game tweak is

just too unfair, while his other work would be okay.

Even more that way you cannot disallow older, possible buggy, addons.

Wait, what? I thought those key files are specific to each pbo they come with? Don't tell me they are just some public key from the author? Like, Author A makes Addon1 and Addon2, which are totally unrelated but they will have the exactly same key file?

That doesn't make too much sense to me.

Each keyfile should be unique, like a hash.

Salah ad Din;1499612']Wait' date=' what? I thought those key files are specific to each pbo they come with? Don't tell me they are just some public key from the author? Like, Author A makes Addon1 and Addon2, which are totally unrelated but they will have the exactly same key file?[/quote']

There are 3 terminology you need to keep in mind.

biprivatekey (aka private key) : This the key that user generates and uses to sign addons. This is private and not to be shared with public. If the author signs multiple addons using the same privatekey, they will have the same bikey. They are also unique and is different when re-generated even if they have the same name.

bikey (aka server key) : This is the file generated while generating a private key. There is only 1 unique bikey for each privatekey. It is the public version of the privatekey so that servers can put it into they keys folder and signature verification checks signatures vs this bikey as well as pbo.

bisign (aka sign, signature, pbo sig etc..) : This is a unique signature file for each pbo. Each bisign works only for its specific pbo...ie you cannot just copy a bisign and change its name. So it is unique.

As you can see, when a server puts the bikey to its Arma2/keys folder, it allows every pbo signed by its specific privatekey.

Now the problem we were talking about was...

Say kju releases Mod-A and generates kju.biprivatekey which also generates kju.bikey and signs the pbo to mod-a.pbo.kju.bisign

As a server admin I allow kju.bikey and this means, unless he re-generates his kju.biprivatekey, I allow anything that comes with kju.biprivatekey signed signatures. Which means I allow the BadMod-B.pbo.kju.bisign.

So best practice is to generate a separate privatekey (thus a separate bikey) for every separate addon which can be used independently or as standalone. But this is not forced by the tool itself.

@ Salah ad Din

The bisign file is pbo specific obviously.

If you allow keyX, you allow any pbos signed with it.

@ Cross

YAS does allow easily to sync your setup to a given server.

If both server admins and users, would use it, the concept of every server admin sign

of addons himself, he wants to grant access, is very easy to achieve.

The CSS would create ALL keys. And per file.

So if an user submits a bad addons, a server admin must not use the key for this very

one file. NO other addon/file can be affected.

So again you miss the point of the CSS creating the keys.

Also the user download all sign files available from the CSS (via YAS

or a similar download/update all app).

Sorry to say Cross, yet its all step by step presented in the first post.

Best to read this one slowly again to get the idea of the concept.

After that we can continue to talk about the same story. :)

You are correct that BI is the best to make this system far easier

and efficient in some many ways. As they see no priority, only we can do it ourselves.

You are right about some of the problems why the sign system isnt working well.

Such a fully automated system like the CSS concept, would allow people to rate

addons via the addon specific keys, to generate key packs (like trusted or compatible).

Without that base I see no way of improving the usability.

The CSS or a very similar concept is a must.

YAS does allow easily to sync your setup to a given server.

If both server admins and users, would use it, the concept of every server admin sign

of addons himself, he wants to grant access, is very easy to achieve.

Well you cannot expect server admin to download and sign every single pbo themselves, can you? No matter how safe it might be. I for one won't. I'd rather disallow them than to run after every single release.

Now...I've read you posts. All I get is CSS will generate a privatekey & bikey for every single pbo and do the signing & distribution of signatures. Write it more openly if what you are saying is something else.

What YOU don't get is the fact that admins cannot & will not go thru every single addon they'll allow and check for malicious code in them. Out of hundreds of pbos, it may be next to impossible to identify which pbo create the problem. ie apart from a simple virus check for the ones they download & put into their server.

Perhaps you need write it more clearly because there are certain assumptions you are making about the behaviors of key actors and saying this system will solve the trust/security problem.

IT WILL NOT, unless admins behave in a certain way, no matter what your CSS does. Because CSS WILL distribute signatures for pbos with malicious code and it is still upto the admins to find out that bad code. If you are not going to do it FOR them than what is the point of generating a privatekey and signing every single pbo. Because if admin finds out something like this ( a bad code), he not only avoids that single pbo but disables everything related to that author or group. I don't care how good his other addons/mods are.

You can say, modularity...BUT it is up to the author whether to split his work or not. If he wants more penetration, he makes it more modular and issue separate keys for each addon...so that it is not all or nothing.

There will always be a selection/filtering process (and forum feedback process) for the servers as I for one don't want to allow everything out there and than find out which ones crash my server or generate Gbs of RPT.

My design would have included these components below...

1-rfactorcental type front end where all authors post their addons and can be rated in certain aspects. Rather than going thru all sorts of forum topics. Well forum is good for discussion but releases must be submitted to a cental DB. example here

2-CSS-Client_Signer&Uploader&Updater&Downloader_Program for authors & players & admins.

3-CSS-Server_Category,Author&KeysDB

4-CSS-Server_KeyDistribution_Web_Interface

...for easier start-up

of course unless CSS brings in

1-addon_file_hosting

2-pre-sign protection by checking against malicious code or malicious free certification,

3-MultiPlayer certification making sure it is MP friendly and does not crash the server.

You bring in a new idea/initiave or a tool which makes the life easier for every party or make creations more accessible and people will use it.

Well you cannot expect server admin to download and sign every single pbo themselves, can you?

Why not. It is very simple to dump all sign files and sign all files again with YAS.

As server admin you dont sign each addon with a different key, instead you sign all

addons with the same. You just dump the key, if needed, create a new and resign all.

The client always just do download/update all. Very simple.

Ehm sorry?!

The first post does indicate the system in the abstract:

Instead an automated system to create the necessary files and provide them

to the players and admins

From basic concept:

# If not the server generates a new key file based on the pbo name and signs the pbo

What YOU don't get is the fact that admins cannot & will not go thru every single addon they'll allow and check for malicious code in them.

No, not a single bit different to how the situation is now. Or rather it is worse now

for the lack of every addon signed at all or with an individual key.

Like I wrote, a comment system about keys and committed users to generate

trusted key packs is the solution to this.

So again your point is mainly unrelated to CSS - instead the CSS would provide a base

to even allow these initiatives.

So again in the concept it is clearly stated that its the admin job to decide which keys

he is to put on his server. This fact is fundamental to the system BI introduced.

This problem does not go away. It can only be improved.

To have a key for each addon offers the flexibility to ban single addons. This is the

ultimate goal a server admin wants it to be.

There are no assumptions here. My line of argumentation is based on the fact like the

reality is at the moment, and on my non expert, yet existing IT security understanding.

Now...if admin finds out something like this ( a bad code), he not only avoids that single pbo but disables everything related to that author or group. I don't care how good his other addons/mods are.

Sorry this is the problem as it is now, and what a CSS would solve. So I dont get your

point here.

How does (addon) modularity related here?

Like I said, you are free to think of a different system.

My opinion is that automation is crucial, so is decoupling of keys and providing a different

key for each addon.

From my developer background I'd say your system is way more complex to realize

technically with a lot less benefits.

---------- Post added at 13:00 ---------- Previous post was at 12:15 ----------

Let me just outline the current different levels based on BI key and sign system.

1. Allow people to join with any files on your server (aka have verifySignatures disabled).

2. Allow only people to join with the core unmodified a2 files from BI (verifySignatures active,

no keys used other than BI.bikey)

3. Allow people to join with any files on your server, yet display a message about non

core unmodified a2 files from BI. (impractical)

4. Allow people to join with some or all keys released by community.

Still somewhat impractical as people often try to join with an addon the server does

not have the key or the addon was not signed at all and has no key from the author.

Even more it is impractical to sort out on the user side the actual addons allowed by a

server (where to know that from anyway).

To announce the allow keys and their addons on the team/serverpage is one way.

5. Use YAS to provide a server specific key, sign files (and addons).

In other words the user sync with a given server. Works, yet requires some effort on

both server side to build such a pack, the client to use YAS and to do it for every server

you want to play.

This can be mixed or made solely with original releases with their keys.

If solely relying on that, impossible to use addons that have no key / were not signed.

6. CSS to just have the server admin pick the keys of the addons he wants to allow

from the CSS FTP (or website), the client to download all sign files (via YAS or HTTP),

and the client to have both the sign file in the same folder as the addon.

Still requires the client to know/check what addons/keys are permitted on a server.

And to download the actual addons. Therefore a YAS server currently is the way of

choice.

7. CSS with download of addons to get both in one go.

Left same as 6.

8. A tool to sort out automatically the addons for a given server in addition to 7.

Aka moving files (using hardlinks) to a server specific modfolder.

9. BI to make it easier.

Um, sorry if I haven't read all those long posts, but this technical stuff is getting to my head (AND it's Saturday :D ).

So, the intent behind CSS is not to facilitate key downloads but to prevent cheating, right?=

The problem being that the public keys are used to verify any and all addons by one author.

Maybe I am wrong, but in my perception this works like PGP or GPG, right. Signing with a private key and verification of signature with public key.

So, I suppose this signing includes some sort of tamper protection, so that if someone takes a trusted mod and modifies the pbo, it won't fit the signature anymore (Hash included in the signature? Dunno).

So, the system prevents people from cheating by using trusted author's addons but it cannot prevent if a trusted author builds in some special stuff for himself into his addons.

Not quite sure if I grasp the advantage of the CSS system then. As far as I understand it simply replaces the authors key with its own, pbo-specific private key, right? The only advantage of this is to being able to allow one addon, while disallowing another one from the same author.

TBH, I don't see the advantage of this system. If an author has misused the trust put into him, ALL of his addons would be banned on our server, no matter how good the non-cheating ones are. It's all or nothing, baby!

Sorry if I reiterated the obvious here, but sometimes I need to spell out stuff to get a better grasp of it.

On the other hand, a system that I would consider helpful would be one that allows me to auto-update the bikey files for client addons that have been marked in a GUI (or a config file, GUI not really needed) as being trusted.

The updater would then connect to the CSS server and download the latest keys for the selected addons.

This can become a major headache, if you want to allow a bunch of harmless, simple GUI addons (Like BC6 or tbr) or various soundmods where you really only need the key files on the server but not the actual addon.