Re: [sqlite] Version 3.0.0 ALPHA now available

[Doug Currie]

Friday, June 18, 2004, 8:33:26 AM, DRH wrote:
> A file format and API freeze is scheduled for July 1.  Users
> are encouraged to evaluate this release and make suggestions
> on how to improve the interface prior to that date.

I ported Tiago Dionizio's LuaSQLite to version 3.0.1. Here are a
few SQLite C API comments based on that experience...

0. Overall the new API is easy to use and understand; it is a logical
extension to the version 2 API. Porting was straightforward and
offered new opportunities for BLOBs and stronger dynamic data typing.

1. Windows DLLs will need sqlite3_libversion() function.

2. Loss of the sqlite_error_string(errnum) function complicates things
a bit. Before the change a glue library could defer capturing the
error string when an error occurred. In fact, it could simply pass the
error code back to the caller, and let the caller decide if a string
was necessary. Now the onus is on the library to capture the error
string immediately. Two reasons: the caller may perform db operations
before inspecting the returned result code and deciding the string is
desired, or the library may need to do some db cleanup functions
(e.g., sqlite3_finalize) after an error occurs, and the caller will
want the string associated with the original call, not the cleanup.

3. It would be convenient to be able to get the size of an integer
before calling one of sqlite3_column_int sqlite3_column_int64 or
sqlite3_column_double. Of course, the glue library can do this with
sqlite3_column_int64 and some arithmetic; the point is that when
sqlite3_column_type returns SQLITE_INTEGER it is not apparent which of
the three above calls to retrieve the value is optimal. [In the case
of Lua the only choice is double or text; asking sqlite for a double
may lose precision if the integer is larger than 52 bits; asking for
text leads to excessive type conversions on the Lua side.]

4. It is odd that sqlite3_exec returns an error message string (well I
guess it is legacy code). It triggers the only use of sqlite3_free in
the glue library just to handle this string. [The library doesn't use
sqlite3_mprintf() or sqlite3_vmprintf() preferring
sqlite3_bind_xxx().] Note that the comment in the source above
sqlite3_free is incorrect w.r.t. sqlite3_open.

e


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: AW: [sqlite] SQLite website hacked

[D. Richard Hipp]

Matthias Zirngibl wrote:
Arg!  "cvs -v" tells me 1.11.5, which is ancient.  I've been doing
   apt-get update
   apt-get upgrade
which I thought was suppose to keep me up to date with all 
security patches.  But I guess not

Anonymous CVS access has been disabled until I can get this fixed.
Somebody please instruct me on the proper way to get security 
updates for debian

Please post your /etc/apt/sources.list
Maybe your CVS package is "On Hold" in APT?

apt-upgrade is giving me the following error.  Can
anyone explain?
Setting up util-linux (2.11n-7) ...
dpkg: error processing util-linux (--configure):
 subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
 util-linux
E: Sub-process /usr/bin/dpkg returned an error code (1)
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sqlite] v3 high memory consumption

[Miguel Angel Latorre Díaz]

Hi all.
I have a db v.3.0.1 of 32Mb with a single table and 598356 rows (no
indexes).
Doing a insert xx into select ...
using no joins, only sums and groups by, it takes hours to complete.
Besides RAM comsumption raises up to 500MB or more till I ran out of virtual
memory.
Rows are small in size.

I guess to do a group by one would have to sort rows and sorting is using
RAM. Could this explain it?
I've change vdbeaux.c line 773 to not use the sqlite3BtreeFactory (db
":memory:",...)
but it didnd't help. I'm a bit concerned about the high memory consumption
using "group by" (and posibly other statements).

I have the db (zipped is "only" 15MB) and a script to run with the .read
metacommand if anyone is interested.

By the way, the same happens with 2.x versions.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: AW: [sqlite] SQLite website hacked

[D. Richard Hipp]

Matthias Zirngibl wrote:
Arg!  "cvs -v" tells me 1.11.5, which is ancient.  I've been doing
   apt-get update
   apt-get upgrade
which I thought was suppose to keep me up to date with all 
security patches.  But I guess not

Anonymous CVS access has been disabled until I can get this fixed.
Somebody please instruct me on the proper way to get security 
updates for debian

Please post your /etc/apt/sources.list
Maybe your CVS package is "On Hold" in APT?


deb http://ftp.us.debian.org/debian/ stable main non-free
deb-src http://ftp.us.debian.org/debian/ stable main non-free
deb http://non-us.debian.org/debian-non-US stable/non-US main
deb-src http://non-us.debian.org/debian-non-US stable/non-US main
deb http://security.debian.org/ stable/updates main


--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] SQLite website hacked

[D. Richard Hipp]

Cesare D'Amico wrote:
Did you update your kernel (and rebooted) recently? Various 
vulnerabilities have been discovered during the last months (debian 
network has been cracked too, some months ago).

