Re: [fossil-users] Why we should NEVER use inetd/xinetd

[Ross Berteig]

Mr. User (if that is indeed your name):

On 10/26/2016 4:30 PM, K. Fossil user wrote:
In this mailing list we need to know everything about fossil and 
fossil related stuffs.
- inetd/xinetd etc. that may be used in conjonction with Fossil (may 
be I am the only one who hear about a daemon (inetd) that was used 
with Fossil?)

- security related (Fossil is a server sort of)


Let me try to explain this a different way.

The single fossil executable is several distinct things, and compatible 
with several distinct technologies. It also has additional features that 
can be enabled when building, which are not enabled by default.


Fossil is:

1. A CLI program that as a DVCS uses a local repository to track changes.
2. A client for push/pull/sync with a remote repository
3. A CGI program usable from a big web server
4. A server, for both web and fossil sync, listening on port 80, 8080, 
or a configured port.


Case 1 has no external security issues. You are at a command prompt. You 
can presumably do anything at all to your own files. Fossil won't 
actively help you destroy data any more than GCC does or your favorite 
IDE. Naturally it can be misused and could have bugs because we are only 
human. This case is exercised by the test suite that is run occasionally 
by various developers.


Case 2 can be compiled to use SSL, otherwise it uses sockets in the 
clear. Login security and access controls are configured at the server 
end. Configuration can be subtle, but for simple open source projects it 
can be simple and largely just works.


Cases 3 and 4 (and other subtly distinct variations that most often come 
up in some SSL configurations) are all on the server end.


Case 3 is normal CGI. Overall security of the server is the 
responsibility of the world-facing web server. This might not be the 
"best" way to setup an externally accessible repository, but it is the 
easiest. Login security that controls access to the repository itself is 
handled by fossil, with a session cookie across transactions. If your 
web server already handles SSL, you can get SSL coverage of your 
repository essentially for free this way.


Case 4 covers at least three distinct usage styles. It is how the 
"fossil ui" command is implemented, essentially by starting a server on 
localhost:8080 and launching a web browser to touch it. A long-running 
server can be easily set up for a single repository or a directory full 
or repositories with the "fossil server" command. You can also use 
(x)inetd or another launch and monitor daemon to defer launching fossil 
until the port is accessed.


Under most conditions, if fossil happens to find itself running as root, 
it enters a chroot jail and drops as much privilege as it can. This 
mitigates most attacks that depend on getting something running as root 
to misbehave. Fossil doesn't examine the user's request until that is done.


If inetd, xinetd, systemd, or something similar is used to launch fossil 
on demand, then that daemon is what is seen first by an attacker. The 
biggest concern is that a bug or incident might cause a denial of 
service by crashing that super-daemon. That is what happened with 
http://fossil-scm.org when you started flogging the inetd is evil horse 
recently. The daemon died. The machine didn't notice. Services not 
managed by that specific daemon remained alive. This is one of the 
problems that systemd is trying to solve: by being more aware of what is 
supposed to be running, systemd can notice losses and repair them. Many 
people think that is a good idea. Many people are not convinced. Inetd 
and its close relatives do less monitoring. But for a resource that is 
rarely used, having fossil launch when touched can be a better use of 
server resources than having fossil launched, listening, and paged in 
when touched.


The bottom line is that fossil does not require the use of inetd, 
xinetd, systemd, a web server.


But for systems where the administrator has made her own judgment of the 
balance of security, reliability, and other risk factors, the option is 
there.




a) I have nothing to ask at this time, so I don't even need to learn 
how to [ask]


Reasons you sound like a troll.

1. This statement right here. The questions you have asked have shown 
very little effort on your part.
2. Fake name. Not all trolls use aliases, sure. But I've seen far fewer 
outright trolls using obviously real identities.
3. Belligerence. We support fossil because it is useful to us. You 
approach us with a hostile attitude, then get worse when people engage 
and try to help.

4. The rest of this email which I'm not responding to in detail.

--
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

