Re: [fossil-users] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti

[Andy Bradford]

Thus said Richard Hipp on Thu, 21 Dec 2017 16:46:05 -0500:

> Suppose Fossil were enhanced to show an icon beside each check-in that
> indicated whether or not the check-in  had been signed and whether the
> signature had been verified.

Regarding such an enhancement, would  it involve configuring an external
tool that  is passed  the content  (perhaps on  stdin) and  then returns
success/fail/whatever semantics  Fossil defines? If  so, I can  see this
being quite  useful to integrate  with any kind of  content verification
system, and not just PGP. One could write a wrapper around gpg, signify,
openssl, or even submit it to a virus scanner if they wanted, and Fossil
could report the the ``verification'' of it.

Andy
-- 
TAI64 timestamp: 40005a3c8ffe


___
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 --repolist showing no repositories

[Andy Bradford]

Thus said "dewey.hyl...@gmail.com" on Thu, 21 Dec 2017 13:40:36 -0500:

> * fossil does  serve both a repo  file and a directory  if these files
> are copied to a different local directory.

Unless  things have  changed, it  is  generally not  recommended to  run
Fossil on a non-local filesystem.

Andy
-- 
TAI64 timestamp: 40005a3c8d71


___
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 skin for trunk fossil

[Antoine Chavasse]

Thanks, and I'll be happy to do it!
I've already made sure that all the included code is either from Blitz,
which I think should be ok to reuse in this context, or from MIT licensed
code. I think the MIT code should be ok to use, since it's the skeleton css
framework, which Blitz also uses.

The remaining bits, including the file browser icons, were made by myself.

On Fri, Dec 22, 2017 at 1:40 AM Richard Hipp  wrote:

> On 12/21/17, Antoine Chavasse  wrote:
> > I made a new skin...
>
> The screen shots look good.  Would you be willing to secure clear
> copyright on all of the code, then sign a contributors agreement
> (https://www.fossil-scm.org/fossil/doc/trunk/www/copyright-release.html)
> so that I can incorporate your new sink into Fossil as one of the
> built-ins?
> --
> 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] New skin for trunk fossil

[Richard Hipp]

On 12/21/17, Antoine Chavasse  wrote:
> I made a new skin...

The screen shots look good.  Would you be willing to secure clear
copyright on all of the code, then sign a contributors agreement
(https://www.fossil-scm.org/fossil/doc/trunk/www/copyright-release.html)
so that I can incorporate your new sink into Fossil as one of the
built-ins?
-- 
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] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti

[jungle Boogie]

On 21 December 2017 at 15:03, Warren Young  wrote:
> On Dec 21, 2017, at 2:58 PM, jungle Boogie  wrote:
>>
>> 3) Small green lock, like you see in your browser for https
>> 2) Unlocked & red
>> 1) Locked, but grey
>
> That’s going to make the red-green color blind unhappy:
>
>
> https://en.wikipedia.org/wiki/Color_blindness#Red%E2%80%93green_color_blindness
>

You're right, I wasn't taking that into account.

>>>  And where would they be placed?  Beside the username?
>
> Works for me.
>
>> I think that's a good starting point, perhaps left of the username.
>
> I think right, simply because it’s currently ordered most-clicked to 
> least-clicked, more or less.
>

In between the username and date/time or right of date/time?

-- 
---
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] New skin for trunk fossil

[Antoine Chavasse]

I made a new skin, very loosely based on blitz. Basically, I wanted to make
a dark version of it and then went into a crusade against lines and border
everywhere.

One caveat is that it only works on trunk fossil for now, as it relies on
the automatic generating of the html header, and on the new element classes
that have been added recently.

Since the theme doesn't work on the version of fossil that chisel is
currently running, I've included screenshots.

http://chiselapp.com/user/achavasse/repository/ardoise-skin

There is probably room for improvement, especially since I'm a absolute CSS
newbie. Any suggestion or fix is welcome!
___
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] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti

[Warren Young]

On Dec 21, 2017, at 2:58 PM, jungle Boogie  wrote:
> 
> 3) Small green lock, like you see in your browser for https
> 2) Unlocked & red
> 1) Locked, but grey

That’s going to make the red-green color blind unhappy:

   
https://en.wikipedia.org/wiki/Color_blindness#Red%E2%80%93green_color_blindness

There are browser plugins to simulate the various forms of color blindness.  
It’s fascinating to play with them for a while.

I’d recommend designing three distinct black-filled SVG icons, then style as 
follows:

1. Drop the opacity of all signedness-state icons to blend it with the 
background, giving a darker form of the skin’s BG color:

   svg.signState {
  opacity: 0.4;
   }

2. Change the inner fill color of the icons based on applied classes:

   svg.signed.inner {
  fill: deepskyblue;
   }
   svg.forged.inner {
  fill: firebrick;
   }

