-
Notifications
You must be signed in to change notification settings - Fork 236
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
No protection against use of SQLite keywords #47
Comments
Hi Patrick, thanks for taking the time to look into ECD. Good point about adding a prefix to every table that gets generated. This seems like a very simple change, and I went ahead and made it in the "name-append" git branch. Would like to test it a bit more though before I merge it and close the issue. If you end up trying it, I'd love to know if it actually fixes your issue. |
Yes, the change on the name-append branch does fix my issue. I think that there may still need to be similar changes made for column names, but I do not currently have a test case to confirm that. |
Hi Patrick! Thanks a bunch for your interest in iMAS and this security control. As part of our research, we are always interested to hear about how folks are incorporating iMAS into their production environments. When you have a chance do you mind emailing me directly and tell me about your use of iMAS. Ideally, which industry, type of application, iMAS security controls used etc. My email address is gganley@mitre.org With your feedback, we are hoping to garner enough support such that we can successfully propose and have accepted another year of research funding which means continued support by Gavin and myself. :-) |
Went ahead and merged in the branch, but will leave this open to remind myself to do the same for the columns. |
I found a place where a column name that uses a reserved SQLite word causes a problem. This occurs during managed object model migration in the method
For all other cases I have tried with ECD, that column name does not conflict with the I should be able to find some time this week to write up a test case that reproduces this issue. The test case that I wrote for #51 captures the managed object model details that pertain to this case, but it lacks the migration component. |
I updated the gist to include another test method ( |
Hi Patrick! Thanks a bunch for your interest and contributions in iMAS and this security control. As part of our research, we are always interested to hear about how folks are incorporating iMAS into their production environments. When you have a chance do you mind emailing me directly and tell me about your use of iMAS. Ideally, which industry, type of application, iMAS security controls used etc. My email address is gganley@mitre.orgmailto:gganley@mitre.org With your feedback, we are hoping to garner enough support such that we can successfully propose and have accepted another year of research funding which means continued support by Gavin and myself. :-) From: Patrick Hartling [mailto:notifications@github.com] I am evaluating ECD, and the managed object model that we want to use with it exposed a problem. We have an entity with the name Transaction, and that is a keywordhttps://www.sqlite.org/lang_keywords.html in SQLite. The convention within Core Data's built-in support for using the SQLite store type is to prefix just about every name (tables, columns, possibly other aspects) with "Z". For my case, I can make a quick change to -tableNameForEntity: so that every table name starts with Z. Other people might run into similar problems but not have such an easy time addressing the naming conflicts. This is a great library, and I hope to put it into production use soon. Thank you! — |
The branch uniq-cols mostly does this now, with a couple of exceptions that I don't think are effecting the migration issue. Once I get to the point where I can merge in that branch I'll probably close this issue and track the migration issues on the newer ticket. |
With the changes on that branch, use of a transformable attribute extracts only 9 bytes from the column. I am working on a test case for this and will submit that as a pull request. |
I submitted a pull request that fixes an issue when using the default value transformer. The two new tests also serve to reproduce a problem with transformable values on the Incidentally, while working on the test cases, I realized that I had forgotten to set up the inverse relationships between the |
Did the |
After a bit of fiddling the only error I'm seeing in EncryptedCoreDataTests.m that is unique to the column names change is:
There are other errors but I will put them up in their own issue. I went ahead and merged in the unique column changes, but let me know if that causes too many headaches for you and can pull them back out. Will close this for now since the columns/tables are now at least unique, and address any bugs as their own issues. |
The |
I am evaluating ECD, and the managed object model that we want to use with it exposed a problem. We have an entity with the name
Transaction
, and that is a keyword in SQLite. The convention within Core Data's built-in support for using the SQLite store type is to prefix just about every name (tables, columns, possibly other aspects) with "Z". For my case, I can make a quick change to-tableNameForEntity:
so that every table name starts with Z. Other people might run into similar problems but not have such an easy time addressing the naming conflicts.This is a great library, and I hope to put it into production use soon. Thank you!
The text was updated successfully, but these errors were encountered: