Re: [fossil-users] same user, multiple logins: the problem and a potential solution

2011-09-15 Thread Stephan Beal 
On Thu, Sep 15, 2011 at 6:19 AM, Altu Faltu  wrote:

> It would be simple to have one auth token for each login and purge stale
> auth tokens regularly. Purging stale tokens should be a matter of few SQLs
> for the current backend of fossil, sqlite.
>

In principal it's simple, yes, but the current code can't support it because
the auth token is written into the user table (i.e. there's only one slot
for it). This would require a new table to hold the data. It sounds
reasonable, though, and i'll take a look at this.

Then, we can enable multiple logins and also keep the current IP check as it
> is.
>

Well "functionally as it" - some amount of code for this would have to be
shifted around. :)


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] same user, multiple logins: the problem and a potential solution

2011-09-15 Thread Stephan Beal 
On Thu, Sep 15, 2011 at 8:50 AM, Ben Summers  wrote:

> For example, you could form the string
>
>   stephan:192.168.0
>
> then sign it with the secret key, and get
>
>   stephan:192.168.0:38fa112673be4946702a74d1d0d1c0b6bd9f0162
>

That is in essence what Richard has done already. He uses the first 2 octets
of the IP, though. The whole mechanism is quite clever, IMO (but i didn't
write it!). As a cookie KEY he uses fossil- where  is the project's
code (or a "group code" for group logins), which means the key itself is
tied to a specific repo (or group). The value's has uses the project code as
part of the data, so the key/value are intimately tied together.

To limit the validity of the tokens, include the time in the string being
> signed, and check it's in an acceptable range.
>

For anonymous logins, the time is part of the cookie, but AFAICS the
non-anonymous logins don't currently use a time element (except for the
expiry time, but that's not actually part of the hash).


> Advantages are that no state is stored in the database and multiple logins
> are possible, with simpler code.[2] You can invalidate all logins by
> changing the secret key, but can't invalidate individual sessions.
>

But that would mean a logout on one client would log out all others, doesn't
it? (My proposal also has that limitation, but has the simpler
1-user=1-login entry record keeping.)


> If you wanted to support logins from multiple locations in a browser which
> is run in multiple networks, include the partial IP address in the cookie
> name.
>

That's a nice idea. Currently the partial IP is used in generating/checking
the hash, but it's not used in the cookie name itself.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] same user, multiple logins: the problem and a potential solution

2011-09-15 Thread Stephan Beal 
On Thu, Sep 15, 2011 at 10:22 AM, Stephan Beal wrote:

>
>
>> Advantages are that no state is stored in the database and multiple logins
>> are possible, with simpler code.[2] You can invalidate all logins by
>> changing the secret key, but can't invalidate individual sessions.
>>
>
> But that would mean a logout on one client would log out all others,
> doesn't it?
>

Ignore that question, please. i didn't grasp the important words "no state
is stored..."

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] JSON login demo: is this interface acceptable?

2011-09-15 Thread Stephan Beal 
On Thu, Sep 15, 2011 at 12:40 AM, Stephan Beal wrote:

> i haven't yet done anonymous user support (that requires special handling
> because of the random password). Nor have i yet thoroughly tested THIS
> support (it's literally under 10 minutes old). "Seems to work."
>

BTW: this seems to mesh fine with the cookie. For example, if i log in:

http://fjson/cgi-bin/fossil.cgi/json/login?...

then check my capabilities:

http://fjson/cgi-bin/fossil.cgi/json/cap

(fjson is a local apache vhost, by the way)

important here is that my client code is not actually recording/re-sending
the auth token in the JSON bits - we're relying 100% on the cookie.

i get (this is a mirror of g.perm):

{
"fossil": "29ec8d0199cab10325fa7d33af90261cd7cf603e",
"timestamp": 1316072920,
"payload": {
"Setup": 1,
"Admin": 1,
"Delete": 1,
"Password": 1,
"Query": 0,
"Write": 1,
"Read": 1,
"History": 1,
"Clone": 1,
"RdWiki": 1,
"NewWiki": 1,
"ApndWiki": 1,
"WrWiki": 1,
"RdTkt": 1,
"NewTkt": 1,
"ApndTkt": 1,
"WrTkt": 1,
"Attach": 1,
"TktFmt": 1,
"RdAddr": 1,
"Zip": 1,
"Private": 0
}
}

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] new fossil docs: is the wiki or embedded docs preferred?