The unsigned state has no tint in this example, but it should still have a 
distinct CSS class so that skin authors can recolor it to suit their taste and 
accessibility requirements.

>>  And where would they be placed?  Beside the username?

Works for me.

> I think that's a good starting point, perhaps left of the username.

I think right, simply because it’s currently ordered most-clicked to 
least-clicked, more or less.

> How are the signatures verified?

There are lots and lots of ways because there is no single best answer.  Some 
ideas:

1. Add a column to the Fossil users table.  Add a text input field on Admin > 
Users accepting a GPG public key.  Also add an Admin preference for whether 
this column syncs between clones by default, which effectively controls whether 
trust is transitive.  Downside: the Fossil Admin gets to maintain yet another 
authentication system.

2. Pull from a PGP key server by email parsed from the current Contact Info 
column.  Downside: all the problems of PGP email.

3. Delegate identity to another provider via any of

   https://en.wikipedia.org/wiki/Federated_identity
   https://en.wikipedia.org/wiki/Identity_management_system

You might need a pluggable architecture so that Fossil can ship with the first 
two, but BigCorp can swap in an LDAP or RADIUS back end.  It *might* be 
sufficient to allow this to be done via Tcl, as that should give you access to 
quite a few protocol clients, and the ability to write more at need.
___
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 clone blocks other clones

[Richard Hipp]

On 12/21/17, Peter Spjuth  wrote:
>
> The patch below makes it work,

Thanks.  Checked in on trunk.

-- 
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] Fossil clone blocks other clones

[Warren Young]

On Dec 21, 2017, at 2:58 PM, Peter Spjuth  wrote:
> 
> I noticed that while a clone was going on another could not be done due to 
> the global config being locked:

I’ve seen such problems when I tried “open”ing *.fossil files with one Fossil 
instance that another was run against with “fossil server”.

The solution I ended up with is to clone a copy on the same machine, so that 
one clone is “served” and the other is “opened.”  On commit, the changes go 
first to the “opened” repo, and then are sync’d to the “served” repo.

This entirely avoids the deadlock, at the expense of N+1 copies of each repo on 
the “fossil server” machine, where N is the number of local developers, as 
compared to N repo copies with the naive solution.
___
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] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti

[jungle Boogie]

On 21 December 2017 at 14:16, Richard Hipp  wrote:
> On 12/21/17, jungle Boogie  wrote:
>>
>> How are the signatures verified?
>
> Signatures are not verified, at the moment.
>
> Probably each repository would have a set of trusted public keys.
> Then as each check-in is received via push (or during a rebuild) those
> with signatures have the signatures verified using the set of trusted
> keys.  Those for which the keys are unknown get marked as signed but
> unverified.
>

Gotcha. I was assuming this was already implemented and I missed a
feature like this.

I like the idea of the repo keeping track of the keys, rather than a
key server _in this instance_. Fossil, while distributed, can work
where's there's no internet. If that's the case, keys wouldn't be
verified.

> The signatures are currently generated by running gpg in a separate
> process.  I suppose the verification step could do something similar.
>
> Hey - I suppose there is a fourth state:  (4) Forgery: The signature
> does not match.

I like SDR's response!

> --
> D. Richard Hipp
> d...@sqlite.org


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

Re: [fossil-users] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti

[Roy Keene]

For what it's worth, I submitted a patch a while back to add S/MIME 
support to Fossil's signature scheme.  I still apply this patch to Fossil 
when I use it.  S/MIME uses PKI and is primarily used for non-repdudiation 
or encryption in email (every major email client supports it out of the 
box).  PKI is also used for HTTPS.


On Thu, 21 Dec 2017, Richard Hipp wrote:


On 12/21/17, jungle Boogie  wrote:


How are the signatures verified?


Signatures are not verified, at the moment.

Probably each repository would have a set of trusted public keys.
Then as each check-in is received via push (or during a rebuild) those
with signatures have the signatures verified using the set of trusted
keys.  Those for which the keys are unknown get marked as signed but
unverified.

The signatures are currently generated by running gpg in a separate
process.  I suppose the verification step could do something similar.

Hey - I suppose there is a fourth state:  (4) Forgery: The signature
does not match.
--
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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti

[Scott Robison]

Forged should be a skull and crossbones. I would think yellow and red
unlocked locks and green locked locks, but definitely with hover text for
those of us with faulty color perception.

On Dec 21, 2017 3:16 PM, "Richard Hipp"  wrote:

> On 12/21/17, jungle Boogie  wrote:
> >
> > How are the signatures verified?
>
> Signatures are not verified, at the moment.
>
> Probably each repository would have a set of trusted public keys.
> Then as each check-in is received via push (or during a rebuild) those
> with signatures have the signatures verified using the set of trusted
> keys.  Those for which the keys are unknown get marked as signed but
> unverified.
>
> The signatures are currently generated by running gpg in a separate
> process.  I suppose the verification step could do something similar.
>
> Hey - I suppose there is a fourth state:  (4) Forgery: The signature
> does not match.
> --
> 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti

