Re: [sqlite] Beginning of release testing for version 3.17.0
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 > 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
> 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
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
> 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
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
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
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
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
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
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
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
[sqlite] Beginning of release testing for version 3.17.0
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. Thanks. -- 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