[sqlite] Version 3.13.0 coming soon
Am Tue, 3 May 2016 13:21:04 -0400 schrieb Richard Hipp: > On 5/3/16, nomad at null.net wrote: >> On Tue May 03, 2016 at 08:33:30AM -0400, Richard Hipp wrote: >>> >>> Yes. Apparently that is the new standard for security on unix >> >> The way I understood Rolf's comment was that he was pointing out a >> typo: > > Ah. You are correct: I completely missed Rolf's point. > > Fixed now. Two more typos (IMHO, I'm not a native English speaker): "where not being recognized" -> "were not being recognized" "that can causes incorrect results" -> "that can cause incorrect results"
[sqlite] Version 3.13.0 coming soon
See in-line; On Wed, May 4, 2016 at 4:39 AM, Wolfgang Enzinger wrote: > > Two more typos (IMHO, I'm not a native English speaker): > > "where not being recognized" -> "were not being recognized" > > "Where" could be right or wrong, but I suspect this is the correct word. WHERE would mean something along the lines of what kind of situation something isn't being recognized, or maybe a set of conditions that make something unrecognized, or encompassing and general reasons, or something along that line. I'm struggling to find another example, as it is 7:17 am, I got out of bed 5 minutes ago, and have yet to have any of my cold coffee. ;) "Were" would be a past tense to something specific not being recognized. "Because of the masks, Jack and Jill were not being recognized by the facial scanner"... (Weak sauce, I know...) The prefix to that sentence would define which would be the correct term to use. > "that can causes incorrect results" -> "that can cause incorrect results" > Your correction here is correct.
[sqlite] Version 3.13.0 coming soon
Original message From: Richard Hipp <d...@sqlite.org> Date: 03/05/2016 13:33 (GMT+00:00) To: SQLite mailing list Subject: Re: [sqlite] Version 3.13.0 coming soon > Yes.? Apparently that is the new standard for security on unix systems.? Write lets you create new temp files.? Execute lets you check to see if a particular file exists.? But because read is disabled, one cannot do an "ls" on the temporary directory to see what temp files other applications have created. New? I remember FTP repositories from the mid 80s (funic, wustl?) where this scheme was common place for the "upload" directory so random visitors couldn't see recently uploaded files until the admins had had a chance to remove "dodgy" files and move genuine files to the correct place. Graham
[sqlite] Version 3.13.0 coming soon
On Tue May 03, 2016 at 08:33:30AM -0400, Richard Hipp wrote: > On 5/2/16, Rolf Ade wrote: > > > > Richard Hipp writes: > >> A change summary for 3.13.0 is at > >> https://www.sqlite.org/draft/releaselog/3_13_0.html > > > > Change the temporary directory search algorithm on Unix to allow > > directories read and execute permission, but without read permission, > > to > > serve as temporary directories. > > > > .. "write and execute permission, but without read permission" ? > > Yes. Apparently that is the new standard for security on unix The way I understood Rolf's comment was that he was pointing out a typo: the text reads "read and execute" permission when it should probably read "write and execute" permission. The way I understood your reply (although informative) was that you missed Rolf's point. Could be however that I've mis-understood both points :-) -- Mark Lawrence
[sqlite] Version 3.13.0 coming soon
On 5/3/16, Graham Holden wrote: > >> Yes. Apparently that is the new standard for security on unix > systems. > > New? I remember FTP repositories from the mid 80s (funic, wustl?) where this > scheme was common place for the "upload" directory so random visitors The capability is not new, but the idea of applying it to /var/tmp is, afaik. -- D. Richard Hipp drh at sqlite.org
[sqlite] Version 3.13.0 coming soon
On 5/3/16, nomad at null.net wrote: > On Tue May 03, 2016 at 08:33:30AM -0400, Richard Hipp wrote: >> >> Yes. Apparently that is the new standard for security on unix > > The way I understood Rolf's comment was that he was pointing out a > typo: Ah. You are correct: I completely missed Rolf's point. Fixed now. -- D. Richard Hipp drh at sqlite.org
[sqlite] Version 3.13.0 coming soon
On 5/2/16, Rolf Ade wrote: > > Richard Hipp writes: >> A change summary for 3.13.0 is at >> https://www.sqlite.org/draft/releaselog/3_13_0.html > > Change the temporary directory search algorithm on Unix to allow > directories read and execute permission, but without read permission, > to > serve as temporary directories. > > .. "write and execute permission, but without read permission" ? Yes. Apparently that is the new standard for security on unix systems. Write lets you create new temp files. Execute lets you check to see if a particular file exists. But because read is disabled, one cannot do an "ls" on the temporary directory to see what temp files other applications have created. Note that SQLite always unlinks its own temp files as soon as they are created, so you were never able to see SQLite's temp file, unless you are lucky and happen to read the directory during the microsecond in between the open() and unlink() system calls. But not all applications do that. The fact that SQLite formerly rejected temporary directories that omitted read permission was submitted to us as a security vulnerability. If that's the worst security vulnerability that SQLite ever creates, then I think we are doing a good job. Nevertheless, we have now fixed the issue. -- D. Richard Hipp drh at sqlite.org
[sqlite] Version 3.13.0 coming soon
Richard Hipp writes: > A change summary for 3.13.0 is at > https://www.sqlite.org/draft/releaselog/3_13_0.html Change the temporary directory search algorithm on Unix to allow directories read and execute permission, but without read permission, to serve as temporary directories. .. "write and execute permission, but without read permission" ?
[sqlite] Version 3.13.0 coming soon
We hope to have the 3.13.0 release of SQLite ready soon. Your assistance in testing the latest snapshot (available at https://www.sqlite.org/download.html) is greatly appreciated. A change summary for 3.13.0 is at https://www.sqlite.org/draft/releaselog/3_13_0.html The first bullet in the change summary (the postponement of IO associated with TEMP files) seems to be the most risky in the sense that it might cause new behavior for applications that are using SQLite in ways that we developers have never envisioned and hence have never tested. The status board for the 3.13.0 release is now on-line at (https://www.sqlite.org/checklists/313/index). The 3.13.0 release will occur when the status-board goes all green, which will hopefully happen within weeks if not sooner. -- D. Richard Hipp drh at sqlite.org