[Richard Hipp]

On 12/21/17, jungle Boogie  wrote:
>
> How are the signatures verified?

Signatures are not verified, at the moment.

Probably each repository would have a set of trusted public keys.
Then as each check-in is received via push (or during a rebuild) those
with signatures have the signatures verified using the set of trusted
keys.  Those for which the keys are unknown get marked as signed but
unverified.

The signatures are currently generated by running gpg in a separate
process.  I suppose the verification step could do something similar.

Hey - I suppose there is a fourth state:  (4) Forgery: The signature
does not match.
-- 
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] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti

[Zakero]

On Thu, Dec 21, 2017 at 3:58 PM, jungle Boogie 
wrote:

> On 21 December 2017 at 13:46, Richard Hipp  wrote:
> > Suppose Fossil were enhanced to show an icon beside each check-in that
> > indicated whether or not the check-in had been signed and whether the
> > signature had been verified.  Thus, there are three states:  (1)
> > unsigned, (2) signed but unverified, and (3) signed and verified.
> > What would the three icons for these three states look like?  And
> > where would they be placed?  Beside the username?
>
> 3) Small green lock, like you see in your browser for https
> 2) Unlocked & red
> 1) Locked, but grey
>
> Nice


> I would think hovering over the icon would show some text, such as
> "This commit is signed & verified".
>
> >   And where would they be placed?  Beside the username?
>
> I think that's a good starting point, perhaps left of the username.
>
> How are the signatures verified?
>

There are several Key Servers available, so it should probably be
configurable.  And if it is configurable, would there be a Key Server per
repository or a Key Server per user?  Or both?
___
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 clone blocks other clones

[Peter Spjuth]

Hi,

I noticed that while a clone was going on another could not be done due to
the global config being locked:

fossil: database is locked: {DELETE FROM global_config WHERE name  =
'repo:/xxx';}
SQLITE_ERROR: statement aborts at 1: [ROLLBACK] cannot rollback - no
transaction is active

Both clone and open are blocked by a clone, which is rather annoying.

I think I tracked it down to that in clone_cmd this happens:
Config database is opened.
A db_swap_connections pair happens.
This leaves the config db as main db since the last swap does nothing.
Repo database is opened, attached to the config db.
Then it seems the config db gets locked with the repo db in the clone
transaction.

The patch below makes it work, but I can't really say if it's the right way
to do it.

/Peter

Index: src/clone.c
==
--- src/clone.c
+++ src/clone.c
@@ -166,12 +166,15 @@
 }else{
   g.zLogin = db_text(0, "SELECT login FROM user WHERE cap LIKE
'%%s%%'");
 }
 fossil_print("Repository cloned into %s\n", g.argv[3]);
   }else{
+/* Close config while opening main database */
+db_close_config();
 db_create_repository(g.argv[3]);
 db_open_repository(g.argv[3]);
+db_open_config(0, 0);
 db_begin_transaction();
 db_record_repository_filename(g.argv[3]);
 db_initial_setup(0, 0, zDefaultUser);
 user_select();
 db_set("content-schema", CONTENT_SCHEMA, 0);
___
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] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti

[jungle Boogie]

On 21 December 2017 at 13:46, Richard Hipp  wrote:
> Suppose Fossil were enhanced to show an icon beside each check-in that
> indicated whether or not the check-in had been signed and whether the
> signature had been verified.  Thus, there are three states:  (1)
> unsigned, (2) signed but unverified, and (3) signed and verified.
> What would the three icons for these three states look like?  And
> where would they be placed?  Beside the username?

3) Small green lock, like you see in your browser for https
2) Unlocked & red
1) Locked, but grey

I would think hovering over the icon would show some text, such as
"This commit is signed & verified".

>   And where would they be placed?  Beside the username?

I think that's a good starting point, perhaps left of the username.

How are the signatures verified?


> --
> D. Richard Hipp
> d...@sqlite.org



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

Re: [fossil-users] fossil --repolist showing no repositories

[dewey.hyl...@gmail.com]

This is something I've not thought of - and I think this is how the fossil 
source
itself is propagated to its official mirrors. I don't know why this didn't occur
to me, unless it is simply an instance of:
"When you are a hammer, everything is a nail."
And I've been looking at container-based replication (eg. docker swarm mode).

At any rate, my comment regarding fossil not being the only service in the 
category
was related apps which were difficult to separate from their data. The fossil
front-end can't be separated from the data because the front-end and back-end 
are
the same. A mysql database server cannot be separated from its data, but any of 
the
front-ends could be - because they are built to obtain their data over the 
network.