Kernel version 2.4.26 up 26 days.  Attack was 3 days ago.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] SQLite website hacked

[D. Richard Hipp]

Marco Bambini wrote:
On 25/giu/04, at 17:34, D. Richard Hipp wrote:
3 days ago, somebody broke into the SQLite website and
defaced the CVSTrac homepage.  (www.cvstrac.org and www.sqlite.org
share the same machine.)

You are not alone: 
http://www.zone-h.org/en/defacements/filter/filter_defacer=Russel-Aid/
Details at: 
http://www.zone-h.org/en/defacements/filter/filter_ip=64.5.53.192/

Unfortunately there is no information about the kind of attack...
The second link alerted me to another file that contained the
attack:  http://www.sqlite.org/index2.html
This supports my theory that the attack came in through CVS.
The main index page "index.html" is owned by root.  The attacker
could not overwrite it, so they created a alternative page at
index2.html.  So the boast that the machine was rooted, appears
to be just that - a boast.  In fact, the attacker was only able
to become the CVS user.
Who can help me move CVS into a chroot jail?
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] Bug or it makes sense?

[Nuno Lucas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Miguel Angel Latorre Díaz wrote:
|Kenneth:
|Thanks, I see your point, but that was just an example, put an "insert" or
|"delete" command instead of the "create table", and that row would be
|"inserted" or "deleted" without executing a rollback due to the SQL error.
|I haven't tested though. But perhaps, as you said, the create table makes
|its own transaction, but that shouldn't bother the rest of statements
|included in the explicit "outer transaction". Should it?
|
|I might be missing something but any number of statements surrounded by a
|begin/commit should all be done or undone.
|
|
|
I don't know if it should be considered a bug or a feature, but what
happens is that it works as expected if you issued the all the commands
in a sentence (that is all in the same line).
When they are separate, sqlite considers it is your responsibility to
check the error returned, as the rollback has occurred already.
That case also baffled me the first time I noticed it.
Regards,
~Nuno Lucas


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA3LKo24S9OitwspoRAiPcAJ4l0dvzT3JDLw+p08rTbxWijRbbVwCfSdUJ
dnd7Z9K+0C/iQ64Ph5RZovU=
=3Nwf
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] Memory Leak

[kenneth long]

Problem fixed... It was in the compile/reset logic..
it just kept compiling without resetting.

Ken

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] tclsqlite: can't load tclsqlite-3.0.1.so

[jux]

jux wrote:
Hello,
I do not manage to load tclsqlite-3.0.1.so into tclsh.
When I try to do it i get :
couldn't find procedure Tclsqlite_Init
   while executing
"load tclsqlite-3.0.1.so"
Does somebody know what I forgot to do ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

fix it like this :
load "tclsqlite-3.0.1.so" "tclsqlite3"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] Date/Time as Default Value

[Lawrence Chitty]

Hi

- Original Message -
From: "Frank Fabbrocino" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 24, 2004 4:22 AM
Subject: [sqlite] Date/Time as Default Value

> I would like to have a default value for a column be the current time.
This is basically a poor man's row creation timestamp. In Oracle SQL, I can
do the following:
>
> CREATE TABLE FOO (
> ID NUMBER NOT NULL,
> CREATED DATE DEFAULT SYSDATE NOT NULL );
>
> So, whenever a row is inserted into the table, you don't need to set the
2nd column because it is automatically set with the date/time of when the
insert occured. How would I do the equivalent of this in SQLite? I've tried
everything with "date" and "now" that I could think of but no luck...
>


there are some date functions (see
http://www.sqlite.org/cvstrac/wiki?p=DateAndTimeFunctions) but I can't get
these accepted as default value. However, a trigger can be set up to insert
the date when a new record is inserted. Try

CREATE TABLE foo (
id NUMBER NOT NULL,
created DATE);

CREATE TRIGGER insert_date AFTER INSERT ON foo
BEGIN
UPDATE foo SET created = DATETIME('NOW')  WHERE rowid = new.rowid;
END;

Lawrence




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.708 / Virus Database: 464 - Release Date: 18/06/04


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Fwd: [sqlite] Expect service interruptions Re: SQLite website hacked

[David Costa]

Very sad to hear that. If I can help anyway or if in the future you
are looking for a full mirror,
I would be glad to help.

Cheers
David Costa



On Fri, 25 Jun 2004 15:43:44 -0400, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
>
> Michael Roth wrote:
> > D. Richard Hipp wrote:
> >
> >> Arg!  "cvs -v" tells me 1.11.5, which is ancient.  I've been doing
> >>
> >>apt-get update
> >>apt-get upgrade
> >>
> >> which I thought was suppose to keep me up to date with all security
> >> patches.  But I guess not
> >
> >
> > For Debian 'woody' the latest cvs is 1.11.1p1, for Debian 'sarge' the
> > latest is 1.12.9.
> >
> > Check out: http://www.debian.org/security/2004/dsa-519
> >
>
> The problem appears to be that I had installed CVS manually,
> not using apt-get.  Thus when I used apt-get to upgrade, CVS
> was missed.  In other words - operator error.
>
> I have leased a new computer and am rebuilding the SQLite website
> on it now.  Once I get it up and running, I'll transfer the domain
> and cancel my lease on the existing machine.
>
> Please be patient of disruptions over the next few days...
>
> --
> D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sqlite] Expect service interruptions Re: SQLite website hacked

