[fossil-users] commit signing
Hello, I've converted (mostly from Git, but as well as from darcs btr) *all* my repost to Fossil in order to exclusively use it and test it thoroughly. Now I experience some (strange) problem that I can't see GPG signatures in my commits. During commit I see the following: You need a passphrase to unlock the secret key for user: Gour-Gadadhara Dasa g...@atmarama.net 4096-bit RSA key, ID 52B5C810, created 2011-04-02 New_Version: da8de0a52e73efdb545cd5020d17182e2e657c6d but when I look in the timeline, I cannot see whether the commit is signed or not? Has something changed in Fossil in regard? Here is the snippet from my settings: clearsign(local) 1 case-sensitive clean-glob crnl-glob default-perms diff-binary diff-command dont-push editor (local) vim empty-dirs encoding-glob gdiff-command gmerge-command (local) meld http-port https-login ignore-glob keep-glob localauth(local) 0 main-branch manifest max-upload mtime-changes pgp-command (local) gpg --clearsign -o When I use: 'gpg clearsign -o' with some test document, it is normally signed without asking for passphrase since gpg-agent is active (via keychain) and required key is set as default. Any hint? Sincerely, Gour -- But for one who takes pleasure in the self, whose human life is one of self-realization, and who is satisfied in the self only, fully satiated — for him there is no duty. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] commit signing
On Tue, Aug 20, 2013 at 7:42 AM, Gour g...@atmarama.net wrote: Hello, I've converted (mostly from Git, but as well as from darcs btr) *all* my repost to Fossil in order to exclusively use it and test it thoroughly. Now I experience some (strange) problem that I can't see GPG signatures in my commits. During commit I see the following: You need a passphrase to unlock the secret key for user: Gour-Gadadhara Dasa g...@atmarama.net 4096-bit RSA key, ID 52B5C810, created 2011-04-02 New_Version: da8de0a52e73efdb545cd5020d17182e2e657c6d but when I look in the timeline, I cannot see whether the commit is signed or not? Has something changed in Fossil in regard? The PGP signature is recorded in the repository. (See, for example the PGP signature on an early check-in to Fossil itself at http://www.fossil-scm.org/fossil/artifact/22c1ac41d4c02c44). However, I have never added any logic in the timeline display to actually show the signature. The need to do this has never arisen in 6+ years. What kind of timeline display are you looking for? Here is the snippet from my settings: clearsign(local) 1 case-sensitive clean-glob crnl-glob default-perms diff-binary diff-command dont-push editor (local) vim empty-dirs encoding-glob gdiff-command gmerge-command (local) meld http-port https-login ignore-glob keep-glob localauth(local) 0 main-branch manifest max-upload mtime-changes pgp-command (local) gpg --clearsign -o When I use: 'gpg clearsign -o' with some test document, it is normally signed without asking for passphrase since gpg-agent is active (via keychain) and required key is set as default. Any hint? Sincerely, Gour -- But for one who takes pleasure in the self, whose human life is one of self-realization, and who is satisfied in the self only, fully satiated — for him there is no duty. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] commit signing
On Tue, 20 Aug 2013 07:47:42 -0400 Richard Hipp d...@sqlite.org wrote: The PGP signature is recorded in the repository. (See, for example the PGP signature on an early check-in to Fossil itself at http://www.fossil-scm.org/fossil/artifact/22c1ac41d4c02c44). OK. However, I have never added any logic in the timeline display to actually show the signature. The need to do this has never arisen in 6+ years. What kind of timeline display are you looking for? Well, the example above is OK, but I wonder is there any ling in the timeline which leads to it or one has to manually enter http://path/artifact/id ? Iow, I'd like an easy way to check whether the commit is signed or not, possibly close to the 'SHA1 Hash:' label or something. I'm also pretty sure that something like that was available or am I dreaming... Sincerely, Gour -- A self-realized man has no purpose to fulfill in the discharge of his prescribed duties, nor has he any reason not to perform such work. Nor has he any need to depend on any other living being. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] commit signing
On Tue, Aug 20, 2013 at 8:05 AM, Gour g...@atmarama.net wrote: Iow, I'd like an easy way to check whether the commit is signed or not, possibly close to the 'SHA1 Hash:' label or something. I'm also pretty sure that something like that was available or am I dreaming... I think you dreamed it. I don't recall ever having added anything like that in Fossil. -- 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] commit signing
On Tue, Aug 20, 2013 at 2:05 PM, Gour g...@atmarama.net wrote: Iow, I'd like an easy way to check whether the commit is signed or not, possibly close to the 'SHA1 Hash:' label or something. i recently some samething similar in the JimTCL timeline, where each commit has a signed off by..., but i don't know if that was done via PGP-sig post-processing or if they commits were manually marked. This is extremely unofficial for the time being, and this isn't the solution you're looking for but you could do: stephan@tiny:~/cvs/fossil/fossil$ ../f2/f-acat 22c1ac41d4c02c44 | head -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C Add\sseparate\sclone\spermissions.\s\sPreviously,\sone\sneeded\sHistory\npremission\sin\sorder\sto\sclone.\s\sBut\ssometimes\swe\swant\sto\sgrant\sclone\nwithout\sgranting\shistory. D 2007-08-23T19:52:19 F BUILD.txt e7fed9d5b647337f8e7abf45981d10cdcc1555e2 ... http://fossil.wanderinghorse.net/repos/f2/index.cgi/wiki?name=f-tools i've just written down a TODO to add this info to the timeline if it's not terribly problematic. The main problem is that the timeline doesn't have that level of data. Ah, but it could - we could still see the PGP key in the crosslink phase, i think, and that's where the timeline is updated, anyway. Written down on my TODO list. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] commit signing
On Tue, Aug 20, 2013 at 2:11 PM, Stephan Beal sgb...@googlemail.com wrote: i've just written down a TODO to add this info to the timeline if it's not terribly problematic. The main problem is that the timeline doesn't have that level of data. Ah, but it could - we could still see the PGP key in the crosslink phase, i think, and that's where the timeline is updated, anyway. Written down on my TODO list. i love low-hanging fruit... http://fossil-scm.org/index.html/timeline?r=timeline-pgp-marker i'm not entirely satisfied with this solution, so i've put it into a branch and am hoping someone has a prettier/better suggestion. What i've done is during manifest parsing, set a flag if we see a PGP key, and add (*PGP SIGNED*) to the event.comment (not ecomment) if that flag is set. e.g. [507ee45f25] http://localhost:8080/info/507ee45f25 Fix an off-by-one bug in the network protocol handler so that it can accept a zero-length file. (*PGP SIGNED*) (user: drhhttp://localhost:8080/timeline?u=drhc=2007-08-25+12%3A31%3A55nd, tags: trunkhttp://localhost:8080/timeline?r=trunkndc=2007-08-25+12%3A31%3A55 )04:02 [9b30224db7] http://localhost:8080/info/9b30224db7 Closed-Leaf: Merging formatting changes to timeline and concepts documentation (*PGP SIGNED*) (user: akuhttp://localhost:8080/timeline?u=akuc=2007-08-25+04%3A02%3A27nd, tags: trunkhttp://localhost:8080/timeline?r=trunkndc=2007-08-25+04%3A02%3A27 ) That didn't paste so well, but you get the idea. Caveat: this marker only applies to new commits or after a rebuild (then it's retroactive). Can you please try that out, Gour? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] commit signing
On Tue, 20 Aug 2013 14:58:49 +0200 Stephan Beal sgb...@googlemail.com wrote: Can you please try that out, Gour? Here is output from configure: gour@atmarama ~/t/fossil ./configure Host System...x86_64-unknown-linux-gnu Build System...x86_64-unknown-linux-gnu C compiler... cc -g -O2 C++ compiler... c++ -g -O2 Build C compiler...cc Checking for stdlib.h...ok Checking for uint32_t...ok Checking for uint16_t...ok Checking for int16_t...ok Checking for uint8_t...ok Checking for pread...ok Checking for tclsh...ok Checking for zlib.h...ok Checking libs for inflateEnd...-lz Checking for ssl via pkg-config...ok HTTPS support enabled Checking for readline/readline.h...not found Checking for editline/readline.h...not found Checking libs for gethostbyname...none needed Checking libs for socket...none needed Checking libs for iconv...none needed Checking for getpassphrase...not found Checking libs for getpass...none needed Checking libs for dlopen...-ldl Created Makefile from Makefile.in Created autoconfig.h From where it should find it? It looks it does not work without it? Sincerely, Gour -- The work of a man who is unattached to the modes of material nature and who is fully situated in transcendental knowledge merges entirely into transcendence. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] commit signing
On Tue, Aug 20, 2013 at 3:23 PM, Gour g...@atmarama.net wrote: On Tue, 20 Aug 2013 14:58:49 +0200 Stephan Beal sgb...@googlemail.com wrote: Can you please try that out, Gour? Here is output from configure: Do: fossil co timeline-pgp-marker ./configure make clean make ./fossil rebuild ./fossil ui and then you'll see the signed entries in the timeline. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] commit signing
On Tue, Aug 20, 2013 at 9:23 AM, Gour g...@atmarama.net wrote: On Tue, 20 Aug 2013 14:58:49 +0200 Stephan Beal sgb...@googlemail.com wrote: Can you please try that out, Gour? Here is output from configure: gour@atmarama ~/t/fossil ./configure Try instead: ./configure --disable-lineedit Host System...x86_64-unknown-linux-gnu Build System...x86_64-unknown-linux-gnu C compiler... cc -g -O2 C++ compiler... c++ -g -O2 Build C compiler...cc Checking for stdlib.h...ok Checking for uint32_t...ok Checking for uint16_t...ok Checking for int16_t...ok Checking for uint8_t...ok Checking for pread...ok Checking for tclsh...ok Checking for zlib.h...ok Checking libs for inflateEnd...-lz Checking for ssl via pkg-config...ok HTTPS support enabled Checking for readline/readline.h...not found Checking for editline/readline.h...not found Checking libs for gethostbyname...none needed Checking libs for socket...none needed Checking libs for iconv...none needed Checking for getpassphrase...not found Checking libs for getpass...none needed Checking libs for dlopen...-ldl Created Makefile from Makefile.in Created autoconfig.h From where it should find it? It looks it does not work without it? Sincerely, Gour -- The work of a man who is unattached to the modes of material nature and who is fully situated in transcendental knowledge merges entirely into transcendence. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] commit signing
On Tue, 20 Aug 2013 14:58:49 +0200 Stephan Beal sgb...@googlemail.com wrote: Can you please try that out, Gour? My mistake...I mixed fossil versions for commit and ui. It's OK, and it would be superb to e.g. have *PGP SIGNED* as hyperlink to the artifact? Sincerely, Gour -- Not by merely abstaining from work can one achieve freedom from reaction, nor by renunciation alone can one attain perfection. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] commit signing
On Tue, Aug 20, 2013 at 3:34 PM, Gour g...@atmarama.net wrote: It's OK, and it would be superb to e.g. have *PGP SIGNED* as hyperlink to the artifact? To the raw manifest, you mean? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] commit signing
On Tue, 20 Aug 2013 15:42:19 +0200 Stephan Beal sgb...@googlemail.com wrote: To the raw manifest, you mean? Yes, to the one e.g. showed by Richard: http://www.fossil-scm.org/fossil/artifact/22c1ac41d4c02c44 Sincerely, Gour -- One who is not disturbed in mind even amidst the threefold miseries or elated when there is happiness, and who is free from attachment, fear and anger, is called a sage of steady mind. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] commit signing
On Tue, Aug 20, 2013 at 4:02 PM, Gour g...@atmarama.net wrote: On Tue, 20 Aug 2013 15:42:19 +0200 Stephan Beal sgb...@googlemail.com wrote: To the raw manifest, you mean? Yes, to the one e.g. showed by Richard: http://www.fossil-scm.org/fossil/artifact/22c1ac41d4c02c44 Please do an update, 'make', fossil rebuild, and try again. i'm not terribly happy with how the link looks, but that seems to be the way those links are supposed to be displayed in the timeline. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] window opened by `diff --tk' is editable
not a big deal but slightly irritating: the tk-window opened by `diff --tk' is editable, i..e one can modify the displayed diff text (w/o any real effect, of course). I don't know Tk, but maybe there's an option to make the window readonly in order to avoid any potential confusion (since many graphical diff/merge tools _do_ allow to edit such diffs)? I don't presume this info is relevant here, but it happens on a current mac with fossil 1.26 j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] window opened by `diff --tk' is editable
On Tue, Aug 20, 2013 at 10:57 AM, j. van den hoff veedeeh...@googlemail.com wrote: not a big deal but slightly irritating: the tk-window opened by `diff --tk' is editable, i..e one can modify the displayed diff text (w/o any real effect, of course). I don't know Tk, but maybe there's an option to make the window readonly in order to avoid any potential confusion (since many graphical diff/merge tools _do_ allow to edit such diffs)? I don't presume this info is relevant here, but it happens on a current mac with fossil 1.26 I just tried it here and couldn't get it to edit. Maybe this has already been fixed? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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 running out of memory
On Mon, Aug 5, 2013 at 10:15 PM, Richard Hipp d...@sqlite.org wrote: On Mon, Aug 5, 2013 at 3:55 PM, Benedikt Ahrens benedikt.ahr...@gmx.netwrote: is not feasible in my situation. packages or libraries or deal with package managers. Just copy *one file* into your $PATH on each machine where it matters. @Benedikt: the easiest thing to do is to edit your $PATH to include $HOME/bin and drop fossil in $HOME/bin. If you need help with setting the PATH, google for ubuntu edit path (bzw. ubuntu path bearbeiten) and several useful answers are there. Thanks. However, my objection to upgrading to newer fossil was not motivated by a lack of know-how, but rather by the fact that this solution comes with a complexity of O(number of affected machines). Also, not all of the affected machines are mine. My question was intended to be Can I do something to the repository---and not to fossil---in order to get things working again, with version 1.22? We don't know, and that version is old enough for us to justify suggesting you try a newer version before we pursue it further. It works fine with 1.26. BTW, is there any chance the Debian packaging could happen in a debian branch of the fossil development repository, i.e. that the Debian fossil maintainer get write access to that repo? Thanks for your help and patience. Benedikt [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718812 ___ 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 running out of memory
On Tue, Aug 20, 2013 at 5:56 PM, Benedikt Ahrens benedikt.ahr...@gmx.netwrote: It works fine with 1.26. :) BTW, is there any chance the Debian packaging could happen in a debian branch of the fossil development repository, i.e. that the Debian fossil maintainer get write access to that repo? @that maintainer: if you're reading this, please speak up :). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] getting fossil timeline to show time offsets
Hello, the fossil timeline command shows UTC time rather than observing the system setting (UTC+02:00, in my case). Is there anything I can do to change this? fossil version is 1.26. Thanks. Benedikt ___ 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] commit signing
On Tue, 20 Aug 2013 16:10:05 +0200 Stephan Beal sgb...@googlemail.com wrote: Please do an update, 'make', fossil rebuild, and try again. i'm not terribly happy with how the link looks, but that seems to be the way those links are supposed to be displayed in the timeline. Yeah, functionality is there, some cosmetic is required...link can point to http://some-domain/artifact/id, but the link title can be e.g. just *PGP-SIGNED* ? Thanks a lot for working on it... Sincerely, Gour -- One who works in devotion, who is a pure soul, and who controls his mind and senses is dear to everyone, and everyone is dear to him. Though always working, such a man is never entangled. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] window opened by `diff --tk' is editable
On Tue, 20 Aug 2013 17:31:24 +0200, Richard Hipp d...@sqlite.org wrote: On Tue, Aug 20, 2013 at 10:57 AM, j. van den hoff veedeeh...@googlemail.com wrote: not a big deal but slightly irritating: the tk-window opened by `diff --tk' is editable, i..e one can modify the displayed diff text (w/o any real effect, of course). I don't know Tk, but maybe there's an option to make the window readonly in order to avoid any potential confusion (since many graphical diff/merge tools _do_ allow to edit such diffs)? I don't presume this info is relevant here, but it happens on a current mac with fossil 1.26 I just tried it here and couldn't get it to edit. Maybe this has already been fixed? you are right. it happenend with fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC but current leaf revision produces a quite differently looking Tk window not exhibiting the reported problem anymore. indeed, things are moving fast with fossil ;-) however, regarding the _new_ Tk window (as of fossil version 1.26 [13161f39aa] 2013-08-20 11:29:01 UTC) I see the following issues: compared to the old one, font size now is at the limit of comfortable readability, i.e. is too small (I could send you a screen shot offline, if you are interested...) and the new central Files drop-down menu (I presume that's what it should be?) is broken does in fact _not_ drop down but opens a new small Tk window about the size of the menu button itself, containing the file name and three inactive close/minimize/maximize buttons. it disappears when clicking somewhere else in the first Tk window but not when releasing/clicking the menu button. so apart from the spurious edit feature I find the alt variant more usable (the font issue alone leads to this) and also cleaner (the black horizontal and vertical bars are distracting in my view and the bare bones `sdiff' look of the old variant was more in accord with my taste). j. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] getting fossil timeline to show time offsets
On Tue, 20 Aug 2013 17:59:11 +0200, Benedikt Ahrens benedikt.ahr...@gmx.net wrote: Hello, the fossil timeline command shows UTC time rather than observing the system setting (UTC+02:00, in my case). Is there anything I can do to change this? you can switch off UTC (so that it uses local time) in the web interface (admin - timeline). don't know whether there is a command line way to do this. j. fossil version is 1.26. Thanks. Benedikt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] window opened by `diff --tk' is editable
On Tue, Aug 20, 2013 at 6:22 PM, j. van den hoff veedeeh...@googlemail.comwrote: indeed, things are moving fast with fossil ;-) This year is turning out to be one of the busier ones: http://fossil-scm.org/index.html/reports?view=byyear and recent activity has been pretty high: http://fossil-scm.org/index.html/reports?view=byweek however, regarding the _new_ Tk window (as of fossil version 1.26 [13161f39aa] 2013-08-20 11:29:01 UTC) I see the following issues: LOL! i'll stay out of this one, except to say that i would like to see a commit button directly in the tk diff. And a way to map that to the gdiff-command, so that (f gdiff) becomes (f diff --tk). But this netbook is too slow for further hacking on fossil tonight... -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] getting fossil timeline to show time offsets
On Tue, Aug 20, 2013 at 6:25 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Tue, 20 Aug 2013 17:59:11 +0200, Benedikt Ahrens benedikt.ahr...@gmx.net wrote: Hello, the fossil timeline command shows UTC time rather than observing the system setting (UTC+02:00, in my case). Is there anything I can do to change this? you can switch off UTC (so that it uses local time) in the web interface (admin - timeline). don't know whether there is a command line way to do this. in parallel i've been looking for one and haven't found it. i assume there isn't one. TODO += add 'localtime' config setting (boolean) IIRC the internal infrastructure is there, it just seems to be missing from the CLI settings comment (?). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] commit signing
On Tue, Aug 20, 2013 at 6:19 PM, Gour g...@atmarama.net wrote: Yeah, functionality is there, some cosmetic is required...link can point to http://some-domain/artifact/id, but the link title can be e.g. just *PGP-SIGNED* ? i don't see a way to do that without hard-coding the link into the comment (which would go against the patterns in similar places in the code). That link-generation a side-effect of a downstream step where the wiki links are produced. Thanks a lot for working on it... My pleasure. By coincidence i recently worked near the PGP-related code (all 8 or 10 lines of it) so knew what needed to be done there. However... i don't want to move this to the trunk until i hear some feedback from the devs whether this is the optimal solution or whether something like a simple PGP would do. i tried to make it stand out, but i'm not sure that's necessary. @others: feel free to patch it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] commit signing
I need to go back in the archives and see where I can find an example of this but in the meantime to ask the obvious, is fossil verifying the signatures as part of the commit process or does fossil simply carry the data so the signature can be verified manually? On Tue, Aug 20, 2013 at 08:00:41PM +0200, Gour wrote: On Tue, 20 Aug 2013 18:41:39 +0200 Stephan Beal sgb...@googlemail.com wrote: However... i don't want to move this to the trunk until i hear some feedback from the devs whether this is the optimal solution or whether something like a simple PGP would do. Sure, let's hear what others can say... Sincerely, Gour -- As a strong wind sweeps away a boat on the water, even one of the roaming senses on which the mind focuses can carry away a man's intelligence. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 ___ 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] commit signing
On Tue, 20 Aug 2013 18:41:39 +0200 Stephan Beal sgb...@googlemail.com wrote: However... i don't want to move this to the trunk until i hear some feedback from the devs whether this is the optimal solution or whether something like a simple PGP would do. Sure, let's hear what others can say... Sincerely, Gour -- As a strong wind sweeps away a boat on the water, even one of the roaming senses on which the mind focuses can carry away a man's intelligence. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] commit signing
On Tue, Aug 20, 2013 at 8:07 PM, John Long codeb...@inbox.lv wrote: I need to go back in the archives and see where I can find an example of this but in the meantime to ask the obvious, is fossil verifying the signatures as part of the commit process or does fossil simply carry the data so the signature can be verified manually? It simply carries them over and accounts for them while parsing manifests. If there is code to verify them, i haven't seen it yet. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] commit signing
On Tue, Aug 20, 2013 at 2:32 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Aug 20, 2013 at 8:07 PM, John Long codeb...@inbox.lv wrote: is fossil verifying the signatures as part of the commit process or does fossil simply carry the data so the signature can be verified manually? It simply carries them over and accounts for them while parsing manifests. If there is code to verify them, i haven't seen it yet. I don't remember ever writing any PGP signature verification code. -- 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] commit signing
On Tue, Aug 20, 2013 at 08:32:21PM +0200, Stephan Beal wrote: On Tue, Aug 20, 2013 at 8:07 PM, John Long codeb...@inbox.lv wrote: I need to go back in the archives and see where I can find an example of this but in the meantime to ask the obvious, is fossil verifying the signatures as part of the commit process or does fossil simply carry the data so the signature can be verified manually? It simply carries them over and accounts for them while parsing manifests. If there is code to verify them, i haven't seen it yet. If you're working on flagging PGP commits then it would be really nice to say PGP in red if the signature doesn't verify or green if it does or something like that. Otherwise saying PGP on a commit does more harm than good imho. Personally for hosted projects I'd like to see a feature that has an option to verify the signature on commits before committing them as a protection against unauthorized access to the repo (weak passwords, http instead of https etc.) /jl ___ 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] commit signing
On Tue, Aug 20, 2013 at 8:39 PM, John Long codeb...@inbox.lv wrote: If you're working on flagging PGP commits then it would be really nice to say PGP in red if the signature doesn't verify or green if it does or something like that. Otherwise saying PGP on a commit does more harm than good imho. Personally for hosted projects I'd like to see a feature that has an option to verify the signature on commits before committing them as a protection against unauthorized access to the repo (weak passwords, http instead of https etc.) Yeah, i left the word signed in the hopes that it didn't apply approved. Patches are of course welcomed for validation, provided they don't require 3rd-party deps (extern deps mean the feature must be optional, e.g. SSL). What should happen if a sign check fails? e.g. on a rebuild of a db (PGP is seen at checkin or on rebuild)? Should it then reject the whole db? i don't think we have a recovery strategy if they fail. The best we could do is flag them in the timeline as passed/failed/unchecked, i think. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] commit signing
On Tue, Aug 20, 2013 at 08:43:36PM +0200, Stephan Beal wrote: On Tue, Aug 20, 2013 at 8:39 PM, John Long codeb...@inbox.lv wrote: If you're working on flagging PGP commits then it would be really nice to say PGP in red if the signature doesn't verify or green if it does or something like that. Otherwise saying PGP on a commit does more harm than good imho. Personally for hosted projects I'd like to see a feature that has an option to verify the signature on commits before committing them as a protection against unauthorized access to the repo (weak passwords, http instead of https etc.) Yeah, i left the word signed in the hopes that it didn't apply approved. Patches are of course welcomed for validation, provided they don't require 3rd-party deps (extern deps mean the feature must be optional, e.g. SSL). I don't code in C, not even with a gun held to my head or I would be glad to try to help. fossil is a fantastic project. I believe there is a library put out by the gnupg project that is used specifically for stuff like email clients to interface to gpg (the open source version of PGP) that should have a very simple interface. I think it is called gpgme (gpg made easy) IIRC. I think it's not something you have to link and you should be able to tell if it's present or not. If a commit is signed and can't be verified, it could be highlited in PGP yellow. Green verified, red doesn't verify. That would be amazing. What should happen if a sign check fails? e.g. on a rebuild of a db (PGP is seen at checkin or on rebuild)? I haven't used gpg/pgp with fossil but I use gpg a lot. Thinking out loud one workflow would be something like: get a commit ready and sign each piece of code/whatever push or commit fossil sees the signature field (easily detected by standard header): -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Stephen Beal! -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJSE7rJAAoJEPh15eraZbwERKIIAMG6gup+QX0s5of4ovxqjuQA IME1rUexfBxVbi5CQGLuk/SvZYotPzbVPcWBsCVS9FW4kaP/19zP1Wpgm+SGU88/ +yOHrn7QBXNeti7lmyhFFCOoV4PqpNhlklTqASz1Ga9pm4ZhjJ1YYUfPXV0V2LDM 0VugnJCYq/QDLXZXI0z9F2/FULjgv7OfUN0dCsjwRwyzBip1tOoWIseG13en1uLm exm8RLUNbzjE7LcYV/jUwrOzCmnFjIqSb3l6CfhPuBeLonKzO0W+jVy/QHKxY2bE hS4dMu3vM6Op7cOfiB4bdT1jMWyIntyOBvZK0+18jRmfKRHJaSzNeSd5noZrCUI= =xA6W -END PGP SIGNATURE- verifies it and commits or fails it and doesn't commit. There are two kinds of signatures, clearsigned like above or detached (separate file). To process a clearsigned object you strip the headers. Otherwise you validate each file in the commit against filename.asc. That would make things a lot simpler because once the commit hits the repo it is a known-good commit. If it gets corrupted it's the same big problem as any corrupted commit. But this is on a single-file level. I do not know how you can sign commits that contain more than one file. Should it then reject the whole db? i don't think we have a recovery strategy if they fail. The best we could do is flag them in the timeline as passed/failed/unchecked, i think. My understanding is you already compute checksums on commits. If that's true I would say if you verify any signed commit (and again it's not clear how multiple files are handled unless every file is signed individually) then you should not have to do anything further, maybe not even note that it's PGP signed. The PGP signing is about authenticating that some user X is really the guy who did this update. Once that has been established it goes into the repo and nothing more has to happen. /jl ___ 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] commit signing
On Tue, Aug 20, 2013 at 9:03 PM, John Long codeb...@inbox.lv wrote: is called gpgme (gpg made easy) IIRC. I think it's not something you have to link and you should be able to tell if it's present or not. i can't personally commit to it, but maybe someone who's listening can. My understanding is you already compute checksums on commits. At a lot of places. Blob content is referenced by its content SHA1, so any change there invalidates it. A commit contains two checksums: one is the checksum of the content of the checkin manifest (basically: the formal list of changes, but not the changes themselves, similar to a PGP signature). The second one is a checksum of the names/sizes/content of each file in the commit manifest (basically: each file that changed). Fossil ignores/skips over/elides the PGP wrapper for purposes of checksums. Fossil only does PGP plaintext signing, btw, unless i'm sorely mistaken. If that's true I would say if you verify any signed commit (and again it's not clear how multiple files are handled unless every file is signed individually) The signing happens at the commit level, and a commit contains N files. then you should not have to do anything further, maybe not even note that it's PGP signed. The PGP signing is about authenticating that some user X is really the guy who did this update. Once that has been established it goes into the repo and nothing more has to happen. There's the problem for the current architecture: when it goes in the repo. Let's say for a second that one of the signed commits in Fossil's repo is currently invalid. Now we add this feature. The next time fossil is rebuilt, it would have to reject that commit, which would break the whole rebuild, effectively leaving us with a repo we can't upgrade because PGP decided we shouldn't. Fossil has no useful recovery strategy there other than to not let you rebuild the db (==update its schema to a newer version, which also rebuilds all derivable/calculable data contained in the repo). i think flag and accept would be the best Fossil could sanely do. What i can envision is, assuming validation has hypothetically been added: a) show yellow/green/red in the timeline, and something similar in CLI b) a 'pgp' command which takes a list of UUIDs to verify. But i don't think Fossil is capable of rejecting failures without seriously endangering backwards compatibility in the case of an age-old signature (==predating this feature) which is invalid. Maybe it could, or maybe it could offer an option/flag to allow failed sigs or not. i'm not in any way, shape, or form a cryptographer, i'm just thinking out loud here :/. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] non-cgi path for CGI-based Fossil hosting
Given a shared hosting account where you want to host a Fossil repository, where following the directions for CGI-based Fossil hosting gives you access to the web UI via example.com/cgi-bin/access_name, I would like to know what techniques people use to make it available via something like one of the following: * example.com * example.com/access_name * access_name.example.com Obviously, in the cgi-bin/access_name example, script that refers to the fossil binary would be called access_name. Any help would be appreciated. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] non-cgi path for CGI-based Fossil hosting
On Tue, Aug 20, 2013 at 10:10 PM, Chad Perrin c...@apotheon.net wrote: Given a shared hosting account where you want to host a Fossil repository, where following the directions for CGI-based Fossil hosting gives you access to the web UI via example.com/cgi-bin/access_name, I would like to know what techniques people use to make it available via something like one of the following: * example.com * example.com/access_name * access_name.example.com # cat .htaccess Options +ExecCGI +Indexes IfModule mod_autoindex.c IndexOptions FancyIndexing NameWidth=* /ifModule # doesn't work on my hoster :( AddHandler cgi-script .html DirectoryIndex index.cgi index.php index.html Hope that helps, -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] non-cgi path for CGI-based Fossil hosting
On Tue, Aug 20, 2013 at 10:25 PM, Stephan Beal sgb...@googlemail.comwrote: # cat .htaccess Options +ExecCGI +Indexes IfModule mod_autoindex.c IndexOptions FancyIndexing NameWidth=* /ifModule # doesn't work on my hoster :( AddHandler cgi-script .html DirectoryIndex index.cgi index.php index.html And... # cat index.cgi #!/path/to/fossil repository: /path/to/f2.fsl i keep all of my repos in a directory under my home, outside the webroot so they cannot be browsed (.htaccess rules could do that, but why bother?). On my hoster CGIs run as me, so i have that freedom. i don't know that all shared hosters run CGIs as the account holder (but suspect that most do). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] window opened by `diff --tk' is editable
Hi j., I'm responsible for the new and improved Tk diff and would like to look into these problems. Send any screenshots and/or hate mail my way. I'd also like to know what OS and Tcl/Tk version you're using. j. van den hoff wrote: however, regarding the _new_ Tk window (as of fossil version 1.26 [13161f39aa] 2013-08-20 11:29:01 UTC) I see the following issues: compared to the old one, font size now is at the limit of comfortable readability, i.e. is too small (I could send you a screen shot offline, if you are interested...) and the new central Files drop-down menu (I presume that's what it should be?) is broken does in fact _not_ drop down but opens a new small Tk window about the size of the menu button itself, containing the file name and three inactive close/minimize/maximize buttons. it disappears when clicking somewhere else in the first Tk window but not when releasing/clicking the menu button. Yeah, the Files drop-down is a hack to work around problems with the standard Tk menu widget when you have a diff with many files. It should pop up a listbox just below the menu button that will allow you to select the file you want to jump to. It shouldn't be showing the window decoration/buttons, though. so apart from the spurious edit feature I find the alt variant more usable (the font issue alone leads to this) and also cleaner (the black horizontal and vertical bars are distracting in my view and the bare bones `sdiff' look of the old variant was more in accord with my taste). I'm not married to any of the styling. If Richard or somebody else wants to change it to whatever other people prefer, be my guest. ___ 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] non-cgi path for CGI-based Fossil hosting
On Tue, Aug 20, 2013 at 10:25:05PM +0200, Stephan Beal wrote: On Tue, Aug 20, 2013 at 10:10 PM, Chad Perrin c...@apotheon.net wrote: Given a shared hosting account where you want to host a Fossil repository, where following the directions for CGI-based Fossil hosting gives you access to the web UI via example.com/cgi-bin/access_name, I would like to know what techniques people use to make it available via something like one of the following: * example.com * example.com/access_name * access_name.example.com # cat .htaccess Options +ExecCGI +Indexes IfModule mod_autoindex.c IndexOptions FancyIndexing NameWidth=* /ifModule # doesn't work on my hoster :( AddHandler cgi-script .html DirectoryIndex index.cgi index.php index.html Hope that helps, It does. Thank you. I didn't end up using +Indexes or the IndexOptions, however. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] commits from host A sometimes not seen on B
Hey Richard, I get the same problem every once in awhile. Many times actually. I consider myself a heavy fossil user. My most active repository has 1087 checkins all made by me. I once submitted a ticket about it here: http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext I have not noticed a pattern with the syncing problems. Going by feel, it feels like it occurs most frequently when I create a new branch, or if I edit a check-in comment. Also keep in mind that I rarely if ever have had sync errors. After every commit I would look at the remote repository to see if all the changes synced and they always do, except for these few cases. Also note that I always have auto-sync turned on. I used to host my repositories on a Linux VPS. I have since moved to Chisel and still have encountered sync problems. One time when the problem occured on my Linux VPS, I solved the problem by rebuilding the repository on the VPS side (the host repository). I dug around the source code of Fossil briefly to try and figure out the problem, and while I did not pinpoint it, I believed at the time that the issue had to do with the usage of clustered and unclustered artifacts. If I understand correctly, the used of these clusters is for a syncing optimization. However once I saw that you committed the --verily option, I stopped pursuing the problem because I was fairly confident that --verily solves the issue. Since my repository is hosted on Chisel, I will not find out until the next version is released and Chisel updates to that version. Also note that in ALL cases, the syncing problem can be solved by recloning the host repository. But I would prefer not to do that every time. I only used the fossil rebuild solution one time so I can't confidently say that it fixed the problem. And since I can't rebuild repositories on Chisel I can't try it with my current syncing problem. The problems have occured with and without HTTPS. So right now I actually have the syncing problem again. I created a new branch where I committed the entire source code to FreeType. This was done in a Linux VM. I then went to my Windows 8 desktop to update (keep in mind I have autosync always on) and it failed to pull the new branch; it's missing entirely from the timeline. It's also missing from my Macbook as well. So Mr. Hipp if you're interested, I can send you a copies of my repository to analyze and debug. However I would also need to get the current maintainer of Chisel to email me an untouched copy of my repository as it exists on that site right now. Does anyone have contact info for Chisel? The site still has James Turner's name on it. I would very much like for this bug to be fixed. Though --verily looks promising. Donny Ward ___ 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] commits from host A sometimes not seen on B
On Aug 20, 2013 8:25 PM, Donny Ward donnyjw...@gmail.com wrote: Hey Richard, I get the same problem every once in awhile. Many times actually. I consider myself a heavy fossil user. My most active repository has 1087 checkins all made by me. I once submitted a ticket about it here: http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext I have not noticed a pattern with the syncing problems. Going by feel, it feels like it occurs most frequently when I create a new branch, or if I edit a check-in comment. Also keep in mind that I rarely if ever have had sync errors. After every commit I would look at the remote repository to see if all the changes synced and they always do, except for these few cases. Also note that I always have auto-sync turned on. I used to host my repositories on a Linux VPS. I have since moved to Chisel and still have encountered sync problems. One time when the problem occured on my Linux VPS, I solved the problem by rebuilding the repository on the VPS side (the host repository). I dug around the source code of Fossil briefly to try and figure out the problem, and while I did not pinpoint it, I believed at the time that the issue had to do with the usage of clustered and unclustered artifacts. If I understand correctly, the used of these clusters is for a syncing optimization. However once I saw that you committed the --verily option, I stopped pursuing the problem because I was fairly confident that --verily solves the issue. Since my repository is hosted on Chisel, I will not find out until the next version is released and Chisel updates to that version. Also note that in ALL cases, the syncing problem can be solved by recloning the host repository. But I would prefer not to do that every time. I only used the fossil rebuild solution one time so I can't confidently say that it fixed the problem. And since I can't rebuild repositories on Chisel I can't try it with my current syncing problem. The problems have occured with and without HTTPS. So right now I actually have the syncing problem again. I created a new branch where I committed the entire source code to FreeType. This was done in a Linux VM. I then went to my Windows 8 desktop to update (keep in mind I have autosync always on) and it failed to pull the new branch; it's missing entirely from the timeline. It's also missing from my Macbook as well. So Mr. Hipp if you're interested, I can send you a copies of my repository to analyze and debug. However I would also need to get the current maintainer of Chisel to email me an untouched copy of my repository as it exists on that site right now. Does anyone have contact info for Chisel? The site still has James Turner's name on it. I think Andreas Kupries is the gentleman you want: andre...@activestate.com I would very much like for this bug to be fixed. Though --verily looks promising. Donny Ward ___ 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
