fix: [misp-core] MySQL HA DB Schema Fix for bruteforces table

[c0dewhacker]

What does it do?

If it fixes an existing issue - fixes #7522

A Stack trace occurs when logging into a MISP instance that utilises a MySQL Cluster HA setup. In order to be compliant with group replication Group Replication Requirements the bruteforces table must have a primary key. It is the only table in the schema that does not conform to this requirement.

Can be checked in the current 2.4 branch in the database with the following query -

SELECT tables.table_schema , tables.table_name , tables.engine
FROM information_schema.tables
LEFT JOIN (
   SELECT table_schema , table_name
   FROM information_schema.statistics
   GROUP BY table_schema, table_name, index_name HAVING
     SUM( case when non_unique = 0 and nullable != 'YES' then 1 else 0 end ) = count(*) ) puks
 ON tables.table_schema = puks.table_schema and tables.table_name = puks.table_name
 WHERE puks.table_name is null
   AND tables.table_type = 'BASE TABLE' AND Engine="InnoDB";

Results in

+--------------+-------------+--------+
| TABLE_SCHEMA | TABLE_NAME  | ENGINE |
+--------------+-------------+--------+
| misp         | bruteforces | InnoDB |
+--------------+-------------+--------+

In addition, due to the changes in db_schema.json. I also updated the relevant table structure in Postgresql related files.

Questions

• Does it require a DB change?
• Are you using it in production?
• Does it require a change in the API (PyMISP for example)?

[c0dewhacker]

Looks like it's failing in the pymisp repository test. Due to a DB schema version. Db schema 108 != 109