[D. Richard Hipp]

Michael Roth wrote:
D. Richard Hipp wrote:
Arg!  "cvs -v" tells me 1.11.5, which is ancient.  I've been doing
   apt-get update
   apt-get upgrade
which I thought was suppose to keep me up to date with all security
patches.  But I guess not

For Debian 'woody' the latest cvs is 1.11.1p1, for Debian 'sarge' the 
latest is 1.12.9.

Check out: http://www.debian.org/security/2004/dsa-519
The problem appears to be that I had installed CVS manually,
not using apt-get.  Thus when I used apt-get to upgrade, CVS
was missed.  In other words - operator error.
I have leased a new computer and am rebuilding the SQLite website
on it now.  Once I get it up and running, I'll transfer the domain
and cancel my lease on the existing machine.
Please be patient of disruptions over the next few days...
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: AW: AW: [sqlite] SQLite website hacked

[Matthias Zirngibl]

> apt-upgrade is giving me the following error.  Can anyone explain?
> 
> 
> Setting up util-linux (2.11n-7) ...
> dpkg: error processing util-linux (--configure):
>   subprocess post-installation script returned error exit 
> status 2 Errors were encountered while processing:
>   util-linux
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Hard to tell what causes this. You could do set this package temporarily on
hold, so that at least the cvs is updated:
echo util-linux hold | dpkg --set-selections


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: [sqlite] SQLite website hacked

[Michael Roth]

D. Richard Hipp wrote:
Arg!  "cvs -v" tells me 1.11.5, which is ancient.  I've been doing
   apt-get update
   apt-get upgrade
which I thought was suppose to keep me up to date with all security
patches.  But I guess not
For Debian 'woody' the latest cvs is 1.11.1p1, for Debian 'sarge' the 
latest is 1.12.9.

Check out: http://www.debian.org/security/2004/dsa-519

Somebody please instruct me on the proper way to get security
updates for debian
For Debian 'woody' the config file /etc/apt/sources.list should contain:
deb http://security.debian.org/ woody/updates main contrib non-free
For Debian 'sarge':
deb http://security.debian.org/ sarge/updates main contrib non-free
For Debian 'sarge', please note the quote from:
http://www.debian.org/releases/index.en.html
"...the main disadvantage is that it's not completely tested and has no 
official support from Debian security team."

You really shouldn't install anything later as Debian 'woody' (3.0) on a 
public server on the internet, because that's a security risk...

cu
Michael

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] Memory Leak

[kenneth long]

Daren

Agreed i found an earlier post. This is just the way
the coding works for the OS posix file locking bug
work around...

I think there is still another memory issue... Not
really a leak, but rather a huge amount of excessive
allocation happening... The sqlite_compile, bind,
reset logic seems to be using more and more  memory
each time through the loop, causing the processes
Virtual Memory foot print to grow. 

I don't think it should behave this way...Resetting
the VM should release any prior allocated memory ( or
at least mark it as re-usable) It seems to be
allocating additional memory each time through the
loop. 
I'm not sure where this is happening ( it could be in
the the bind, step or the reset )...

Again any input is appreciated.

Ken



--- Darren Duncan <[EMAIL PROTECTED]> wrote:
> My interpretation of your results is that you do not
> have a memory leak.
> 
> This is partly evidenced that all of the memory in
> the summary is 
> "still reachable"; a leak is defined as memory you
> have not freed but 
> can not reach.
> 
> I also know for a fact that SQLite maintains an
> in-memory cache to 
> speed things up, and that is probably why your
> memory usage increased 
> over time.
> 
> I don't see a problem.
> 
> -- Darren Duncan
> 
> At 10:11 AM -0700 6/25/04, kenneth long wrote:
> >Hi all,
> >I'm curious if anyone has experience a memory leak
> >with sqlite? Here is the program outline:
> >
> > Output:
> >Number of Mallocs: 101882
> >Number of Free   : 66747
> >--- Also I ran this through valgrind on linux and
> had
> >the following output...
> >
> >===
> >==3457== LEAK SUMMARY:
> >==3457==definitely lost: 0 bytes in 0 blocks.
> >==3457==possibly lost:   0 bytes in 0 blocks.
> >==3457==still reachable: 53791 bytes in 205
> blocks.
> >==3457== suppressed: 0 bytes in 0 blocks.
> >
> >So, I'm curious if this is "normal and expected
> >behavior" It seems that the program grows pretty
> >rapidly when using the compile/reset methods.. And
> >that  the VM memory is being added to each time
> >through the loop.
> >
> >Its starts at rough size of about 2m of Virtual
> Memory
> >and grows to 30M of VM through the execution of the
> >loop. Any ideas on how to reclaim this memory?
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 