In the end, I hate that I spent two days on something which I should have 
logically
mapped around before I got started - but I've learned some, so it wasn't all 
wasted
time. I'll look at using fossil to provide the replication for itself and move 
on
to the next service.

Thanks again for your insight.

- On Dec 21, 2017, at 4:10 PM, Warren Young war...@etr-usa.com wrote:

> On Dec 21, 2017, at 1:00 PM, dewey.hyl...@gmail.com wrote:
>> 
>> That's where the NAS and sshfs came into play.
> 
> You seem to be trying to use containers and such to provide distributed 
> service,
> but Fossil already does that: it’s a DVCS.  There’s no one telling you it must
> live in only one place.
> 
> Therefore:
> 
> Option 1: Run the container anywhere you like, but with its internal Fossil
> storing to the container’s view of the host OS, not to some other machine over
> a network file system.  Then from another computer, clone that repository onto
> the SAN or NAS.  Periodically, run a sync.  Now your repo is both in the
> container and on the NAS/SAN.
> 
> Option 2: If the NAS permits, run a Fossil instance there.  Clone it into the
> container for actual use.  Whether syncs mostly go first to the container or 
> to
> the NAS and are then pushed to the other doesn’t much matter.  Again, think
> distributed.
> 
> Either way, Fossil get a local real POSIX-compliant file system for SQLite, 
> and
> uses its own sync protocol for inter-host operations, which means that SQLite
> transactions end up avoiding the need to worry about network unreliability.
> The clone/push will either complete successfully or it will be wholly rolled
> back to the prior safe state.
> 
>> I'm sure fossil won't be the only service
>> in that category - I just started with fossil because I *thought* it would 
>> be an
>> easy win.
> 
> Any DBMS is going to have problems with sshfs.  It’s not something special to
> SQLite.
> 
> If you mean to reference VCSes competing with Fossil, it’s at best a “push” 
> (in
> the poker sense) when it comes to networked data reliability with your current
> storage design, simply because reliable storage in the face of multiple 
> writers
> requires correct locking.
> 
> Switching to another VCS may even make things worse.  Fossil looks like it is
> causing problems here, but only because it’s trying to do things in an
> ACID-compliant fashion, where other systems might not even try, and so 
> *appear*
> to be less problem-free.
> 
> I’ve tried researching Git ACID compliance and concurrency, and all I see is 
> raw
> speculation, no hard claims from people who actually know what they’re talking
> about, and have battle-tested it.
> 
> SQLite, by contrast, is very well known to be a durable data store…*if* you 
> put
> it on a filesystem with correct locking semantics!
> ___
> 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] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti

[Richard Hipp]

Suppose Fossil were enhanced to show an icon beside each check-in that
indicated whether or not the check-in had been signed and whether the
signature had been verified.  Thus, there are three states:  (1)
unsigned, (2) signed but unverified, and (3) signed and verified.
What would the three icons for these three states look like?  And
where would they be placed?  Beside the username?
-- 
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] fossil --repolist showing no repositories

[Warren Young]

On Dec 21, 2017, at 1:00 PM, dewey.hyl...@gmail.com wrote:
> 
> That's where the NAS and sshfs came into play.

You seem to be trying to use containers and such to provide distributed 
service, but Fossil already does that: it’s a DVCS.  There’s no one telling you 
it must live in only one place.

Therefore:

Option 1: Run the container anywhere you like, but with its internal Fossil 
storing to the container’s view of the host OS, not to some other machine over 
a network file system.  Then from another computer, clone that repository onto 
the SAN or NAS.  Periodically, run a sync.  Now your repo is both in the 
container and on the NAS/SAN.

Option 2: If the NAS permits, run a Fossil instance there.  Clone it into the 
container for actual use.  Whether syncs mostly go first to the container or to 
the NAS and are then pushed to the other doesn’t much matter.  Again, think 
distributed.

Either way, Fossil get a local real POSIX-compliant file system for SQLite, and 
uses its own sync protocol for inter-host operations, which means that SQLite 
transactions end up avoiding the need to worry about network unreliability.  
The clone/push will either complete successfully or it will be wholly rolled 
back to the prior safe state.

> I'm sure fossil won't be the only service
> in that category - I just started with fossil because I *thought* it would be 
> an
> easy win.

Any DBMS is going to have problems with sshfs.  It’s not something special to 
SQLite.

If you mean to reference VCSes competing with Fossil, it’s at best a “push” (in 
the poker sense) when it comes to networked data reliability with your current 
storage design, simply because reliable storage in the face of multiple writers 
requires correct locking.

Switching to another VCS may even make things worse.  Fossil looks like it is 
causing problems here, but only because it’s trying to do things in an 
ACID-compliant fashion, where other systems might not even try, and so *appear* 
to be less problem-free.

I’ve tried researching Git ACID compliance and concurrency, and all I see is 
raw speculation, no hard claims from people who actually know what they’re 
talking about, and have battle-tested it.

