Stephan Beal wrote:
> After a _filesystem_ error, fossil cannot trust anything. Throwing it away
> is as good as not, IMO. Had it NOT thrown it away, someone (quite possibly
> you!!!) would have complained that a useless, half-completed file was
> laying around.
When redoing an operation is fast,
The branching.wiki page gives an example of a trunk branch with the ⌜trunk⌝
name, and a test branch from it that cancels the ⌜trunk⌝ name and adds the
⌜test⌝ name.
I can't think of any cases where it would make sense to have a branch X without
the name ⌜X⌝ or with the name ⌜Y⌝ where Y is anothe
This is with Fossil 1.29.
root@helpme:/mnt/hgfs/emacs# time git fast-export --all | fossil import --git
emacs.fossil
[A few hours later:]
Rebuilding repository meta-data...
[A day later:]
100.0% complete...
Vacuuming...
[A couple hours later:]
SQLITE_IOERR: os_unix.c:27527: (5) ftruncate(/mnt/h
Andy Bradford wrote:
>> Instead of sha1, use something like a 160-bit version of xxhash, which
>> is 10-20 times faster than a secure hash, and has no more risk of
>> collision than does the latter, assuming you don't commit malicious
>> people's data.
>
> The use of SHA1 is detailed here:
Joerg Sonnenberger wrote:
> If you don't pull from malicious users, it doesn't happen. If you do,
> you already have bigger problems. What you want just makes things slower
> for no good reason.
You're right, if you don't commit malicious people's data, then there's no
problem. But in that case,
Ron W wrote:
> So, you are asking for an option to enable an automatic, post-commit
> "fossil diff $@" (where $@ is the list of files just committed)?
Yes. And it needs to compare the contents, not just compare hashes as a
shortcut.
For a simple implementation, it can just unconditionally compar
Joerg Sonnenberger wrote:
> Either the hash is broken AND you have
> allowed untrusted third parties to write to your repository or not.
> In your scenario, you have already lost at the point where you allow
> untrusted third parties near the the repository, so the strength of the
> hash function i
I wrote:
> B. (13.3·10^9 years per eon) / (2^66.7 days) → 2^33 eons.
Er, that's 2^24.6 eons. (Forgot to divide by days/year.)
Unless you're a young-Earth creationist, in which case it's 2^45.6 eons.
___
fossil-users mailing list
fossil-users@lists.fossi
Ron W wrote:
> As I understand the Fossil sync protocol, if the remote side offers
> something whose ID matches the ID of something the local Fossil already
> has, the local Fossil will decline it.
Which means if the attacker wins the race to offer you an artifact, then your
local Fossil will dec
Joerg Sonnenberger wrote:
>> If you have files foo and bar with different content but the same hash
>> (i.e. there's a hash collision), and you commit foo, then bar, and
>> dedup by hash (which Fossil does, just like Git), then do a checkout
>> and try to verify by checking the hashes, you'll be fo
Richard Hipp wrote:
> Homework problem: Suppose 100 developers each make 100 file changes
> every day on the same fossil repository. So 10,000 new hashes enter
> the repository every day. (A) Compute the expected time until the
> first SHA1 hash collision is encountered. (B) Rewrite the answer
Stephan Beal wrote:
>> If you allow me to push anything into your repository (even just pushing
>> bug reports; you don't have to trust me), and I can find a hash preimage
>
> Prove it can happen first ;). It's a theoretical problem with (AFAIK) no
> proven attack
Are you referring to finding a pr
Stephan Beal wrote:
>> #0 alone make the Z-card redundant.
>
> The Z-card is a separate check on the manifests contents, and isn't
> actually its blob hash
[snip]
> The Z-card serves not to identify the checkin, but to validate that the
> manifest itself has not changed since it was created.
I und
Richard Hipp wrote:
> The monotone people addressed this concern over a decade ago:
> http://www.monotone.ca/docs/Hash-Integrity.html
The monotone page says:
⌜the vulnerability is not that the hash might suddenly cease to address benign
blocks well, but merely that additional security precautions
Joerg Sonnenberger wrote:
> I have no idea who Valerie Hansen is or why I should care about him.
As Richard Hipp pointed out, I misspelled her name. It was ‟Henson” (now
‟Aurora”).
(Head hung in shame.)
Anyway I was being facetious with the ‟because Valerie said so” remark.
> Comparing by conte
Stephan Beal wrote:
> The justification i remember hearing[1] when i asked about it was that the
> md5 is faster, and therefore was chosen for the (expensive) R-card
> calculation. Right or wrong, it's how it is and cannot be changed without
> manifest format chantes.
But if the R-card is optional
Stephan Beal wrote:
> Fossil separates the names and "body" of a file, and any number of files
> may refer to the same blob body. The zlib-level compression is part of the
> implementation, not explicitly accounted for anywhere in the model.
[snip]
> Manifests are themselves stored as blobs, so the
Baruch Burstein wrote:
> Syncing the exact same content again won't cause any harm (other then
> needles work done by the server to process it)
In that case, it would be useful to point out on the password.wiki page that a
nonce is unnecessary, rather than incorrectly saying that the hash of the
http://www.fossil-scm.org/index.html/doc/tip/www/selfcheck.wiki says:
⌜Note that these added checks use a different hash (MD5 instead of SHA1) in
order to avoid common-mode failures in the hash algorithm implementation.⌝
That makes no sense. To avoid common-mode failures in the implementation, yo
Git does compare-by-hash. This is a mistake, because Valerie Hansen said so. It
seems Fossil makes the same mistake. If the hash function is broken, you're
hosed, and you don't know until it's too late. The checks described at
selfcheck.wiki don't detect it.
ZFS provides a dedup=verify option i
Attached below.
Also, the second hunk of the diff at delta_format.wiki doesn't look like it
changes anything.
BTW, qandc.wiki says the exe is less than 1MB. But I'm getting over 5MB when I
compile it. I vaguely remember the explanation being documented somewhere, but
I don't remember where.
-
Stephan Beal wrote:
>> Fossil tries to keep the storage of content a separate matter from the
>> content itself, but doesn't fully succeed.
>
> Yes and no. It uses sqlite (the storage) to do a lot of the work, but the
> manifests contain all the raw metadata needed _except_ for the mapping of
> UUI
Andy Bradford wrote:
> I can set up all kind of QoS on my firewall, but most devices don't
> allow one to request random and routine packet loss and actual
> connection resets (e.g. TCP/IP RST packets) as part of the QoS settings.
> ;-)
Just hurl a few gratuitous insults at some bor
I haven't tried this, or looked at the code. I'm just going by the description
at:
https://www.fossil-scm.org/index.html/doc/tip/www/password.wiki
In the ‟Sync Protocol Authentication” section, it calls the sha1 hash of the
request content a ‟nonce”. But that isn't a nonce; if the client were to
Andy Bradford wrote:
> This explanation seems to fit the facts, but
> reproducing it is a pain.
>
> Let me see if I can cause what I've just stated above to happen.
Just ask your ISP or network administrator to lower your quality of service, or
try using wifi while a large number of microwave ov
Andy Bradford wrote:
> were you presented with a certificate to accept
No.
> is it transparent or does Fossil know it's using a proxy?
It's transparent. Firefox works fine through it (both HTTP and HTTPS), and ssh
works fine through it. Except that it's slow and tends to drop packets and
ra
Whoever kept trying and failing to download my fossil-src files using MSIE 8.0
an hour ago, and only got 153600 bytes each time... try a better browser.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-
Andy Bradford wrote:
> Any chance you can use --httptrace when cloning with whatever is causing
> this problem? --httptrace will leave behind a handful of .txt files
> beginning with http- which have the requests and replies Fossil makes.
Problem not reproducible at the moment.
>> -rw-r--r--
Andy Bradford wrote:
> If the connection times out
> then I would expect the whole operation to fail and the repository be
> deleted.
That's horrible. You have to re-download the entire repository if one packet is
lost at the end?
> I'm curious what Fossil would do with one of the partial cl
Fossil says the artifact list is supposed to be append-only, but it also has
clusters as artifacts that are discardable. This is conceptually suboptimal.
Fossil tries to keep the storage of content a separate matter from the content
itself, but doesn't fully succeed. The manifest is an essential
--- fileformat.wiki
+++ fileformat.wiki
@@ -95 +95 @@
-make up a fossil repository are stored in in as delta- and zlib-compressed
+make up a fossil repository are stored as delta- and zlib-compressed
@@ -214 +214 @@
-The target is preceeded by "+" or "-" to show inclusion or
+The target is preceded
Yesterday I tried Fossil for the first time.
Using 1.29:
# fossil clone https://www.fossil-scm.org/ fossil-src.fossil
Round-trips: 2 Artifacts sent: 0 received: 3073
Clone finished with 3113 bytes sent, 1850717 bytes received
Rebuilding repository meta-data...
100.0% complete...
project-id:
a
32 matches
Mail list logo