2011-09-15 Thread Stephan Beal 
Hi, all,

When adding new docs (for the up-coming json bits), which is the currently
preferred approach: wiki or embedded docs ?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] new fossil docs: is the wiki or embedded docs preferred?

2011-09-15 Thread Richard Hipp 
On Thu, Sep 15, 2011 at 5:11 AM, Stephan Beal  wrote:

> Hi, all,
>
> When adding new docs (for the up-coming json bits), which is the currently
> preferred approach: wiki or embedded docs ?
>

I've grown to prefer embedded docs, since they are tied to specific versions
of the code, and hence you know exactly which version of the code the
documentation applies to.


>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
>
> ___
> 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] any objections to moving my JSON branch into the main repo?

2011-09-15 Thread Stephan Beal 
Yo!

Currently the JSON code is in my own fossil copy, which i regularly
merge/resolve against the trunk. Now that the code is moving along nicely,
would anyone object to me moving it into the 'json' branch of the main repo?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] lol: funny favicon behaviour in local server mode...

2011-09-15 Thread Stephan Beal 
Last night i ran a media player (VLC) web service on localhost:8080. Today
when i started 'fossil ui' my browser had cached the favicon.ico from the
media player and now shows the VLC favicon in place of fossil's.

(Not a fossil bug, by the way.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] lol: funny favicon behaviour in local server mode...

2011-09-15 Thread Remigiusz Modrzejewski 

On Sep 15, 2011, at 1:44 PM, Stephan Beal wrote:

> Last night i ran a media player (VLC) web service on localhost:8080. Today
> when i started 'fossil ui' my browser had cached the favicon.ico from the
> media player and now shows the VLC favicon in place of fossil's.
> 
> (Not a fossil bug, by the way.)

Still, it can be fixed by fossil providing a favicon ;)


Kind regards,
Remigiusz Modrzejewski



___
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] any objections to moving my JSON branch into the main repo?

2011-09-15 Thread Richard Hipp 
On Thu, Sep 15, 2011 at 7:41 AM, Stephan Beal  wrote:

> Yo!
>
> Currently the JSON code is in my own fossil copy, which i regularly
> merge/resolve against the trunk. Now that the code is moving along nicely,
> would anyone object to me moving it into the 'json' branch of the main repo?
>

No objections.


>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
>
> ___
> 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] any objections to moving my JSON branch into the main repo?

2011-09-15 Thread Stephan Beal 
On Thu, Sep 15, 2011 at 1:49 PM, Richard Hipp  wrote:

> No objections.
>

Thank you very much :)

http://www.fossil-scm.org/index.html/timeline?r=json

@Contributors: that branch is in no way holy. Feel free to hack. See
src/json.c for details. Most of the interesting higher-level bits are in
functions named json_page_XXX().

Happy Hacking!

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] new fossil docs: is the wiki or embedded docs preferred?

2011-09-15 Thread Matt Welland 
On Thu, Sep 15, 2011 at 3:50 AM, Richard Hipp  wrote:

>
>
> On Thu, Sep 15, 2011 at 5:11 AM, Stephan Beal wrote:
>
>> Hi, all,
>>
>> When adding new docs (for the up-coming json bits), which is the currently
>> preferred approach: wiki or embedded docs ?
>>
>
> I've grown to prefer embedded docs, since they are tied to specific
> versions of the code, and hence you know exactly which version of the code
> the documentation applies to.
>