SQLite, by contrast, is very well known to be a durable data store…*if* you put 
it on a filesystem with correct locking semantics!
___
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] Rebrand Fossil as "Blockchain-VCS"...

[Thomas Levine]

The other distributed version control systems are all blockchains too,
yes?

I find the term "distributed ledger" more interesting, as I store the
accounts for my unincorporated server cooperative in GNU ledger format,
controlled redundantly in git (for my colleagues) and fossil (for me).

This distributed ledger is private, 2.4mb in size (including many other
files, such as copies of invoices), and portable. If my colleagues would
use fossil instead of git, the history would be immutable. I appreciate
the possibility to store far more complex information than is convenient
in Bitcoin, but if I were to restrict the information to what is stored
in Bitcoin, I could represent a transaction history in something like
one-tenth the space that it would take up in Bitcoin.

Fossil is far superior to Bitcoin for situations where you can weakly
trust the other people who are editing your ledger.
___
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] Timeline comments ignore all newlines AGAIN...

[sky5walk]

Big thanks to Zakero for highlighting subtle CSS/html components necessary
to achieve my desired Compact view.
With the following changes, I now prefer Compact view over Modern.
/* CSS */
span.timelineCompactComment {
  display: block;/*Necessary for margin-top to work.*/
  font-family: Consolas; /*Fixed pitch font.*/
  white-space: pre;  /*Respect newlines and spaces. */
  margin-top: -1em;  /*Shove comment higher in the cell.*/
}
span.timelineEllipsis {
  display: block;/*Necessary for visibilty to work. */
  visibility: hidden;/*Do not show '...'*/
  position: absolute;/*No newline applied to hidden content.*/
}
span.clutter {
  display: block;/*Necessary for visibilty to work. */
  visibility: hidden;/*Do not show 'check-in,user,tags.'*/
  position: absolute;/*No newline applied to hidden content.*/
}

Thanks for Fossil!

On Wed, Dec 20, 2017 at 10:10 AM,  wrote:

> Is this leading and trailing newline in 'timeline[Modern|Compact]Comment'
> intentional or bug?
> Is it necessary to create padding for the borders?
> If so, why can't borders be applied with CSS?
>
> I'm trying to shrink my Timeline text but no idea what CSS strips contents
> of object?
>
> What I see...
> " <-- Why double quote here?
> My multiline comment is here.
> And here...
> " <-- Why double quote here?
>
> What I want...
> "My multiline comment is here.
> And here..."
>
>
> On Tue, Dec 19, 2017 at 1:56 PM,  wrote:
>
>> Ok, using Google Chrome Version 65, I never see CheckBox anywhere within
>> trunk of:
>>   http://fossil-scm.org/index.html/timeline.
>>
>> "Johan"
>> Leaf check-in: a6c5a462 user: drh tags: trunk
>> When you select that element, you should see, in one of the "Developer's
>> Tools" frames, the definition for the selected element's CSS class(es):
>>
>> (CB = CheckBox)
>>
>> .timelineModernDetail{
>>   CB: font-size: 80%;
>>   CB: text-align: right;
>>   CB: float: right;
>>   CB: opacity: 0.75;
>>   CB: margin-top: 0.5em;
>>   CB: margin-left: 1em;
>> }
>>
>> But I do see the light. The Style was not 'text-align: left', but 'float:
>> left'.
>> span.timelineModernDetail {
>>   float: left;
>> }
>>
>> Even with this insight, I cannot shift the 'timelineModernComment' text
>> up because it is mysteriously surrounded with a leading and trailing
>> newline?
>>
>> What I see...
>> "  <-- Why is the double quote here?
>> My multiline comment is here.
>> And here...
>> "  <-- Why is the double quote here?
>>
>> What I want...
>> "My multiline comment is here.
>> And here..."
>>
>>
>> Thanks for the 'teach a man to fish' pointers.
>>
>
>
___
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] Rebrand Fossil as "Blockchain-VCS"...

[Warren Young]

On Dec 21, 2017, at 12:50 PM, Richard Hipp  wrote:
> 
> Will someone with a modicum of marketing-foo please explain to me how
> to do this?

What would it mean for Fossil’s stock price to triple? :)
___
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 --repolist showing no repositories

[Richard Hipp]

On 12/21/17, dewey.hyl...@gmail.com  wrote:
> 1268vfile_scan(&base, blob_size(&base), 0, 0, 0);
> (gdb) n

You need to step into vfile_scan() (using "s" instead of "n") because
that is where all the interesting stuff happens.  There is a loop
inside vfile_scan() that uses readdir() to read out the contents of a
directory and store each filename into the SFILE temp table of the
database.  You need to figure out for us why it is that the *.fossil
files are not being discovered by readdir(), or why they are not
making it into the SFILE table.  This will require some C-debugging
skills.