[fossil-users] Which IDE is good with Fossil ?

[K. Fossil user]

Hi,
I would like to have some information, even little one about IDE that have 
Fossil as a DVCS (even a plugin that is experimental).
a) glade/GTK based IDE    Qt based 
    wxWidget based    Python based    Java based
    etc.
b) it could be interesting if you could give your point of view about it.(good 
news, issues, personal point of view, etc.)
c) Even if I am not interested in a comparison Git/SVN/etc. vs Fossil inside an 
IDE, I do suppose that it may be useful to tell something about it...d) IMHO it 
is interesting to hear what are the features inside the IDE (you talked about) 
that you would like to have or that you really appreciate...e) If you could, 
tell us about the release which suited the best.(sometimes old release are 
better ...)


 Best Regards

K.___
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] Why we should NEVER use inetd/xinetd

[K. Fossil user]

In this mailing list we need to know everything about fossil and fossil related 
stuffs.- inetd/xinetd etc. that may be used in conjonction with Fossil (may be 
I am the only one who hear about a daemon (inetd) that was used with Fossil?)
- security related (Fossil is a server sort of)- Windows/Linux/etc. issue when 
it comes to Fossil- tips and tricks (most of the time are used with something 
else)
Every experience around Fossil use should be reported ...
This funny part :
>« you don't learn what to ask on the right mailing list »

You don't know when to stop which is worse... :-x

a) I have nothing to ask at this time, so I don't even need to learn how to 
[ask]
b) Someone who have something to say could demonstrate whatever he wants (e.g. 
Why does Fossil need (x)inetd when it is clearly forbidden by security expert 
?).c) If I were you the next time people would talk about OpenSSL/LibreSSL/etc. 
just demand to the Fossil Team to ban him.
    Of course, if someone would like to talk about GIT, it should be forbidden 
because it is a Fossil user enemy...

And if I understand your logic, you should not say that I am a troll/etc. : 
this is not Fossil ONLY talk ! :-)Wake up man ! :-D


Best Regards
K.

  De : Luca Ferrari 
 À : Fossil SCM user's discussion  
 Envoyé le : Mercredi 26 octobre 2016 6h25
 Objet : Re: [fossil-users] Why we should NEVER use inetd/xinetd
   
On Wed, Oct 26, 2016 at 1:02 AM, K. Fossil user
 wrote:
> For example, today I've learned that Luca is not aware about security like
> 90% of Windows normal users...

And still you don't learn what to ask on the right mailing list.
Stop trolling.
___
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] Fossil plugin for QtCreator IDE

[Artur Shepilko]

A quick follow-up. A few folks asked if the Fossil plugin for Qt Creator
supports "Commit" action -- it does support commit.
I missed to list it in my original email, sorry for the confusion.
This is actually mentioned on the project page:
https://github.com/nomadbyte/qtcreator-plugin-fossil

At a glance, the Tools>Fossil menu includes the following:

   - Annotate 
   - Diff 
   - Timeline 
   - Status 
   - 
   - Add 
   - Delete 
   - Revert 
   - ---
   - Diff
   - Timeline
   - Revert
   - Status
   - ---
   - Pull
   - Push
   - Update
   - Commit
   - Settings
   - Create Repository


All of these actions result in resp. Fossil commands, with a bunch of
accompanying niceties thanks to QtCreator's VCS framework.
Branching and tagging is done on commit.
Fossil "Clone" is handled via New Project wizard -- that's how it's done in
Qt Creator.

So for the most part this should shield the developer from SCM command-line
interaction in routine project work.
However "Merge" and some other repo-maintenance tasks should be done from
command-line or Fossil UI.
>From personal experience, I feel that "Stash" should also be made available
in the plugin, but that's later.

Hope this clears it.


On Sat, Oct 8, 2016 at 2:10 PM, Artur Shepilko  wrote:

