Re: [sqlite] Beginning of release testing for version 3.17.0

[Keith Medcalf]

You can always write your own SHA-224/SHA-256/SHA-512/RIPEMD160/WHIRLPOOL or 
other hash function extension.  I wrote an extension that provides 
MD4/MD5/SHA1/SHA256/SHA512 on Windows using the built-in Windows Crypto API 
functions.  Once you can call something that computes the hash, making it an 
extension is not that difficult.

The advantage of the SHA1 extension to SQLite is that it has no external 
dependencies, is cross platform, and is unencumbered, just like the rest of 
SQLite.

> -Original Message-
> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org]
> On Behalf Of Jens Alfke
> Sent: Monday, 27 February, 2017 17:44
> To: SQLite mailing list
> Subject: Re: [sqlite] Beginning of release testing for version 3.17.0
> 
> 
> > On Feb 27, 2017, at 3:51 PM, Bob Friesenhahn
> <bfrie...@simple.dallas.tx.us> wrote:
> >
> > Are you somehow depending on sqlite3 for a SHA-1 implementation? That
> would be strange.
> 
> I’m genuinely mystified by this statement. Why would the extension be
> included if not for people to use it?
> 
> (I’m not using this extension myself. But I am in the process of
> investigating the Shattered vulnerability and filing issues against the
> components of our software that use SHA-1, and thinking about how to
> upgrade them to use SHA-256 or SHA-3.)
> 
> > The SHA-1 implementation in SQLite is surely intended to ease certain
> aspects of SQLite development
> 
> If it were for internal use only, why expose it publicly as an extension,
> and incur the overhead of having to support it and keep its API
> consistent?
> 
> —Jens
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Beginning of release testing for version 3.17.0

[Jens Alfke]

> On Feb 27, 2017, at 3:51 PM, Bob Friesenhahn  
> wrote:
> 
> Are you somehow depending on sqlite3 for a SHA-1 implementation? That would 
> be strange.

I’m genuinely mystified by this statement. Why would the extension be included 
if not for people to use it?

(I’m not using this extension myself. But I am in the process of investigating 
the Shattered vulnerability and filing issues against the components of our 
software that use SHA-1, and thinking about how to upgrade them to use SHA-256 
or SHA-3.)

> The SHA-1 implementation in SQLite is surely intended to ease certain aspects 
> of SQLite development

If it were for internal use only, why expose it publicly as an extension, and 
incur the overhead of having to support it and keep its API consistent?

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Beginning of release testing for version 3.17.0

[Bob Friesenhahn]

On Mon, 27 Feb 2017, Jens Alfke wrote:


SHA-1 is now definitely too weak, so it would be good for SQLite to offer an 
alternative that’s still safe(r).)


Are you somehow depending on sqlite3 for a SHA-1 implementation? 
That would be strange.


The SHA-1 implementation in SQLite is surely intended to ease certain 
aspects of SQLite development which are assisted from a portable 
implementation with no external dependencies.


The mere existence of an implementation does not mean that it is a 
defect.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Beginning of release testing for version 3.17.0

[Jens Alfke]

> On Feb 7, 2017, at 7:39 AM, no...@null.net wrote:
> 
> Nice to see a sha1 extension included with SQLite now.

… Just in time for SHA-1 to be declared officially broken: there’s now an 
effective mechanism to generate collisions (it only takes 100 GPU-years), and 
at least two colliding files are in the wild and have already wreaked havoc on 
SVN repositories they’ve been checked into:
https://shattered.io

https://arstechnica.com/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow/

It may be too late for 3.17, but it would be a good idea to add SHA-256 and/or 
SHA-3 ASAP.
Also, there is a ‘hardened’ implementation of SHA-1, a drop-in replacement that 
detects and rejects input data that shows the hallmarks of the collision 
attack. It would be great to use this for SQLite’s SHA1 function:
https://github.com/cr-marcstevens/sha1collisiondetection

(I don’t want to reopen the argument about whether it’s reasonable to treat any 
digest as a unique identifier! The fact is that, like it or not, cryptographic 
digests are very commonly used for this purpose, and most (but not all) 
security professionals think it’s reasonable to, as long as the algorithm is 
strong enough. SHA-1 is now definitely too weak, so it would be good for SQLite 
to offer an alternative that’s still safe(r).)

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Beginning of release testing for version 3.17.0

[Cecil Westerhof]

2017-02-09 18:46 GMT+01:00 Roger Binns :

> On 08/02/17 11:41, Cecil Westerhof wrote:
> > ​OK, glad to help. What should I do?
>
> It is nicest if whatever software/tools you already have also has some
> sort of testing (ideally automated, but a manual checklist works too).
>
> Then run the testing with the existing version of SQLite, and repeat
> with the new (draft) version.  You should see no differences in the
> results from SQLite (correctness).  You may see some performance
> improvements, and if very unlucky regressions.
>