__
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sqlite] default cache size optimal value

[David Costa]

Hello everyone,
I am still working on my PHP extension, quick question on  the pragma
default_cache_size:

>From your experience what would be an advisable value for a powerfull
hardware e.g. 1 gb ram, dual Xeon etc.

is there any  limit on the max size (e.g. 10,000 or 20,000) ?

Thanks
David Costa

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] Memory Leak

[Darren Duncan]

My interpretation of your results is that you do not have a memory leak.
This is partly evidenced that all of the memory in the summary is 
"still reachable"; a leak is defined as memory you have not freed but 
can not reach.

I also know for a fact that SQLite maintains an in-memory cache to 
speed things up, and that is probably why your memory usage increased 
over time.

I don't see a problem.
-- Darren Duncan
At 10:11 AM -0700 6/25/04, kenneth long wrote:
Hi all,
I'm curious if anyone has experience a memory leak
with sqlite? Here is the program outline:
 Output:
Number of Mallocs: 101882
Number of Free   : 66747
--- Also I ran this through valgrind on linux and had
the following output...
===
==3457== LEAK SUMMARY:
==3457==definitely lost: 0 bytes in 0 blocks.
==3457==possibly lost:   0 bytes in 0 blocks.
==3457==still reachable: 53791 bytes in 205 blocks.
==3457== suppressed: 0 bytes in 0 blocks.
So, I'm curious if this is "normal and expected
behavior" It seems that the program grows pretty
rapidly when using the compile/reset methods.. And
that  the VM memory is being added to each time
through the loop.
Its starts at rough size of about 2m of Virtual Memory
and grows to 30M of VM through the execution of the
loop. Any ideas on how to reclaim this memory?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] PRAGMA synchronous in SQLite version 3.0

[Darren Duncan]

At 9:51 AM -0400 6/25/04, D. Richard Hipp wrote:
QUESTION 1:
The default setting in version 2.8 is ON.  For version 3.0
we propose to change the default synchronous setting to FULL.
Does anybody have any problems with this?
No problem.  In fact, I would recommend the change to FULL regardless 
of whether that was being planned or not.

As a general rule, I always advocate default settings which are the 
most effective at safe data preservation.  Even if things are slower 
as a result, data integrity is the most important thing.  Any 
settings that allow for less safety should be explicitely enabled by 
a user that knows full well the consequences of what they are doing, 
and are willing to take the risks for extra speed.  And for people 
who don't know enough to judge whether they should take risks, they 
should be handed the safest option by default.  Naive users have to 
be able to trust that defaults are in most peoples' best interest.

And in this case, as you said, there is little perceivable difference 
between ON and FULL, so considering you are already using ON, FULL is 
a small price to pay.

QUESTION 2:
We propose to eliminate default_synchronous and have the
regular synchronous pragma change the synchronous setting
persistently.  Does anybody have any problems with this?
I suggest that you keep both options.  As Derrell said, for API consistency.
Alternately, I have a different suggestion.  Perhaps 
default_synchronous could simply always be FULL and that default 
isn't changeable.  Anyone who wants to change it will always do so on 
a non-persistent basis.

This is advantageous when, for example, multiple people are sharing a 
SQLite data file.  Subsequent users can always trust that the file is 
set to its safest mode by default, regardless of how the previous 
users worked with the file.

And even for those people who want a faster setting for some 
circumstance, it is little extra work to request that each time.  If 
code is opening the database, that's one extra line.  If its manual 
such as with the command line client, then people are unlikely to use 
said client very often in a non-synchronous way.

That's what I think.
-- Darren Duncan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] Bug or it makes sense?

[Kurt Welgehausen]

This is the usual behavior.  Read the sections BEGIN TRANSACTION
and ON CONFLICT in lang.html, especially the explanation of the
ABORT algorithm.

Regards

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] Bug or it makes sense?

[Miguel Angel Latorre Díaz]

Kenneth:
Thanks, I see your point, but that was just an example, put an "insert" or
"delete" command instead of the "create table", and that row would be
"inserted" or "deleted" without executing a rollback due to the SQL error.
I haven't tested though. But perhaps, as you said, the create table makes
its own transaction, but that shouldn't bother the rest of statements
included in the explicit "outer transaction". Should it?

I might be missing something but any number of statements surrounded by a
begin/commit should all be done or undone.


