SQLite Windows GUI alternative to Excel?

classic Classic list List threaded Threaded
65 messages Options
1234
cl
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

cl
Warren Young <[hidden email]> wrote:

> On Oct 10, 2018, at 11:23 AM, Tim Streater <[hidden email]> wrote:
> >
> > On 10 Oct 2018, at 18:10, Warren Young <[hidden email]> wrote:
> >
> >> On Oct 10, 2018, at 10:39 AM, Eric <[hidden email]> wrote:
> >>>
> >>> * mailing lists come to me, I don't have to go and get them
> >>
> >> So do Fossil email alerts.
> >
> > So there's an unecessary email I've just received telling me to go to the forum.
>
> Fossil forum email alerts include the full content of the message.

And can you then simply 'reply' from your E-Mail client?  If not then
it doesn't really help much.

--
Chris Green
·

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Warren Young
On Oct 10, 2018, at 11:51 AM, Chris Green <[hidden email]> wrote:
>
> Warren Young <[hidden email]> wrote:
>> Fossil forum email alerts include the full content of the message.
>
> And can you then simply 'reply' from your E-Mail client?  If not then
> it doesn't really help much.

I already addressed that up-thread.  The next version of Fossil is likely to include a fully-capable SMTP server, which among other things will allow email submissions, in principle at least.  I have no idea if drh intends to actually write code to allow that.

I opined up-thread that such submissions will be subject to moderation, unconditionally, due to the ease with which From addresses can be forged via email.  Contrast Fossil forums, where positive identity checks are made before accepting a new post from someone.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Petite Abeille-2


> On Oct 10, 2018, at 8:31 PM, Warren Young <[hidden email]> wrote:
>
> The next version of Fossil is likely to include a fully-capable SMTP server

Zawinski's Law at work! :D

“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
http://www.catb.org/jargon/html/Z/Zawinskis-Law.html


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Petite Abeille-2
In reply to this post by Warren Young


> On Oct 10, 2018, at 8:31 PM, Warren Young <[hidden email]> wrote:
>
> addresses can be *forged*

forged fɔːdʒd/ adjective • copied fraudulently; fake.

Ohhhhhhhh nooooo! :(

Perhaps the time has come for you to learn the gory details of that so-called 'Simple Mail Transfer Protocol'! :)

Simple, but mighty.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Keith Medcalf
In reply to this post by Warren Young

On Wednesday, 10 October, 2018 12:31, Warren Young <[hidden email]> wrote:

>On Oct 10, 2018, at 11:51 AM, Chris Green <[hidden email]> wrote:

>> Warren Young <[hidden email]> wrote:

>>> Fossil forum email alerts include the full content of the message.

>> And can you then simply 'reply' from your E-Mail client?  If not
>> then it doesn't really help much.

>I already addressed that up-thread.  The next version of Fossil is
>likely to include a fully-capable SMTP server, which among other
>things will allow email submissions, in principle at least.  I have
>no idea if drh intends to actually write code to allow that.

>I opined up-thread that such submissions will be subject to
>moderation, unconditionally, due to the ease with which From
>addresses can be forged via email.  Contrast Fossil forums, where
>positive identity checks are made before accepting a new post from
>someone.

There is almost no difference between authentication of e-mail and the authentication of snail-mail.  Generally one will find that the *same* people have trouble authenticating both snail-mail and e-mail, and for exactly the same reason -- they have no idea what it is that they are doing.  These people generally have HTML enabled and do stupid things like "Ooooh, the pretty pictures look nice, so it must be authentic".  This is not an issue inherent in e-mail but rather an issue inherent in the inability of the "authenticators" to have any idea of what it is that they are doing.  (They also authenticate snail-mail by judging the prettyness of the pictures).

In other words, the same triviality applies to all manner of falisification and in ALL CASES the proof-of-veracity is the same.  Most people simply cannot be bothered to authenticate e-mail (nor snail-mail either) and blame this on the medium rather than on their own stupidity and lazyness.

