This would require putting it into SQLite. This would allow a lot of different goodies, simplficiation of the upcoming handlers and more. The problem is that this database needs to be writeable by Apache. If there is an upload bug and someone can tamper the SQLite database then said attacker should not to be able to include files outside of the modules/includes directory. I will write another patch which adds a warnign to the status report if the modules dir is writeable. I have attached a patch which adds the check but it does nothing meaningful really because the SQLite part is not yet there.
killes and jmorahan have reviewed the regex and the only known issue is that we allow files inside say sites/all/modules2 -- however the above mentioned report needs to check sites/all for writeability anyways so this is not a problem really.
| Comment | File | Size | Author |
|---|---|---|---|
| registry_everywhere.patch | 4.24 KB | chx |
Comments
Comment #1
mfer commentedsubscribe. I'll review later.
Comment #2
dries commentedThe function is missing phpDoc.
Comment #3
chx commentedPutting the registry in a local SQLite file requires that in case that file is not found then Drupal can boot itself up to a state where it can copy those tables back to SQLite and then continue on. I think redirecting to request_uri after such a rebuild is the cleanest.
Comment #4
morbus iffSubscribe.
Comment #5
Crell commentedSubscribe.
Comment #7
CorniI commentedwouldn't be an approach as i outlined in #430972: Add a file cache to the cache API be faster than invoking sqlite? One would need to sanity-check the php-file though, in case you're paranoid.
Comment #8
chx commentedComment #9
Crell commentedRequiring SQLite for D7 is not on the table, and we're not making big changes to D7 anyway. The registry is also gone in D8. Closing this out.