Re: [fossil-users] Fossil in a chroot jail. Was: Chiselapp status
On Jul 13, 2018, at 7:09 PM, Richard Hipp wrote: > > So, if you want to use the rate limiting feature on > Linux, you will need /proc mounted in your chroot jail. I wish there > were a better way… That’s actually one of the older features of cgroups. Maybe take a look? ___ 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] Fossil in a chroot jail. Was: Chiselapp status
As a defense against DoS attacks, Fossil has a feature were it refuses to run certain expense web pages (ex: creating new tarballs) if the system load averages is too high. Fossil uses the getloadavg() interface to compute this. On Linux, getloadavg() requires that /proc be mounted. So, if you want to use the rate limiting feature on Linux, you will need /proc mounted in your chroot jail. I wish there were a better way... A Linux-specific hack here could be to open the `/proc/loadavg` file before entering the chroot and dropping privileges. You can then seek to zero and read as many times as you want. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil in a chroot jail. Was: Chiselapp status
On 7/13/18, Warren Young wrote: > > chroot() might even be strong enough given the tight scoping. Just checking to make sure you know: If you launch Fossil as root, it will automatically put itself into a chroot jail in the directory containing the repository, then change its userid and groupid to match the owner of the repository. It does this prior to reading any content from the wire. The chroot jail that Fossil runs in can be very lean. It does not need a shell nor a bunch of libraries (assuming you have statically linked). You will need to mknod a /dev/null, /dev/random, and /dev/urandom inside the jail, but that seems harmless enough. As a defense against DoS attacks, Fossil has a feature were it refuses to run certain expense web pages (ex: creating new tarballs) if the system load averages is too high. Fossil uses the getloadavg() interface to compute this. On Linux, getloadavg() requires that /proc be mounted. So, if you want to use the rate limiting feature on Linux, you will need /proc mounted in your chroot jail. I wish there were a better way... -- 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] OT: security/entropy (was Re: New Fossil user experiences)
On Fri 13 Jul 2018 4:22 PM, David Mason wrote: > So I guess this is what Warren had in mind. Posting this in case it helps > somebody on the list. > Taking this offtopic a little bit more...let's talk about VPNs. Don't use PPTP and don't get tangled up in ipsec configuration hell. Be happy with wireguard! https://www.wireguard.com It runs on everything but Windows (Linux, *BSD, MacOS, Andriod, iphone). There's no passwords to share and the public keys are easily, easily distributed. > Thanks ../Dave ___ 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] OT: security/entropy (was Re: New Fossil user experiences)
On Jul 13, 2018, at 3:13 PM, Warren Young wrote: > > 2. Add a dollar sign to the message, and bpc goes up a bit. (This conflicts > with your report that adding a special character didn’t change it, but it did > for me.) I just realized where the discrepancy comes from: you *replaced* one character of the original message with a special character, so the resulting alphabet size didn’t change, whereas I *added* a non-alphanumeric character to the message, which did change my alphabet size. This calculator doesn’t know about “special characters,” all it knows about are the number of unique input symbols it is given and how that relates to the total message size. ___ 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] OT: security/entropy (was Re: New Fossil user experiences)
On Jul 13, 2018, at 3:13 PM, Warren Young wrote: > > Now paste in an equivalent number of ‘a’ characters, and you get 0 bits of > entropy. Strictly speaking, you get 1 bit of entropy for the whole message, > but it shows 0 because the calculator is rounding the result off to 3 > significant figures. Hmmm…we also need something like a run-length prefix to reconstruct the message, so this calculator is undershooting slightly. For example, 100 a’s requires a 7-bit run-length plus zero bits for our only code point, so we should get 0.07 bpc, within this calculator’s apparent precision even without dealing with roundoff errors. Still, it’s good enough for our purposes here, which is to make it clear to us that if you use a hex string as a passphrase, you need 128 characters of it to fully justify the use of 256-bit symmetric encryption. ___ 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] OT: security/entropy (was Re: New Fossil user experiences)
On Jul 13, 2018, at 2:22 PM, David Mason wrote: > > Acgq75VpCWjdsJaa5abe9JeX3I (don't worry, this isn't a real password to > anything) > > …I fed this through an online entropy calculator and got 4.29 bits of Shannon > entropy That calculator is giving you bits *per character*. You can see this several ways: 1. Double the message and the bits per character doesn’t change because the size of the source alphabet doesn’t change. 2. Add a dollar sign to the message, and bpc goes up a bit. (This conflicts with your report that adding a special character didn’t change it, but it did for me.) 3. Turn on the calculator’s case folding option and the bpc value goes down a bit. One key realization you should get from this calculator is that ASCII text is not 7 or 8 bits of entropy per character. It simply is not, because not all characters in the source text are equally likely. Many code points may never be used in a given corpus. Another realization is that a random blob of hex noise should asymptotically approach 4 bpc, since each character is 4 bits of data, and the data are supposed to be evenly distributed across the code space. Here’s some noise from grc.com/pass: C79683189EFBEBEC30A4C1A6D733F0242FB48E2582F3B2E7581D85E91E0A2FA5 The initial value is 3.91, and pasting it in a bunch of times does increase the value towards 4, suggesting it’s got pretty good entropy. Now paste in an equivalent number of ‘a’ characters, and you get 0 bits of entropy. Strictly speaking, you get 1 bit of entropy for the whole message, but it shows 0 because the calculator is rounding the result off to 3 significant figures. > So I tried: > dd if=/dev/random bs=100 count=1|od -c > and the result only gave 5.00 bits That’s plausible. With a much larger sample, the result should approach 7, 8, 16, or 21, depending on your local character set size. (Respectively: pure ASCII, ISO 8859 or similar, UCS-2 and full Unicode.) Now see if you can guess the asymptotic ideal for this slightly different command: $ dd if=/dev/random bs=100 count=1 | od Spoiler below. ……….. 3, because the output is restricted to octal, thus 3 bpc. ___ 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] Chiselapp status
On Jul 13, 2018, at 2:13 PM, Roy Keene wrote: > > Upgrading from Fossil 2.1 to something more recent hasn't been a priority; I > have to go through the versions and verify no new features will cause > problems when hosting untrusted repositories, and I haven't done that. I guess you’re worried about CSRF, XSS and such? There was an XSS fix in 2.3, and there’s one still pending for the current release. I didn’t pay attention to who noticed these problems and wanted these fixes, but if you’d asked me yesterday, I’d have guessed Chiselapp! > If you would like to volunteer to do that then it'll go faster ! :-D Would it be easier to switch to a technology like BSD jails or Illumos zones that let you run a separate Fossil instance for each customer, so that you don’t have to worry about how multiple customers’ Fossil instances will interact? With Fossil’s option of a single statically-linked executable, you might end up with only a handful of files in each container, so that the attack surface is little more than Fossil itself, and if exploited, all you get access to is the repository data within that single container. cgroups based containers on Linux (e.g. Docker, though not limited to it) are reportedly not as strong as BSD jails or Illumos zones: https://unix.stackexchange.com/questions/127001/linux-lxc-vs-freebsd-jail https://www.blackhat.com/docs/eu-15/materials/eu-15-Bettini-Vulnerability-Exploitation-In-Docker-Container-Environments-wp.pdf https://www.reddit.com/r/IAmA/comments/31ny87/i_am_the_cto_of_joyent_the_father_of_dtrace_and/cq414ac Yet, they may be strong enough for this purpose, given its tight scoping. chroot() might even be strong enough given the tight scoping. None of the ways I’m aware of to escape a chroot() apply to a minimal Fossil-in-a-box configuration. Most of these methods require root access inside the chroot, and there isn’t cause for that, not even for low-numbered port binding, since your HTTPS front end could map external URLs to high-numbered internal port numbers. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] OT: security/entropy (was Re: New Fossil user experiences)
I use a password generator of my own design - basically takes the userid, concatenated with a fairly long secret phrase, and then I do SHA1 and convert it to base64, giving a password like: Acgq75VpCWjdsJaa5abe9JeX3I (don't worry, this isn't a real password to anything) After Warren's comment about wanting 256 bits of entropy, I fed this through an online entropy calculator (https://planetcalc.com/2476/ - I wouldn't feed a real password through anything on the web!), and got 4.29 bits of Shannon entropy (replacing a character with a special character didn't change the number). Calculating it on a whole web page only gave 5.41. So I tried: dd if=/dev/random bs=100 count=1|od -c and the result only gave 5.00 bits So I'm guessing this isn't what he meant. http://rumkin.com/tools/password/passchk.php does a version and it says my fake password above is 130 bits. The 800 bits of random converted to hex gives 779 bits So I guess this is what Warren had in mind. Posting this in case it helps somebody on the list. Thanks ../Dave ___ 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] Chiselapp status
It's still me -- though I don't check email that often, and when I do I don't read all of it, normally just the subject and sometimes the From. Upgrading from Fossil 2.1 to something more recent hasn't been a priority; I have to go through the versions and verify no new features will cause problems when hosting untrusted repositories, and I haven't done that. If you would like to volunteer to do that then it'll go faster ! :-D Thanks, Roy Keene P.S., I'm usually on the Tcl IRC or Slack ( https://slack.tcl-lang.org ). On Fri, 13 Jul 2018, Andy Goth wrote: Whom should I be talking to regarding Chiselapp questions? I want to know if there's a reason why it uses Fossil version 2.1 [83e3445f67] and if there are any plans to upgrade. I've not gotten any email replies from Roy Keene in a long time, neither regarding Tcl nor Chiselapp, though I know he's out there because of recent commits to his kitcreator project. Perhaps I just don't have the right address. -- Andy Goth | ___ 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
[fossil-users] Chiselapp status
Whom should I be talking to regarding Chiselapp questions? I want to know if there's a reason why it uses Fossil version 2.1 [83e3445f67] and if there are any plans to upgrade. I've not gotten any email replies from Roy Keene in a long time, neither regarding Tcl nor Chiselapp, though I know he's out there because of recent commits to his kitcreator project. Perhaps I just don't have the right address. -- Andy Goth | ___ 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] New Fossil user experiences
On 07/13/18 12:23, Warren Young wrote: 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. That's a good policy, though in this situation all his check-ins have been project planning documentation. The code is my responsibility at this point. Also there's no worry about destabilization because we aren't stable to begin with. Once we have a working platform, I do plan to institute a policy like yours. 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. If the guy with the money believes Chiselapp's security is good enough for him, it's good enough for me, especially since I'd have made it fully public if it were entirely my decision. I just didn't want to put implementation details in a section that's expressly public. For a different paid project much more strongly commercial in nature, I hosted Fossil myself to avoid trusting Chiselapp or any other such public host. 350MHz Pentium II with 256 megabytes RAM, by the way. 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. Thanks. I may have need of that at some point. 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: https://drive.google.com/open?id=1Pl3XQAVtJOv-LXTlZmPyP_tkNML9YJDa It appears to be linked to the Homebrew version of OpenSSL, so he’ll need to have that installed to run it. Not up to me. I don't have macOS anywhere at home or at work. We used to have some vendor-supplied Mac Minis, but I think they were running Linux anyway. There are two fairly common cases where he may need to sync manually: 1. Fossil UI -> edit wiki. 2. Ditto, but with tickets. True, though he has just used Chiselapp directly so far, and is now focusing on checked-in documents instead. I'll have to remind him about the doc/ckout feature so he can preview his changes. -- Andy Goth | ___ 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] New Fossil user experiences
On Jul 13, 2018, at 9:39 AM, Andy Goth wrote: > > On 07/11/18 16:10, Warren Young wrote: >> On Jul 10, 2018, at 8:58 PM, Andy Goth 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 them. 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 script. 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: https://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol#Security > 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:
Re: [fossil-users] New Fossil user experiences
On 07/11/18 16:10, Warren Young wrote: On Jul 10, 2018, at 8:58 PM, Andy Goth 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. "...I'm reading the best practice for fossil is to leave the deprecated .md in place?" I'm not sure where he got the idea that it's best to not delete files It’s not Fossil-specific at all: once publicized, a URL should never die, else you get broken links, if only from web crawlers that saw that document once upon a time and then continue to return it in search results. Ah, that makes sense. Except, our project is private, and at the moment the two of us are the only ones with logins. 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. "People don't much like this behavior, but it's what we have, and it can be changed." Did you make it clear that "it can be changed" means your codeveloper can change it on his end, as opposed to waiting for someone to get around to changing Fossil for him? Yes, I told him the command to type to change the setting. Though at the time I was stupidly hoping that it was a versionable setting, in which case I could change it for him. Of course it's not, and I'm not asking for it to become one. Two weeks ago, Fossil trunk was changed so that you no longer need to reconfigure Fossil’s checkout tree to enable this: http://fossil-scm.org/index.html/info/27e5e5ce65262f5a I told him the binary he downloaded from the website probably wouldn't have the ability to change the setting on the fly and that I might have to provide him with more current binaries. Though I'll have to leave it to him to make his own macOS binary, since I'm only set up to build for Linux and Windows at the moment. (He uses macOS and Windows.) Regarding fossil changes, he said, "If I get a carriage return/new line with no prompt, does that mean there are no changes to apply?" So there seems to be a bit of confusion, or at least hesitancy, about fossil changes (probably also fossil extras) printing nothing. That’s not a Fossil issue, it’s a Unix vs Windows issue: traditionally-designed Unix programs often do their work silently if no problem occurs and there is nothing to tell the user. I am well aware. I'm just reporting new user experience. It really does drive me nuts when programs have a special case to report nothing since half the time I've got them talking to other programs (rather than a human) and I need to put in a matching special case to not treat "no changes found" as the name of a file being changed. fossil sync website_design.md That the sync command stores the given URL blindly here seems like a UX bug to me. Just as Fossil re-prompts for a password until it gets one that works, it should not store the URL until it successfully uses the given one to sync the local repo. Very good point. And if we really do want to force the URL, for example in the rare case that the system is being prepared for remote sync'ing but the network or server isn't immediately available, that's what "fossil remote-url" is for. This was easily fixed with fossil remote-url. I’d have told your codeveloper to use “fossil sync URL” here instead, so he could compare and contrast the incorrect and correct forms of the command. Hmm, right. Good point. 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. We've not gotten to the point of using any of the commands that don't sync on their own. He's no dummy. He's just trying to come out of the git fog. the default of not deleting the file from disk is confusing to new users. Yes, well, the argument’s been had for years here. I take the recent change on Fossil trunk as a sign that *eventually* the default will change. We shall wee. Nice typo. ;^) -- Andy Goth | ___ 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] /usr/bin/ld: cannot find -ldl
On Fri 13 Jul 2018 5:08 AM, Artur Shepilko wrote: > > openBSD -current x64 > > $ cc -v > > OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0) > > Target: amd64-unknown-openbsd6.3 > > Thread model: posix > > InstalledDir: /usr/bin > > > > Ok, I think I found the problem. This info was very helpful. > > Indeed, the *BSD platforms have all the dl functionality in the > standard C library, so no libdl present. > This should make the test `[check-function-in-lib dlopen dl]` pass > without the need for -ldl. > > Corrected it and pushed an update > [http://fossil-scm.org/index.html/info/7cdb522b42aad6a1] > Please try if this solves it for you. > > Thank you for catching the bug! Thank YOU for fixing and pushing it to trunk. I've been able to successfully build fossil now. Thanks! ___ 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] /usr/bin/ld: cannot find -ldl
> openBSD -current x64 > $ cc -v > OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0) > Target: amd64-unknown-openbsd6.3 > Thread model: posix > InstalledDir: /usr/bin > Ok, I think I found the problem. This info was very helpful. Indeed, the *BSD platforms have all the dl functionality in the standard C library, so no libdl present. This should make the test `[check-function-in-lib dlopen dl]` pass without the need for -ldl. Corrected it and pushed an update [http://fossil-scm.org/index.html/info/7cdb522b42aad6a1] Please try if this solves it for you. Thank you for catching the bug! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
