On Jan 21, 2016, at 5:21 AM, Richard Hipp <d...@sqlite.org> wrote: > > On 1/21/16, Stephan Beal <sgb...@googlemail.com> wrote: >> >> - make sure that the 'anonymous' user cannot write to the wiki > > I wonder if we could come up with a "security checklist" page of some > kind that would guide admins through these steps, and perhaps others > we have yet to think of?
Sins of omission: 1. Not removing permissions from default users and groups before exposing the Fossil instance to a hostile network: 1a. anonymous: This ships as hmncz currently, but I’ll either reduce it to hnz or blank, depending on whether it’s a public open source project or a private repository. 1b. nobody: I leave the default gjorz permission set for open source projects, but reduce it to jr for private repos. 2. Removing permissions per 1a and 1b above, but then failing to distribute them: 2a. reader: May gain c and z if these were removed from anonymous. 2b. developer: Gains all permissions removed above that weren’t given to reader. May also gain additional permissions besides those not removed above, resulting in alphabet soup flavors such as the ever popular bcdefghikmnotw. (Now 20% off with coupon! Limit 3 per customer, offer ends 2/1/2016.) 3. Failing to put Fossil behind a TLS proxy if passwords may traverse an untrusted network. Now that we have Let’s Encrypt, you have no more excuses. 4. Failing to keep an eye on the mailing list, to be aware of times when you should update to the latest Fossil. Sins of commission: 1. Checking passwords, passphrases, symmetric encryption keys, or private halves of asymmetric encryption keys into a public-facing repo. You’d never do that, of course. Then there was the time you set up a public F/OSS project and built a pretty front-end web site for the parts that Fossil isn’t good at serving. Then you heeded item 3 above, and used the web frontend to proxy access to the code repo over TLS. And then you checked the TLS cert files into the frontend’s repo to make sure they get backed up. Ooops! Where are your DB passwords? Code signing certs? CI server login scripts? Where are the passwords you install into VMs you build with Vagrant? Where do you keep the output of the system that generates software registration keys for customers of your trialware? Where are the the encryption keys that make those registration keys unforgeable? 2. Writing commit comments, wiki articles, or tickets with comments you would not willingly speak to a known black hat. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users