SudoBox FF#12


Fellow Boxers,

How did the testing go and where have you guys been?
We took a stumble. During the first beta release we unfortunately, had some information still in our configuration files. This was all completely unintentional and this hit the SudoBox team hard in all honesty. As many of you know this is a passion project and we take to heart all comments, feedback and all repercussions. Of course, we’re only human and this is completely natural.

So what was leaked?

Keys. Now, no magic was used and even at a basic skill level, anyone could have located these keys. They were simple in the config file. A simple Google and know-how and anyone could have obtained the information. It was what that information led to which is the crippling part. No one wants their keys leaked anywhere. This is why when a user posts a screenshot of their own API keys or anything which can make them vulnerable in any way, SudoBox will respectfully remove such posts/content (reactiveness dependant on online activity but we are generally informed by users).

But it was just keys?

We’d like to take this approach as if someone you don’t know has keys to your house, access to your phone, bank details. Anything personal to you which you hold dear or have even put effort into. We’d like to publicly apologise to Speedy and Hawks. Both are valuable members of the team and they took the hit hard. We really must admire them for their persistence, loyalty and ceaseless dedication. We’d also like to thank those that reported the leak. You didn’t have to do this but you did so with immediate effect which shows some communities are stronger than others.

So what did you do?

This stopped everything in its tracks. The first immediate action was to lock everything down and conduct damage control. Following that the beta access was terminated and auditing grabbed the reigns. We then took the utmost necessary precautions and steps needed to make sure things were in hand.
Oh and we then met up. All of us, in person, in the UK. We’ve now done this twice where we have strategised our actions in moving forward and we’ve even gone ahead when we met for the second time where we have also purchased a server. This is the real dedication that we want people to focus on…we are still friends…we are still a community.

Steps moving forward

This was a blessing in disguise for the SudoBox team. We’ve had to learn methods to tighten our own infrastructure even more.

SudoBox will be developed on our own hosted Gitlab instance. We will be utilising tools ( SonarQube ) to assist us with vulnerability scans, bugs and even code smells. Once our Dev has sent a Commit/Merge from their IDE to Gitlab, SudoBox will be built with tests and scans following suite. Most of this will be done on our gitlab dev branch, however, when we decide to make a release, we will merge our dev branch with our master branch, this will then trigger our automated pipelines to push the code to it’s corresponding platform such as GitHub, DockerHub and NPM. This means that all of our code will always be available from these platforms and we only intent to use our gitlab instance for testing pruposes. There will be no Hotspots in this code, nothing will be hidden! Fully Open Sourced.

Reporting will now naturally fall out of the back of this. Where all work is essentially audited and no future releases or versions are to be pushed without agreement. Therefore we are now utilising Jira (Atlassian) and testing starts Monday 19th July with a working development workflow whilst monitoring build status.

We would also like to talk about the implementation of the new official Sudobox API and why we are doing this. As you probably know, projects such as PG and PTS allow you to install apps by utilising a pre-configured .yml file, this file contains all the information required to configure and setup a docker container, now this is exactly how Sudobox plans to do it, however, where the API comes in is how these files end up on your server. Usually a git pull request is made to Github and every config file is downloaded, even the ones you won’t be using. In order for these yml’s to stay up to date it needs to constantly pull these files from github. Where the API makes this process more efficient is how it only requests the config it needs, all within milliseconds. The use of our API also makes it easier for users to create and publish their own apps for others to use. Both our CLI and Dashboard will have tools to allow you to easily create entries in the Community apps section, and once an Admin / Moderator approves of the app, it will become instantly available through the API.

Now obviously one of the main concerns is the risk that comes with hosting your own service. We know how frustrating is can be when you want to do something but then are stopped dead in your tracks because a service you expect to be online becomes unavailable. So, let us tell you how we are going to overcome this risk. First, we will have multiple servers running our API, one main one and the others acting as redundant servers. Now as our userbase grows and api usage goes up, we will look into load balancing these services as well but we won’t be crossing that bridge until we get there. In addition to this, all config files stored within our Database will be automatically converted into json files and then uploaded to our GitHub account. Both our CLI and Dashboard will be configured to pull from here if it determines that our API is inaccessible, hopefully this never happens but in the event it does, at least you will have somewhere to pull those files.


We have more or less finished the uploader, just need to continue testing it and it will be done. In addition, we have also finished our Mount and will be soon making this available for our staff / testers to start testing it out. This means we only have the following things to work on:

  • Implementation of Traefik V2 and Authelia
  • Rclone config generator and SA generator

Once these have been completed, we will pretty much have a working project, and you will be able to install our CLI as a standalone project.

After this, we will be developing our Dashboard, and since the dashboard will be tapping into the existing internal infrastructure that makes Sudobox tick, it shouldn’t take us much time to do so. Infact, our designer has been working on our designs and when the time comes will start converting them into usable tailwind components.

New Team Member

We’d like to welcome onboard Pianomanx. Already a dedicated SudoBox member bringing along with him a very high and valuable skillset. We are proud and ecstatic to have you join the team and look forward to our journey together.

This was a long Fact Friday and we can only thank you all for your understanding and commitment to the project so far. Starting from scratch a while ago wasn’t easy and we have only just started to pick ourselves up again but now we’re going full steam ahead with this.

“A person who never made a mistake never tried anything new” - Albert Einstein. That’s what you’re getting here with SB, something new, something different, something earned.


Sorry to hear about the leak but it sounds like you guys took control of the situation and pressing forward.


Thanks for letting the community know what’s been happening and the transparency in this post.

It sucks but it does sound like some good did come out of it, and you have plans to help mitigate against any such problems in the future (and know what to do if something like it happens again)

It’s great to see you guys pull together and help each other out. :beer:


I can’t wait…:slight_smile:


Kudos for such an honest and transparent post.
Kudos again, for the manner of your conduct and picking yourselves up.
I’m super excited to use SB, and thank you for your ongoing efforts.
Best wishes.

1 Like

Thanks for the update guys (and girls) and the honesty.

Keep up the good work. Can’t wait to start using your solution.

1 Like