Furthermore, there is also absolutely no way to perform "positive identity checks" on a web page post that cannot be equally trivially falsified.  And if you think that I am going to create YET ANOTHER LOGIN and YET ANOTHER PASSWORD just to use some crappy forum software, you have another think coming.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Warren Young
On Oct 10, 2018, at 1:26 PM, Keith Medcalf <[hidden email]> wrote:
>
> there is also absolutely no way to perform "positive identity checks" on a web page post that cannot be equally trivially falsified.

You’re conflating physical identity with forum identity.

I don’t care whether you have state-approved documentation proving that your name is Keith Medcalf.  What I care to prevent is some spammer sending messages to the forum or to members of the forum directly, in your name, just because he happens to know your email address, which is trivially obtained.

> And if you think that I am going to create YET ANOTHER LOGIN and YET ANOTHER PASSWORD just to use some crappy forum software, you have another think coming.

Once again, Fossil forums don’t require that you create a login and password:

    https://fossil-scm.org/forum/subscribe

You fill out that form, hit Submit, and click the link in the validation email.  No password anywhere.

The “security code” is just a CAPTCHA, and proves that you can read the ASCII hex code below the form, which so far is a pretty good test for being a human, rather than a bot.

Contrast this mailing list, which *does* require that you create YET ANOTHER PASSWORD:

   http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

I think I can summarize the real objection to this plan quite simply: nobody likes to have their cheese moved.  But cheese moves nevertheless.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Eric-2
In reply to this post by Warren Young
On Wed, 10 Oct 2018 11:10:24 -0600, Warren Young <[hidden email]> wrote:
> On Oct 10, 2018, at 10:39 AM, Eric <[hidden email]> wrote:
>>
>> * mailing lists come to me, I don't have to go and get them
>
> So do Fossil email alerts.

Do they thread? Anyway I have to go and get context, and go elsewhere to
reply.

>> * mailing lists all work the same
>
> No, they don't. There are many different mailing list managers, each
> with different subscription methods, unsubscription methods, password
> requirements, commands, etc. On top of that, the popular mailing list
> managers are highly configurable, so you can't even say that all GNU
> Mailman mailing lists work the same.

None of which matters on a day-to-day basis - you read emails and you
answer them.

>> no multiple forum URLs

> …but multiple mailing list manager URLs instead.

See previous answer.

>> passwords
>
> Fossil forum subscribers don't need a password ...

OK, but one or two "forums" among many - I prefer to have a password
anyway.

>> * context usually exists within each email, no need to jump around the
>>   interface
>
> When was the last time you used a mail client without threading?
> Mail messages are *rarely* entirely self-contained.

Depends on what you mean by "entirely". If you can tell what the first
sentence is actually talking about, that's often enough context.
"Entirely" is not necessary.

> And when they are, it's usually because you're looking at some
> monstrosity perpetrated by those who like untrimmed top-posting, so that
> every past message is listed below the new content, in reverse order.

I spent too many hours of my working life reading those, but they're not
really relevant here.

>> * mailing lists are easy to read selectively and/or skim read
>
> Yes, just like Fossil email alerts.

I haven't seen an alert yet, unless it looks exactly like a normal
single-message email!

>> * I can keep my own (possibly selective) archive
>
> You can clone a Fossil forum repository, if the forum's administrator
> allows it.  The fossil-scm.org/forum allows it, so presumably the future
> sqlite.org/forum will as well.

Too much overhead, how often must I clone ...

> As for selective archives, Fossil will let you delete content from a repository:
>
>     https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki
>
> This includes forum posts.

Too tedious, and also seems like misuse of a feature, in which case it
is the potential start of a slippery slope.

> What non-accidental differences do you have in your local SQLite mailing
> list archive as compared to those on the public mailing list archive
> services?

Only that mine starts when I first subscribed to the list, and is
partial if I wanted it that way. And it's local!

> This line of argument also ignores the opposite virtue: with Fossil
> forums, it is easy to get a complete archive of past discussions without
> having been a subscriber since the beginning.

If I want something from outside the time when I was subscribed, I will
have to go looking, but this is pretty rare. Unless I'm looking for the
solution to a problem, in which case I will do a web search.

> Even if you do happen to be on mailing lists from the start, are your
> local mail backups complete?  I'm pretty sure I've lost old mailing
> list archives in moves from one client to another.  That can't happen
> with Fossil, due to the durability of its block chain technology.

