Incident

On Oct 17, 2020, around 07:00 GMT we became aware of a person that gained access to an admin account. We are not certain of how they gained access. With the hijacked account that person changed the frontpage of the forum.

In response to this we restored the forum from a recent backup and changed the password of the compromised account. Several hours later the account was again compromised and this time the attacker began making malicious edits to category titles and malicious posts.

We again restored the forum from backup and again changed the password of the admin account and removed admin privileges from that account.

The admin account is a default account created with the 'nodebb' (that runs this forum) and we had left it enabled with a relatively secure password.

Impact

While the attacker had access to the "admin" account they had access and could download the list of all usernames and emails.

Passwords were not exposed and are stored encrypted.

It's a guess that the main goal of this attack was largely site defacement. The attacker seems to have a collection of defaced sites and was running up their score.

Analysis

We were on version 13 of nodebb which had an open security advisory that could allow for account takeover. We do not know the exact method used for account takeover, exploiting that security advisory seems to have been the most likely attack vector used.

Corrective Action

• We have upgraded the forum software to 14.3 picking up a number of security patches, notably picking up a patch for the security advisory mentioned above.

• We now require all admin accounts to use MFA (multi-factor-authentication). This new requirements means if a password is compromised, an attacker would still not be able to log in to that account without the MFA device.

• We have increased password complexity requirements from 6 characters to 8 and now require passwords to not be "easily guessable".

• We have deleted the unnecessary 'admin' account that had been compromised.

Lessons Learned and Future Investments

We will continue investing in the security of the forum to improve intrusion detection, security vulnerability notification, improve logging (so we can better investigate breaches), and facilitate deployments so that we can increase the deployment frequency and keep the forum software much closer to the latest version available.

We want TripleA to grow, to gain new features, game-play be easier, faster, maps more interesting and everything prettier.

So, how can you help?

• create bug requests directly into the bug tracker after a problem has been identified in any forum thread
• avoid having a dev do anything you can do yourself
• do not PM dev's asking for something to be done, instead create a bug tracker item

Background:

I would like to address and point out the scaling problem TripleA has. As TripleA has grown from a small project, where one person could handle the code, another could handle communication and submitting bug reports, as the volume of people and traffic has grown, this no longer works

Development is one of the slowest things to happen for TripleA. Most interesting features take perhaps anywhere from 10 - 50 hours of work. The way I see it, those that can code, we want them to spend time coding, not doing general communication on forums, not finding bug reports on forums and transferring them to bug tracking, not managing maps, and generally not doing anything that could not be done otherwise by the community.

The trick I think for scaling is we need to be sure that we update any process so that a team of people can handle the item rather than just an individual. If for example "Joe" handles all maps, then when the amount of map stuff is too much for "Joe", we'll see a backlog. If "Joe" goes on vacation, everything stops, and if Joe gets tired of spending 20 hours a week on maps and backs away, then everything grinds to a halt. Worse yet, if Joe leaves, all the know-how Joe had in his head leaves too, and suddenly not only is there nobody to manage maps, but nobody even knows how to manage maps.

Teams solve this, if all map items go to a queue, and a team works on the queue, people can take vacations, people can rotate in and out. The team has incentive to document how the team operates so that new team members can join and become effective and everything doesn't stop when one person leaves.

Without a team handling items, when it is individuals, we do not scale.

We see this problem mostly in bug reports and change requests in forums. If we rely on individual developers to read, distill and create bug reports, then we have a bottleneck and an individual responsible for a process. If that individual stops creating bug reports from problems reported in forums, then we won't get any new items in the bug queue. Notice, the bug queue is a process that goes to a team, all developers work on it. We could easily have the one developer not create a bug report and fix the problem, but then we are into the "silo" problem to an extreme.

TripleA Needs your help!

We need help finding any remaining problems in the 2.0 beta. We'd like to release 2.0 imminently, we've almost all major bugs fixed. We're at a bottleneck where we don't have enough labor to test everything to get this release out. Your support of time and effort is really appreciated here and will help get 2.0 launched sooner.

We're inviting everyone to be an early release beta tester. We're asking you to:

• download the latest TripleA
• test anything/everything, all menus, all game play configurations, all rules, play a game through
• report any problems that you might find

Instructions

• Download the latest TripleA prerelease here: https://github.com/triplea-game/triplea/releases

• Run the installer, install to a folder named somethign like "TripleA-{Version}" or similar so you don't overwrite your existing TripleA installation.

• Launch the game, click on anything/everything, test everything!

• Report any problems that you see, new or existing: https://github.com/triplea-game/triplea/issues/new

Word of Caution

Since you are testing a beta, there could be stability issues, you might see crashes or other issues. We really want any of these to be reported so we may properly fix them.

Good luck and thank you to all those that step up to help.