> We finally got to release Fossil plugin for QtCreator:
> https://github.com/nomadbyte/qtcreator-plugin-fossil
>
> The Fossil plugin is free and open-source, of course. The README describes
> how to build it. The most recent QtCreator version we used it with is
> QtCreator-4.0.1, which is included in Qt 5.6.1-1 LTS (long-time support)
> release. Through its life, internally we used the plugin with previous
> versions of both QtCreator and Fossil client (the most recent was 1.35).
>
> Hope this would help further spread the use of Fossil SCM, which is hard
> to over-praise for its simplicity and versatility. Notably, thanks to
> Fossil core devs for advancing its features over the years -- we really
> appreciated this (first plugin release used fossil 1.26)
>
> For folks not familiar with QtCreator -- it's a multi-platform IDE for
> C/C++ development. Primarily it targets Qt-based projects, but it's also
> used with non-Qt projects and supports CMake-based projects. Support for
> several popular SCMs is already built-in, yet Fossil is not supported --
> with this plugin it is!
>
> Fossil plugin adds Fossil SCM as a choice for version control to use with
> projects (similar to git, bazaar etc.). It's implemented using QtCreator
> VCS framework which calls Fossil command-line interface. It supports
> create/clone project repo, add/delete/rename files, diff/annotate,
> status/timeline, revert/update/pull/push. Base set of operations, but it's
> sufficient in routine development, the rest can be done directly with
> fossil command.
>
> Enjoy!
>
> Artur
>
>
___
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] git incremental import speedup.

[Karel Gardas]

On Wed, Oct 26, 2016 at 11:53 PM, Adam Jensen  wrote:
> On 10/26/2016 05:37 PM, Karel Gardas wrote:
>> I'm now able to import OpenBSD
>> source tree from OpenBSD src git mirror to fossil.
>
> This might be a silly question since I am terribly uniformed of the
> issues but could you have imported the OpenBSD source directly from
> their CVS repository?
>
> http://www.fossil-scm.org/index.html/wiki?name=Import+CVS+Repositories
> http://www.openbsd.org/anoncvs.html

For this you would need to have working cvs -> svn transition tool but
the problem is that cvs2svn was buggy on OpenBSD src. I've tested that
in the past and reported even a proper bugreport but I'm not able to
find it now...
___
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] git incremental import speedup.

[Karel Gardas]

On Wed, Oct 26, 2016 at 11:44 PM, jungle Boogie  wrote:
> On 26 October 2016 at 14:37, Karel Gardas  wrote:
>> Anyway, there is small nitpick. While using incremental import on such
>> repo, fossil is horribly slow. The pstack command reveals that
>> majority of time is spent in import_cmd -> export_marks ->
>> mark_name_from_rid call chain. I've solved this by patch below which
>> basically just adds index on xmark's trid field. Speedup is from 50-60
>> minutes (fossil head) to 30-40 seconds (fossil head + patch) so please
>> consider for inclusion if possible -- and if it is correct of course.
>> I think the same change may also be added to export.c but I'm not able
>> to test it now as I'm not using export for two-way sync yet.
>
>
> You're saying openbsd import from git to fossil with fossil head is 60
> minutes and with your patch and with the same repo on the same
> machine, it's not 60 seconds??

No, I'm not talking about whole import but about incremental import.
If you like to know all numbers then

1) import OpenBSD src git -> fossil from 1995 till let say 2016-10-24
took 42 hours when run with --no-rebuild option

2) *incremental* import of 2016-10-25 changes (few patches) takes 56
minutes on fossil head and if I do the same with the patch I takes 34
seconds.

Honestly (2) is still not correct since patches into git are pushed
constantly so I do not test exactly the same situation. I just seen
few patches added into git so I tested another run, OK?
___
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] git incremental import speedup.

[Adam Jensen]

On 10/26/2016 05:37 PM, Karel Gardas wrote:
> I'm now able to import OpenBSD
> source tree from OpenBSD src git mirror to fossil.

This might be a silly question since I am terribly uniformed of the
issues but could you have imported the OpenBSD source directly from
their CVS repository?