Nobody else can do this for you, because nobody else is able to
reproduce your problem.

-- 
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] fossil --repolist showing no repositories

[dewey.hyl...@gmail.com]

Ugh, that is bad news. I was interested in the ssh method for ease of use as 
well
as its encrypted communications ... I suppose nfs is another possibility, but 
I'm
not a fan for several reasons. And maybe iscsi, if 

Here is what I'm currently attempting to accomplish:

We have redundant storage options (SAN, NAS) to leverage. These are largely 
static
services whose hardware rarely changes. Those get backed up and some of them are
also replicated off-site for DR purposes. I am told to trust the storage, and 
find
ways to make our apps and services more redundant.

We are using containers in docker swarm mode for other apps, so I was trying to
find a way to fit fossil into that picture. Your load balancer points to all
backend swarm nodes. One instance of fossil service can be fired up on any node,
and all nodes redirect traffic to the correct location. If the node running 
fossil
goes away, an instance is started elsewhere. For this to work, of course, I need
shared storage. That's where the NAS and sshfs came into play.

I've been using fossil in a container for quite a long while, just not in swarm
mode - so the app container is not decoupled from the data, which makes failing
over to another node quite a bit more difficult. I do understand fossil uses
sqlite, which of course is *not* a network-friendly database such as mysql. Its
simplicity is why I love it, and why I will stick with it. I'm just hoping to 
find
a solution to my need that is simple - sshfs would have been great in that 
regard.

Any other simple solution would be welcomed. Otherwise, I'll just have to stick
with the tried-and-true backup and restore method, and not being able to move 
the
fossil service around very easily. But I'm sure fossil won't be the only service
in that category - I just started with fossil because I *thought* it would be an
easy win.

Thanks for your insight.

- On Dec 21, 2017, at 2:02 PM, Warren Young war...@etr-usa.com wrote:

> On Dec 21, 2017, at 11:40 AM, dewey.hyl...@gmail.com wrote:
>> 
>>  ranch2@10.1.51.120:fossils on /fossils type fuse.sshfs
>>  (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
> 
> Running SQLite — upon which Fossil is based — over sshfs is a bad idea.  The
> current implementation doesn’t even try to implement the file locking
> operation:
> 
>https://github.com/libfuse/sshfs/blob/master/sshfs.c#L3304
> 
> That structure definition would have to include the “.lock” member for the 
> sort
> of locking SQLite does for this to be safe.
> 
> See also:
> 
>
> https://www.sqlite.org/howtocorrupt.html#_filesystems_with_broken_or_missing_lock_implementations
> 
> There are other network file systems with locking semantics, but it’s often
> optional, and when present and enabled, it is often buggy.
> 
> Here’s hoping you have some other option.  Best would be to store the 
> *.fossils
> inside the container.  Second best would be to map a [virtual] block device
> into the container and put a normal Linux file system on it.
> ___
> 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] Rebrand Fossil as "Blockchain-VCS"...

[Richard Hipp]

http://www.nasdaq.com/press-release/long-island-iced-tea-corp-to-rebrand-as-long-blockchain-corp-20171221-00468
 (HT: slashdot and arstechnica -
https://arstechnica.com/tech-policy/2017/12/iced-tea-company-stock-triples-after-adding-blockchain-to-name/)

Unlike iced tea, Fossil really does have something to do with
blockchain.  The sequence of commits in a Fossil repository *is* a
blockchain.  So, why can't we rebrand fossil as Blockchain-VCS or
something and move on toward world domination?

Will someone with a modicum of marketing-foo please explain to me how
to do this?

-- 
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] fossil --repolist showing no repositories

[dewey.hyl...@gmail.com]

New host: CentOS 7
Running directly on the host, with repositories over sshfs as before:

ranch2@10.1.51.120:fossils on /fossils type fuse.sshfs 
(rw,nosuid,nodev,relatime,user_id=0,group_id=0)

I'm not a C dev, so I'm largely unfamiliar with this type of debugging;
let me know if I need to handle this differently somehow. For better
readability, I've also posted the debug output here:

  https://paste.pound-python.org/show/QWBnPqc953rXnFK4pxOg/

