On Jul 13, 2018, at 9:39 AM, Andy Goth <andrew.m.g...@gmail.com> wrote:
> On 07/11/18 16:10, Warren Young wrote:
>> On Jul 10, 2018, at 8:58 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:
>>> I thought it interesting that he spoke of merging as if it were a
>>> distinct task in the workflow for adding a file.
>> Did he check the file in on a branch and then merge it down to trunk?
> No he did not, but after reading my email to this list, he told me he said 
> merge because his git habit is to always work on a branch.  I took that as an 
> opening to discuss the difference between git and Fossil branches.

In my public Fossil projects, the policy is that any checkin that is 
potentially destabilizing should be done on a branch, as should any coherent 
line of work that will require multiple checkins to complete.  Trunk is ideally 
stable at all times, so as long as a checkin is self-contained and trunk 
remains as stable as before, direct checkins to trunk are fine.

The rule requiring multiple-checkin lines of work to be on a branch doesn’t 
apply if each step along the way is self-contained and doesn’t destabilize 
trunk.  So for example, work on a new script that requires multiple checkins 
can be done directly on the trunk as long as that script isn’t called by 
something other developers run frequently, such as the build system.

This is an ideal not always achieved, but since there are consequences to not 
achieving it, over time developers on the project learn to be thoughtful about 
checking in directly to trunk.

As a result of this policy, a new developer’s first checkin might well be on a 
branch, either because they’re going off on a new development tangent that will 
take them multiple checkins to finish, or because they’re still feeling 
tentative about their work, so they want one of the old hands to okay it before 
merging it to trunk.

>> once publicized, a URL should never die
> our project is private

In that case, I think it’s perfectly fine to delete these docs unceremoniously, 
as needed.

> Only the front page and the wiki are public, and I've been migrating most of 
> our wiki stuff to the private areas because in my opinion it gives away too 
> much secret sauce.  Probably not worth shunning wiki history though.

Until one of the publicly-hosted “private” repository services is designed to 
and audited at the same level we use for VPNs, I’m unwilling to trust any of 

If your codeveloper is remote from you, I recommend that you relieve Fossil of 
the burden of providing the capital-S security for your project, laying that 
off on SSH or some VPN technology you trust instead.

I’m not a black hat, so I haven’t tried to break Fossil’s permission system, 
but I only depend on it about as much as a door lock: it’s a thing to prevent 
civilized users from doing things we’d rather they not do.  If I decide that a 
Fossil repository’s contents shouldn’t be visible to the public, I don’t put it 
on a publicly-accessible server, period.

If you want to treat Fossil as a CMS for your public web site, I’d run it as a 
separate instance, with only those things you’re willing to publicize going out 
to it.

For off-site backups of private repositories, I use the attached script.  
Technically it violates my rule not to put private data on publicly-accessible 
servers, but I trust AES, gpg, and my key to turn that repository data into a 
blob of useless noise to anyone without the key.

There are several things you need to adjust in the script to use it:

1. The “pass” value on line 3.  I use a generated random blob, but it could be 
a passphrase or similar.  If it’s short enough to be called a password, run it 
through an entropy calculator: if your password gives less than 256 bits of 
entropy, you’re artificially weakening the encryption.

2. The repository list used in the “for” loop.

3. The “bdir” output directory.  It could be something like ~/Dropbox/Fossils, 
or it could be a directory sync’d elsewhere by a command that you append to the 

I’ve come to this position not out of specific distrust over Fossil’s security 
design, but out of deep respect for what the ‘hats can do once they’re feeling 
motivated to attack something.  SSH, VPNs, GPG, and AES have all been pounded 
on by the ‘hats sufficiently long and hard that I trust those technologies 
implicitly, as long as the best practices are followed.  

Since Fossil hasn’t attracted that sort of attention yet, I feel that my idea 
of “best practice” for Fossil security is just my opinion and worth only as 
much as that realization implies.

While I’m pontificating on paranoia, I’ll say that a VPN is only a VPN if it is 
truly private.  Technologies which fail to provide the “P” are not VPNs.  
Hence, PPTP is not a VPN, in my view:


> I'll have to leave it to him to make his own macOS binary

Here’s the current trunk, built a couple of hours ago on a macOS 10.13.6 system:


It appears to be linked to the Homebrew version of OpenSSL, so he’ll need to 
have that installed to run it.

I won’t be upset if you decide not to download and run that, having endured my 
lecture on paranoia.  I tell you it’s a safe binary, but who am I to certify 

>> By giving him a different command to back out, he may now be afraid to
>> use “fossil sync” entirely.
> I already told him he should never need to use "fossil sync" manually.

There are two fairly common cases where he may need to sync manually:

1. Fossil UI -> edit wiki.

2. Ditto, but with tickets.

On saving the ticket/wiki changes, the local Fossil instance won’t autosync to 
the remote instance, even if it’s available and autosync is enabled.

I also do manual syncs when taking a laptop that had autosync disabled back 
into the warm wifi bath after re-enabling autosync.

>> We shall wee.
> Nice typo. ;^)

We did, and we thank you for your concern over our urological health. :)

Attachment: backup-fossils
Description: Binary data

fossil-users mailing list

Reply via email to