This PR addresses #1605 and improves PostgreSQL support in Sliver.
It seems that SQLite and PostgreSQL handle the zero GUID differently, so for PostgreSQL databases, we need to store NULL instead of the zero GUID. SQLite takes care of storing the zero GUID when NULL is provided as the value for a UUID column. For PostgreSQL and the current model, we need to be explicit, so some UUIDs have been changed to *uuid.UUID to signal to GORM that when we pass in a nil UUID, we want NULL and not uuid.Nil (the zero GUID).
I tested this change with both SQLite and PostgreSQL (14.11), and they handled the following tasks just fine:
Generating an http implant without an associated profile as described in #1605
Generating a beacon without an associated profile, tasking the beacon, and killing it
Generating an http implant with an associated profile and deleting the profile
Creating and deleting a job
Adding and removing loot
There may be other tasks which generate errors in PostgreSQL that I am not aware of, but I wanted to hit common use cases. Are there any other common tasks that I should test?
I tested database support in MySQL (8.0) and MariaDB (10.11), and I suggest we remove support for the mysql dialect. It is not compatible with our database model. MySQL does not have a uuid datatype and instead uses BINARY(16). We could either shift our current model to use BINARY(16) for all dialects or create hooks that translate uuid.UUID to BINARY(16) when mysql is the active dialect. MariaDB 10.7 gained the UUID datatype, but lacks support for array type which breaks the crackstation model. No one has asked for MySQL or MariaDB support publicly, so I am not sure the juice is worth the squeeze to support it.
This PR addresses #1605 and improves PostgreSQL support in Sliver.
It seems that SQLite and PostgreSQL handle the zero GUID differently, so for PostgreSQL databases, we need to store
NULLinstead of the zero GUID. SQLite takes care of storing the zero GUID whenNULLis provided as the value for a UUID column. For PostgreSQL and the current model, we need to be explicit, so some UUIDs have been changed to*uuid.UUIDto signal to GORM that when we pass in anilUUID, we wantNULLand notuuid.Nil(the zero GUID).I tested this change with both SQLite and PostgreSQL (14.11), and they handled the following tasks just fine:
httpimplant without an associated profile as described in #1605httpimplant with an associated profile and deleting the profileThere may be other tasks which generate errors in PostgreSQL that I am not aware of, but I wanted to hit common use cases. Are there any other common tasks that I should test?
I tested database support in MySQL (8.0) and MariaDB (10.11), and I suggest we remove support for the
mysqldialect. It is not compatible with our database model. MySQL does not have auuiddatatype and instead usesBINARY(16). We could either shift our current model to useBINARY(16)for all dialects or create hooks that translateuuid.UUIDtoBINARY(16)whenmysqlis the active dialect. MariaDB 10.7 gained the UUID datatype, but lacks support for array type which breaks thecrackstationmodel. No one has asked for MySQL or MariaDB support publicly, so I am not sure the juice is worth the squeeze to support it.