```
[root@localhost fossil-2.4]# gdb ./fossil   


   [45/2179]
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /root/fossil-2.4/fossil...done.
(gdb) break repo_list_page
Breakpoint 1 at 0x45c1ce: file ./src/main.c, line 1240.
(gdb) run http --repolist /fossils 
(gdb) n
1278  n = db_int(0, "SELECT count(*) FROM sfile");
(gdb) n
1279  if( n>0 ){
(gdb) n
1308@ No Repositories Found
(gdb) n
1310  @ 
(gdb) n
1312  cgi_reply();
(gdb) n
HTTP/1.0 200 OK
Date: Thu, 21 Dec 2017 19:02:47 GMT
Connection: close
X-UA-Compatible: IE=edge
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 132



http:///"; />
Repository List


No Repositories Found


1313  sqlite3_close(g.db);
(gdb) n
1314  g.db = 0;
(gdb) n
1315  return n;
(gdb) n
1316}
(gdb) n
process_one_web_page (zNotFound=0x0, pFileGlob=0x0, allowRepoList=1) at 
./src/main.c:1497
1497}else if( zNotFound ){
(gdb) n
1506  @ Not Found
(gdb) n
1507  cgi_set_status(404, "not found");
(gdb) n
1508  cgi_reply();
(gdb) n
HTTP/1.0 404 not found
Date: Thu, 21 Dec 2017 19:03:14 GMT
Connection: close
X-UA-Compatible: IE=edge
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 151



http:///"; />
Repository List


No Repositories Found


Not Found
1510return;
(gdb) n
1706}
(gdb) n
cmd_http () at ./src/main.c:2226
2226}
(gdb) n
main (argc=4, argv=0x7fffe678) at ./src/main.c:768
768   fossil_exit(0);
(gdb) n
[Inferior 1 (process 12740) exited normally]
(gdb) q
[root@localhost fossil-2.4]# ls -alh /fossils/
total 1.6M
drwxr-xr-x   1 foouser foouser8 Dec 21 14:12 .
dr-xr-xr-x. 18 rootroot 259 Dec 21 13:55 ..
-rw-r--r--   1 foouser foouser 272K Dec 21 11:15 archsetup.fossil
-rw-r--r--   1 foouser foouser 224K Dec 21 11:15 guac-install-script.fossil
-rw-r--r--   1 foouser foouser 224K Dec 21 11:15 miscreports.fossil
-rwxrwxrwx   1 foouser foouser 308K Dec 21 14:12 pkgReport.fossil
-rw-r--r--   1 foouser foouser 596K Dec 21 11:31 servercfg.fossil

```

- On Dec 21, 2017, at 1:40 PM, dewey hylton dewey.hyl...@gmail.com wrote:

> Unfortunately, my first stab at this failed:
> 
> (gdb) break repo_list_page
> Breakpoint 1 at 0x7ccc0: file ./src/main.c, line 1238.
> (gdb) run http --repolist /fossils  Starting program: /root/fossil-2.4/fossil http --repolist /fossils  warning: Error disabling address space randomization: Operation not permitted
> Could not trace the inferior process.
> Error: ptrace: Operation not permittedDuring startup program exited with code
> 127.
> (gdb)
> 
> This was done in the same container which is failing as previously described.
> The host is running rancheros, which is a very stripped down and highly
> customized distribution meant specifically for hosting docker containers. As
> such, I'll have to find a different host and distribution to test this 
> against.
> 
> Things I have learned thus far:
> * fossil fails in a similar way when serving a specific repository file. In 
> this
>  case, the web page presents "Not Found" or something similar.
> * fossil appears to work properly on this mountpoint when not serving; i can
> open
>  one of the repository files, edit, commit, sync back across the network, etc.
> * fossil does serve both a repo file and a directory if these files are copied
>  to a different local directory.
> 
> The filesystem mount looks like this:
> 
>  ranch2@10.1.51.120:fossils on /fossils type fuse.sshfs
>  (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
> 
> 
> So ... I'll continue by attempting the same type of thing on a different and
> more complete distribution, outside of a container, so that gdb will work if
> fossil fails there as well. But hopefully someone

Re: [fossil-users] fossil --repolist showing no repositories

[Warren Young]

On Dec 21, 2017, at 11:40 AM, dewey.hyl...@gmail.com wrote:
> 
>  ranch2@10.1.51.120:fossils on /fossils type fuse.sshfs 
> (rw,nosuid,nodev,relatime,user_id=0,group_id=0)

Running SQLite — upon which Fossil is based — over sshfs is a bad idea.  The 
current implementation doesn’t even try to implement the file locking operation:

https://github.com/libfuse/sshfs/blob/master/sshfs.c#L3304

That structure definition would have to include the “.lock” member for the sort 
of locking SQLite does for this to be safe.

See also:


https://www.sqlite.org/howtocorrupt.html#_filesystems_with_broken_or_missing_lock_implementations

There are other network file systems with locking semantics, but it’s often 
optional, and when present and enabled, it is often buggy.

Here’s hoping you have some other option.  Best would be to store the *.fossils 
inside the container.  Second best would be to map a [virtual] block device 
into the container and put a normal Linux file system on it.
___
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 --repolist showing no repositories

[dewey.hyl...@gmail.com]

Unfortunately, my first stab at this failed:

(gdb) break repo_list_page
Breakpoint 1 at 0x7ccc0: file ./src/main.c, line 1238.
(gdb) run http --repolist /fossils  On 12/20/17, dewey.hyl...@gmail.com  wrote:
>> Would someone help me understand what I'm seeing here? I expect a list of
>> repositories
>> in the web page output, but am told there are none.
> 
> I don't understand it either.
> 
> To debug, recompile Fossil with -g and -O0.  Create a HTTP request
> text file like this:
> 
>  GET / HTTP/1.0\n
>  \n
> 
> (The first line is "GET /" and the second line is blank.  The \r
> characters normally required by HTTP are optional.) Then run fossil in
> gdb.  Set a breakpoint on the routine repo_list_page and run this
> command:
> 
>run http --repolist /fossils  
> Single step through the repolist routine and try to figure out why it
> is not finding your repository files.  Please let us know what you
> discover.
> --
> 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Cross-link tech notes to commits

[jungle Boogie]

On 20 December 2017 at 13:13, jungle Boogie  wrote:
> Hi All,
>
> I know a tech note entry in the timeline can be linked to a specific commit.
> For example:
> http://fossil-scm.org/index.html/timeline?ss=m&n=200&y=e&advm=0
>
> See the top commit by AG.
>
> Can a commit message contain the [ID] of a tech note and have it linked to it?
>

At this point in reading the documentation, I don't think this is the
case. Technotes commit messages can contain the [ID] of a check-in,
though.

https://www.fossil-scm.org/index.html/doc/trunk/www/event.wiki

Is this because of this?
Because technotes are considered a special kind of wiki, users must have
permission to read wiki in order read technotes.

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] fossil --repolist showing no repositories

