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.

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

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

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.

@Cernel That's a good idea, may as well use it for bots.

I'd really encourage us to explore any/all implications of any suggestion. Coding up such a feature is probably going to require 5-10 hours. It's a waste of valuable time if it turns out something was missed that could have been avoided with a little more design up front.

I hear ya @Schulz , though are you considering all solutions? You seemed fixated on the XML route, which has a lot of drawbacks. A dynamic toggle would avoid a number of those.

@Schulz said in Question About the Battle Screen:

If one side need to pick bombers first before other units to protect its capital then it means the fate of game is already sealed.

Maybe, but as a blanket rule you cannot say that and it could be very wrong (what if both players are on the ropes and are using bombers to defend. What if the stack of 8 bombers is important HP but not worth the attack, pyrhic victory). Very rare does not mean it does not happen and means 'wrong' in those times when it does happen. It can't be mostly right, it needs to be right.

Being able to turn this on/off dynamically sounds like it gets us the benefit without a good bit of the draw-back.

I do think it's a more general solution if a player can either select a default OOL algo to always use without confirmation until change, or to toggle an option to use a default OOL algo unless some condition happens where the player wishes to confirm (ie: accept default algo except when chosen unit is not the least TUV).

@Schulz said in Question About the Battle Screen:

As cruisers nobody buy them and considered less bang for bucks compared to carriers.

Sometimes that bombard is worth more than a carrier.

In land one the only exception maybe could be picking bombers before infantries in capitals if one side forget to calculate the capital properly

When one side is closer to defeat, the bombers are sometimes throw-away and it's not a matter of not having calculated properly(EG: you land your 3 bombers in your cap for the HP).

These examples are why I think having an option to toggle an auto-accept is a good way to go so that it can be changed as the game players out. I agree initially those OOL are generally always what a person wants.

https://triplea-game.org/user-guide/ has the latest and up-to-date info on how to host a bot.

@Panther could you confirm that the OP is up to date? Better yet, could you confirm that all linked issues are tagged appropriately in bug tracking: https://github.com/triplea-game/triplea/labels/Impact%3A Bad Game Rules?

Are there any closed that actually require more work? https://github.com/triplea-game/triplea/issues?q=label%3A"Impact%3A+Bad+Game+Rules"+is%3Aclosed

I am unpinning this topic, I want to better focus this category for player-help.

@Schulz Could you provide some specific examples of such re-arrangments?

If we can avoid a map-specific solution for a global one, that is a win. I would like to avoid XMLs from specifying engine behavior and instead focus on game play configuration.