Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 12:55 PM, Stephan Beal wrote: > That's one of the beauties of restructuring fossil as a library: we don't > need to embed any language at all. Instead, they can be built on top of the > library. > Sure thing: but if that happens (which I'm rooting for), arguing about what language is better is even sillier, since any particular binding existing doesn't negatively affect any other binding :) cheers lvh ___ 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] Scripting in Fossil v2
Hi, Not aimed at anyone in particular, but if you are going to suggest a particular language, can you please point to an interpreter that is easily embeddable into fossil? That seems to be the problem with at least JS and Python, and seems to be Lua's strong point. There's no point in discussing the relative merits of languages if we can't actually reasonably *use that language*. cheers lvh ___ 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] Random thoughts on Fossil v2
+1 for a more common markup language (e.g. markdown) :) ___ 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] Random thoughts on Fossil v2
Hi, Just my 2c: a JSON hook API a la Github would be fantastic. Documentation: https://help.github.com/articles/post-receive-hooks It would also hopefully make it easy to re-use existing services with fossil, if the spec were sufficiently close :) cheers lvh On Mon, Jul 22, 2013 at 12:10 PM, Stephan Beal wrote: > On Mon, Jul 22, 2013 at 12:04 PM, Gautier DI FOLCO < > gautier.difo...@gmail.com> wrote: > >> 2013/7/22 Stephan Beal >>> >>> That's an interesting idea. What would you imagine doing with fossil >>> over RPC? >>> >> >> For example putting the calls in queues (ZeroMQ, RabbitMQ, etc.) to make >> asynchronous and distributed calls, to have a scallable architecture. >> > > So you envision fossil making RPC calls to other services, correct? The > JSON API is a sort of RPC service. If we will add scriptable triggers then > they could do this sort of thing. > -- > - 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Random thoughts on Fossil v2
Hi, While, ceteris paribus, I'd certainly prefer Python, I definitely understand that embedding CPython may be more trouble than it's worth. If you are going to embed *something*, I'd vote for a langauge explicitly designed with that purpose in mind, say, Lua. However, if this is to happen, I really do think that Fossil shouldn't have more than one embedded dynamic language. So, either we do everything with TH1, or we have something that replaces TH1... Definitely a huge +1 for hooks, though; I'd be perfectly happy with something that gets passed to system(3)... lvh ___ 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] release 1.26 (WAS: Fwd: cloning / opening fails on WinXP SP3)
I attempted to, but perhaps I messed it up in some way. Message repeated below. --- Hi, I've written a pretty small patch to make fossil serve files with extension "mp4" as "video/mp4". This in accordance with RFC 4337[1]. The RFC says: 1. if neither audio nor video, use application/mp4 2. for every other file, use video/mp4. 3. if only audio, you *may* use audio/mp4, but video/mp4 is still fine Of course, it's impossible to guess intent from just the extension, although I'm guessing the vast, vast majority of mp4 files are being used to serve video and/or audio, in which case video/mp4 is the appropriate type to serve it with. Either way, that's an upgrade over the current behavior, which, according to curl -I at least, is sending: Content-Type: application/x-fossil-artifact; charset=utf-8 There was some extra whitespace at the end of some lines. My editor helpfully (?) removed it. If you'd like it back, I'll happily provide the same patch without the end-of-line whitespace removal. The reason I wanted this is because I am using fossil to source-control a talk I hope to give at PyCon 2014. In this talk, I have some screencasts to replace live demos. Those screencasts are MP4 (h264 + AAC, or h264 without an audio track) because of browser support. Currently, all browsers want to download this file with a "Save as" dialog because they don't recognize the file type. After the patch, the video just plays, in all browsers that know how to do so. This is my first patch to fossil, so apologies if I messed something up... I don't know if there's a preferred way to send patches in, but this is just the output of "fossil diff". patch -p0 < mp4.patch seems to work fine for applying it :) Patch is against latest trunk at time of writing. It's pretty simple, so I expect it to apply cleanly to a whole lot of revisions... checkout: a6dad6508c0e95bd0aceb28fec1a269114917ac5 2013-06-14 07:19:58 UTC thanks in advance :) lvh [1]: https://tools.ietf.org/html/rfc4337#section-2 mp4.patch 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
Re: [fossil-users] release 1.26 (WAS: Fwd: cloning / opening fails on WinXP SP3)
Would it be possible to include my rather small patch in the release? My
contributor agreement has been sent in, and the patch is about as small as
they come.
On Tue, Jun 18, 2013 at 7:49 PM, Stephan Beal wrote:
> On Tue, Jun 18, 2013 at 4:27 PM, Richard Hipp wrote:
>
>> Thanks for the updates Stephan. I'm studying the diffs now ("fossil diff
>> --tk -c 50 --from release"). And looking at
>> http://www.fossil-scm.org/fossil/timeline?n=1000&y=ci&a=release&t=trunkto
>> see what else has changed. I've also updated the version number to 1.26
>> in preparation for the release.
>
>
> As far as my 64-bit system is concerned, it looks good to me. My 4 year
> old 32-bit netbook, though, is still having a long conversation with
> valgrind (from which i expect the same results).
>
>
> --
> - 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] PATCH: serve mp4 files as video/mp4
Hi, I've written a pretty small patch to make fossil serve files with extension "mp4" as "video/mp4". This in accordance with RFC 4337[1]. The RFC says: 1. if neither audio nor video, use application/mp4 2. for every other file, use video/mp4. 3. if only audio, you *may* use audio/mp4, but video/mp4 is still fine Of course, it's impossible to guess intent from just the extension, although I'm guessing the vast, vast majority of mp4 files are being used to serve video and/or audio, in which case video/mp4 is the appropriate type to serve it with. Either way, that's an upgrade over the current behavior, which, according to curl -I at least, is sending: Content-Type: application/x-fossil-artifact; charset=utf-8 There was some extra whitespace at the end of some lines. My editor helpfully (?) removed it. If you'd like it back, I'll happily provide the same patch without the end-of-line whitespace removal. The reason I wanted this is because I am using fossil to source-control a talk I hope to give at PyCon 2014. In this talk, I have some screencasts to replace live demos. Those screencasts are MP4 (h264 + AAC, or h264 without an audio track) because of browser support. Currently, all browsers want to download this file with a "Save as" dialog because they don't recognize the file type. After the patch, the video just plays, in all browsers that know how to do so. This is my first patch to fossil, so apologies if I messed something up... I don't know if there's a preferred way to send patches in, but this is just the output of "fossil diff". patch -p0 < mp4.patch seems to work fine for applying it :) Patch is against latest trunk at time of writing. It's pretty simple, so I expect it to apply cleanly to a whole lot of revisions... checkout: a6dad6508c0e95bd0aceb28fec1a269114917ac5 2013-06-14 07:19:58 UTC thanks in advance :) lvh [1]: https://tools.ietf.org/html/rfc4337#section-2 ___ 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] Code review (reloaded)
On Tue, May 28, 2013 at 5:25 PM, Richard Hipp wrote: > On Tue, May 28, 2013 at 11:05 AM, Laurens Van Houtven <_...@lvh.io> wrote: > >> >> My question about how this process with the "pending-review" branch works >> was more about the mechanics of how you'd use such a branch to facilitate >> code review. What goes in that branch? How does it get there? What is the >> sequence of fossil commands? >> > > You can create the branch as you do the comment. For example: > > fossil commit --branch pending-review > > Or > > fossil commit --branch experimental > Cool, thanks :) > If you forget to do it then, you can always visit a check-in after it is > committed and click on the "Edit" link to do things like revise the > check-in comment, update the check-in time, or move the check-in to a > different branch (such as "experimental" or "pending-review" or "mistake"). > Ah, I didn't know about that feature. > Sometimes somebody will check-in a change to trunk that I don't agree > with. When that happens, I just move their check-in off into a branch. > Right -- so basically, the default is to trust the commit is good and to do something when it goes wrong, as opposed to always reviewing all of the time? :) > A tangent: Note that when you "edit" a check-in, you are not really > changing the check-in. You are, instead, adding additional information. > Fossil does not erase or modify, it only augments. The original check-in > comment, and time, and branch are all still there for anybody to see. By > 'editing' the commit, you are adding a new record to the repository that > says "for display purposes, modify checking XYZ as follows..." > Right, that philosophy is one of the main reasons I want to get rid of git :) One thing I'm confused about though: "for display purposes"? I understand the ledger-like behavior of recording the change instead of changing the original, but I would expect that the checkin is for all intents and purposes in the new branch, not just for display ones. Notes also that Fossil allows you to start a new branch named (for example) > "experimental" even if there already exists one or more other branches with > the same name. At > http://www.fossil-scm.org/fossil/timeline?n=200&r=experimental it looks > like there are a dozen or more "experimental" branches currently in the > Fossil tree. > I knew that in the back of my head, but that definitely helped my understanding: I was still thinking in terms of one single review branch :-) Can commits be in multiple branches? > -- > 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] Code review (reloaded)
On Tue, May 28, 2013 at 1:15 PM, Richard Hipp wrote: > Fossil follows a BSD-style of code development, rather than a GPL-style. > I think my question may have been a bit ambiguous. I've pondered the differences between those licenses a lot, and I very strongly prefer permissive licenses. (I've snipped most of the discussions about development models; I agree with most of what you have to say. I do have my doubts to what extent that ties to the license. but I think that's mostly irrelevant) As it happens, I also use the CLA process to vet developers. I only turn > on the ability to push changes to the canonical Fossil repository for > people who have proven their ability to write good code. Typically, this > "proof" consists of submitting some patches either directly to me, or by > posting on this mailing list. Another way of looking at it: I place more > emphasis on reviewing coders than on reviewing code. Right, right. I think Twisted, the other project I mentioned in my original mail, is in a similar situation. It's MIT/X11 licensed, and contributions come from a small team of constant contributors and a large long tail of occasional contributors. Once you've proven your worth, you're likely to get a commit bit. The difference, however, is that Twisted still has a mandatory review process regardless of whether or not you have a commit bit or not. It appears you're saying that once people get a commit bit in Fossil, code review requirements are significantly more lax, because they've shown that they know what they're doing? My question about how this process with the "pending-review" branch works was more about the mechanics of how you'd use such a branch to facilitate code review. What goes in that branch? How does it get there? What is the sequence of fossil commands? cheers lvh ___ 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] Did you know that Fossil could do...
On Tue, May 28, 2013 at 3:08 PM, Richard Hipp wrote: > Survey: How many people know that in the web-based timeline for Fossil, > you can click on any two nodes in the graph and get a diff between those > two nodes? > I did not know that. > And assuming I'm guessing correctly, do you have any suggestions on how I > can get the word out about this and other useful but obscure features of > Fossil? > For this particular feature, the pointer change is great, and also a one-line howto as already suggested in this thread. Documentation is only useful if people read it and use it. If something can be made self-explanatory, it should be, probably ;-) cheers lvh ___ 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] Code review (reloaded)
On May 28, 2013 12:39 PM, "Richard Hipp" wrote: > There is a "pending review" branch ( http://www.fossil-scm.org/fossil/timeline?c=pending-review&y=ci) on the Fossil self-hosting repository now! I'm not sure I understand the workflow here. It seems the branch name itself is "pending-review". Where do I start writing code? How do I submit it for review? How does code get reviewed? > Fossil also has the ability to move a check-in to a different branch after it has been committed. Sometimes people will check-in some code by mistake, or which is rejected by reviewers, and in those cases we simply move the check-in off to a dead-end branch, often called "mistake". See http://www.fossil-scm.org/fossil/timeline?r=mistake for some examples of this. > >> >> >> thanks in advance >> lvh >> >> ___ >> 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 > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Code review (reloaded)
Hi, I'd like to know what sort of code review practices Fossil users employ. I believe this has come up at least twice: I've asked about it myself back in 2010, and Russ Paielli from the Scala team in 2011. All the projects I currently work on have some explicit form of code review, be it: - Github pull requests - explicit code review processes on top of an existing tool (such as twisted + trac) - Launchpad merge proposals All of these tend to operate on the merging of a branch: the changes get reviewed before being merged into master/trunk/... It is my understanding that Fossil doesn't come with such a tool for code reviews. Additionally, the entire point of autosync by default is to prevent having to branch and merge all the time. So, I'm wondering, do you: 1. not do code review at all 2. only do code review on major things that get their own branch, not reviewing small changes to trunk 3. have a code review system not based on merging into trunk 4. something else? thanks in advance lvh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Syncing with Github
Hi, I'd like to move some projects from Github to self-hosted fossil (or maybe chisel, I haven't decided yet). However, I'd like to keep the Github repository available and updated. I can do a one-time move with fast-export/fast-import, but that doesn't help for new code. I'm willing to have the Github repository only be computer writable, and have the Fossil repository be the Single Source of Truth. People may contribute code through pull requests, but once vetted I'll commit it to the Fossil repository myself. Has someone built something already (presumably using fast-import and fast-export, since those seem to be the go-to tool for cross-scm compatibility) to keep a git repository synced with a fossil one? cheers lvh ___ 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] re-thinking commit access to the main fossil repo...
How difficult would it be to implement something like Launchpad's merge proposals or Github's pull requests? We're currently using Fossil the way drh described SQLite-like development processes and it does indeed work very well, but it would be nice if there was a good contributor story for the project I'm going to publish soon-ish. cheers lvh ___ 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 CGI problem
For the people potentially checking out the Twisted script -- the ticket with the bug just got fixed upstream, so there's basically a one-release window where it was broken (10.2.0). cheers lvh ___ 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 CGI problem
If I'm reading src/http.c correctly, that basically only happens if iLength remains set to its original value of -1, so the response is probably accurate. My best guess is that it's either a Bauk bug or misconfiguration issue. Unfortunately I've never heard of Bauk, so I can't really help you there. I have added a smaller version of my twisted script[1] which may help you unless you really need to use Bauk. Fair word of warning: maybe be flakey with some clients in latest version of twisted because of a http header regression[2]). Edit lines 17 and 18. Put your fossil repo in repositories/Yourname.fossil, along with a file Yourname.cgi, which just contains: repository: Yourname.fossil (Twisted will already run this with fossil, if fossil is on your PATH.) Run python script.py, and you can access your repo at http://localhost:8080/Yourname (the name it's available under is the first argument to root.putChild on line 18) [1] http://www.bpaste.net/show/12921/ [2] Ticket: http://twistedmatrix.com/trac/ticket/4786 Workaround (may not be necessary depending on client): comment out twisted/web/server.py, line 118 : http://twistedmatrix.com/trac/browser/tags/releases/twisted-10.2.0/twisted/web/server.py#L118 cheers lvh ___ 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 CGI problem
I do wonder why there aren't any newlines. Was that lost in the paste, or is that really what Bauk produces as a response? If my spec-memory is correct, HTTP defines a newline as a CR LF, there's supposed to be one after each header, and the request ends with a double newline. I can't see that in the paste. It's possible, that Fossil, like Chrome is less forgiving of bogus input? (I can hardly blame it, Accept and cookie-specific headers are already difficult enough to parse without having to guess where they end...) cheers lvh ___ 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 CGI problem
That hostname isn't supposed to be internet-accessible, is it? I've written an admittedly ad-hoc Twisted script which sort-of works (depending on versions, you might get a duplicate Content-Type, which, depending on browser (ie Chrome), may mean the CSS doesn't work). If you want, you can try that, perhaps we can compare responses to see what goes wrong. cheers lvh ___ 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] Chrome not showing CSS with CGI?
Yep, looks like it's a silly bug in some really old CGI serving code I wasn't supposed to use but am going to fix now -- either way unrelated to Fossil (which is, indeed, doing the right thing). Sorry to bother you, happy new year :-) lvh ___ 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] Chrome not showing CSS with CGI?
Turns out I misinterpreted the Developer tool. Here's what's actually in the HTTP header: Content-Type: text/html Content-Type: text/css; charset=utf-8 That doesn't look right. Still no idea where it's coming from though. lvh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Chrome not showing CSS with CGI?
Hi :-) First of all, happy new year (that was about half an hour ago) from Belgium. May 2011 bring you good health and sane version control :-D I've just tried to move my Fossil repo to a slightly more advanced server (so I can do SSL and REMOTE_USER and friends), so I used Twisted to write a CGI server. For some reason, Chrome doesn't display any CSS. It works fine in: - Firefox 3.6 and Namoroka (nightlies) - Firefox 4.0 and Minefield (nightlies) - Opera 11 Chrome is definitely downloading the file (I can see that in the file server logs). In the network and resource tabs of the Chrome developer tools, I can see it's downloading the file and getting a 200 OK response, and the file is of the correct size and content. It's simply not applying that stylesheet to the page. The most likely culprit is the Content-Type, which is prefixed with "text/html\n\r". It's probably important enough that Chrome doesn't like it anymore. I'm not sure if that's the fault of my CGI script or what, but maybe someone has seen a similar problem? I've "fixed" it by using fossil serve -- that seems to serve it with the right Content-Type, so then Chrome grabs it from cache, which works. Obviously not ideal ;-) Here's the python script, so you can try it yourself if you have Twisted: http://bpaste.net/show/12610/ I'm assuming it's really not got anything to do with Fossil for now, but I'll keep you posted. thanks and happy new year! :-) lvh ___ 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] Password hashing: why doesn't fossil use bcrypt/scrypt?
Right, okay -- that's fairly reasonable, you couldn't realistically prepare an attack on a repository then. (The question of using things that are slower than SHA1 as in my original post still stands, of course. As you've said, it's definitely better than some stuff that gets used -- such as the recent Gawker farce which was unsalted DES IIRC -- but given how easy that attack was in hindsight, is this good enough?) thanks for your time an attention, lvh ___ 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] Password hashing: why doesn't fossil use bcrypt/scrypt?
Ahh, yes, I just realized you were probably talking about PBKDF1/2. My apologies :-) That is a fair comparison, since they're both tunably hard to compute KDFs. cheers lvh ___ 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] Password hashing: why doesn't fossil use bcrypt/scrypt?
On Thu, Dec 23, 2010 at 12:05 AM, Joerg Sonnenberger wrote: > On Thu, Dec 23, 2010 at 12:01:43AM +0100, Joerg Sonnenberger wrote: >> Using scrypt wouldn't increase size much as most of the primitives exist >> already. Using a format like $id$salt$encrypted like most UNIX systems >> for passwd would be an improvement in any case. > > s/scrypt/HMAC-SHA1 based crypt/ (which is very similar to bcrypt). > > Joerg Considering one uses SHA1 and the other relies on BlowfishEKS, a tunably slow implementation of Blowfish, I'm not sure what attributes of those two you are comparing to call them similar. Perhaps you are thinking of stretching (aka phk's technique, which is used in FreeBSD -- but that uses MD5, not SHA1)? cheers, lvh ___ 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] Password hashing: why doesn't fossil use bcrypt/scrypt?
On Thu, Dec 23, 2010 at 12:01 AM, Joerg Sonnenberger wrote: > On Wed, Dec 22, 2010 at 11:06:47PM +0100, Laurens Van Houtven wrote: >> I was looking at >> http://www.fossil-scm.org/index.html/doc/trunk/www/password.wiki and >> worried about the case of a compromised repository. Why does Fossil >> use SHA1 and not scrypt/bcrypt to store passwords? > > Positive: the passwords (if encrypted) are salted based on the project code > and login name. So at least two users with the same password have > differen't encrypted passwords. If I understand correctly, the nonce (the project code part and the user name part) is known up front, so you wouldn't have to wait for a compromised repository. You'd need numusers*dictsize worth of space which, may be pretty large (perhaps too large to be feasible), but still nowhere near (2**nonce_bits)*dict_size which is the number that backs the claim that nonces make (up-front) dictionary attacks infeasible. I'm not sure about the project code part (perhaps it has some random bits in it too, for which you'd actually need the real repository), am I correct about that being predictable? > Joerg cheers lvh ___ 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] Password hashing: why doesn't fossil use bcrypt/scrypt?
On Wed, Dec 22, 2010 at 11:39 PM, Richard Hipp wrote: > On Wed, Dec 22, 2010 at 5:06 PM, Laurens Van Houtven > wrote: >> Hi. >> >> I was looking at >> http://www.fossil-scm.org/index.html/doc/trunk/www/password.wiki and >> worried about the case of a compromised repository. Why does Fossil >> use SHA1 and not scrypt/bcrypt to store passwords? > > SHA1 is already available in the source tree whereas scrypt/bcrypt introduce > unwanted and undesirable dependencies. Also, if the repository is > compromised, such that the adversary is able to mount a dictionary attack > against the passwords, what makes you think scrypt/bcrypt is going to be any > stronger than SHA1? The short version is "SHA is designed to be fast -- key derivation functions ought to be slow". SHA1 is much, much faster to compute than bcrypt or scrypt. Relatively speaking, SHA1 is much closer to MD4/MD5's ballpark in terms of CPU time. That has resulted in people mounting attacks against these algorithms using now-commodity fast number crunching hardware (these days also known as a GPU ;-)). Example: http://www.win.tue.nl//sha-1-challenge.html bcrypt and scrypt are designed so that such an attack against a compromised repository would take a ridiculous amount of time. scrypt, additionally, makes it take a whole lot of memory, too. I would be repeating Percival's work, and given how clever a person he is, I'd probably be doing him a disservice, so here's his paper on the subject: http://www.tarsnap.com/scrypt/scrypt.pdf You might want to skim the slides for the talk he gave at BSDConf09: http://www.tarsnap.com/scrypt/scrypt-slides.pdf cheers lvh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Password hashing: why doesn't fossil use bcrypt/scrypt?
Hi. I was looking at http://www.fossil-scm.org/index.html/doc/trunk/www/password.wiki and worried about the case of a compromised repository. Why does Fossil use SHA1 and not scrypt/bcrypt to store passwords? thanks in advance (and happy holidays), lvh ___ 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] Hello. Anyone for source highlighting?
This would be totally awesome. Like the generic "just call a script" event notification system, I think it's a great idea, because it makes Fossil significantly more flexible without making it bloat up. thanks, lvh ___ 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 local server
Can you try it anyway in Firefox? I had a very similar redirect loop problem with Chrome nightlies in a different app that magically went away with FF. lvh ___ 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] Multiple fossil projects: sharing configuration
Richard, Thank you very much for your reply. I'm interested in REMOTE_USER: what Fossil docs should I be reading? How does this work with cloned repositories? (I assume these users do exist when I clone a repository?) thanks lvh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Multiple fossil projects: sharing configuration
Hi. Let's say I have a development shop with a few developers and a similar workflow (ticket states etc). Is there a recommended way of keeping this configuration (including users if at all possible) in sync between multiple Fossil repos? Can I just copy over the relevant tables and expect everything to Just Work? thanks lvh ___ 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 + Buildbot
Hi! I've found some mailing list mentions of Fossil + Buildbot, but never any concrete success. Is anyone doing this? Specifically, does anyone successfully push changes from Fossil to buildbot? I saw a patch for fossil and some buildbot-specific code (involving their generic VCS integration command). I was wondering if anyone actually got it working and has concrete instructions for getting it working here as well. thanks lvh ___ 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 Sync Questions
Whoops, I accidentally sent this to the wrong list. Never mind me. ___ 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 Sync Questions
No, I hadn't! That was very helpful, thank you. I'm specifically interested in using conch as a server: using manhole together with file transfer. I've found some stuff from Tahoe-LAFS that uses it, but it's not incredibly illuminating. thanks for the pointer lvh ___ 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] Code review and branch per issue
Hi Richard, First of all thanks for your reply. Why we create branches: the idea in our workflow is that stuff in trunk gets put to production (after a continuous integration system runs all the tests on it). One of the steps between development and production is mandatory code review. Obviously, it would be nice if we did said mandatory code review before shipping things off to production, because reverting in production is a relatively expensive operation. (Note: we also have tickets for *features* as a place to store discussion for later references. Features, of course, are generally big enough to warrant >1 commits.) The branch you linked me looks great and almost like something that would work wonders, but I do not understand conceptually why the branch is "open" and not "closed". I think a very easy to implement and useful feature would be to get the entire diff, like you showed me in the second link, as a link on the branch page, for purposes of code review. Especially if there's a way of getting that in a standard format that existing tools understand, so it can be used for producing syntax highlighted and side-by-side diffs (the kind Rietveld or bzr qdiff do). We're used to using code review tools like Rietvield for commenting on diffs. Basically the best feature ever would be Launchpad's merge requests, but I realize that's a huge amount of stuff to implement. cheers lvh ___ 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] Code review and branch per issue
2010/10/4 Lluís Batlle i Rossell : > On Mon, Oct 04, 2010 at 10:55:02PM +0200, Laurens Van Houtven wrote: > You can review against the trunk version it was updated from. As any DVCS, > fossil does not provide methods to guarantee that noone commited over the same > parent as you, so if that happens, you then will have to merge two heads of a > single branch. This is inherent in DVCS, and not related to your review > process. Yeah I was kind of hoping there was a way of creating a diff for the entire branch that just combines the subsequent changes. Or some automagic way of doing this. I guess it's not much of a problem. >> Is there a decent way of filtering tickets on the ones which are up >> for review and which ones aren't? In trac, I did this with tags; but >> fossil doesn't appear to have tags for tickets. > You can write your own queries for fossil, and your own fields in each ticket. > In the web Admin -> Ticket configuration you can find that. Oh, cool, thanks. >> Also what do you people use for code review? I can imagine using >> fossil diff for this, I guess. Ideas welcome. > I still have not moved our scripts from svn to fossil, but what we used to do > was prepare two checkout directories, one with the last trunk version merged > in, > and the other with the branch to review. Then we used meld (meld.sf.net) to > get > a diff while being able to edit the files. > Then we leave comments and commit in the branch with the review results. > > I wonder how difficult it will be in fossil to find "the version of the parent > branch last merged into a child branch". I will take a look at meld, thank you. > Regards, > Lluís. cheers lvh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Code review and branch per issue
Hello, I'm trying to migrate a Trac workflow to Fossil. Here's what it looks like: For each feature: 1. create ticket 2. create branch 3. implement 4. submit branch for review 5. review: if not good, back to 3 6. merge branch to trunk (trunk gets handed off to continuous integration/deployment system) It feels kind of unwieldy. I'm trying to figure out if that's because I'm not used to Fossil, or because I'm trying to make a cat bark. Is Fossil not built to work this way? It could be a misunderstanding, but I saw something about Fossil's autosync feature being all about preventing lots of "needless" branching. What is workflow supposed to look like instead? Is there a decent way of filtering tickets on the ones which are up for review and which ones aren't? In trac, I did this with tags; but fossil doesn't appear to have tags for tickets. Also what do you people use for code review? I can imagine using fossil diff for this, I guess. Ideas welcome. Thanks in advance, Laurens ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