In my own projects I've found this to be true also but then we sorely miss
the ability to make quick edits which is one of the best things about the
Wiki. Is it technically feasible to implement editing and checking in of
controlled files from the web interface? It imagine it would require another
permissions flag and would be a lot of work but if some enterprising fossil
hacker decided to implement it I for one would be thrilled :)


>
>
>> http://wanderinghorse.net/home/stephan/
>> --
>> - stephan beal
>>
>> ___
>> 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] conflict between HTML5 and Fossil

2011-09-15 Thread Stephan Beal 
Hi, all,

And now something which has nothing to do with JSON...

i noticed yesterday (via a comment in one of the tickets) that fossil now
sends an HTML5 doctype. That's all fine and good, but the wiki does not
actually play well as-is with HTML5. In v5 several features wiki authors
rely on are deprecated, e.g. the TT tag, align options, and several other
things are now (=v5) officially delegated to CSS. Fossil strips out all but
a small subset of element properties (CSS styles get removed).

We may need to enable at least CSS (but keep the other stripping) in order
to be v5 compliant. We'd also need to change code-side uses of TT and such,
replacing them with styled SPANs.

(Granted, i don't honestly believe that any existing browsers will remove
the TT tag or the A.TARGET attribute, but they are officially deprecated.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] new fossil docs: is the wiki or embedded docs preferred?

2011-09-15 Thread Stephan Beal 
On Thu, Sep 15, 2011 at 2:10 PM, Matt Welland  wrote:

> In my own projects I've found this to be true also but then we sorely miss
> the ability to make quick edits which is one of the best things about the
> Wiki. Is it technically feasible to implement editing and checking in of
> controlled files from the web interface? It imagine it would require
>

Just FYI: one of the goals of the JSON API is saving wiki pages (and that's
one of my own personal favourite use cases for the JSON bits, so it'll
eventually get done). We wouldn't need special permissions for that
implementation, as we would simply use fossil's existing perms.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] new fossil docs: is the wiki or embedded docs preferred?

2011-09-15 Thread Stephan Beal 
On Thu, Sep 15, 2011 at 2:18 PM, Stephan Beal  wrote:

> On Thu, Sep 15, 2011 at 2:10 PM, Matt Welland  wrote:
>
>> ...checking in of controlled files from the web interface? It imagine it
>> would require
>>
>
> Just FYI: one of the goals of the JSON API is saving wiki pages (and
>

Sorry, hit send too soon...

In theory we could also perform commits over the JSON interface, at least
for text files (things which can be JSONified), but implementing that is way
down the list of TODOs.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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 tutorial - Oct 25 in Manassas VA

2011-09-15 Thread Steve Bennett 
On 15/09/2011, at 1:42 AM, Richard Hipp wrote:

> I'm schedule to give a 3.5 hour in-depth tutorial on Fossil on Tuesday, Oct 
> 25 from 09:00 to 12:30 in Manassas VA as part of the 2011 Tcl/Tk conference.  
> See http://www.tcl.tk/community/tcl2011/schedule.html for schedule and 
> registration information.  In addition to usual high-level information about 
> the history and usage of DVCSes in general and Fossil in particular, I plan 
> to go into detail about the internal data structures, code organization, and 
> file format for Fossil, with the idea of equipping users with 
> behind-the-scenes information that will help them to make more effective use 
> of Fossil, and to better understand why Fossil behaves the way it does.

That's great. I'm going to be giving a presentation on Jim Tcl for the main 
conference.
Are you staying for the conference, or are you only going to be there on the 
Tuesday?

Cheers,
Steve

--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au  P: +61 434 921 300
E: ste...@workware.net.au   F: +61 7 3391 6002





___
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] authentication in JSON: anonymous vs. guest user

2011-09-15 Thread fossil-m...@h-rd.org 


On Tue, Sep 13, 2011 at 10:30 AM, Alaric Snell-Pym
wrote:


by context, but it might be worth including JSON and human-HTML versions
of each URL, like so:

{
  ...stufff about a commit...
  "parents" : {
 "" : { "json" : "http://..json";, "html"
: "http://...html"; },
 "" : { "json" : "http://..json";, "html"
: "http://...html"; }
  }
}



I think including links etc. gets baroque pretty fast, and different  
use cases require different links.  It may be better in the long run  
to simply add a kind of template mechanism to the server.  This is  
explained on p. 297 in "Effective Tcl/Tk Programming" by M. Harrison  
and M. McLennan.  Basically the client sends a request giving a  
template and the data it wants.  This allows each client to get fossil  
data in the format the client needs, with just the data fields it  
needs.  So a client could request just the title of a ticket, or just  
the contents.


http://.../ticket.json&{"title"+:+$title} as an example


___
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 tutorial - Oct 25 in Manassas VA

2011-09-15 Thread Richard Hipp 
On Thu, Sep 15, 2011 at 8:28 AM, Steve Bennett wrote:

> On 15/09/2011, at 1:42 AM, Richard Hipp wrote:
>
> I'm schedule to give a 3.5 hour in-depth tutorial on Fossil on Tuesday, Oct
> 25 from 09:00 to 12:30 in Manassas VA as part of the 2011 Tcl/Tk
> conference.  See http://www.tcl.tk/community/tcl2011/schedule.html for
> schedule and registration information.  In addition to usual high-level
> information about the history and usage of DVCSes in general and Fossil in
> particular, I plan to go into detail about the internal data structures,
> code organization, and file format for Fossil, with the idea of equipping
> users with behind-the-scenes information that will help them to make more
> effective use of Fossil, and to better understand why Fossil behaves the way
> it does.
>
>
> That's great. I'm going to be giving a presentation on Jim Tcl for the main
> conference.
> Are you staying for the conference, or are you only going to be there on
> the Tuesday?
>

I might after to leave early on Friday, but I should be around for most of
the technical sessions.  Look forward to meeting you there!


>
> Cheers,
> Steve
>
>--
> µWeb: Embedded Web Framework - http://uweb.workware.net.au/
> WorkWare Systems Pty Ltd
> W: www.workware.net.au  P: +61 434 921 300
> E: ste...@workware.net.au   F: +61 7 3391 6002
>
>
>
>
>
>
> ___
> 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] authentication in JSON: anonymous vs. guest user

2011-09-15 Thread Stephan Beal 
On Thu, Sep 15, 2011 at 2:32 PM, fossil-m...@h-rd.org
wrote:

> I think including links etc. gets baroque pretty fast, and different use


i think i would have used the word "painful", but baroque is more colorful.


> cases require different links.  It may be better in the long run to simply
> add a kind of template mechanism to the server.  This is explained on p. 297
> in "Effective Tcl/Tk Programming" by M. Harrison and M. ...
> http://.../ticket.json&{"**title"+:+$title} as an example


That's an interesting idea. In principal there's nothing stopping us from
experimenting with multiple approaches, and we can, to a large degree,
implement them side by side until we settle on something we like.

Right now i'm trying to get the "easy requests" out of the way, and they
have straightforward/non-controversial structures, but eventually questions
like the above will need to be answered before we can start implementing
client apps based on the JSON API.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Has any fossil user ever experienced a SHA1 collision?

2011-09-15 Thread jos van kesteren 
Dear fellow fossil-users ?

As we all know, SHA1 and its successor algorithms are specifically
designed to make collisions
not just improbable, but very very very improbable.

However, there are a lot of fossil users doing lots and lots of
commits and other stuff that
involves lots and lots of SHA1 calculations, so we could look at
fossil not just as being a DVCS,
but also as a kind of SHA1 collision search engine :-)

Just for the sake of my curiosity;
is there any fossil user out there who has encountered a SHA1 collision ?

Does fossil contain code to cope with such a situation ?

( Yes, I know that there are a couple of dedicated machines out there
burning lots of CPU-cycles
in search of such a collision, but maybe they can't find it just
because they look too hard :-) )

