> From: owner-openssl-us...@openssl.org On Behalf Of Marc Phillips > Sent: Thursday, 05 August, 2010 11:20
> Ger Hobbelt <g...@hobbelt.com> wrote: > > Got some sample data to show which makes the bugger fail? > > sqlite3 /tmp/MyTestsqlite.db > SQLite version 3.3.6 > Enter ".help" for instructions > sqlite> CREATE TABLE test (id INTEGER primary key > AUTOINCREMENT, test TEXT); > sqlite> .quit > > encode: <snipped> > The code above yields the following encoded file: <snipped> So you're encoding the whole db, not data in it. Linebreaks are good here, because this can be huge. > If I do the following I get back the db: > cat /tmp/MyTestsqlite.db.b64 | openssl enc -base64 -d > > /tmp/MyTestsqlite.db.unb64 > (Aside: you don't need cat there. Just redirect 'enc' input.) > sqlite3 /tmp/MyTestsqlite.db.unb64 <snipped> > But if I use the code below to decode, It stops at byte 15: > buffer = SQLite format 3, outlen = 15, inlen = 4160 > > Decode: > b64 = BIO_new(BIO_f_base64()); > bmem = BIO_new_mem_buf(inbuf, inlen); > bmem = BIO_push(b64, bmem); > outlen=BIO_read(bmem,outbuf,inlen); > BIO_free_all(bmem); > If I use exactly that code, with obvious declarations added, and inbuf/inlen = the encoded data you posted, I get outlen=3072 and outbuf contains data looking like what commandline produces (and you confirm is correct). You say 'buffer' = 'SQLite format 3', but there is no 'buffer' in your code. If you meant 'inbuf', that input is clearly not remotely similar to the encoded data you posted. Also it's suspicious to use inlen as max-read. While it's possible you've allocated your outbuf to be the same size as your encoded input (or greater) it's rather odd to do that. The outbuf size should be the amount of *decoded* data you expect and/or allow, and max-read should be that. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
