Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.
|Comment:||Simplify the "Verifying Code Authenticity" section of the README.md file. No code changes.|
|Downloads:||Tarball | ZIP archive | SQL archive|
|Timelines:||family | ancestors | descendants | both | trunk|
|Files:||files | file ages | folders|
|User & Date:||drh 2019-05-15 10:16:34|
|18:42||Fix the count-of-view optimization so that it is (correctly) disabled for a query that includes a WHERE clause or a GROUP BY clause. (check-in: 05897ca4 user: drh tags: trunk)|
|10:16||Simplify the "Verifying Code Authenticity" section of the README.md file. No code changes. (check-in: adebffc1 user: drh tags: trunk)|
|20:25||Fix a problem with the fix for [9cf6c9bb51] (commit [658b84d7]) that could cause a cursor to be left in an invalid state following a (rowid < text-value) search. (check-in: bc7d2c16 user: dan tags: trunk)|
Changes to README.md.
302 302 303 303 There are many other source files. Each has a succinct header comment that 304 304 describes its purpose and role within the larger system. 305 305 306 306 <a name="vauth"></a> 307 307 ## Verifying Code Authenticity 308 308 309 -If you obtained an SQLite source tree from a secondary source, such as a 310 -GitHub mirror, and you want to verify that it has not been altered, there 311 -are a couple of ways to do that. 312 - 313 -If you have a release version of SQLite, and you are using the 314 -`sqlite3.c` amalgamation, then SHA3-256 hashes for the amalgamation are 315 -available in the [change log](https://www.sqlite.org/changes.html) on 316 -the official website. After building the `sqlite3.c` file, you can check 317 -that it is authentic by comparing the hash. This does not ensure that the 318 -test scripts are unaltered, but it does validate the deliverable part of 319 -the code and the verification process only involves computing and 320 -comparing a single hash. 321 - 322 -For versions other than an official release, or if you are building the 323 -`sqlite3.c` amalgamation using non-standard build options, the verification 324 -process is a little more involved. The `manifest` file at the root directory 325 -of the source tree 309 +The `manifest` file at the root directory of the source tree 326 310 contains either a SHA3-256 hash (for newer files) or a SHA1 hash (for 327 -older files) for every source file in the repository. You can write a script 328 -to extracts hashes from `manifest` and verifies the hashes against the 329 -corresponding files in the source tree. The SHA3-256 hash of the `manifest` 311 +older files) for every source file in the repository. 312 +The SHA3-256 hash of the `manifest` 330 313 file itself is the official name of the version of the source tree that you 331 -have. The `manifest.uuid` file should contain the SHA3-256 hash of the 332 -`manifest` file. If all of the above hash comparisons are correct, then 314 +have. The `manifest.uuid` file should contain the SHA3-256 hash of the 315 +`manifest` file. If all of the above hash comparisons are correct, then 333 316 you can be confident that your source tree is authentic and unadulterated. 334 317 335 318 The format of the `manifest` file should be mostly self-explanatory, but 336 319 if you want details, they are available 337 320 [here](https://fossil-scm.org/fossil/doc/trunk/www/fileformat.wiki#manifest). 338 321 339 322 ## Contacts 340 323 341 324 The main SQLite website is [http://www.sqlite.org/](http://www.sqlite.org/) 342 325 with geographically distributed backups at 343 326 [http://www2.sqlite.org/](http://www2.sqlite.org) and 344 327 [http://www3.sqlite.org/](http://www3.sqlite.org).