Unless you lose the whole thing :-) I have an older archive (always
partial) which is a set of mbox files, and a newer one (always complete)
which is a maildir, and they go back a long time. They are always backed
up and independent of whatever mail reader I happen to be using at the
moment.

>> searchable across all lists
>
> Do you often find yourself unable to remember where you posted something,
> and thus wouldn't know which forum to search for a given post, and thus
> must search all of them?
>
> It's happened to me, but only very rarely.  Usually I end up doing an
> Internet search for my own name and relevant keywords, which would also
> turn up Fossil forums content.

There are overlapping "forums", and OT threads, so it happens fairly
often, and anyway I have only one search interface for each of my
archives, each of which covers multiple "forums".

>> I never get around to looking at most of the
>> forums, partly, of course, because there isn't time.
>
> It's no faster to open a mail client than it is to open a folder full
> of forum bookmarks and scan their contents.

Yes it is, it's always open. And no need to dig for the password or
struggle with how the particular interface works.

> Fossil forums are especially nice in this regard, since there is currently
> no subforum feature, so you don't have to go digging through them
> to find out what's new.  The forum's front page lists new posts in
> newest-first order, with the unread posts in a brighter hyperlink color.

"Currently"? You don't want subforums, there's a good search, and it
might be reasonable to allow tagging posts.

Eric
--
ms fnd in a lbry

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Keith Medcalf
In reply to this post by Warren Young
On Wednesday, 10 October, 2018 14:08, Warren Young wrote:

>On Oct 10, 2018, at 1:26 PM, Keith Medcalf <[hidden email]>
>wrote:

>> there is also absolutely no way to perform "positive identity
>checks" on a web page post that cannot be equally trivially
>falsified.

>You’re conflating physical identity with forum identity.

>I don’t care whether you have state-approved documentation proving
>that your name is Keith Medcalf.  What I care to prevent is some
>spammer sending messages to the forum or to members of the forum
>directly, in your name, just because he happens to know your email
>address, which is trivially obtained.

But they cannot do that anyway.  That is because e-mail coming from me must be contained within an envelope which properly authenticates.  If the "inside contents" of the envelope purport to come from me but those contents are contained in an envelope which did not come from me, then your assumption of the validity of the contents of the envelope is your own assinine stupid assumption.

Again, you should learn how to authenticate mail (whether the old fashioned paper in an envelope variety or the new electronic body in an electronic envelope variety).  That you do not know how to do this is not really my problem.

>> And if you think that I am going to create YET ANOTHER LOGIN and
>YET ANOTHER PASSWORD just to use some crappy forum software, you have
>another think coming.

>Once again, Fossil forums don’t require that you create a login and
>password:

>    https://fossil-scm.org/forum/subscribe

>You fill out that form, hit Submit, and click the link in the
>validation email.  No password anywhere.

>The “security code” is just a CAPTCHA, and proves that you can read
>the ASCII hex code below the form, which so far is a pretty good test
>for being a human, rather than a bot.

I hate captcha's and will not use them.  They require permitting unrestricted third-party code to execute on MY computer.  This I do not permit.  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.

>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.

Doesn't sound like a password I have to (a) use or (b) remember.  I have very few passwords.  There are many cryptographically generated ones that I do not care about.

On the other hand, if one wants to post to your "forum" other than anonymously, one must create a userid and password, remember that password, and it is probably subject to all sorts of stupidity which prevents the use of cryptographically generated passwords (such as requirements to change the password, restrictions on password length and content, etc).  I am not interested in doing that.  There are very VERY few instances in which I am interested in doing that.

>I think I can summarize the real objection to this plan quite simply:
>nobody likes to have their cheese moved.  But cheese moves
>nevertheless.



---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Eric-2
In reply to this post by Warren Young
On Wed, 10 Oct 2018 14:08:11 -0600, Warren Young <[hidden email]> wrote:
8>< --------

> I think I can summarize the real objection to this plan quite simply:
> nobody likes to have their cheese moved.  But cheese moves nevertheless.

Cheese does not move, it gets moved. Even in the face of reasoned
arguments. You have chosen to write an answer to everything, but they
obviously do not all convince all of us. Based on what others have said,
the SQLite list may lose some worthwhile contributors (not trying to
include myself in that category).

