Tampering resistance by storing the migrations' hashes

[marton78]

Hi,

great project, it ticks off all of my requirements for a light weight migrations tool, but the following:

The table of applied migrations should contain a column for the hash of each migrations file

This prevents applying a chain of migrations if an already applied migration file has different contents than previously seen. See e.g. node-postgres-migrations for an example where this is implemented.

Additionally, migrations should always be applied in order, so a database with the migrations 100_foo and 200_bar should refuse to apply 150_baz.

[amacneil]

This would add a lot of complexity to dbmate, and I'm not convinced that it is necessary. In a typical software development workflow, it's easy to avoid this situation by simply never editing migration files that have already been committed to your master/main branch (other than whitespace/formatting changes, which are safe but would break with this feature).

Is there a particular workflow you are concerned about, or could you explain more about the real world issues you are seeing due to the lack of this feature?

[WoodyWoodsta]

I was hoping for this as well. Theoretically, everything should be caught during code-review, but in reality, mistakes happen. Versioning the record of migrations based on a hash of the content + order would add an extra level of robustness against accidental tampering. Ultimately, it's the content and the order of the files that are the axes of impact on the DB, not the filename and order.

How would this "add a lot of complexity"?

[jgonera]

I'd also love to see hash/checksum validation (order is a bit less important for me). Coming from https://github.com/rickbergfalk/postgrator I feel like I have one less mechanism for preventing developer mistakes.

[amacneil]

Generally speaking, dbmate aims to be a lightweight tool and we're not looking to add major new functionality.

Adding some record of the migration hash would then require features like "prevents applying a chain of migrations if an already applied migration file has different contents than previously seen" (per original issue description) and features to override those features if you are sure, and features to display the current status.

So I think it's unlikely we will add this feature, and it's better suited for a different tool that wants to tackle these sorts of problems.