Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SQL refactor #287

Open
wants to merge 19 commits into
base: master
Choose a base branch
from
Open

SQL refactor #287

wants to merge 19 commits into from

Conversation

DJAndries
Copy link
Collaborator

@DJAndries DJAndries commented Sep 7, 2024

Resolves #216

@DJAndries DJAndries marked this pull request as ready for review September 21, 2024 00:04
Copy link
Collaborator

@AlexeyBarabash AlexeyBarabash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, great work

I left one question at spec discussion.

Tried locally - works fine, I saw TRANSIENT_ERROR/SQL rollout not ready - but then client status turned to SUCCESS.

command/helpers.go Show resolved Hide resolved
@@ -70,3 +75,14 @@ services:
- ALLOW_EMPTY_PASSWORD=yes
networks:
- sync
postgres:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reported by reviewdog 🐶
[semgrep] Service 'postgres' allows for privilege escalation via setuid or setgid binaries. Add 'no-new-privileges=true' in 'security_opt' to prevent this.

Source: https://github.com/brave/security-action/blob/main/assets/semgrep_rules/services/docker-compose-no-new-privileges.yaml


Cc @thypon kdenhartog

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The combination of this one with the additional one below do look like they'll present issues. Should be an easy fix to add the no-new-privileges=true configuration to this file. If there's a reason we intentionally haven't done this though @DJAndries let me know and we can determine together what the best way forward is.

@@ -70,3 +75,14 @@ services:
- ALLOW_EMPTY_PASSWORD=yes
networks:
- sync
postgres:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reported by reviewdog 🐶
[semgrep] Service 'postgres' is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add 'read_only: true' to this service to prevent this.

Source: https://semgrep.dev/r/yaml.docker-compose.security.writable-filesystem-service.writable-filesystem-service


Cc @thypon kdenhartog

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above, seems like a simple solution to solve this is to add the read_only: true configuration. If you can't let me know and we'll figure out the best way forward @DJAndries.

if !h.SQLDB.Variations().Ready {
return nil, nil
}
if rand.Float32() > h.SQLDB.MigrateIntervalPercent() {
Copy link
Member

@kdenhartog kdenhartog Oct 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non blocking question: @DJAndries what's the purpose in this validation check? The logic is non-deterministic in the sense that rand could return a very large number forcing this to fail the migration. Is this intentional?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to reduce DB load, we only want to migrate chunks of data from ddb to pg on a certain percentage of "get update" requests from the client, which are sent every 30 seconds. the check enforces this requirement.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will add a comment for clarity

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want a more uniform randomness, crypto/rand can provide that guarantee, but based on that answer it doesn't seem like we really need that so feel free to ignore that sec-actions comment.


import (
"fmt"
"math/rand/v2"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reported by reviewdog 🐶
[semgrep] Do not use math/rand. Use crypto/rand instead.

Source: https://semgrep.dev/r/go.lang.security.audit.crypto.math_random.math-random-used


Cc @thypon @kdenhartog

@@ -0,0 +1,9 @@
FROM public.ecr.aws/docker/library/postgres:16

RUN apt update && apt install -y git make gcc postgresql-server-dev-16

Check notice

Code scanning / SonarCloud

Arguments in long RUN instructions should be sorted Low

Sort these package names alphanumerically. See more on SonarCloud
Copy link

[puLL-Merge] - brave/go-sync@287

Description

This PR introduces significant changes to the codebase, primarily focusing on adding support for SQL databases alongside the existing DynamoDB implementation. It also includes improvements to the data migration process, updates to the project structure, and enhancements to the testing suite.

Changes

Changes

  1. Database Support:

    • Added SQL database support (datastore/sql.go, datastore/sync_entity_sql.go)
    • Created interfaces for DynamoDB and SQL datastores (datastore/interfaces.go)
    • Implemented migration functionality from DynamoDB to SQL (command/migrate_test.go)
  2. Project Structure:

    • Separated DynamoDB-specific code (datastore/sync_entity_dynamo.go)
    • Added SQL migrations (datastore/migrations/)
    • Created new files for SQL-related functionality (datastore/sql_variations.go, datastore/item_count_sql.go)
  3. Command Package:

    • Refactored command/command.go to support both DynamoDB and SQL operations
    • Added new helper functions in command/helpers.go
    • Implemented item count tracking (command/item_count.go)
  4. Testing:

    • Updated existing tests to work with both DynamoDB and SQL
    • Added new tests for SQL functionality and migrations
  5. Configuration and Environment:

    • Added support for SQL database connection strings
    • Introduced new environment variables for SQL configuration
  6. Docker and Development:

    • Updated docker-compose.yml to include PostgreSQL service
    • Added pg.Dockerfile for custom PostgreSQL image with extensions
  7. Dependencies:

    • Updated go.mod and go.sum with new dependencies, including SQL-related libraries
  8. Rollout Management:

    • Implemented rollout configuration management (server/rollout.go)

Possible Issues

  1. The migration process from DynamoDB to SQL might cause temporary inconsistencies during the transition period.
  2. The new SQL implementation might introduce performance differences compared to the previous DynamoDB-only setup.
  3. The additional complexity of supporting both databases could make future maintenance more challenging.

Security Hotspots

  1. SQL query construction in datastore/sync_entity_sql.go should be carefully reviewed to prevent SQL injection vulnerabilities.
  2. The new database connection strings and credentials management in datastore/sql.go should be audited for proper security practices.
  3. The rollout confirmation mechanism in server/rollout.go should be reviewed to ensure it doesn't introduce any potential security weaknesses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Database migration
4 participants