- Original Message - 
From: "kenneth long" <[EMAIL PROTECTED]>
To: "Miguel_Angel_Latorre_Díaz" <[EMAIL PROTECTED]>
Sent: Friday, June 25, 2004 7:31 PM
Subject: Re: [sqlite] Bug or it makes sense?


> Miguel,
>
> I suspect that similar to most SQL languages the
> "Create" statements are their own transactions and
> perform an automatic commit.. Thats the way Oracle
> performs as do many others.
>
>
>
> --- Miguel_Angel_Latorre_Díaz
> <[EMAIL PROTECTED]> wrote:
> > Ok. But if one just does (also tried with the .read
> > metacommand):
> > sqlite3_exec (db, "begin; create table foo (value1
> > integer, value2 integer);
> > just an error; commit;", rest of params...)
> >
> > should it do the same?
> > To me, the "begin; ..." is a whole multi statement
> > which should be done
> > whitin a transaction because of the "begin". So, all
> > or nothing, but I get a
> > mixture.
> >
> >
> >
> -
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
>
>
>
>
> __
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: [sqlite] SQLite website hacked

[Derrell . Lipman]

"D. Richard Hipp" <[EMAIL PROTECTED]> writes:

> Somebody please instruct me on the proper way to get security
> updates for debian

Be sure you have the following line in /etc/apt/sources.list and prior to
doing "apt-get update ; apt-get upgrade"

  deb http://security.debian.org/ stable/updates main contrib non-free

If you already have that in your source.list file, then there's something more
seriously wrong (possibly it's "pinned" at the old version?)  Someone else
will have to tell you how to determine if you've inadvertently pinned cvs to
an old version, and how to unpin it; I don't recall how.

Derrell

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: AW: [sqlite] SQLite website hacked

[Matthias Zirngibl]

> Arg!  "cvs -v" tells me 1.11.5, which is ancient.  I've been doing
> 
> apt-get update
> apt-get upgrade
> 
> which I thought was suppose to keep me up to date with all 
> security patches.  But I guess not
> 
> Anonymous CVS access has been disabled until I can get this fixed.
> 
> Somebody please instruct me on the proper way to get security 
> updates for debian

Please post your /etc/apt/sources.list

Maybe your CVS package is "On Hold" in APT?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sqlite] SQLite website hacked

[kenneth long]

I recall, recently the CVS website posting a "security
bulletin" They had to entirely rebuild their site.
This was because the pserver (cvs bacground server)
had a serious security flaw that allowed an attacker
to run commands on the host.  Here is a link to the
details!!!

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0396

Ken





__
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] SQLite website hacked

[Cesare D'Amico]

Alle 17:34, venerdì 25 giugno 2004, D. Richard Hipp ha scritto:
> Anybody have any clues how an attacker might have gotten in?
> Does anybody have any advice on how best to secure the system?

Did you update your kernel (and rebooted) recently? Various 
vulnerabilities have been discovered during the last months (debian 
network has been cracked too, some months ago).

-- 
Cesare D'Amico - Key on pgp.mit.edu, ID 92802693
http://cesaredamico.com  ~  http://phpday.it  ~  http://verona.linux.it/
Ho messo via un po' di consigli, dicono e` piu` facile,   | Liga, 
li ho messi via perche' a sbagliare sono bravissimo da me | Ho messo via

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: [sqlite] SQLite website hacked

[Matthias Zirngibl]

> On 25/giu/04, at 17:34, D. Richard Hipp wrote:
> 
> > 3 days ago, somebody broke into the SQLite website and defaced the 
> > CVSTrac homepage.  (www.cvstrac.org and www.sqlite.org 
> share the same 
> > machine.)
> 
> You are not alone: 
> http://www.zone-h.org/en/defacements/filter/filter_defacer=Russel-Aid/
> Details at: 
> http://www.zone-h.org/en/defacements/filter/filter_ip=64.5.53.192/
> 

If you look on this site you see this entry:
2004/06/24 Russel-Aid Hcvs.designcommunity.com FreeBSD 

Looks like an CVS-server. Besides that it's FreeBSD, so it is unlikely a
Linux flaw. Which version of CVS where you using at the time of the attack?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] SQLite versions in CVS

[John Oliva]

Thanks.  What file should I reference to get the data/time for past
releases?
 
John

Re: [sqlite] SQLite website hacked

[Marco Bambini]

On 25/giu/04, at 17:34, D. Richard Hipp wrote:
3 days ago, somebody broke into the SQLite website and
defaced the CVSTrac homepage.  (www.cvstrac.org and www.sqlite.org
share the same machine.)
You are not alone: 
http://www.zone-h.org/en/defacements/filter/filter_defacer=Russel-Aid/
Details at: 
http://www.zone-h.org/en/defacements/filter/filter_ip=64.5.53.192/