[Warren Young]

On Dec 20, 2017, at 10:24 PM, Andy Bradford  wrote:
> 
> Thus said Warren Young on Wed, 20 Dec 2017 21:02:01 -0700:
> 
>> Linux  containers  aren't  foolproof   when  it  comes  to  permission
>> isolation. Better  to not  let Fossil  have root  privs even  inside a
>> container.
> 
> Fossil  does chroot  first  and  then drop  root  privileges which  then
> changes to  the user that owns  the directory of fossils  (or the fossil
> repository if serving only one).

If you’re running a privileged container, all you then need is a local root 
escalation, one of which pops up roughly every year.

If you’re using an *unprivileged* container, you may be fine, though I don’t 
know if those will allow the host-side port 80 to be bound to the container.

https://linuxcontainers.org/pt_br/lxc/security/

Another thought: perhaps SELinux or AppArmor is interfering here?  Try turning 
the one your host OS runs off temporarily.  If it’s SELinux, set it to 
permissive mode and then use audit2allow to build a policy that will fix the 
problem:

https://wiki.centos.org/HowTos/SELinux
___
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 hack: quickly finding the first checkin via the web UI

[Dominique Devienne]

On Thu, Dec 21, 2017 at 11:17 AM, Stephan Beal 
wrote:

> i sometimes want to find out how old a given 3rd-party repo is, and paging
> through the timeline is a tedious way to do it. It can be done more quickly
> by drilling down through the /reports (by year, selecting the first year,
> then the first week-of-year). What i didn't know, until today, is that it's
> possible to use fossil's "rid:#" artifact ID alias with the /info page,
> e.g.:
>
> https://fossil-scm.org/fossil/info/rid:1
>
> RID #1 is always the first artifact ever stored in the fossil db, which is
> (historically, at least) the empty initial checkin. i'm not sure that that
> always applies after a rebuild/reconstruct, but it works on all the repos
> i've tried so far.
>

Nice tip.

Since I've seen DRH ask about available features on GitHub since I started
lurking on this list recently,
I'd mention the graphs the latter provide which I find useful, in the
Insights tab of a project.
The Code Frequency [1] one seems to be since inception, while the Commit
[2] one is year-to-date.
I also like the per-user "map" that shows activity of a GitHub user, across
all projects, but there's
also a per-project page with contributor graphs [3], also since inception
it seems.

I find such graphs useful myself, FWIW. --DD

[1] https://github.com/rqlite/rqlite/graphs/code-frequency
[2] https://github.com/rqlite/rqlite/graphs/commit-activity
[3] https://github.com/rqlite/rqlite/graphs/contributors
___
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 hack: quickly finding the first checkin via the web UI

[Stephan Beal]

i sometimes want to find out how old a given 3rd-party repo is, and paging
through the timeline is a tedious way to do it. It can be done more quickly
by drilling down through the /reports (by year, selecting the first year,
then the first week-of-year). What i didn't know, until today, is that it's
possible to use fossil's "rid:#" artifact ID alias with the /info page,
e.g.:

https://fossil-scm.org/fossil/info/rid:1

RID #1 is always the first artifact ever stored in the fossil db, which is
(historically, at least) the empty initial checkin. i'm not sure that that
always applies after a rebuild/reconstruct, but it works on all the repos
i've tried so far.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users