Re: [fossil-users] OT: Facebook engineers preferring hg to Git
On Oct 28, 2016, at 07:33, Richard Hipp wrote: > > Perhaps true. But in my brief look at Rust I observed that you really > cannot use it effectively without also having to use Git. The two > seem closely linked. Is that incorrect? It is indeed. Sadly, the examples don't help to dispel that at all. Git is merely a first-class citizen for some of the tooling (like Cargo[0]), and if you dig deeply enough, you'll notice things like `--hg` flags and explicit mentions in, e.g., Cargo.toml of the version control system being used to pull in dependencies for those who choose to have that tool manage their checkouts for them. (Though, in my experience, some of the features are a little schizophrenic in their raisons d'être, and the proliferation of language-specific package managers is proving to be an acquired taste like IPAs or caviar. YMMV.) However, there's also the option of referring to dependencies in Cargo by a file path on the local filesystem tree, relative to where that particular crate's (the Rustese word for package) Cargo.toml resides. There's more at [1]. If you're willing to roll your own crate by hand, you can even use something like Darcs, as the thrussh portable SSH library[2] does. The only other consequence outside of that is that you lose some of the ability for Cargo to manage your dependencies for you if you choose to rely on one that doesn't use Git and wish to use something other than a published stable version. Given Cargo's opinions about version numbers[3] though, I don't think that's such a bad consequence. —n 0: http://crates.io/ 1: http://doc.crates.io/specifying-dependencies.html 2: https://pijul.org/thrussh/ 3: http://doc.crates.io/manifest.html#the-version-field ___ 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: Why we should NEVER use inetd/xinetd
> On Oct 28, 2016, at 02:29, Luca Ferrari wrote: > No, I do. > You should go trolling somewhere else. Just checking in. It seems that my decision to mute this thread within my mailer immediately after my single response was a good idea. From my perspective, this thread has far outlasted its usefulness and has become an exercise in self-satisfaction for those who prefer to write words instead of writing code. Can we perhaps refrain from offering attention-addicted individuals the attention they so desperately crave? I promise you'll look back fondly on this decision just as I have. —n ___ 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: Why we should NEVER use inetd/xinetd
> On Oct 22, 2016, at 17:23, K. Fossil user > wrote: > P.S. : I will never understand why people don't know about security issue > when it comes to inetd. Aha, so this was a security concern. I figured just as much. Please read on. (: > I was explained to never use ONE daemon for many servers. When needed ONE > daemon for ONE server and not more. OK, so, from a systems design standpoint, inetd and xinetd don't inherently have insecure designs as super servers. Instead, that design lends them a tendency to exhibit pathological unreliability; if inetd or xinetd crash (say, because the configuration parser has a bug because it unwittingly derefs NULL), the services that are run under the auspices of either one will similarly meet a less than pleasant fate. The security concerns come in as a result of not paying attention to the details of the implementation. Make sure you use things like initgroups(3), setgid(2), and setuid(2) to drop privileges. Make sure you understand how inter-process communication can be made secure. Make sure you have good hygiene when you dynamically allocate memory and work with, e.g., NUL-terminated strings. Now, it just so happens that it's simpler to keep track of the security details in things like tcpserver and tcpsvd because the single-instance-per-single-server architecture lends itself well to fewer lines of code to serve as a liability, but that is by no means a guarantee. Caveat emptor. > 2/ Xinetd is old (four years ?) so may be not secure. xinetd is actually older than that. It may have not, for whatever reason, seen a recent release. That said, xinetd has comparatively few lines of code (granted, it's still more than tcpserver and tcpsvd for just the configuration file bits alone) when placed next to other pieces of software that often run in part with escalated privileges like, well, modern full-featured HTTP servers. Also, it's folly to discount everything above a certain age as insecure. tcpserver, part of Dan Bernstein's ucspi-tcp package, has a solid design that lends itself very well to running TCP servers that are invulnerable to the exploits you're afraid of. I don't think it has seen an update in 15 years. Anyway, that's all I have to say about that. —n ___ 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 bind to a single address?
On Oct 21, 2016, at 18:55, K. Fossil user wrote: > However, xinetd or inetd are not recommended... That ellipsis really should be filled in with more details. Would you perhaps be willing to elaborate a bit on what you mean? —n ___ 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 bind to a single address?
On Fri, Oct 21, 2016, at 05:28 PM, Steven Gawroriski wrote: > Is Fossil able to bind to a single IP address? There is `--localhost` It doesn't seem that way, no. I've personally worked around it by employing tcpsvd from Gerrit Pape's excellent ipsvd package. The inetd super server (and its descendants) provide similar functionality. In my runit run script, modulo tcpsvd-specific details not relevant here, I have `exec tcpsvd 127.0.1.6 3000 fossil http /data/fossil/root --https`, and that seems to work well when using a reverse proxy to send traffic to it via something like Apache, HAProxy, or an Amazon ELB. —n ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