http://www.fossil-scm.org/index.html/wiki?name=Import+CVS+Repositories
http://www.openbsd.org/anoncvs.html
___
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] git incremental import speedup.

[jungle Boogie]

On 26 October 2016 at 14:37, Karel Gardas  wrote:
> Anyway, there is small nitpick. While using incremental import on such
> repo, fossil is horribly slow. The pstack command reveals that
> majority of time is spent in import_cmd -> export_marks ->
> mark_name_from_rid call chain. I've solved this by patch below which
> basically just adds index on xmark's trid field. Speedup is from 50-60
> minutes (fossil head) to 30-40 seconds (fossil head + patch) so please
> consider for inclusion if possible -- and if it is correct of course.
> I think the same change may also be added to export.c but I'm not able
> to test it now as I'm not using export for two-way sync yet.


You're saying openbsd import from git to fossil with fossil head is 60
minutes and with your patch and with the same repo on the same
machine, it's not 60 seconds??



-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] git incremental import speedup.

[Karel Gardas]

Hello,

first of all thanks a lot to the developer(s) who fixed import and
incremental import from git to fossil. I'm now able to import OpenBSD
source tree from OpenBSD src git mirror to fossil.

Anyway, there is small nitpick. While using incremental import on such
repo, fossil is horribly slow. The pstack command reveals that
majority of time is spent in import_cmd -> export_marks ->
mark_name_from_rid call chain. I've solved this by patch below which
basically just adds index on xmark's trid field. Speedup is from 50-60
minutes (fossil head) to 30-40 seconds (fossil head + patch) so please
consider for inclusion if possible -- and if it is correct of course.
I think the same change may also be added to export.c but I'm not able
to test it now as I'm not using export for two-way sync yet.

Thanks,
Karel

Index: src/import.c
==
--- src/import.c
+++ src/import.c
@@ -1761,10 +1761,11 @@
 ** times but only the last tag should be used.  And we do not know which
 ** occurrence of the tag is the last until the import finishes.
 */
 db_multi_exec(
"CREATE TEMP TABLE xmark(tname TEXT UNIQUE, trid INT, tuuid TEXT);"
+   "CREATE INDEX xmark_trid_index ON xmark(trid);"
"CREATE TEMP TABLE xbranch(tname TEXT UNIQUE, brnm TEXT);"
"CREATE TEMP TABLE xtag(tname TEXT UNIQUE, tcontent TEXT);"
 );

 if( markfile_in ){
___
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 rebuild on new version(s)?

[Kain Abel]

Thanks for the quick clarification and the useful tips.

With regards,
Kain
___
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 rebuild on new version(s)?

[Richard Hipp]

On 10/26/16, Kain Abel  wrote:
> Dear readers,
>
> after a new release is the task 'fossil rebuild $existing_repro' a
> SHOULD, a MUST or is it not necessary?

There have been no database schema changes, so a rebuild is not necessary.

You might want to run "fossil rebuild --compress-only" if you want to
minimize the size of your repository/  Also, if you have an older
repository, running "fossil rebuild --pagesize 8192 --wal" might give
you a small performance increase.  But all of this is entirely
optional.


-- 
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

[fossil-users] fossil rebuild on new version(s)?

[Kain Abel]

Dear readers,

after a new release is the task 'fossil rebuild $existing_repro' a
SHOULD, a MUST or is it not necessary?

https://www.ietf.org/rfc/rfc2119.txt

Is there an internal trigger, if it should be necessary in future versions?

There were no technical problems and it is more of a kind of
'academic' question, but it's a missing part (and hopefully not
overseen) in FAQ and Quick Start Guide [in the On upgrade section].

Thank you for your attention and time,
Kain Abel
___
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] Why we should NEVER use inetd/xinetd

[Luca Ferrari]

On Wed, Oct 26, 2016 at 1:02 AM, K. Fossil user
 wrote:
> For example, today I've learned that Luca is not aware about security like
> 90% of Windows normal users...

And still you don't learn what to ask on the right mailing list.
Stop trolling.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users