Re: [fossil-users] Release 1.35 checksums?
On 7/1/16, Ross Berteig wrote: > On 7/1/2016 10:11 AM, Lonnie Abelbeck wrote: >> It seems the Checksums are on a different site from the downloads, >> raising the bar for mischief. BTW including 1.35 now. >> http://www.hwaci.com/fossil_download_checksums.html > > FYI, Hwaci is D. R. Hipp's company that owns the assigned copyrights to > all work on fossil. Quoting that page, "Hipp, Wyrick & Company, Inc., or > "Hwaci" for short, is a small North Carolina company providing knowledge > services to clients around the world since 1992." > > That site is as official as fossil-scm.org. It's the same IP address as www3.fossil-scm.org. More importantly, it is on a separate server, in a separate datacenter, owned by a different company (Hurricane Electric vs. Linode) and in a different state (CA vs TX), from the canonical www.fossil-scm.org server. The idea is that a hack of both servers seems unlikely. FWIW, the checksums were added years ago by request from users on this mailing list. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Release 1.35 checksums?
On Jul 1, 2016, at 3:42 PM, Ross Berteig wrote: > On 7/1/2016 10:11 AM, Lonnie Abelbeck wrote: >> It seems the Checksums are on a different site from the downloads, >> raising the bar for mischief. BTW including 1.35 now. >> http://www.hwaci.com/fossil_download_checksums.html > > FYI, Hwaci is D. R. Hipp's company that owns the assigned copyrights to all > work on fossil. Quoting that page, "Hipp, Wyrick & Company, Inc., or "Hwaci" > for short, is a small North Carolina company providing knowledge services to > clients around the world since 1992." > > That site is as official as fossil-scm.org. Indeed, and this requires a bad guy to hack two different servers to create bogus downloads and SHA1's. As usual, well done D. R. Hipp. Lonnie ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Release 1.35 checksums?
On 7/1/2016 10:11 AM, Lonnie Abelbeck wrote: It seems the Checksums are on a different site from the downloads, raising the bar for mischief. BTW including 1.35 now. http://www.hwaci.com/fossil_download_checksums.html FYI, Hwaci is D. R. Hipp's company that owns the assigned copyrights to all work on fossil. Quoting that page, "Hipp, Wyrick & Company, Inc., or "Hwaci" for short, is a small North Carolina company providing knowledge services to clients around the world since 1992." That site is as official as fossil-scm.org. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Release 1.35 checksums?
On 7/1/2016 10:35 AM, Warren Young wrote: On Jul 1, 2016, at 11:13 AM, Todd C. Olson wrote: Then why does fossil-scm.org offer checksums at all? Better question: why does any download site offer checksums? One answer is mirrors. If a download is widely mirrored, then one might have reason for concern that a third-party provided mirror might be serving up modified content. Having the official site publish one or more checksums is a cheap way of providing some assurance that hasn't happened. A cryptographic signature would be stronger, but enough harder for end users to verify that it would not be checked at all. It did happen to a number of iOS developers in China recently. They were of the habit of getting developer tools from a mirror site that was far closer to them (by bandwidth and download time measures) than the official Apple sites. The tools they got included a modified toolchain that produced iOS app with backdoor access. That also passed all Apple review stages since they were linked against "official" libraries. That said, fossil doesn't provide an automated pool of mirrors hosted at third party providers so this would be less of a concern. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Release 1.35 checksums?
On Jul 1, 2016, at 11:13 AM, Todd C. Olson wrote: > > Then why does fossil-scm.org offer checksums at all? Better question: why does any download site offer checksums? My answer: I have no idea, which is why I ask these questions ever time the question comes up. I have yet to get a satisfactory answer. I *can* see the point for large ISOs and such, simply because the download time required means that a quick way of verifying that you’ve got a clean download is useful. That same doesn’t apply to Fossil. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Can fossil be made to work on OS X 10.11.5 network home directories (over AFP or SMB or NFS)?
On Jun 30, 2016, at 8:07 PM, Todd C. Olson wrote: > > Using the fossil OS X binary v1.35 provided at fossil-scm.org in a networked > home directory provided over AFP, I am unable to create a new fossil > repository > % fossil init test01.fossil > SQLITE_IOERR: statement aborts at 1: [BEGIN EXCLUSIVE] disk I/O error Network file systems often either do file locking incorrectly or skip it entirely. I suspect if you run dtruss on the Fossil binary that you’ll find the error is coming from flock(), fcntl(), lockf() or similar. See: http://www2.sqlite.org/faq.html#q5 > Yet with the sqlite3 provide with OS X I can create and access sqlite > databases with out problem. > That sqlite3 appears to be compiled thusly > % sqlite3 > SQLite version 3.8.10.2 2015-05-20 18:17:19 That proves nothing. You didn’t give a database file name as an argument to sqlite3, and you didn’t try to modify the database. Thus, nothing needs to be written to disk, so there is not even an attempt to lock anything. Try: sqlite3 foo.db 'create table bar (a, b)' > The same behavior occurs with SMB mounting. Proper locking is at least *possible* in principle with SMB, but it’s often broken or disabled on purpose to make file sharing faster. Incidentally, news out of WWDC this year is that AFP won’t be supported for Apple’s new APFS file system. I’m guessing the protocol is tied to ancient Mac OS Classic file semantics, so now is the time to finally give this old protocol the boot. SMB is the official path forward. > I've not yet got NFS setup to test. Locking is entirely optional with NFS. If you aren’t running the separate locking daemon, you won’t get locking at all, and if you are, it may not work anyway. For example, flock() typically doesn’t work with NFS mounts. You have to use POSIX locks to get locking across NFS. This plays into Fossil because SQLite may have multiple ways of doing locks, and there are ways of manipulating its VFS layer to force it to use one method vs another. Thus, either by default or configuration you might be bypassing any NFS locking you *do* have. > Also in a non-networked home directory I can create a new repository without > problem. Since you’re using Fossil, why not store the local clone on a non-network drive and sync with the remote server? Why sync your cloned Fossil repo DB back to the server at all? Realize that your working checkouts don’t have to be on the same filesystem as your local repo clones. > QUESTION 1: Is there a setting that will allow fossil-binary-as-provided to > work on AFP or SMB, command line, environment variable, or something? Possibly, but realize that it may involve digging into the SQLite VFS layer on the local side and may also involve changing settings on the file server. Even then, you’re probably more likely to create a configuration that stops giving errors but instead opens the possibility for data corruption. > QUESTION 2: Is there a way I can compile fossil so that it will run on AFP > or SMB, even if unsafe? No, but I’ve got a leg brace for an S&W N frame revolver here that keeps it pointed right at your foot. Wanna buy it? See section 2 of https://www.sqlite.org/howtocorrupt.html > QUESTION 3: How unsafe is it? It’s far less safe than cloning to a local disk and syncing over the normal Fossil network protocol. > If I am the only user of the system and I am only ever accessing the > repository with one process from one location, is it still unsafe? My guess is “no,” but how are you sure that the use case you outlined will never change? Your question reminds me of amateur electrical work I’ve seen where the justification for all the code violations is that it works as designed. Then it fails as soon as some small thing changes which invalidates the thinking that lead to the brittle design. That’s why the National Electrical Code is written so stringently: because power systems must fail safe in all conceivable use cases. The same goes for DBMSes. > Searching the SQLite build documentation and Fossil build documentation has > not enlightened me That’s because you’re chasing an unsupported configuration. You can’t expect to find documentation describing how to set yourself up for future disaster. > I'm guessing ENABLE_LOCKING_STYLE=1 is important That could indeed help. > how to implement when building fossil? Modify src/main.mk, changing the hardcoded SQLITE_ENABLE_LOCKING_STYLE=0 presently on line 486 to =1. I wonder why that’s not enabled by default? Isn’t that setting essentially harmless? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Release 1.35 checksums?
On Jul 1, 2016, at 11:39 AM, Warren Young wrote: > On Jun 30, 2016, at 7:21 PM, Todd C. Olson wrote: >> >> The checksum file on the down load page only has values for up to v1.34 >> Where do we get the values for v1.35 > > Why do you trust such things in the first case? > > If you’re expecting the checksum to protect you against someone hacking the > web site and uploading malware, they can modify the checksums on the web site > at the same time. It seems the Checksums are on a different site from the downloads, raising the bar for mischief. BTW including 1.35 now. http://www.hwaci.com/fossil_download_checksums.html Lonnie ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Release 1.35 checksums?
Then why does fossil-scm.org offer checksums at all? Regards, tco2 > On Fr, 2016-07-01, at 12:39, Warren Young wrote: > > On Jun 30, 2016, at 7:21 PM, Todd C. Olson wrote: >> >> The checksum file on the down load page only has values for up to v1.34 >> Where do we get the values for v1.35 > > Why do you trust such things in the first case? > > If you’re looking to checksums to protect you against MITM malware injection, > the same MITM can modify the checksum, too. > > If you’re expecting the checksum to protect you against someone hacking the > web site and uploading malware, they can modify the checksums on the web site > at the same time. > > If you’re expecting to copy the checksums somewhere secure for verifying EXEs > later, downloading the current EXE and doing your own checksum gets you the > same benefit with no useful drop in security. > > If you’re looking to these checksums for an integrity check, what kind of > horrible network are you on where Ethernet + TCP checksums are insufficient? > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Release 1.35 checksums?
On Jul 1, 2016 9:39 AM, "Warren Young" wrote: > > On Jun 30, 2016, at 7:21 PM, Todd C. Olson wrote: > > > > The checksum file on the down load page only has values for up to v1.34 > > Where do we get the values for v1.35 > > Why do you trust such things in the first case? > > If you’re looking to checksums to protect you against MITM malware injection, the same MITM can modify the checksum, too. > > If you’re expecting the checksum to protect you against someone hacking the web site and uploading malware, they can modify the checksums on the web site at the same time. > > If you’re expecting to copy the checksums somewhere secure for verifying EXEs later, downloading the current EXE and doing your own checksum gets you the same benefit with no useful drop in security. > > If you’re looking to these checksums for an integrity check, what kind of horrible network are you on where Ethernet + TCP checksums are insufficient? Given all this then, why are the checksums (incompletely) provided? Obviously somewhat confusing. -bch ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Release 1.35 checksums?
On Jun 30, 2016, at 7:21 PM, Todd C. Olson wrote: > > The checksum file on the down load page only has values for up to v1.34 > Where do we get the values for v1.35 Why do you trust such things in the first case? If you’re looking to checksums to protect you against MITM malware injection, the same MITM can modify the checksum, too. If you’re expecting the checksum to protect you against someone hacking the web site and uploading malware, they can modify the checksums on the web site at the same time. If you’re expecting to copy the checksums somewhere secure for verifying EXEs later, downloading the current EXE and doing your own checksum gets you the same benefit with no useful drop in security. If you’re looking to these checksums for an integrity check, what kind of horrible network are you on where Ethernet + TCP checksums are insufficient? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