But then it doesn't matter if you marginalise only a small number of
people.

Eric
--
ms fnd in a lbry
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Warren Young
In reply to this post by Eric-2
On Oct 10, 2018, at 2:36 PM, Eric <[hidden email]> wrote:
>
> On Wed, 10 Oct 2018 11:10:24 -0600, Warren Young <[hidden email]> wrote:
>> On Oct 10, 2018, at 10:39 AM, Eric <[hidden email]> wrote:
>>>
>>> * mailing lists come to me, I don't have to go and get them
>>
>> So do Fossil email alerts.
>
> Do they thread?

They do in Apple Mail, which is the only thing I’ve tested it in.  

If Fossil email alerts aren’t threading properly in your mailer, let us know which one it is, so we can see what additional headers Fossil might need to send.

Here’s the code that appends the In-Reply-To header when the message isn’t the first in a thread:

   https://fossil-scm.org/fossil/artifact?udc=1&ln=2120-2123&name=e66cf827047a9b39

Incidentally, I invite Keith to switch that page into “blame” mode and look at the user name column before yelling about “some crappy forum software” again.

> go elsewhere to reply.

The plan is to finish the SMTP server implementation in Fossil, which will allow email submission, among other things.

My understanding is that finishing the Fossil SMTP server is high on drh's to-do list, but I don’t suppose he’d be all that upset if someone else contributed the work.  A good bit of the code is already in place, so you have a good starting point:

    https://fossil-scm.org/fossil/file?fn=src/smtp.c&ci=trunk

>> Fossil forum subscribers don't need a password ...
>
> OK, but one or two "forums" among many - I prefer to have a password
> anyway.

Fossil lets you do it either way, because Fossil makes a distinction between users and subscribers:

   https://fossil-scm.org/fossil/doc/trunk/www/alerts.md#uvs

A subscriber-only user has no password, but also has no identity to the server other than the long hex subscriber code they can uniquely present to the server to adjust their subscription settings.  They can read the forum and get alerts, but they can only post anonymously.

If you want a named identity on the Fossil forum, you have to sign up as a user, and then you do need to manage a password.  That’s probably a good thing, since users have more power in the repository.  Users can be granted the ability to post without going through moderation, for example.

>>> * mailing lists are easy to read selectively and/or skim read
>>
>> Yes, just like Fossil email alerts.
>
> I haven't seen an alert yet, unless it looks exactly like a normal
> single-message email!

If you have "To unsubscribe: https://fossil-scm.org/forum/unsubscribe” and other stuff in the footer of the email, that’s a Fossil alert email.

If you aren’t getting those, visit

   https://fossil-scm.org/forum/subscribe

If that doesn’t redirect you to /alerts, you aren’t subscribed to email alerts yet.

>>> * I can keep my own (possibly selective) archive
>>
>> You can clone a Fossil forum repository
>
> Too much overhead, how often must I clone …

You must clone only once per machine where you want the clone to exist.

To automatically update that clone, add something like this to your user’s crontab:

    42 2 * * * /usr/local/bin/fossil all sync

That updates all Fossil repositories known to your local Fossil installation, based on values stored in a SQLite database that Fossil keeps in $HOME/.fossil.

Since the SQLite source code is also managed by Fossil, you might want to have a clone of that repository as well anyway.  The “fossil all sync” command will keep that up-to-date as well.

>> As for selective archives, Fossil will let you delete content from a repository:
>
> Too tedious

I agree, but then, I don’t see why I’d bother to weed my forum archives in the first place.  I *want* a complete archive.

In fact, I’m eagerly waiting for drh to get around to importing the past mailing list traffic into the forum, so I can stop going to mail-archive.com, etc.

> it's local!

So is a Fossil forum repo clone.  Say

    $ fossil ui -R /path/to/fossil-forum.fossil

to open the forum clone in your default web browser.  The result will look an awful lot like what you see at https://fossil-scm.org/forum, because it’s running the same code, from a very nearly identical repository.

The only differences in the public instance’s repository are a few categories of info purposely not synced with the clone:

1. The user table, for security and PII reasons.

2. Certain local-only settings, such as the ones involved in the email server configuration, so that each clone doesn’t try to send email alerts on each new forum post, too.

