it's worth noting that the crypto-enabled version probably won't work
with PHP without some (simple) patching.
In case it isn't clear, the message is: don't put the files under the
web root. If you provider forces you to do that and offers no other
way to control security, find one that does.
--
I don't get this thread either...
it's no more or less secure than anything else you store in a file.
We are not going to hack libsqlite or change anything else in PHP to
cater for this--it really isn't our problem.
If you have a cheap provider that insists on putting your private data
under the w
On Tue, 24 Aug 2004, Adam Q wrote:
I thought more about the issue last night and I guess it can be summaried as
thus:
In skilled hands an SQLite DB can be potentially more secure than a standard
DB - but in unskilled hands the reverse is true, and SQLite becomes seriously
insecure. Standard DBs
On August 24, 2004 09:10 am, Adam Q wrote:
> Could we have SQLite DB creation "option" that creates the DB with a
> header that begins first 20 chars anyway... ) - either way, I'm going to do some testing
> of Ilia's create table option and see if I can get around it.
No, the reason is that my "s
At 19:34 23/08/2004, Sterling Hughes wrote:
Saying that just because someone is too stupid to properly lock down their
data store (put outside the web root, run PHP with proper perms, etc.),
makes PHP/SQLite themselves insecure, is like putting coffee on your lap,
driving and blaming McDonalds f
On 24/08/2004, at 12:34 AM, Zeev Suraski wrote:
At 17:16 23/08/2004, Ilia Alshanetsky wrote:
Here is the simple truth, if you are using a shared hosting solution
that is
not VPS (Virtual Private Server) it would be relatively trivial for
other
users of the system to access any file that the webse
On Aug 23, 2004, at 4:04 PM, Chris Shiflett wrote:
--- Adam Q <[EMAIL PROTECTED]> wrote:
The database needs a password otherwise it is just too much of a
security risk.
Based on my observation of the conversation you've been having, I think
you might be making things too complex on yourself. Th
--- Adam Q <[EMAIL PROTECTED]> wrote:
> The database needs a password otherwise it is just too much of a
> security risk.
Based on my observation of the conversation you've been having, I think
you might be making things too complex on yourself. This database is just
a file. So, think of havi
Ilia Alshanetsky wrote:
An Sqlite database is nothing more then a binary file, and you should treat it
such. If you do not want to have people being able to download it, do not put
it inside a web accessible directory.
Or, don't forget the existance of .htaccess files. Want to block sqlite
file
This one time, at band camp, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > I would like to distribute a tarball for a PHP application that can be
> > dropped into someones website along the same lines as PostNuke,
> > phpMyAdmin etc (you get the idea).
>
> Perhaps this is exactly why PostNuke is
On August 23, 2004 12:34 pm, Zeev Suraski wrote:
> The point is that hosting companies, especially those using chroot, have to
> make sure that they don't force their users to store the database files in
> web-accessible locations, since the server is most probably designed to be
> able to serve fi
At 17:16 23/08/2004, Ilia Alshanetsky wrote:
Here is the simple truth, if you are using a shared hosting solution that is
not VPS (Virtual Private Server) it would be relatively trivial for other
users of the system to access any file that the webserver has access to.
The point is that hosting comp
There are a lot of ways being a stupid programmer can give you an
insecure website. Saying that just because someone is too stupid to
properly lock down their data store (put outside the web root, run PHP
with proper perms, etc.), makes PHP/SQLite themselves insecure, is like
putting coffee on
Here is the simple truth, if you are using a shared hosting solution that is
not VPS (Virtual Private Server) it would be relatively trivial for other
users of the system to access any file that the webserver has access to. Now,
because webserver will need access privileges to various PHP config
On 23/08/2004, at 9:22 PM, [EMAIL PROTECTED] wrote:
Adam Q <[EMAIL PROTECTED]> writes:
I think encryption for SQLite is essential for PHP. Without it, it
makes it
almost useless in a webscripting language. Suppose you wanted to
create an
open source, easily portable, file based guestbook in PHP.
Adam Q wrote:
Putting the files outside the document root is secure, I agree... But
how can you be sure of this with an open source application (as opposed
to internally developed)? People are likely to drop your application
anywhere in their web tree they think it fits.
you document the problem
On Monday 23 August 2004 14:27, Zeev Suraski wrote:
[...]
>
> Hrm, well, it's a very bad idea to put the database anywhere under the
> document root, because then you'd obviously be serving it for everyone to
> download. Encryption or no encryption, that's a very bad idea.
> Instead, you should p
On Mon, 23 Aug 2004, Adam Q wrote:
> > Hrm, well, it's a very bad idea to put the database anywhere under the
> > document root, because then you'd obviously be serving it for everyone
> > to download. Encryption or no encryption, that's a very bad idea.
> > Instead, you should place the database
On 23/08/2004, at 8:27 PM, Zeev Suraski wrote:
At 15:18 23/08/2004, Adam Q wrote:
On 23/08/2004, at 7:24 PM, Zeev Suraski wrote:
At 13:56 23/08/2004, Adam Q wrote:
Dear all,
I feel I may have uncovered a potentially large difficulty for the
adoption of SQLite.
I think encryption for SQLite is ess
Adam Q <[EMAIL PROTECTED]> writes:
> I think encryption for SQLite is essential for PHP. Without it, it makes it
> almost useless in a webscripting language. Suppose you wanted to create an
> open source, easily portable, file based guestbook in PHP. I would never use
> SQLLite under the current
On Mon, 2004-08-23 at 12:24, Zeev Suraski wrote:
> I think that most database setups in general don't keep their information
> encrypted, and the reasons they use username/password pairs is mainly
> because (a) they're designed to serve multiple users (at the OS level) on
> the same machine, an
At 15:18 23/08/2004, Adam Q wrote:
On 23/08/2004, at 7:24 PM, Zeev Suraski wrote:
At 13:56 23/08/2004, Adam Q wrote:
Dear all,
I feel I may have uncovered a potentially large difficulty for the
adoption of SQLite.
I think encryption for SQLite is essential for PHP. Without it, it makes
it almost
On 23/08/2004, at 7:24 PM, Zeev Suraski wrote:
At 13:56 23/08/2004, Adam Q wrote:
Dear all,
I feel I may have uncovered a potentially large difficulty for the
adoption of SQLite.
I think encryption for SQLite is essential for PHP. Without it, it
makes it almost useless in a webscripting language
At 13:56 23/08/2004, Adam Q wrote:
Dear all,
I feel I may have uncovered a potentially large difficulty for the
adoption of SQLite.
I think encryption for SQLite is essential for PHP. Without it, it makes
it almost useless in a webscripting language.
Why is that? You would have to gain file-lev
Dear all,
I feel I may have uncovered a potentially large difficulty for the
adoption of SQLite.
I think encryption for SQLite is essential for PHP. Without it, it
makes it almost useless in a webscripting language.
Suppose you wanted to create an open source, easily portable, file
based guestb
25 matches
Mail list logo
