[sqlite] Version 3.13.0 coming soon

2016-05-04 Thread Wolfgang Enzinger
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

2016-05-04 Thread Stephen Chrzanowski
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

2016-05-03 Thread Graham Holden


 Original message 
From: Richard Hipp  
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

2016-05-03 Thread no...@null.net
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

2016-05-03 Thread Richard Hipp
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

2016-05-03 Thread 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.

-- 
D. Richard Hipp
drh at sqlite.org


[sqlite] Version 3.13.0 coming soon

2016-05-03 Thread Richard Hipp
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

2016-05-03 Thread Rolf Ade

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

2016-05-02 Thread Richard Hipp
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