Unfortunately there is no information about the kind of attack...
Marco Bambini
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] SQLite website hacked

[Louis P. Santillan]

It looks like you were not the only person to have
their webserver hacked
.
 Since you are running an "atypical" web server,
chances are the cracker got in with either a Linux
root kit, a ssh flaw, or a CVS flaw (Linux and CVS
have security alerts that were sent out in the last 10
days or so).

The only other reference I found of Russel-l-Aid  was
this Italian site
.

Louis

--- "D. Richard Hipp" <[EMAIL PROTECTED]> wrote:
> 3 days ago, somebody broke into the SQLite website
> and
> defaced the CVSTrac homepage.  (www.cvstrac.org and
> www.sqlite.org
> share the same machine.)
> 
> I do not know how the attacker got in.  The message
> left
> on the homepage of www.cvstrac.org was "Rooted by
> Russel-Aid'.
> 
> www.sqlite.org runs a minimal Debian 3.0.  qmail is
> used for
> the mailing list.  CVS is running.  The web server
> is a custom
> implementation running in a chroot jail.  CVSTrac
> runs in a chroot
> jail.  And sshd is running.  There is a private chat
> server written
> in TCL running on an unpublished port. Nothing else.
> I keep the system
> updated at all times with the latest Debian security
> patches.
> In particular, the most recent CVS patches have been
> installed.
> 
> Anybody have any clues how an attacker might have
> gotten in?
> Does anybody have any advice on how best to secure
> the system?
> 
> I'm up to my eyeballs with SQLite version 3 right
> now.  Anybody
> with the time, skills, and inclination to help fix
> this is
> welcomed to volunteer by calling me at the phone
> number below.
> 
> Thanks.
> -- 
> D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 




__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] Multi-User design

[Wempa, Kristofer \(Kris\), ALABS]

This really depends on many things.  How often are the individual tables
accessed and is the access spread evenly across them ?  Also, what will
there be a lot more reading than writing or will it be a close ratio ?
We recently used sqlite in a multi-user environment using only a single
database and ran into some issues. The problem occurred because the
reads and writes were conflicting and we were getting a lot of "busy"
statuses.  We resolved the problem by re-compiling and setting the read
lock attempts to blocking instead of non-blocking.  It worked fine, but
obviously the more reads/writes going on, the slower things got.
Looking back, I probably would have split the databases up into 1 per
table because of the nature of our program.  Either way will work, but
having a lot of reads and writes hammering on the same database files
requires higher timeout settings or blocking reads.  I'd like to know
which solution you choose and how it works.


-Original Message-
From: Chris Ulliott [mailto:[EMAIL PROTECTED]
Sent: Friday, June 25, 2004 8:28 AM
To: [EMAIL PROTECTED]
Subject: [sqlite] Multi-User design


Hi All,
 
When using SQLite3 in a multi user environment is it better to have a
single table per database file or is it better to have just one file
which contains all tables in the database?
 
I am worried about the file locking, I do not want users to have to wait
for a table to become accessible just because another user is updating a
different table within the database.
 
What is the cost of performance if I put the tables into separate
database files?
 
Kind Regards,
 
Chris
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sqlite] SQLite website hacked

[D. Richard Hipp]

3 days ago, somebody broke into the SQLite website and
defaced the CVSTrac homepage.  (www.cvstrac.org and www.sqlite.org
share the same machine.)
I do not know how the attacker got in.  The message left
on the homepage of www.cvstrac.org was "Rooted by Russel-Aid'.
www.sqlite.org runs a minimal Debian 3.0.  qmail is used for
the mailing list.  CVS is running.  The web server is a custom
implementation running in a chroot jail.  CVSTrac runs in a chroot
jail.  And sshd is running.  There is a private chat server written
in TCL running on an unpublished port. Nothing else. I keep the system
updated at all times with the latest Debian security patches.
In particular, the most recent CVS patches have been installed.
Anybody have any clues how an attacker might have gotten in?
Does anybody have any advice on how best to secure the system?
I'm up to my eyeballs with SQLite version 3 right now.  Anybody
with the time, skills, and inclination to help fix this is
welcomed to volunteer by calling me at the phone number below.
Thanks.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sqlite] problem on table create and synchronous in 3.0.1

[Guillaume Fougnies]

This bug is happening on a new empty db file with two sqlite_exec.
It's a test request, it's nonsense.

