Re: [sqlite] Proposed registration for application/vnd.sqlite3 and +sqlite3 (was: Why is Sqlite mediatype not registered at iana)
Keith Medcalf wrote: > I should that the Security Implications are NONE. > > There are no security implications in setting a MIME type for "magic > number" containing SQLite3 databases. RFC 6838 § 4.6 says that | the security considerations MUST NOT state that there are "no security | issues associated with this type". > I should think that the "Interoperability Considerations" are that the > contained data cannot be processed as a stream and it must be saved to > a filesystem before it can be used by any application incorporating the > SQLite3 database engine. Then you're using the wrong VFS. ;-) Regards, Clemens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Proposed registration for application/vnd.sqlite3 and +sqlite3 (was: Why is Sqlite mediatype not registered at iana)
I should that the Security Implications are NONE. There are no security implications in setting a MIME type for "magic number" containing SQLite3 databases. I should think that the "Interoperability Considerations" are that the contained data cannot be processed as a stream and it must be saved to a filesystem before it can be used by any application incorporating the SQLite3 database engine. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-Original Message- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Clemens Ladisch >Sent: Sunday, 1 October, 2017 08:33 >To: sqlite-users@mailinglists.sqlite.org >Subject: Re: [sqlite] Proposed registration for >application/vnd.sqlite3 and +sqlite3 (was: Why is Sqlite mediatype >not registered at iana) > >Paul van Genuchten wrote: >> i’m currently not a member of the sqlite consortium. > >RFC 6838 § 3.2 says: >| A registration may be placed in the vendor tree by anyone who needs >| to interchange files associated with some product or set of >products. >| However, the registration properly belongs to the vendor or >| organization producing the software that employs the type being >| registered, and that vendor or organization can at any time elect >to >| assert ownership of a registration done by a third party in order >to >| correct or update it. > > >Okay, did I overlook anything (especially in the security or >interoperability considerations sections)? > > >= >=== > > >Type name: > > application > >Subtype name: > > vnd.sqlite3 > >Required parameters: > > none > >Optional parameters: > > none > >Encoding considerations: > > binary > >Security considerations: > > Database files contain complex data structures, so parsers must >take > care to prevent buffer overflows, stack overruns, and other >unexpected > behaviour caused by malicious content. > > Views and triggers can contain arbitrary SQL expressions (including > recursion), which can result in arbitrarily large amounts of > processing time, memory, and disk space required when attempting to > access data. Applications should use mechanisms like > sqlite3_interrupt() or sqlite3_progress_handler() to allow long > computations to be aborted, and an alternative memory allocator to > limit the amount of memory used. > > The SQLite library itself, as distributed, does not allow SQL > statements to access resources or data outside the database. >However, > if applications add extension modules or functions, they should not >do > so in the database connection used to access untrusted content, or > they must ensure that these modules/functions are safe to use even > when called from malicious SQL code. > > The database may leave part of deleted or updated data in the >database > file. Applications that do not want ot leave traces of old data >must > enable PRAGMA secure_delete before doing any modifications, or run > VACUUM before transmitting the database file. > > Databases can use indexes to cache data in a format that is faster >to > access for certain queries. It is possible to construct database > files with inconsistent data in indexes so that some queries return > data different from what is actually stored in a table. To avoid > this, applications should run REINDEX before accessing a database > received from a potentially malicious source. > > This format provides no cryptographic integrity protection of any > kind. > > Databases can be used to store blobs containing data to be handled >by > other applications or libraries; any security considerations of >those > must also be taken into account. > >Interoperability considerations: > > At publication of this document, there exists only a single > implementation, the SQLite library. > > Database files written with recent versions of the library can be >read > and modified by any version back to at least 3.7.0 (released > 2010-07-21). However, there is no backwards compatibility if SQL > features introduced in a newer version are actually used. To >ensure > interoperability with other applications that use an older version >of > the library, applications SHOULD avoid using features that are not > supported in the version that other applications are known or > suspected to use. At publication of this document, features > introduced in newer versions are: > > 3.20.0: deterministic date/time functions; > 3.18.0: printf() thousands marks; > 3.16.0: PRAGMA functions; > 3.15.0: row values; deterministic SQL functions in partial indexes; > 3.9.0: expression indexes; > 3.8.8: more than 500 rows in a VALUES clause; > 3.8.6: hexadecimal integer literals; likely(); > 3.8.3: common table expressions (WITH); printf(); > 3.8.2: clustered indexes (WITHOUT ROWID tables); > 3.8.1: unlikely(); likelihood(); > 3.8.0:
Re: [sqlite] Proposed registration for application/vnd.sqlite3 and +sqlite3 (was: Why is Sqlite mediatype not registered at iana)
Paul van Genuchten wrote: > i’m currently not a member of the sqlite consortium. RFC 6838 § 3.2 says: | A registration may be placed in the vendor tree by anyone who needs | to interchange files associated with some product or set of products. | However, the registration properly belongs to the vendor or | organization producing the software that employs the type being | registered, and that vendor or organization can at any time elect to | assert ownership of a registration done by a third party in order to | correct or update it. Okay, did I overlook anything (especially in the security or interoperability considerations sections)? Type name: application Subtype name: vnd.sqlite3 Required parameters: none Optional parameters: none Encoding considerations: binary Security considerations: Database files contain complex data structures, so parsers must take care to prevent buffer overflows, stack overruns, and other unexpected behaviour caused by malicious content. Views and triggers can contain arbitrary SQL expressions (including recursion), which can result in arbitrarily large amounts of processing time, memory, and disk space required when attempting to access data. Applications should use mechanisms like sqlite3_interrupt() or sqlite3_progress_handler() to allow long computations to be aborted, and an alternative memory allocator to limit the amount of memory used. The SQLite library itself, as distributed, does not allow SQL statements to access resources or data outside the database. However, if applications add extension modules or functions, they should not do so in the database connection used to access untrusted content, or they must ensure that these modules/functions are safe to use even when called from malicious SQL code. The database may leave part of deleted or updated data in the database file. Applications that do not want ot leave traces of old data must enable PRAGMA secure_delete before doing any modifications, or run VACUUM before transmitting the database file. Databases can use indexes to cache data in a format that is faster to access for certain queries. It is possible to construct database files with inconsistent data in indexes so that some queries return data different from what is actually stored in a table. To avoid this, applications should run REINDEX before accessing a database received from a potentially malicious source. This format provides no cryptographic integrity protection of any kind. Databases can be used to store blobs containing data to be handled by other applications or libraries; any security considerations of those must also be taken into account. Interoperability considerations: At publication of this document, there exists only a single implementation, the SQLite library. Database files written with recent versions of the library can be read and modified by any version back to at least 3.7.0 (released 2010-07-21). However, there is no backwards compatibility if SQL features introduced in a newer version are actually used. To ensure interoperability with other applications that use an older version of the library, applications SHOULD avoid using features that are not supported in the version that other applications are known or suspected to use. At publication of this document, features introduced in newer versions are: 3.20.0: deterministic date/time functions; 3.18.0: printf() thousands marks; 3.16.0: PRAGMA functions; 3.15.0: row values; deterministic SQL functions in partial indexes; 3.9.0: expression indexes; 3.8.8: more than 500 rows in a VALUES clause; 3.8.6: hexadecimal integer literals; likely(); 3.8.3: common table expressions (WITH); printf(); 3.8.2: clustered indexes (WITHOUT ROWID tables); 3.8.1: unlikely(); likelihood(); 3.8.0: partial indexes; 3.7.16: unicode(); char(); 3.7.15: instr(); 3.7.11: multiple rows in a VALUES clause; bare columns in aggregate queries. Some runtime settings (e.g., PRAGMA case_sensitive_like) or compilation options can change the semantics of SQL statements. Applications SHOULD use the default settings and options; however, some settings (e.g., PRAGMA foreign_keys) are disabled by default only for backwards compatibility and are commonly enabled. When a transaction that changes the database has not yet committed, the database file might be in an inconsistent state and require data from the rollback journal to get back to a consistent state. Therefore, when it is possible that other processes or threads change a database, an application that wishes to transmit a database file SHOULD prevent concurrent changes by executing BEGIN IMMEDIATE before reading/copying the file, or use the backup API to create a consistent copy of the database. A database in WAL mode