​​
​Only do some very simple store and retrieve things. I'll think about how
to do something with that.
I could just do a bunch of things and send the output to a file with the
current one and the new one and check that they are the same. That can be
automated.
​

​


> Then report those differences.  Correctness is the most important, but
> performance is relevant.
>

​Some time ago I posted something about bad performance. I could try that
with my current and the new version.

-- 
Cecil Westerhof
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Beginning of release testing for version 3.17.0

[Roger Binns]

On 08/02/17 11:41, Cecil Westerhof wrote:
> ​OK, glad to help. What should I do?

It is nicest if whatever software/tools you already have also has some
sort of testing (ideally automated, but a manual checklist works too).

Then run the testing with the existing version of SQLite, and repeat
with the new (draft) version.  You should see no differences in the
results from SQLite (correctness).  You may see some performance
improvements, and if very unlucky regressions.

Then report those differences.  Correctness is the most important, but
performance is relevant.

Roger



signature.asc
Description: OpenPGP digital signature
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Beginning of release testing for version 3.17.0

[Cecil Westerhof]

2017-02-08 16:49 GMT+01:00 Richard Hipp :

> On 2/8/17, Cecil Westerhof  wrote:
> >
> > ​I use SQLite, but only for relative simple things. Is there a way I can
> > help with testing, or do you need a ‘heavy’ application to do that?
> >
>
> All tests are welcomed.
>

​OK, glad to help. What should I do?

-- 
Cecil Westerhof
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Beginning of release testing for version 3.17.0

[Richard Hipp]

On 2/8/17, Cecil Westerhof  wrote:
>
> ​I use SQLite, but only for relative simple things. Is there a way I can
> help with testing, or do you need a ‘heavy’ application to do that?
>

All tests are welcomed.

The extensive SQLite test suite probably already covers most of the
"simple things".  But you never know what might have been missed.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Beginning of release testing for version 3.17.0

[Cecil Westerhof]

2017-02-07 15:32 GMT+01:00 Richard Hipp :

> In a few days, we will begin the official release testing for SQLite
> version 3.17.0.
>
> A recent snapshot of the code can be found on the
> https://www.sqlite.org/download.html page or directly from Fossil at
> https://www.sqlite.org/src/timeline
>
> A draft change log can be seen at
> https://www.sqlite.org/draft/releaselog/3_17_0.html
>
> Please try the new code, as you are able, and report any issues to
> this mailing list or directly to me at the email shown below.
>

​I use SQLite, but only for relative simple things. Is there a way I can
help with testing, or do you need a ‘heavy’ application to do that?

I have installed openSUSE, Debian and Ubuntu. I could also install another
OS in a VirtualBox if useful.

-- 
Cecil Westerhof
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Beginning of release testing for version 3.17.0

[jose isaias cabrera]

Just thinking out loud for those of us that use the DLL provided in your
site... 

It would be nice that this email would be accompanied by ready made DLLs
also.  Perhaps under, 

https://www.sqlite.org/draft/ [1]download.html [2] 

This is because some of us may not have the time to create the DLLs, but
we can download and drop the DLL in the folder and run our applications
and do some test.  Actually even run the application under the test DLL.
 I don't expect a daily creation of DLLs, but at least the original
"Please test" and the "Beginning of release..." emails.  I know this may
be extra work, but the testing will have broader exposure. 

Thanks for the wonderful tool... 

On 2017-02-07 09:32, Richard Hipp wrote:

> In a few days, we will begin the official release testing for SQLite
> version 3.17.0.
> 
> A recent snapshot of the code can be found on the
> https://www.sqlite.org/download.html page or directly from Fossil at
> https://www.sqlite.org/src/timeline
> 
> A draft change log can be seen at
> https://www.sqlite.org/draft/releaselog/3_17_0.html
> 
> Please try the new code, as you are able, and report any issues to
> this mailing list or directly to me at the email shown below.
 

Links:
--
[1] https://www.sqlite.org/draft/releaselog/3_17_0.html
[2] https://www.sqlite.org/download.html
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Beginning of release testing for version 3.17.0

[nomad]

On Tue Feb 07, 2017 at 09:32:18AM -0500, Richard Hipp wrote:
> 
> A draft change log can be seen at
> https://www.sqlite.org/draft/releaselog/3_17_0.html

Nice to see a sha1 extension included with SQLite now. I don't see a
matching SQLITE_ENABLE_SHA1 to add it statically (if that is what the
SQLITE_ENABLE_* compile options do).

-- 
Mark Lawrence
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users