$ sqlite3 test.db
SQLite version 3.0.1
Enter ".help" for instructions
sqlite> BEGIN;CREATE TABLE TEST(id INT); PRAGMA default_synchronous=OFF;
sqlite> COMMIT;
sqlite3: src/pager.c:1548: syncJournal: Assertion `pPg->needSync==0'
failed.Aborted

--
Guillaume FOUGNIES

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sqlite] tclsqlite: can't load tclsqlite-3.0.1.so

[jux]

Hello,
I do not manage to load tclsqlite-3.0.1.so into tclsh.
When I try to do it i get :
couldn't find procedure Tclsqlite_Init
   while executing
"load tclsqlite-3.0.1.so"
Does somebody know what I forgot to do ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] PRAGMA synchronous in SQLite version 3.0

[Derrell . Lipman]

"D. Richard Hipp" <[EMAIL PROTECTED]> writes:

> QUESTION 1:
> The default setting in version 2.8 is ON.  For version 3.0
> we propose to change the default synchronous setting to FULL.
> Does anybody have any problems with this?

I have no problem with this.

> QUESTION 2:
> We propose to eliminate default_synchronous and have the
> regular synchronous pragma change the synchronous setting
> persistently.  Does anybody have any problems with this?

A possible problem with this is that it creates a naming inconsistency.  There
are other "default_*" pragmas which cause a persistent change.  In looking
through the pragma documentation, I don't see any non-"default_*" pragmas
which currently cause a persistent change, so this one would be unique.

If you were to delete one of the two, I would think it would be to delete
"synchronous" and retain "default_synchronous" given the meaning you are
trying to portray.  Unfortunately, that too would create an inconsistency
(although not as significant of one) in that all of the other "default_*"
pragmas have a non-"default_*" equivalent for transient use.

Derrell

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sqlite] PRAGMA synchronous in SQLite version 3.0

[D. Richard Hipp]

We have some questions about the "synchronous" pragma and
how it should work in version 3.0.  Feedback from the user
community is welcomed.
First some review:
The synchronous pragma determines how agressive SQLite is
about making sure data really reaches the surface of the
disk drive as opposed to just being stored in the operating
systems filesystem cache.  There are three possible
settings:
   PRAGMA synchronous=off;
   PRAGMA synchronous=on;
   PRAGMA synchronous=full;
When synchronous is OFF, no effort is made to flush data
to the disk.  This means an unexpected power loss or an
OS crash can corrupt the database.  When synchronous is
ON, data is flushed to disk at key points so that the
database is (usually) safe from corruption during a power
loss.  FULL synchronous does some additional disk flushes
in order to guard against a race condition that can lead
to database corruption following a power failure on
unjournalled filesystems.
Generally speaking, writes happen faster when synchronous
is OFF, but at the price of a serious risk of database
corruption following a power failure.  ON is a little
faster than FULL, but not by much.  Most users will not
notice the difference between ON and FULL.
There are actually two synchronous pragmas.  The normal
"synchronous" pragma only effects the current session.
When the database is reopened, the synchronous setting
reverts to what it was.  A second "default_synchronous"
pragma changes the synchronous setting persistently.
QUESTION 1:
The default setting in version 2.8 is ON.  For version 3.0
we propose to change the default synchronous setting to FULL.
Does anybody have any problems with this?
QUESTION 2:
We propose to eliminate default_synchronous and have the
regular synchronous pragma change the synchronous setting
persistently.  Does anybody have any problems with this?
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sqlite] Multi-User design

[Chris Ulliott]

Hi All,
 
When using SQLite3 in a multi user environment is it better to have a
single table per database file or is it better to have just one file
which contains all tables in the database?
 
I am worried about the file locking, I do not want users to have to wait
for a table to become accessible just because another user is updating a
different table within the database.
 
What is the cost of performance if I put the tables into separate
database files?
 
Kind Regards,
 
Chris
 

Re: [sqlite] SQL Syntax from 2.8 to 3.0 not backward compatible?

[Guillaume Fougnies]

Ok.
Perhaps it should be written in the documentation of
"SQLite Version 3" or in the chapter "Transaction Control At The SQL
Level" of the "Locking And Concurrency In SQLite Version 3".

Thanks.
bye.

Fri, Jun 25, 2004 at 04:22:10AM -0700: Daniel K wrote:
> A BEGIN cannot have an ON CONFLICT clause in sqlite
> version 3.
>
> Dan.
>
>
> --- Guillaume Fougnies <[EMAIL PROTECTED]> wrote:
> > Here is it:
> >
> > SQLite version 3.0.1
> > Enter ".help" for instructions
> > sqlite> BEGIN TRANSACTION ON CONFLICT ROLLBACK;
> > SQL error: near "ON": syntax error
> >
> > bye.

--
Guillaume FOUGNIES

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] SQL Syntax from 2.8 to 3.0 not backward compatible?

[Daniel K]

A BEGIN cannot have an ON CONFLICT clause in sqlite
version 3.

Dan.


--- Guillaume Fougnies <[EMAIL PROTECTED]> wrote:
> Here is it:
> 
> SQLite version 3.0.1
> Enter ".help" for instructions
> sqlite> BEGIN TRANSACTION ON CONFLICT ROLLBACK;
> SQL error: near "ON": syntax error
> 
> bye.
> --
> Guillaume FOUGNIES
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 





__
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sqlite] SQL Syntax from 2.8 to 3.0 not backward compatible?

[Guillaume Fougnies]

Here is it:

SQLite version 3.0.1
Enter ".help" for instructions
sqlite> BEGIN TRANSACTION ON CONFLICT ROLLBACK;
SQL error: near "ON": syntax error

bye.
--
Guillaume FOUGNIES

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sqlite] SPLite3 compiling under MS VC6

[Chris Ulliott]

Hi All,
 
Does anyone have a VC6 project of the splite3 DLL. I would like the
ability to recompile it myself so that I can add my own specific changes
etc.. Also when a new release comes out I would like to take the new
code, do a comparison to my own, add the changes and re-compile again.
 
When I download the code for the DLL and do a compile I get lots of
warnings regarding the size of variables (which maybe ok to ignore but
they annoy me) and also after the DLL is compiled, zero functions are
exported!
 
Any help you could give me on compiling in VC6 would be very much
appreciated.
 
Thank you,
 
Chris
 

Re: [sqlite] A quick code review, analysis of locking model, "fine-tuning" suggestions

[Daniel K]

Hi Ben,

Just addressing the locking things for now, not the
code review stuff. Although I'm interested to find
out if we really have a problem with sqlite3OsRead().
(wow)

> ... been reviewing the locking model for about
> four hours now to get to this point ...

Thanks for this. It is much appreciated by all
concerned I assure you. Everyone else who has been
helping too.

I put in some more comments about the implementation
of the locking model, and what it is supposed to do.
Some are reproduced below. You're right that the
current model would deadlock if blocking locks were
substituted in. It would be better if this were not
the case. 

The RESERVED/PENDING state mechanism reduces the 
requirement some though.

Another thing to keep in mind is that transactions
are atomic across multiple databases now. This means
that if you're in a transaction you can't drop
a read-lock on a database you have read from until
after the transaction is concluded.

Any more ideas/clarifications are welcome. It's a 
prety complicated topic, I'm still trying to get my
head around it all.

Dan.  

/*
** The following values may be passed as the second
** argument to sqlite3OsLock(). The various locks
** exhibit the following semantics:
**
** SHARED:Any number of processes may hold a
**SHARED lock simultaneously.  
** RESERVED:  A single process may hold a RESERVED
**lock on a file at any time. Other
**processes may hold and obtain new SHARED
**locks.  
** PENDING:   A single process may hold a PENDING lock
**on a file at any one time. Existing
**SHARED locks may persist, but no new
**SHARED locks may be obtained by other
**processes.  
**
** EXCLUSIVE: An EXCLUSIVE lock precludes all other
** locks.
**
** PENDING_LOCK may not be passed directly to
** sqlite3OsLock(). Instead, a process that requests
** an EXCLUSIVE lock may actually obtain a PENDING
** lock. This can be upgraded to an EXCLUSIVE lock by
** a subsequent call to sqlite3OsLock().
*/

/* The following describes the implementation of the
** various locks and lock transitions in terms of the
** POSIX advisory shared and exclusive lock primitives
** (called read-locks and write-locks below, to avoid
** confusion with SQLite lock names). The algorithms
** are complicated slightly in order to be compatible
** with windows systems simultaneously accessing the
** same database file, in case that is ever required.
**
** Symbols defined in os.h indentify the 'pending
** byte' and the 'reserved byte', each single bytes at
** well known offsets, and the 'shared byte range', a
** range of 510 bytes at a well known offset.
**
** To obtain a SHARED lock, a read-lock is obtained on
** the 'pending byte'.  If this is successful, a
** random byte from the 'shared byte range' is
** read-locked and the lock on the 'pending byte'
** released.
**
** A process may only obtain a RESERVED lock after it
** has a SHARED lock.  A RESERVED lock is implemented
** by grabbing a write-lock on the 'reserved byte'. 
**
** A process may only obtain a PENDING lock after it
** has obtained a SHARED lock. A PENDING lock is
** implemented by obtaining a write-lock on the
** 'pending byte'. This ensures that no new SHARED
** locks can be obtained, but existing SHARED locks
** are allowed to persist. A process does not have to
** obtain a RESERVED lock on the way to a PENDING
** lock.  This property is used by the algorithm for
** rolling back a journal file after a crash.
**
** An EXCLUSIVE lock, obtained after a PENDING lock is
** held, is implemented by obtaining a write-lock on
** the entire 'shared byte range'. Since all other
** locks require a read-lock on one of the bytes
** within this range, this ensures that no other locks
** are held on the database. 
**
** The reason a single byte cannot be used instead of
** the 'shared byte range' is that some versions of
** windows do not support read-locks. By locking a
** random byte from a range, concurrent SHARED locks
** may exist even if the locking primitive used is
** always a write-lock.
*/







__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]