Over time, a clone and the repo it cloned from can diverge in other ways.  For example, changes to the skin aren’t automatically sync’d down, on purpose, since you may have local changes you want to keep.  You can pull such changes down on demand with the “fossil conf pull” commands.  You might therefore want to follow the “fossil all sync” command with a “fossil all conf pull all” command, if the local machine never has local-only configuration changes.

> Unless I'm looking for the
> solution to a problem, in which case I will do a web search.

…which will get you one result for each matching post from The Mail Archive, one from Gmane, one from Nabble…

Isn’t it better to search one archive directly?

>> That can't happen
>> with Fossil, due to the durability of its block chain technology.
>
> Unless you lose the whole thing :-)

   “Only wimps use tape backup. REAL men just upload their important stuff on ftp and let the rest of the world mirror it.”

   — Linus Torvalds

Times have changed a bit, so it’s GitFosCurial instead of FTP and CloudBlazeBox instead of tape, but you get the idea.

The Fossil forum repository is mirrored in at least six different places to my personal knowledge.  I wouldn’t be surprised if I’m off by at least an order of magnitude of the number of actual regularly-synchronized clones.

> no need to dig for the password

Again, you don’t need a password at all if you’re a Fossil subscriber only.

Fossil could do better about letting a user — distinct from a “subscriber” — stay logged in.  One particular weakness is that it only allows one active IP at a time, so if you log in from two different locations, then go back to the first location, you have to log back in.

Patches to fix that will be thoughtfully considered, and probably eagerly applied. ;)

> struggle with how the particular interface works.

We’re also open to suggestions and patches for that.  The interface has improved markedly over the past few months of development.

>> Fossil forums are especially nice in this regard, since there is currently
>> no subforum feature, so you don't have to go digging through them
>> to find out what's new.  The forum's front page lists new posts in
>> newest-first order, with the unread posts in a brighter hyperlink color.
>
> "Currently"? You don't want subforums, there's a good search, and it
> might be reasonable to allow tagging posts.

Here’s the relevant thread if you want to catch up on the conversation we’ve had on that topic already:

  https://fossil-scm.org/forum/forumpost/ba1144bc9f

Maybe you have new ideas to contribute.  Or better, patches.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Warren Young
In reply to this post by Keith Medcalf
On Oct 10, 2018, at 2:42 PM, Keith Medcalf <[hidden email]> wrote:
>
> On Wednesday, 10 October, 2018 14:08, Warren Young wrote:
>
>> On Oct 10, 2018, at 1:26 PM, Keith Medcalf <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Random Coder
On Wed, Oct 10, 2018 at 3:45 PM Warren Young <[hidden email]> wrote:
> Fossil currently has no restrictions on password length[1] or content.  The input text is simply salted, hashed, and inserted into the user table:
> [...]
> 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.

This does not prevent new rainbow tables from being generated, and since:

https://fossil-scm.org/fossil/file?udc=1&ln=436-441&filename=src%2Fsha1.c

You're using a single iteration of the (technically insecure) hash
function to generate the password, creating a rainbow table is much
less computationally hard than if a modern password hashing function
had been used.

I'd be curious if someone's taken the effort to setup hashcat with
your rule set and see how quickly it can brute force it's way to the
plaintext.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Darren Duncan
In reply to this post by cl
On 2018-10-10 10:51 AM, Chris Green wrote:
> Warren Young <[hidden email]> wrote:
>> Fossil forum email alerts include the full content of the message.

That's great!  Especially if the alert email subject includes the forum thread
subject.

That said, I consider it critical that these alert emails can also send my own
posts in the forum and not just others.  If they don't send for EVERY post, the
emails aren't suitable for reading / backing up a thread in one place.

> And can you then simply 'reply' from your E-Mail client?  If not then
> it doesn't really help much.

Actually it helps a lot.  I think in practice most people using this forum would
be reading a lot more than they post.  So you can do your majority action of
reading in your email client with the forum alerts.  In the rare situation where
you want to reply, then you just switch over to the web forum.  (And assuming
you then get a copy back in your email, so its like you wrote it with email.)

