> On Mar 15, 2018, at 1:26 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > The built-in path functions of some operating systems interpret file paths > beginning with a path separator as relative to the root of the drive rather > than the current subdirectory. […] > A 'name' field in a SQLite archive file could be edited to hold such a path. > This would be a vulnerability if a utility used to 'unpack' an archive is > accidentally given too much power, as 'install' scripts often are.
It’s pretty common for install scripts to write to absolute paths, since many types of installable components need to go in specific locations in the filesystem. Any time you run an installer you’re implicitly giving it permission to write anywhere in the filesystem that you can access; fortunately the really sensitive locations (/etc, /System/Library, etc.) are locked down to root accounts. But for the general purpose extraction CLI, it’d be wise to either fail if an absolute path is found, or allow absolute paths only if a special flag is given. > Because not all operating systems use the same character as a subdirectory > separator, you might document whether archives always use the '/' character > as a path separator. +1. If sqlar is to be a cross-platform archive format like Zip, it should have a single format for representing paths. > Does the deflated stream include a header which says "what follows is > deflated data" ? If not, what will you do when users want to use better > algorithms than 'Deflate’ ? It looks as though it doesn’t. The discussion of sqlar_uncompress() shows that it tells compressed data apart from uncompressed by comparing the data size against the original file size, which would be unnecessary if there were metadata identifying the compression algorithm. I agree it would be a good idea to add such metadata, either in the blob itself or as a table column. The ‘deflate’ algorithm is pretty long in the tooth, and newer algorithms like lz4 and zstd offer much better compression and performance. It would be wise to future-proof the archive format to allow for them. —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