Cheers,

JvK
___
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] conflict between HTML5 and Fossil

2011-09-15 Thread Joshua Paine 

On 9/15/2011 8:16 AM, Stephan Beal wrote:

(Granted, i don't honestly believe that any existing browsers will
remove the TT tag or the A.TARGET attribute, but they are officially
deprecated.)


"The target attribute for the a and area elements is no longer 
deprecated, as it is useful in Web applications, e.g. in conjunction 
with iframe." 


Deprecating 'target' was a mistake of xhtml and html 4--it's back in 
html 5. (In fact, there's official support for the target attribute on 
more elements!) In contrast, tt and other purely presentational tags and 
attributes are not just deprecated but out completely.


--
Joshua Paine
LetterBlock: Web Applications Built With Joy
http://letterblock.com/
301-576-1920
___
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] Has any fossil user ever experienced a SHA1 collision?

2011-09-15 Thread Stephan Beal 
On Thu, Sep 15, 2011 at 2:54 PM, jos van kesteren
wrote:

> Just for the sake of my curiosity;
> is there any fossil user out there who has encountered a SHA1 collision ?
>

Almost 4 years with fossil (nearly every day) and never noticed a
collision.

According to wikipedia, there has never been a collision discovered in sha1
(and i didn't write that article ;), but there is a "theoretical attack"
listed:

http://en.wikipedia.org/wiki/SHA-1

If that is indeed still the case, and people have actively been searching
for duplications, then "very very unlikely" still holds ;).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] conflict between HTML5 and Fossil

2011-09-15 Thread Stephan Beal 
On Thu, Sep 15, 2011 at 3:12 PM, Joshua Paine wrote:

> "The target attribute for the a and area elements is no longer deprecated,
> as it is useful in Web applications, e.g. in conjunction with iframe." <
> http://www.w3.org/TR/html5-**diff/ >
>

Doh, that means i lied to everyone at work in my "intro to html5"
presentation a few weeks ago :/.


> Deprecating 'target' was a mistake of xhtml and html 4--it's back in html
> 5. (In fact, there's official support for the target attribute on more


It was a huge mistake. The idea was apparently that scripting could replace
it, but there are different policy/security restrictions with scripts
opening new windows than there are with anchors opening them.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] authentication in JSON: anonymous vs. guest user

2011-09-15 Thread fossil-m...@h-rd.org 

Hi,

the template approach in my last post could also be used for the wsdl  
stuff mentioned in another thread about json.




___
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] conflict between HTML5 and Fossil

2011-09-15 Thread Konstantin Khomoutov 
On Thu, 15 Sep 2011 14:16:23 +0200
Stephan Beal  wrote:

> And now something which has nothing to do with JSON...
> 
> i noticed yesterday (via a comment in one of the tickets) that fossil
> now sends an HTML5 doctype. That's all fine and good, but the wiki
> does not actually play well as-is with HTML5. In v5 several features
> wiki authors rely on are deprecated, e.g. the TT tag, align options,
> and several other things are now (=v5) officially delegated to CSS.
> Fossil strips out all but a small subset of element properties (CSS
> styles get removed).
I think the problem is really rooted in the wiki markup which is too
simplistic for any real use beyond one-sentence notes.
I'm not in position to weigh high-profile solutions like
the proposed intergation of a markdown parser (which itself is not
without irritating warts), but at least having something like *this* for
this and `this` for what-span-attribute-currently-replaces
this would be really nice to have.
___
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] Has any fossil user ever experienced a SHA1 collision?

2011-09-15 Thread Konstantin Khomoutov 
On Thu, 15 Sep 2011 14:54:19 +0200
jos van kesteren  wrote:

> As we all know, SHA1 and its successor algorithms are specifically
> designed to make collisions
> not just improbable, but very very very improbable.
> 
> However, there are a lot of fossil users doing lots and lots of
> commits and other stuff that
> involves lots and lots of SHA1 calculations, so we could look at
> fossil not just as being a DVCS,
> but also as a kind of SHA1 collision search engine :-)
Just look at the size of the Linux kernel repository which uses SHA-1
for everything as well.
No signs of detected collisions so far reported from the Linux team.
There are other monstrous projects using DVSC, Firefox, for instance.
No signs of detected collisions also.
The list can be continued, I suppose.
___
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] Has any fossil user ever experienced a SHA1 collision?

2011-09-15 Thread Dmitry Chestnykh 
On Sep 15, 2011, at 2:54 PM, jos van kesteren wrote:
> 
> Just for the sake of my curiosity;
> is there any fossil user out there who has encountered a SHA1 collision ?

Nope. You'd hear about it in the news :-)

There's a theoretical collision attack at 2^51 operations (instead of the ideal 
2^80),
but it's a specific attack (which means that you're specifically trying to 
craft two messages
that give the same hash), and if I'm not mistaken, the probability of 
collisions from a
"good" source (not specifically crafted) is still the same as before the attack.

--
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] Has any fossil user ever experienced a SHA1 collision?

2011-09-15 Thread Dmitry Chestnykh 
On Sep 15, 2011, at 2:54 PM, jos van kesteren wrote:
> 
> Just for the sake of my curiosity;
> is there any fossil user out there who has encountered a SHA1 collision ?

Nope. You'd hear about it in the news :-)

There's a theoretical collision attack at 2^51 operations (instead of the ideal 
2^80),
but it's a specific attack (which means that you're specifically trying to 
craft two messages
that give the same hash), and if I'm not mistaken, the probability of 
collisions from a
"good" source (not specifically crafted) is still the same as before the attack.

--
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] Has any fossil user ever experienced a SHA1 collision?

2011-09-15 Thread Richard Hipp 
On Thu, Sep 15, 2011 at 8:54 AM, jos van kesteren
wrote:

> Dear fellow fossil-users ?
>
> As we all know, SHA1 and its successor algorithms are specifically
> designed to make collisions
> not just improbable, but very very very improbable.
>

Using the "birthday paradox", I calculated last year that for the SQLite
repository, if it continues to change and evolve at the same rate it has for
the previous 10 years, will encounter its first SHA1 collision in
approximately 3.6e20 years - or about 26 billion times longer than the
current estimate for the age of the universe.  By that point, the SQLite
repository database file will have grown to about 5e28 bytes or about 5
million billion terabytes.

-- 
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] Has any fossil user ever experienced a SHA1 collision?

2011-09-15 Thread Stephan Beal 
On Thu, Sep 15, 2011 at 4:34 PM, Richard Hipp  wrote:

> On Thu, Sep 15, 2011 at 8:54 AM, jos van kesteren <
> josvankeste...@gmail.com> wrote:
>
>> Dear fellow fossil-users ?
>> not just improbable, but very very very improbable.
>
>
> ...repository database file will have grown to about 5e28 bytes or about 5
> million billion terabytes.
>

So i think we need a few more "very"s in that description ;)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Has any fossil user ever experienced a SHA1 collision?

2011-09-15 Thread Ron Aaron 


On 09/15/2011 05:34 PM, Richard Hipp wrote:
>
> Using the "birthday paradox", I calculated last year that for the
> SQLite repository, if it continues to change and evolve at the same
> rate it has for the previous 10 years, will encounter its first SHA1
> collision in approximately 3.6e20 years

Oh, sure -- but what will you do then?
___
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: numerous open trunk leaves

2011-09-15 Thread Martin S. Weber 

Hey fellow archaeologists,

I was just wondering: how did fossil end up with all these distinct open 
leaves of the same branch? If you look at our leaves display here:


http://fossil-scm.org/index.html/leaves

And do a search for "tags: trunk", you should find six instances of trunk 
leaves:

http://fossil-scm.org/index.html/info/b344d3c0cd
http://fossil-scm.org/index.html/info/9503a9152e
http://fossil-scm.org/index.html/info/b41feab774
http://fossil-scm.org/index.html/info/0072bfefd2
http://fossil-scm.org/index.html/info/4c931047ef
http://fossil-scm.org/index.html/info/4ba7b9c288

How'd that happen? Can/Should the open leaves 2-6 be closed?

:-?

-Martin
___
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: numerous open trunk leaves

2011-09-15 Thread Dmitry Chestnykh 
> How'd that happen? Can/Should the open leaves 2-6 be closed?

Speaking of cleanup, what about removing the following files from trunk?

kktodo.wiki
rse-notes.txt
ci_cvs.txt
ci_fossil.txt
cvs2fossil.txt

--
Dmitry Chestnykh

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] JSON/wiki: what info needs to be returned for...

2011-09-15 Thread Stephan Beal 
Hi, all!

Now that logging in works, i'd like to start tackling some of the bigger
fish...

For /json/wiki/list requests, what page info needs to be returned?

i was thinking:

name, sizeInBytes (as opposed to size in UTF8 chars), name of last
committer, artifact ID

i'm not sure i can get the committers name easily, but the rest should be
easy to do.

Is there info i've overlooked here?

Note that the content will not be returned with the 'list' request because
the point of this request is to get just the list of pages. The content can
be arbitrarily large and will be fetched via a separate wiki/get request.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] JSON login demo: is this interface acceptable?

2011-09-15 Thread Ron Wilson 
On Wed, Sep 14, 2011 at 6:40 PM, Stephan Beal  wrote:
> Hi, all!
> Just implemented...
> Request:
> GET: /json/login?n=name&p=pass
> Param names "n" and "p" are for compatibility with the current usage, and
> may optionally be written out as "name" and "password".
> or POST: /json/login
> POST request body: { "payload":{"name":"...", "password":"..."} }
> (POSTed login data doesn't land in the apache logs, so it's highly
> preferred!)

For the password on GET, you could mimic what HTTP-Auth-Digest does.

Instead of sending the password in plain text, you hash the password
with a nonce received from the server. Of course, to get the nonce,
you have to attempt to login without supplying credentials. The server
would then respond with a payload containing the nonce to use in the
hash.

One way to generate the nonce would be to concatenate the date, time,
IP address and a random number, then hash the result.
___
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] authentication in JSON: anonymous vs. guest user

2011-09-15 Thread Ron Wilson 
On Thu, Sep 15, 2011 at 8:32 AM, fossil-m...@h-rd.org
 wrote:
> I think including links etc. gets baroque pretty fast, and different use
> cases require different links.  It may be better in the long run to simply
> add a kind of template mechanism to the server.  This is explained on p. 297
> in "Effective Tcl/Tk Programming" by M. Harrison and M. McLennan.  Basically
> the client sends a request giving a template and the data it wants.  This
> allows each client to get fossil data in the format the client needs, with
> just the data fields it needs.  So a client could request just the title of
> a ticket, or just the contents.

Yes, I think t would be a simple way to get a lot of flexibility.

A simplification on templates would be a list of fields in the desired
order. Since most of the JSON responses would be lists of fields and
their values, this would achieve nearly all that templates could.
(True, some fields do have complex values, but a field list should be
simple to implement and would be a good next step)
___
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] JSON/wiki: what info needs to be returned for...

2011-09-15 Thread Ron Wilson 
On Thu, Sep 15, 2011 at 6:20 PM, Stephan Beal  wrote:
> For /json/wiki/list requests, what page info needs to be returned?
> i was thinking:
> name, sizeInBytes (as opposed to size in UTF8 chars), name of last
> committer, artifact ID
> i'm not sure i can get the committers name easily, but the rest should be
> easy to do.
> Is there info i've overlooked here?

Actually, Fossil fetches wiki pages by name. Artifact Id would be used
to fetch a specific version of a page.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users