-- Darren Duncan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Darren Duncan
In reply to this post by Keith Medcalf
On 2018-10-10 12:26 PM, Keith Medcalf wrote:
> And if you think that I am going to create YET ANOTHER LOGIN and YET ANOTHER PASSWORD just to use some crappy forum software, you have another think coming.

What do you think password managers are for?  Proper security means having a
different password everywhere that uses passwords, and one presumably already
has dozens or more of those, so if they use a password manager, the SQLite forum
is just another one it automatically handles. -- Darren Duncan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Darren Duncan
In reply to this post by Eric-2
On 2018-10-10 1:36 PM, Eric wrote:
> Too much overhead, how often must I clone ...

This makes me think that it would be useful, if it doesn't already, for Fossil
to have something analogous to a database replication feature.  A bit like a
mailing list but that the sender and client are both instances of Fossil. --
Darren Duncan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Keith Medcalf
In reply to this post by Darren Duncan

On Thursday, 11 October, 2018 00:22, Darren Duncan <[hidden email]> wrote:
>On 2018-10-10 12:26 PM, Keith Medcalf wrote:

>> And if you think that I am going to create YET ANOTHER LOGIN and
>> YET ANOTHER PASSWORD just to use some crappy forum software, you have
>> another think coming.

> What do you think password managers are for?  

You mean the equivalent of sticky-notes on the monitor?  Sorry, do not use them, ever.

> Proper security means having a different password everywhere that uses
> passwords, and one presumably already has dozens or more of those,
> so if they use a password manager, the SQLite forum is just another
> one it automatically handles. -- Darren Duncan

There are only a very small number of passwords that are to useful things.  Those are remembered and not written down or stored anywhere.  There are a lot of "junk" passwords which are merely generated.  Many of the latter have "stupid" rules, but even so if they are compromised, who gives a crap?  Having a requirement to "change" or other idiotic composition rules automatically puts the password in the latter camp.

So do you intend the forum password to be one of the former or one of the latter?

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
cl
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

cl
In reply to this post by Darren Duncan
Darren Duncan <[hidden email]> wrote:

> On 2018-10-10 10:51 AM, Chris Green wrote:
> > Warren Young <[hidden email]> wrote:
> >> Fossil forum email alerts include the full content of the message.
>
> That's great!  Especially if the alert email subject includes the forum thread
> subject.
>
> That said, I consider it critical that these alert emails can also send my own
> posts in the forum and not just others.  If they don't send for EVERY post, the
> emails aren't suitable for reading / backing up a thread in one place.
>
> > And can you then simply 'reply' from your E-Mail client?  If not then
> > it doesn't really help much.
>
> Actually it helps a lot.  I think in practice most people using this forum would
> be reading a lot more than they post.  So you can do your majority action of
> reading in your email client with the forum alerts.  In the rare situation where
> you want to reply, then you just switch over to the web forum.

Yes, and there lies the rub, it's a window-swapping, mouse clicking
hassle.  If it was a mailing list I'd simply hit L[ist reply] and that
would be it.

--
Chris Green
·

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Eric-2
In reply to this post by Warren Young
On Wed, 10 Oct 2018 16:00:02 -0600, Warren Young <[hidden email]> wrote:
8>< --------

There comes a point in any written discussion where point-by-point
answers become a risk to sanity. I think we are there.

It seems that a Fossil forum will someday be able to behave like a mailing
list. Good, but if the price is moderation for everything that comes in
by email, then I won't be happy without seeing the moderation guidelines.

I will still prefer mailing lists.

In the post I am now answering you have told me several things I
already know, and missed the point a couple of times. That is merely
an observation, I can't claim to never miss the point.

I contributed to Fossil in the early days, until Richard moved it out of
GPL. I didn't object to that per se, but the then contributor agreement
was something I could not sign. The current one is OK, but I'm doing
too many other things now.

>   https://fossil-scm.org/forum/forumpost/ba1144bc9f

Thanks for that link, I will read it properly.

Eric
--
ms fnd in a lbry
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Warren Young
In reply to this post by Darren Duncan
On Oct 11, 2018, at 12:26 AM, Darren Duncan <[hidden email]> wrote:
>
> On 2018-10-10 1:36 PM, Eric wrote:
>> Too much overhead, how often must I clone ...
>
> This makes me think that it would be useful, if it doesn't already, for Fossil to have something analogous to a database replication feature.