The proposal is that we add a yml configuration file to each map that will index the games contained in the map bundle. This will be useful for a number of items:

• map uploads
• removes n-layer dependency on map name
• faster map parsing
• allows for thumbnail images to be bundled with the map
• would obsolete the "*.properties" file that gets created on client file systems.

To illustrate, the proposed structure would be the following list:

games:
  - name: game name
    path: <path>/game-name.xml
    game_notes: <path>/game-name-notes.html
    preview_image: <path>/game-name.png

This yml would be in a specifically named file called 'maps.yml' that would live at the top level of any map bundle (map zip or map dir).

Changes to XML

• we would no longer need the map name property
• we would no longer need the game name property

Changes to map loading

The name of a map zip, map repository, and map name in XML would no longer all need to line up. The map zip could have arbitrary names, the name of games would be pulled from the maps.yml file.

Changes to preview image

The preview image would no longer need to be specified in triplea_maps.yaml and could be either an absolute URL path or a relative path. The relative path would be useful for having a preview image be in the zip itself. This goes on to help map uploading as a zip file would be more complete and would simplify that process.

Example

For example, you could create the following map structure:

- maps.yml
- games/
   - world_at_war/
           world_at_war.xml
           world_at_war-notes.html
           world_at_war.png
   - world_at_war_mod/
           world_at_war_mod.xml
           world_at_war_mod-notes.html
           world_at_war_mod.png

In the above example, the names and locations of the files would be arbitrary, they just happen to line up in the example and that perhaps would be a best practice. At the end of the day all of the paths would be found in the maps.yml file. To fully illustrate, the maps.yml file for the above would look like:

games:
  - name: World At War
    path: games/world_at_war/world_at_war.xml
    preview: games/world_at_war/world_at_war.png
    notes: games/world_at_war/world_at_war-notes.html
  - name: World At War Alph Mod
    path: games/world_at_war/world_at_war_mod.xml
    preview: games/world_at_war/world_at_war_mod.png
    notes: games/world_at_war/world_at_war_mod-notes.html

We'll be getting a spotlight from the Legendary Games podcast in the coming weeks/months.

In the meantime they've done an interview with Larry Harris that would be of interest to everyone here (and will be interviewing David Jensen of 'A&A.org' soon too!)

The Larry Harris interview is available at:

• itunes
• google podcasts
• spotify

Wargaming is a niche, it's not for everyone, but there are people like you and me who love it - and for these people I make my games. "
- Larry Harris

Background: TripleA QA team has been operating for some time:
https://forums.triplea-game.org/topic/268/volunteers-needed-early-release-testing-group

We have coordinated mostly via gitter channel: https://gitter.im/triplea-game/QA

We coordinate testing via a pretty simple google spreadsheet:
https://docs.google.com/spreadsheets/d/1CSZ4s7wBLcvgue_IHwl-CbjQd95qj8hhR8m89ngCzbU/edit#gid=0

When there are multiple green bars lining up, meaning multiple people have reasonably checked as much of the game as they can, that version of the game can become the latest release.

Available at: triplea-game.org/download/

Change list: https://triplea-game.org/release_notes/

This release contains a change of how maps are loaded so that we will have more flexibility going forward with map XML and have improved map loading performance.

We have also restored the ability to play TripleA 1.8 maps.

Also included are a small number of bug and game rule fixes.

We have a lot of map controls, unit size, search territory, unit highlight, map zoom, that are buried behind magic keys or various view menus. These are difficult to find and easily adjust.

I'm opening this thread to discuss options. Some were discussed in context of unit flags and movable unit highlight in this thread: https://forums.triplea-game.org/topic/1524/toggle-flags-and-toggle-highlight-movable-units-updates/30

Needed are good ideas of where we can place the various items and what kind of UI treatment we can provide.

So we need:
(a) a survey of the various settings and features that are better pulled out from the menus and placed behind a UI control
(b) a mock-up and ideas of how/where everything can be placed and what kinds of UI controls would be good for containing those elements.

Why the QA team?

The QA team is essentially a way to coordinate multiple people to test the software before it is released. The team was created in response to a number of problems.

• Development team had trouble tracking results and general confusion on "is it safe to release?". With a defined policy and tracking, we can now look at the testing results and know when a specific version has been confirmed to be okay for release.
• the TripleA code base is very difficult to modify and repeated releases kept introducing small but extremely significant bugs. Regression testing for any of these is a huge effort, and needs to be done repeatedly as the code base is constantly modified. It's too large of a task for just one or two developers, hence the QA team.

How will we know if the QA team is successful?

• The number of major bugs reported by users to github issues will go down and head towards zero
• The number of times a release is 'rolled back' will go down and head to zero

Where is the QA team heading?

• Still formalizing how we operate, but we're getting pretty close to a stable operating process
• Long term try to work with development team to reduce the number of items being hand tested
• Short/medium term, formalize testing a bit, a few things are getting through, perhaps a testing check list of all features and cases that need to be checked would be a good start

