On Oct 10, 2018, at 2:42 PM, Keith Medcalf <kmedc...@dessus.com> wrote:
>
> On Wednesday, 10 October, 2018 14:08, Warren Young wrote:
>
>> On Oct 10, 2018, at 1:26 PM, Keith Medcalf <kmedc...@dessus.com> wrote:
>
>> The “security code” is just a CAPTCHA
>
> I hate captcha's and will not use them. They require permitting unrestricted
> third-party code to execute on MY computer.
Fossil CAPTCHAs do not run any code on your computer. It’s static HTML, with
the CAPTCHA text generated by and validated on the server.
I believe it is possible to use Fossil forums without JavaScript, though there
are some other areas of the Fossil UI that will definitely break. The timeline
page, the file browser, the WYSIWYG wiki editor, and the hamburger menu all
rely on JavaScript to work.
I ran NoScript for many years, but I gave that battle up as lost years ago.
The “unrestricted” bit is an overreach besides. Browser JavaScript is highly
restricted in what it can do.
> Granted in this case it is not a third-party captcha that requires permitting
> third-party code to execute, but that is likely just a happenstance of the
> moment.
I’m sure drh wrote the Fossil CAPTCHA system with full intent. It did not just
happen.
I don’t expect that code to be replaced until someone bothers to write a bot
that interprets it. It wouldn’t be hard to do that, but since that code has
been in use since 2009, even if this happened tomorrow, that CAPTCHA’s given us
a pretty good return on the effort invested:
https://fossil-scm.org/fossil/file?fn=src/captcha.c&ci=trunk
>> Contrast this mailing list, which *does* require that you create YET
>> ANOTHER PASSWORD:
>
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
> If you choose not to enter a password, one will be automatically generated
> for you, and it will be sent to you once you've confirmed your subscription.
> You can always request a mail-back of your password when you edit your
> personal options.
That’s pretty much how Fossil forums’ subscriber feature works.
A password generation feature sounds like a fine idea for Fossil, too. Patches
thoughtfully considered.
As for password recovery, that’s already on the wish list. We have the
technology to implement it within Fossil, we just need someone to choose to
take the time to write it.
> it is probably subject to all sorts of stupidity which prevents the use of
> cryptographically generated passwords
Fossil currently has no restrictions on password length[1] or content. The
input text is simply salted, hashed, and inserted into the user table:
https://fossil-scm.org/fossil/file?udc=1&ln=385-395&filename=src%2Fuser.c
I’ve tested this in a local repository by setting user’s password to and
successfully logging in with these passwords:
1. “a”
2. 63 random printable ASCII characters
3. 5 paragraphs of HTML-formatted Lorem Ipsum text
The salt is the project code combined with the user ID, not a secret per-user
salt. Both of those values are publicly visible, but it does defeat rainbow
table attacks, which is the main point of salting.
[1]: Okay, okay, there technically is a limit on length. Several, in fact:
1. If you’re setting the password via Fossil UI, I think you’ll hit the browser
POST limit first. This is probably in the gigs for mainstream browsers on
64-bit hosts.
2. If you’re setting the password via “fossil user password”, the limit is the
host OS’s getpass(3) limit, which is 128 bytes on the machine I’m typing this
on. With ~6 bits of entropy per ASCII printable character, that exceeds the
power of the hash function we use in the Fossil user table by about 600 bits.
3. Fossil’s Blob type, which receives the password. It uses an unsigned int to
hold the size. It’s possible the code isn’t 64-bit clean, in which case it’s
probably limited to 2^31-1 bytes or so. Otherwise, it’s the size of available
virtual memory.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