That’s pretty much what Fossil *is*: a replicated database.  Most of it happens to be blockchain structured, rather than relational table structured, but much of the table-structured data is also synchronized between a clone and its parent.

Fossil forum content is just more of the same of what Fossil already stores, so it syncs down to a clone just the same as anything else you’ve got stored in Fossil.

The only differences between a Fossil repository clone and its parent are some local-only settings and security-sensitive information such as the user table.

If you clone as a sufficiently privileged user, you can even pull down the user table.  This is useful when replicating Fossil across multiple sites for backup and site fail-over purposes.  The SQLite and Fossil project repos are currently replicated across 3 different hosts in this way.

> A bit like a mailing list but that the sender and client are both instances of Fossil.

Fossil allows you to open your local repository in a browser and insert content into the forum locally, then sync the content up to the remote repository.

That requires a user capability that had not been given to my user on the fossil-scm.org/forum instance, last I checked.  I assume that no one else but drh can do this at the moment on that instance.

However, I’ve done it on one of my own Fossil repositories, just now:

   https://tangentsoft.com/mysqlpp/forumpost/f8b7fc2ca9
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

Warren Young
In reply to this post by Random Coder
On Oct 11, 2018, at 12:06 AM, Random Coder <[hidden email]> wrote:
>
> On Wed, Oct 10, 2018 at 3:45 PM Warren Young <[hidden email]> wrote:
>> 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.
>
> This does not prevent new rainbow tables from being generated

Since part of the salt is the user name, that requires a “rainbow table” per user, which means it isn’t much of a rainbow table at all.  Basically, it devolves to a brute-force hash attack.

> You're using a single iteration of the (technically insecure) hash
> function to generate the password

If you take the faux “rainbow table” approach — which again is really just brute force in this case — the known weaknesses in SHA-1 don’t matter.  You still have to generate half of the SHA-1 possibilities on average to brute force one of these passwords.

In [one experiment][1] a single large GPU generated SHA-1 hashes at a rate of 160 million per second.  To generate 2^80 hashes (half the SHA-1 space) you’d need 4.6x10^39 seconds, or about 1.45x10^32 years.

Current top-end GPUs are about twice as fast as the one used in that experiment, and you could rack a bunch of those up, but even a time reduction of 1000x doesn’t make the attack practical.

Instead, you might try to take advantage of the SHA-1 weaknesses to generate a second preimage, which in this case amounts to a password that happens to work even though it isn’t actually the password known to the legitimate user.  I have no idea how difficult that is, but it’s probably still awfully difficult.

To pull that off, you need a copy of the user table, which is not synchronized down to clones unless you’re the Fossil “setup” user, who is all-powerful and doesn’t need to resort to such things to break into the repository in the first place.

An attacker without such privileges would have to break into the server hosting the Fossil instance, at which point he wouldn’t *need* to break the password hash: he could just modify the user table directly!


[1]: https://security.stackexchange.com/a/3450

> creating a rainbow table is much
> less computationally hard than if a modern password hashing function
> had been used.

Okay, so replace the algorithm with N-thousand rounds of PBKDF2 and whatever hash algo you like.  How does it practically change what I’ve said above?

> I'd be curious if someone's taken the effort to setup hashcat with
> your rule set

What rules?  As I said, Fossil currently has no restrictions on the password.  Fossil assumes you will use good passwords for purely selfish reasons, and don’t need to be forced to do so.

And again, hashcat is a silly way to attack Fossil.  If you have access to the Fossil user table, you can just edit the database and insert whatever hash you like.  Or, insert content directly into the block chain.  Or add users with arbitrary permissions.  Or...

The primary attack the Fossil password system fends off is the remote one, which is gated by the maximum number of password tries allowed per second.  I don’t know of any internal limits on this in Fossil, so it amounts to the maximum number of HTTP connections the host machine can process per second, which will be orders of magnitude lower than the hash rates above.

If that still bothers you, put Fossil behind an HTTP proxy and set up fail2ban on the access log.  With 5 passwords allowed per user per second, an 8 character random password takes decades to break.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
1234