Opening a dedicated thread to discuss these ideas.

From: https://forums.triplea-game.org/post/29462
@Hepps created this mockup:

I like the idea of action buttons, but I don't think we'll be able to agree just yet which ones should be on the game screen and which ones accessible in menus.

Let's focus here then on the minimap. Moving the tabs and map to bottom probably won't be that difficult. The translucent background might take a bit more work, but could be possible. It probably would make sense to make that a setting so that users can control translucent vs not.

Please add in any extra 2 cents, or thoughts on this topic.

What would happen to the unit scroller? Would that get squished beyond usability? With fewer buttons on it, I think it's more tractable to reduce the min.

I'm curious how this would look with movement history, particularly when multiple types of units are moving.

What impact would this have on the unit scroller?

The country names being cut-off is not great, though some flags really similar to one another. I think that makes it a bit of a toss-up.

@TheDog , I had my threads crossed. For this version number, it is never displayed to anyone at all. It is just used by the engine to know when to notify a user that their map is out of date. When to trigger that notification is up to the map maker.

All good, just trying to explore the idea in case there is something I'm missing.

While a date and timestamp are easier to know if one version is newer than another, who is to know if that has significance? Does the newer version imply it is incompatible, or just has some newer images maybe? What if the XML is simplified in one, and not the other, does that make a difference?

In the lobby, the game version is horribly cut off, so the current value is not very useful. Even if we made the engine aware of map versions and then complain if versions did not align, would that lead to excessive issues for map versions that are actually compatible?

If so, then what would the version be used for @TheDog ?

There is a commit 'sha' attached to any change, every version of a map is already uniquely identified by that.

Another important implication, having the map.yml file will replace the need for a mapName and gameName attribute to be specified in the XML, both of those attributes will become ignored after the map.yml file is used by the engine (perhaps starting in release 2.6)

An important implication of having a map.yml file to index the games in a map, the engine would no longer scrape the map looking for any XML file to be a game file. Instead it would only use the XML files explicitly referenced from the map.yml file. This would impact map development as you would need to create a map.yml file for the engine to "see" new XML files.

The category information needs to live outside of the map entirely. If the category changes we should not need to change the map contents and that would require users to re-download the map. I'm thinking the category would live in the maps-server database. The maps-server can query github to get a list of all repositories, from there it can then scrape the 'map.yml' file in each one and create a listing of available maps. This database will replace the main triplea_maps.yaml file. Then the game client when requesting the list of available maps would send a request to the server which would then query it's database to return results.

Partial downloads is not on the radar right now. It'll be quite complex. I'd rather we first do other projects to reduce the size of the download. Like specifically I'd like to see maps broken up and the XML distributed apart from the assets. This would essentially create a pool of assets such as images, maps, and XMLs would be independent and reference the assets by ID. When downloading an XML, the engine would figure out which asset IDs are required and download those. I don't know if we'll ever get to that model, so discussing it now is perhaps premature, but that's more or less the long-term radar on where maps could go.

I'm working on a way to avoid having to update: triplea_maps..yaml by instead embedding the needed information in the map bundle itself.

We still need to supply the same information, but in an alternative location. Today the map folder structure at a top level is just:

- map/

The data needed from each map is:

• map name
• version (download version, used to notify users of updates)
• preview image location (the link to this image is in triplea_maps.yaml, typically the image is stored in the map repository)
• map description (currently this lives in triplea_maps.yaml, usually as a CDATA block.

The map name and version will be found in map.yml file. The structure of that file is described in the map.yml forum thread. The description and preview I think can just be files. That would make the top level of a map look like this:

- map/
- map.yml       ## contains 'map-name' + 'version'
- preview.png      ## this will be the preview image
- description.html    ## contains the description

And there you have it, once those files are added, the engine would be able to pull information automatically without needing an entry in triplea_maps.yml.

I hope for this feature to be live for 2.6, until we get users migrated to 2.6 the triplea_maps.yml file will need an entry. Meanwhile, we can certainly add the above files and 2.5 or less will ignore them and 2.6 or greater will pick them up.

Please provide any feedback that comes up, I'm particularly interested in the file naming and if this all seems easy enough.

Which map are you referring to? That is an interesting example on its own.

Though, the game engine today is not handling that. Furthermore, presumably the map maker should have incremented the version to 2.x to indicate it is not compatible. So even if the engine were set up to disallow incompatible versions, in that case it would not have disallowed the connection anyways since 1.93 ought to be compatible with 1.94. (and if not, this goes back to the point that the version number is not well defined).

Hence, for now the version number of game XMLs is being removed.

I'm a bit surprised you managed to isolate that example to a map version. How did you know it was map version causing the problem? @beelee