Interesting but doesn't seem overly practical. If you're in a postiion to
run 'busybox ash /foo/bar' then you can easily create a shell script
through simpler means.
Filesystem access via ATTACH DATABASE is worth bringing attention to
though, as I think a lot of developers wouldn't expect that. It
well, if you have a sysadmin that has "." in their path, you could write a
database called "ls" or common misspellings of commands, and that way
execute arbitrary code if the sysadmin visits the system.
Wout.
On Wed, Nov 16, 2016 at 11:43 AM Rowan Worth wrote:
> Interesting but doesn't seem ove
On 16 Nov 2016, at 7:25am, Jens Alfke wrote:
> The case I’m concerned about happens on Macs, as I said, and the developer
> says he can trigger it in his app via a power failure or a forced shutdown
> (holding the power button for 5 seconds.) This version of our library is one
> I wrote, in O
Not true. You can go ahead and create a database called "ls", but:
a) it will not be executable, and
b) the file will start with "SQLite format 3" rather than the requisite
"#!/bin/busybox ash"
So the sysadmin would still have to manually execute the "script" with an
appropriate shell.
-Rowan
On
On 11/16/16, Simon Slavin wrote:
>
> There's also a tool from the SQLite team which can analyze a corrupt SQLite
> file and tell some things about how it is corrupt. Unfortunately I can't
> remember what it's called or where to find it. But I heard about it on this
> list and I hope someone can.
> > I still cannot fathom why anyone would assign random numbers or (even
> more useless) long random blobs to use as psuedo-keys. It just boggles
> the mind.
> I take it you’re not a cryptographer :) All modern ciphers do this. For
> example, an RSA key pair is simply a pair of large random n
On 11/16/16, Keith Medcalf wrote:
> What I do not
> understand is why one would use a UUID (randomly generated bunch of bytes)
> as a key in a database. It is long, every use must be checked for
> collisions, and inherently far less efficient than the simple integer
> sequence it is replacing.
I
Hi,
I have a table that is giving me errors. I can recover the
data from another source, but need a way to clear the table. The following is
my process:
Read row from table1 - detect error (SQL logic error or missing database).
Have been able to read other rows from same table
On Wed, Nov 16, 2016 at 7:59 AM, Keith Medcalf wrote:
> Using the systemid sequence and the recordid sequence directly however,
> has a 0% probability of collision, so any rational person would use that
> directly and forgo entirely the introduction of uncertainty and bugs using
> "UUID" type cra
On 16 Nov 2016, at 2:52pm, Andrew Stewart wrote:
>I have a table that is giving me errors. I can recover the
> data from another source, but need a way to clear the table.
This process is very fast and easy, but it may not help with your form of
corruption.
Open the database
Simon,
Thank you for the response. I will give it a try. I can do this with
2 different database connections and then just transfer all of the tables from
database1 to database2. Close database1. Remove/rename the file for database1.
Close database2. Rename file for database2 to fil
Simon,
Forgot to ask 1 thing. What is a quick way to copy an entire table
from database1 to database2?
Thanks,
Andrew
-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On
Behalf Of Andrew Stewart
Sent: Wednesday, November 16, 2016 7:16
On 16 Nov 2016, at 3:14pm, Andrew Stewart wrote:
>
>Thank you for the response. I will give it a try. I can do this with
> 2 different database connections and then just transfer all of the tables
> from database1 to database2. Close database1. Remove/rename the file for
> database
On 16 Nov 2016, at 3:16pm, Andrew Stewart wrote:
> Forgot to ask 1 thing. What is a quick way to copy an entire table
> from database1 to database2?
If they are open in different connections you cannot do it.
If they are open in the same connection using ATTACH then you can do it like
On 11/16/2016 05:53 AM, Nico Williams wrote:
I don't normally pay attention to warnings when compiling SQLite3, nor
to Coverity or other static analysis tools' output either, as I'm quite
aware that most of these are false positives and thus unwelcome noise
here.
However, I do sample them occasi
On Wed, 16 Nov 2016 08:59:03 -0600
Paul Egli wrote:
> > Using the systemid sequence and the recordid sequence directly
> > however, has a 0% probability of collision, so any rational person
> > would use that directly and forgo entirely the introduction of
> > uncertainty and bugs using "UUID" ty
On Tue, Nov 15, 2016 at 09:38:11PM -0200, Bernardo Sulzbach wrote:
> if( s1>7 && s2>7 ){
> res = s1 - s2;
> }else{
> if( s1==s2 ){
> // Accesses to aLen as mentioned above
>
> If s1 > 7 && s2 > 7 is false, then at least one of s1 and s2 is not above 7.
> If they are equal, then n
On Wed, Nov 16, 2016 at 10:52:13PM +0700, Dan Kennedy wrote:
> On 11/16/2016 05:53 AM, Nico Williams wrote:
> > [...]
> >
> > Anyways, the analysis from here is non-trivial, and I can't convince
> > myself that sNC.pNext will not be dereferenced.
>
> Thanks for taking the time to look into these.
On Wed, Nov 16, 2016 at 12:06:39PM -0600, Nico Williams wrote:
> On Tue, Nov 15, 2016 at 09:38:11PM -0200, Bernardo Sulzbach wrote:
> > if( s1>7 && s2>7 ){
> > res = s1 - s2;
> > }else{
> > if( s1==s2 ){
> > // Accesses to aLen as mentioned above
> >
> > If s1 > 7 && s2 > 7 is fa
On Nov 16, 2016, at 8:46 AM, Richard Hipp wrote:
>
>> On 11/16/16, Keith Medcalf wrote:
>> What I do not
>> understand is why one would use a UUID (randomly generated bunch of bytes)
>> as a key in a database. It is long, every use must be checked for
>> collisions, and inherently far less effi
On Wed, Nov 16, 2016 at 02:51:35PM -0600, Jeffrey Mattox wrote:
> On Nov 16, 2016, at 8:46 AM, Richard Hipp wrote:
> >
> >> On 11/16/16, Keith Medcalf wrote:
> >> What I do not
> >> understand is why one would use a UUID (randomly generated bunch of bytes)
> >> as a key in a database. It is lon
If you are unsucessful dro me an email - I might be able to help (not
a commercial proposition - just may help me doing some testing with my
code)
Cheers
Paul
www.sandersonforensics.com
skype: r3scue193
twitter: @sandersonforens
Tel +44 (0)1326 572786
http://sandersonforensics.com/forum/content.ph
https://xkcd.com/221/
"The generation of random numbers is too important to be left to chance." -I
forget who
A UUID is basically a 16 byte integer that people agree to type out in a
standard way. All the properties of UUID's that you've mentioned below depend
on the random number generator b
On Wed, Nov 16, 2016 at 02:51:35PM -0600, Jeffrey Mattox wrote:
> I think this discussion is about apples and oranges. UUID stands for
> universally UNIQUE identifier, so there won't be any collisions. It
> looks random, but it never repeats. [...]
No, DRH is right that this depends on how good
> As someone mentioned in a different part of this thread, the issue is
> centralization. If you have multiple decentralied machines generating
> UUIDs you *could* have collisions, but if you pick your UUID scheme well
> enough collisions will be extremely rare, on par with things like data
> loss
On 17 Nov 2016, at 3:13am, Keith Medcalf wrote:
> You would only get guaranteed collision avoidance if you kept track of every
> UUID issued and checked for duplicates at time of issue to avoid duplication
> by keeping a list of all the "used" identifiers. I do not think that keeping
> track
26 matches
Mail list logo
