Curious if anyone has more details on this. Does it have encryption?
Fossil chat has the advantages that (1) it is fully encrypted and (2) it works from any web-browser, including on mobile phones.
I suppose the encryption is only at the TLS layer?
Correct unless the fossil repository in question uses SQLite's SEE (encryption) extension (which fossil can, but relatively few repositories use that, AFAIK).
That said, to the best of my knowledge git-lfs operates upon stdin and stdout, like much of git, so I'd guess you could actually just commit the tracking file and manually run $(git-lfs scrub) et al. I do hear that "manually run" isn't the same as the way it works in git, but that's why fossil does things the fossil way
"may be aborted if a file contains content that appears to be binary, Unicode text, or text with CR/LF line endings unless the interactive user chooses to proceed. If there is no interactive user or these warnings should be skipped for some other reason, the --no-warnings option may be used."
I use fossil and checking in binaries works beautifully. You _do_ get a warning, but as seen in the documentation, you can use --no-warnings if you don't want that.
Note however, that you can't use diff on binaries, and since the entire history of the repository and the versions is shipped to all developers, storing large binaries quickly becomes cumbersome. I would in that case, store links to binaries, which themselves are stored in an archive, or switch to another scm program.
Note however, that you can't use diff on binaries, [...]
fossil diff --command "compare"
As for storing binaries, unversioned files have no history, and are not synced automatically.
But then I'm old and still use perl for small stuff, so probably not reading the room....
One of the best ways.
See also, Lua.
SELECT passwd, photo FROM user WHERE uid=$uid
No, at least not if you put the SQL inside of {...}, which IIRC the documentation strongly recommends.
The $uid is passed down into SQLite. It is a single token recognized by the SQL parser itself. It does not get expanded by TCL. The $uid token serves the same roll as a "?" or ":abc" token would in some other SQL implementations. It is a placeholder for a value. The tclsqlite3.c interface first parses the SQL, then asks for the names of all of the placeholder tokens. Then it binds the values in TCL variables of the same name to those placeholders.
Indeed, this whole mechanism is specifically designed to make it easy to write SQL-injection-free code. As long as you put your SQL inside of {...}, you are completely safe from SQL injections.
If your TCL script includes SQL text inside of "...", then TCL will do the expansion and SQL injection is possible. But as long as the SQL text is inside of {...}, SQL injection is not possible.
% set ex1 "SELECT * FROM FOO WHERE alpha=$bravo"
can't read "bravo": no such variable
% set ex2 "SELECT * FROM FOO WHERE alpha=?1"
SELECT * FROM FOO WHERE alpha=?1
Haha, didn't know that. That's cool.
While most of this looks cool, the stuff about parsing vdbe.c's switch cases and assigning opcodes seems a little too much for my taste.
mdaniel•5mo ago
https://en.wikipedia.org/wiki/Modified_condition/decision_co...
https://shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001-tm2108... (This tutorial provides a practical approach to assessing modified condition/decision coverage (MC/DC) for aviation software products that must comply with regulatory guidance for DO-178B level A software)