General criteria

NOTE: Fluid Attacks does the review between 8:30 am and 6:00 pm Colombia time, Monday to Friday. These are the maximum review times:

• Code: 1 hour.
• Hacking: 2 hours.

The reviewers process the solutions in the order of arrival. Thus the time also depends on the quantity of solutions in the queue.

You send each solution in a merge request to the master branch of the academy repository.

When Fluid Attacks gives you access to the repository, read this page again. Also examine the merge requests that Fluid Attacks merged.

Before you send a merge request, make certain that your work obeys these criteria:

1. You can work on one branch or on more than one branch. Fluid Attacks accepts concurrent merge requests from different branches. You do not have to wait for the merge of a previous merge request before you open a new one. The CI validates each merge request independently. The app computes its cumulative metrics at build time. The total hours, the rankings and the productivity are the sum of the effort of every merged solution.

   The name of a branch must be login or login-word, where:

   • login is your GitLab username. It must be exactly the same.
   • word is one alphanumeric suffix in lowercase. Use letters and numbers, and do not use a special character.
   • The separator is a hyphen (-), which is the kebab-case style.

   Examples: jdoe, jdoe-rust, jdoe-python, jdoe-ctf, jdoe-challenge3

   This format is a rule, not a recommendation. Fluid Attacks does not accept a branch with a different name.

2. Your GitLab profile must show your local time zone and your location.

3. All the files of a solution must obey the structure of its type:

   • Code structure for a programming solution.
   • Hack structure for a ctf-hacking solution.
   • VbD structure for a vbd-hacking solution.

4. If a solution needs more files, put them in the folder of that challenge.

5. Each solution must also have new external solutions for any other challenge in the repository. External solutions gives the quantity of these links and their rules. Plagiarism gives the reason for them.

6. Each solution must also have a user-name.yml file. These are the two templates:

   • Programming and ctf-hacking challenges.
   • vbd-hacking vulnerabilities.

7. You can add new items to the repository. Obey the structure page of the type when you do it. These are the items:

   • A challenge site, or a challenge for a site that the repository already has, for programming and ctf-hacking.
   • A ToE, or a new vulnerability for a ToE that the repository already has, for vbd-hacking.

8. You sometimes add a new site, a new ToE, a new challenge or a new vulnerability. You can then also add external solutions to their OTHERS.lst files. Do not do this for the challenge that you solve in the same commit. Those links remove the unique status of your own solution. External solutions gives the condition for each type.

9. Configure git and the .mailmap file before your first commit. First commit gives the procedure.

10. You must send the solution and all its files in 1 commit.

11. You must send the commit of each solution in only 1 merge request.

12. Send the merge request only after your branch passes all the pipelines. A complete and correct pipeline shows the color green.

13. If a reviewer rejects the merge request, do not open it again. Correct the errors and send the solution in a new merge request.

14. The message of the commit must obey one of these two templates:

    • Programming and ctf-hacking challenges.
    • vbd-hacking vulnerabilities.

15. Each solution must obey the Style guide. This is applicable to programming, ctf-hacking and vbd-hacking.