Re: [fossil-users] Ticket 305143bd876f693f446f78d12dbef143c46eec58
On Wed, Mar 16, 2011 at 1:04 AM, Michael Richter wrote: > The > ticket http://fossil-scm.org/index.html/tktview/305143bd876f693f446f78d12dbef143c46eec58 is > moving into "show-stopper" territory for me. I'm trying to share a > repository's code through fossil to fossil non-users. The inability to log > in in the timeline views means no ability to bundle up ZIP/TAR files. > Could someone look into this and let me know either what the problem is or > what stupid thing I'm doing? > Does it happens when login as anonymous ? Since a lot of people use anonymous and nobody complain about something like this, it might be related with your user configurations ? -- Martin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Verifying releases with GPG?
First of all, I just wanted to say that I was thrilled to learn that Fossil has learned a git import/export mechanism. I tried Fossil a while back, but the inability to export data from fossil without diving into internals kept me from spending more time with it. I'm glad that's been addressed in recent releases. Unfortunately, the version of Fossil shipped with Ubuntu 10.10 doesn't have this support. I considered grabbing a more recent version directly from the website, but when looking at the downloads page, there didn't seem to be any way at all to verify the integrity of the binaries. I realize that a GPG signature or md5sum is only as reliable as the trust path to its source, but I'd still feel better if the downloads were signed and an md5sum or sha1sum easily accessible for comparison. Any chance of the maintainers signing the downloads and providing an out-of-band public key fingerprint--say, by posting the fingerprint to the mailing list? If I've simply missed the authentication information on the website, please point me in the right direction. Otherwise, I hope the maintainers will give some serious thought to making verification easier. ___ 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] Ticket 305143bd876f693f446f78d12dbef143c46eec58
On Wed, Mar 16, 2011 at 1:04 AM, Michael Richter wrote: > The ticket > http://fossil-scm.org/index.html/tktview/305143bd876f693f446f78d12dbef143c46eec58 > is > moving into "show-stopper" territory for me. I'm trying to share a > repository's code through fossil to fossil non-users. The inability to log > in in the timeline views means no ability to bundle up ZIP/TAR files. > > Could someone look into this and let me know either what the problem is or > what stupid thing I'm doing? > Please try again now and let me know if it is working any better for you. (I am unable to reproduce the problem here so I'm having to guess) > > -- > "Perhaps people don't believe this, but throughout all of the discussions > of entering China our focus has really been what's best for the Chinese > people. It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. > > ___ > 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] Ticket 305143bd876f693f446f78d12dbef143c46eec58
On 16 March 2011 19:21, Richard Hipp wrote: > > > On Wed, Mar 16, 2011 at 1:04 AM, Michael Richter wrote: > >> The ticket >> http://fossil-scm.org/index.html/tktview/305143bd876f693f446f78d12dbef143c46eec58 >> is >> moving into "show-stopper" territory for me. I'm trying to share a >> repository's code through fossil to fossil non-users. The inability to log >> in in the timeline views means no ability to bundle up ZIP/TAR files. >> >> Could someone look into this and let me know either what the problem is or >> what stupid thing I'm doing? >> > > Please try again now and let me know if it is working any better for you. > (I am unable to reproduce the problem here so I'm having to guess) > Same problem, I'm afraid. Let me try a more "burn everything to the ground" approach and report back. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. ___ 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] Ticket 305143bd876f693f446f78d12dbef143c46eec58
On 16 March 2011 23:15, Michael Richter wrote: > On 16 March 2011 19:21, Richard Hipp wrote: > >> >> >> On Wed, Mar 16, 2011 at 1:04 AM, Michael Richter wrote: >> >>> The ticket >>> http://fossil-scm.org/index.html/tktview/305143bd876f693f446f78d12dbef143c46eec58 >>> is >>> moving into "show-stopper" territory for me. I'm trying to share a >>> repository's code through fossil to fossil non-users. The inability to log >>> in in the timeline views means no ability to bundle up ZIP/TAR files. >>> >>> Could someone look into this and let me know either what the problem is >>> or what stupid thing I'm doing? >>> >> >> Please try again now and let me know if it is working any better for you. >> (I am unable to reproduce the problem here so I'm having to guess) >> > > Same problem, I'm afraid. Let me try a more "burn everything to the > ground" approach and report back. > OK, this is the sequence I've tried on my main workstation (Ubuntu 10.04): 1. Delete all fossil-scm.org cookies. 2. Close my browser (Chrome 10.0.648.134). 3. Re-open my browser. 4. Go to fossil-scm.org. 5. Log in. 6. Click on Timeline. Result: "you are not logged in". If I repeat this experiment on my backup machine (Windows XP, Chrome 10.0.648.133) I do not have this problem. Curious about that, I tried other browsers (Opera, Firefox) on my main machine again. Again I don't have this problem. The issue seems specific to Chrome under Linux in my case. I have no idea how to proceed from here on however because I can't figure out what could be going wrong that affects only Fossil and nothing else, especially since I killed all cookies related to the fossil-scm.org domain. Any suggestions or ideas on what's next to investigate? -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. ___ 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] Ticket 305143bd876f693f446f78d12dbef143c46eec58
On Wed, Mar 16, 2011 at 16:30, Michael Richter wrote: > > OK, this is the sequence I've tried on my main workstation (Ubuntu 10.04): > > 1. Delete all fossil-scm.org cookies. > 2. Close my browser (Chrome 10.0.648.134). > 3. Re-open my browser. > 4. Go to fossil-scm.org. > 5. Log in. > 6. Click on Timeline. > > Result: "you are not logged in". > > If I repeat this experiment on my backup machine (Windows XP, > Chrome 10.0.648.133) I do not have this problem. Curious about that, I > tried other browsers (Opera, Firefox) on my main machine again. Again I > don't have this problem. > > The issue seems specific to Chrome under Linux in my case. I have no idea > how to proceed from here on however because I can't figure out what could be > going wrong that affects only Fossil and nothing else, especially since I > killed all cookies related to the fossil-scm.org domain. > > Any suggestions or ideas on what's next to investigate? > Maybe knowing whether you happen to have add-ons for Google Chrome installed could help? -- BM ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Feature Idea: Mail A Patch
Any thoughts on a feature to take a diff from a local fossil repo and email it to someone, who can then put it in their stash? Something like this: fossil mail -r 23234234 zeds...@zedshaw.com Which would send a patch from current to the -r revision to me. I could then save the attachment and do: fossil patch stuff.diff And it'd attempt applying it using whatever diff/patch tools are configured. -- Zed A. Shaw http://zedshaw.com/ ___ 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] Feature Idea: Mail A Patch
On Mar 16, 2011, at 5:09 PM, Zed A. Shaw wrote: > Any thoughts on a feature to take a diff from a local fossil repo and > email it to someone, who can then put it in their stash? Something like > this: > > fossil mail -r 23234234 zeds...@zedshaw.com ...and as a side-effect allow binary diffs to be sent in ascii85 (like git) or base64-encoded format. -- Dmitry Chestnykh ___ 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] Ticket 305143bd876f693f446f78d12dbef143c46eec58
On Wed, Mar 16, 2011 at 11:30 AM, Michael Richter wrote: > > OK, this is the sequence I've tried on my main workstation (Ubuntu 10.04): > > 1. Delete all fossil-scm.org cookies. > 2. Close my browser (Chrome 10.0.648.134). > 3. Re-open my browser. > 4. Go to fossil-scm.org. > 5. Log in. > 6. Click on Timeline. > > Result: "you are not logged in". > > If I repeat this experiment on my backup machine (Windows XP, > Chrome 10.0.648.133) I do not have this problem. Curious about that, I > tried other browsers (Opera, Firefox) on my main machine again. Again I > don't have this problem. > > The issue seems specific to Chrome under Linux in my case. I have no idea > how to proceed from here on however because I can't figure out what could be > going wrong that affects only Fossil and nothing else, especially since I > killed all cookies related to the fossil-scm.org domain. > > Any suggestions or ideas on what's next to investigate? > The attachment is a Tcl/Tk script that sets up a TCP/IP proxy. Please make it point to http://www.fossil-scm.org/ and then point your Chrome browser at the proxy. Record your traffic. Send me what you see. -- D. Richard Hipp d...@sqlite.org sockettee Description: Binary data ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] attachment problem
The problem with not being able to attach files to tickets seems to be limited to Windows XP. Don't know it it is limited to SP3 because all the PCs around my office that are running XP are SP3. Seems to work in Windows 7 64-bit and on Ubuntu. ___ 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] submodules
Ok, I think I found the solution. The submodule must be integrated by using fossil open --nested That's not documented, but I'm happy there's a solution. From: tr...@tekwissusa.com Sent: Tuesday, March 15, 2011 3:39 PM To: fossil-users@lists.fossil-scm.org Subject: [fossil-users] submodules I was trying to add to the discussion about submodules in the archives, but not being a power mailing list user I don’t know how. So I apologize for starting this new thread. /myprj/src/... /ip/... whereas ip.fossil is a wholly independent fossil repository In “/myprj/ip” I ‘d like to execute something like fossil extract VERSION|—latest ip.fossil which would not open the repo, but just extract the files. Doing it that way will of course never allow to make changes to /myprj/ip and propagate them back into ip.fossil, since all connection to the repo has been lost. Update of the ip is only by manually executing again fossil extract ..., which is a critical requirement for me. So the question is, does such an ‘extract’ function exist, I wasn’t able to find anything, but maybe I’m just blind. I guess it would be the same as ‘fossil open’ followed by ‘fossil close’ without the complaint that it’s already within an open tree ‘myprj’. Best Regards, Daniel ___ 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] submodules
Wow, didn't know about that either. For your original question, the command is not extract but export. As specified, it just creates the files, which don't then contain any marker that they came from fossil. Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 On Mar 16, 2011, at 3:36 PM, "trash" wrote: > Ok, I think I found the solution. > > The submodule must be integrated by using > fossil open --nested > > That's not documented, but I'm happy there's a solution. > > > From: tr...@tekwissusa.com > Sent: Tuesday, March 15, 2011 3:39 PM > To: fossil-users@lists.fossil-scm.org > Subject: [fossil-users] submodules > > I was trying to add to the discussion about submodules in the archives, but > not being a power mailing list user I don’t know how. So I apologize for > starting this new thread. > > /myprj/src/... > /ip/... > > whereas > ip.fossil > is a wholly independent fossil repository > > In “/myprj/ip” I ‘d like to execute something like > fossil extract VERSION|—latest ip.fossil > which would not open the repo, but just extract the files. Doing it that way > will of course never allow to make changes to /myprj/ip and propagate them > back into ip.fossil, since all connection to the repo has been lost. Update > of the ip is only by manually executing again fossil extract ..., which is a > critical requirement for me. > > So the question is, does such an ‘extract’ function exist, I wasn’t able to > find anything, but maybe I’m just blind. > I guess it would be the same as ‘fossil open’ followed by ‘fossil close’ > without the complaint that it’s already within an open tree ‘myprj’. > > Best Regards, > Daniel > ___ > 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Feature Idea: Mail A Patch
On Wed, 16 Mar 2011 09:09:44 -0700
"Zed A. Shaw" wrote:
> Any thoughts on a feature to take a diff from a local fossil repo and
> email it to someone, who can then put it in their stash? Something
> like this:
>
> fossil mail -r 23234234
> zeds...@zedshaw.com
>
> Which would send a patch from current to the -r revision to me. I
> could then save the attachment and do:
>
> fossil patch stuff.diff
>
> And it'd attempt applying it using whatever diff/patch tools are
> configured.
I'd also like to have something like that...it was discussed earlier
("Fossil bundles" thread").
Sincerely,
Gour
--
“In the material world, conceptions of good and bad are
all mental speculations…” (Sri Caitanya Mahaprabhu)
http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
signature.asc
Description: PGP signature
___
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] Client certs - revelation
On 03/16/11 00:37, Dmitry Chestnykh wrote: >> I figured out why no one is explaining to me how to specify >> which client certificate to use when connecting with https: Because >> fossil doesn't support it yet. :) > > You're right :-) > http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04069.html I promise I won't simply grep and extrapolate again. :) >> Our development server only allows fully verified certificate >> chains when connecting to it (with the exception of ssh); I added >> support for specifying a certificate and key file to my local fossil >> copy, and now I can properly access our repositories through https >> (via apache and cgi). However, it seems appropriate to implement this >> properly so that everyone can benefit from it. > > What's the user interface for specifying a certificate and key file? I just added hardcoded support for ~/.pki/clientkey.pem and ~/.pki/clientcrt.pem. To get that basic functionality, it's really as simple as adding two lines of code(!). However, as for how I'll implement the real solution; that's still open for discussion. As I figure, the two most "fossilic" solutions would be one of the two: 1) Store key/certificate (or reference to them) in the local datastore (_FOSSIL_) 2) Store key/certificate (or reference to them) in the global datastore (~/.fossil) Option 1 has a painfully obvious chicken-and-egg problem, as the certificate/key may be required to even get a clone of the repository. Also, conceptually, a client certificate is normally issued to a person, not a service. Therefore it makes much more sense to have a global certificate store of some kind (to identify the person who owns the home directory, rather than the specific repository). So my first goal is to add a command line interface (including a web gui interface?) to manage client certificates/keys, bundling them together into some named data entity in the global data store (~/.fossil). Then when a clone & open are performed, the user can - through a switch - choose which certificate entity to use to connect to the server. This information will be - through some magical means - stored in the local (_FOSSIL_) data store for future use (for push/pull/sync) after an open. I need to read up on ~/.fossil and _FOSSIL_ though to see if there's any risk of accidental information leak when pushing/pulling. The question is if the client key should be stored in the database, or if it's safer to store a reference to it instead, and keep the actual key outside (in the file system). Any input from seasoned fossil developers on this is much appreciated. > I don't use client certificates, but I agree that fossil should support them. Yeah; for some (like me) it's an actual requirement. On that note.. Planning a little bit further into the future here. Is anyone interested in "full" support for PKI in fossil? For instance, signing commits using a client key belonging to a certificate, adding means to distribute public certificates for purposes of verification, etc. The way the repo data can be sync'd could make it almost ideal for sharing certificates. And I would obviously add support for signing commits using smart cards (using PKCS#11). In the industry I work, web of trust signatures are not accepted. (I'm not saying this is right, but it's the way it is). In fact, smart cards are the only accepted mechanism for signing digital documents. I'm not saying that it's in any way implied that we'd get new users by supporting PKI, but it could open a door which is most definitely closed right now. Anyway, this is just some random brainstorming. If anyone sees any value in it, let me know. -- Kind regards, Jan Danielsson signature.asc Description: OpenPGP digital signature ___ 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] submodules
On Wed, Mar 16, 2011 at 3:41 PM, Joshua Paine wrote: > For your original question, the command > is not extract but export. As specified, it just creates the files, which > don't then contain any marker that they came from fossil. Sorry, export dumps the repository in git-fast-export format, for the purpose of exporting commits from Fossil to git (or other VCS that can import git-fast-export format). ___ 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] Client certs - revelation
On Wed, Mar 16, 2011 at 5:08 PM, Jan Danielsson wrote: > I need to read up on ~/.fossil and _FOSSIL_ though to see if there's > any risk of accidental information leak when pushing/pulling. The > question is if the client key should be stored in the database, or if > it's safer to store a reference to it instead, and keep the actual key > outside (in the file system). I would keep the certs, themselves, completely outside of Fossil or any other VCS, just storing paths to the files containing the certs. Even the public certs. The public certs you use are your means for authenticating who you trust. You want to be very careful accepting them. > On that note.. Planning a little bit further into the future here. Is > anyone interested in "full" support for PKI in fossil? For instance, > signing commits using a client key belonging to a certificate Signing commits is a good idea. I would recomend invoking gpg (or other crypto tool) to generate and validate signatures, rather than even using a library. Tools like gpg receive a huge amount of scrutiny, so it is very probably safer than performing those functions in Fossil. I know this goes against the Fossil philosophy of providing a single, self-contained executable, but this is one area where using a dedicated, purpose-made tool for the job makes sense. ___ 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] submodules
On Mar 16, 2011, at 6:11 PM, "Ron Wilson" wrote: > Sorry, export dumps the repository in git-fast-export format, for the > purpose of exporting commits from Fossil to git (or other VCS that can > import git-fast-export format). Oops--thanks for the correction. I must have been having flashbacks to my SVN days. Surprisingly, fossil won't export a copy of the files without repository info. Closest thing is the zip command, which will create a zip of all files at a given revision. You could combine it with an unzip command line utility to achieve a file export, but it's awkward and a little silly. ___ 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] Client certs - revelation
On Mar 16, 2011, at 6:40 PM, "Ron Wilson" wrote: > On Wed, Mar 16, 2011 at 5:08 PM, Jan Danielsson > wrote: >> On that note.. Planning a little bit further into the future here. Is >> anyone interested in "full" support for PKI in fossil? For instance, >> signing commits using a client key belonging to a certificate > > Signing commits is a good idea. I would recomend invoking gpg (or > other crypto tool) to generate and validate signatures, rather than > even using a library. Fossil already supports signing commits with gpg. It used to be turned on by default but is now off b/c too many people found it annoying/confusing. Fossil does not, however, do anything to verify signatures--it's more of an audit trail feature than access control. ___ 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] submodules
On Wed, Mar 16, 2011 at 6:41 PM, Joshua Paine wrote: > Oops--thanks for the correction. I must have been having flashbacks to my SVN > days. > Surprisingly, fossil won't export a copy of the files without repository > info. Closest thing > is the zip command, which will create a zip of all files at a given revision. > You could > combine it with an unzip command line utility to achieve a file export, but > it's awkward > and a little silly. You could just rm the _FOSSIL_ file in the root of the working copy, after doing the open. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] more about the attachment problem
I was peeking around and looked in the Log. I found a record of 2 artifacts representing my latest attempt to attach a file to a ticket. Perhaps the attachments are just not being shown? I did recheck the changes I made to the view ticket page, but I have not made changes to the time line settings, so I would expect an entry to appear in the time line, but there was not. Nor in the ticket history page. Any ideas why the attachment did not appear except in this Log? Here is the text of the entry and artifact descriptors: rcvid: 37 User: rwilson Date: 2011-03-16 17:51:18 IP Address: 127.0.0.1 Artifacts: b83e8248547e3c4e8b45558d0efea6aeed26e9ce (rid: 46, size: 1844) abd12f0882e624a03c05214fda6c82fe58fa9631 (rid: 47, size: 229) Artifact abd12f0882e624a03c05214fda6c82fe58fa9631 Control artifact. A \\C_file_header_template.c d99117135f97aa56319aa287768d83b66b095ade b83e8248547e3c4e8b45558d0efea6aeed26e9ce C test\sof\sattaching\sfiles\sto\stickets.\r\n D 2011-03-16T17:51:18.673 U rwilson Z 5f5dd8fa77d2d56fd49867fb8822d9fe Artifact b83e8248547e3c4e8b45558d0efea6aeed26e9ce Control artifact. //** // (C) Copyright xxx. All rights reserved. // ___ 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] Client certs - revelation
On Wed, Mar 16, 2011 at 11:40 PM, Ron Wilson wrote: >> I need to read up on ~/.fossil and _FOSSIL_ though to see if there's >> any risk of accidental information leak when pushing/pulling. The >> question is if the client key should be stored in the database, or if >> it's safer to store a reference to it instead, and keep the actual key >> outside (in the file system). > > I would keep the certs, themselves, completely outside of Fossil or > any other VCS, just storing paths to the files containing the certs. Yeah, and another point I thought of was that it also makes it much easier to globally update the certificate/key in case the certificate gets revoked or expires. (Which happens..). > Even the public certs. The public certs you use are your means for > authenticating who you trust. You want to be very careful accepting > them. That's true for distributed web of trusts, but if you're using PKI you (typically) use the CA certificate to verify the authenticity of a client certificate. It's a different trust model. >> On that note.. Planning a little bit further into the future here. Is >> anyone interested in "full" support for PKI in fossil? For instance, >> signing commits using a client key belonging to a certificate > > Signing commits is a good idea. I would recomend invoking gpg (or > other crypto tool) to generate and validate signatures, rather than > even using a library. Tools like gpg receive a huge amount of > scrutiny, so it is very probably safer than performing those functions > in Fossil. I know this goes against the Fossil philosophy of providing > a single, self-contained executable, but this is one area where using > a dedicated, purpose-made tool for the job makes sense. As Joshua mentioned, gpg signing is already supported. But my proposition was to add another trust model, for organizations/industries which are not allowed to trust anything but PKI structures. Anyway, that's further down the road; just wanted to see if there was any immediate interest for PKI in fossil. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
