Re: [fossil-users] Is Fossil Hash-collision proof?

[Warren Young]

On Mar 21, 2017, at 11:04 PM, Martin Vahi  wrote:
> 
> I haven't encountered any collisions yet

Nor are you likely to by accident, ever.

The only reason it’s even a concern is that a motivated attacker with lots of 
money could force a collision with the old SHA-1 algorithm.  It’s believed to 
be essentially impossible with the new SHA-3 algorithm.

> I was wondering, what will happen, if 2 different
> files that have the same size, same timestamps,
> different bitstreams, but the same hash (regardless of hash algorithm)
> were to be committed simultaneously, at the same commit?

There is no “simultaneously.”  SQLite has locking and transactions that prevent 
multiple simultaneous writes to the same table.  Therefore, one commit will 
happen, then the other will be rejected because Fossil says “I already have an 
artifact with that ID.”

The only known way to make use of a hash collision is to MITM the sync stream 
and substitute a bad artifact for a good one when the receiving repository 
doesn’t have the good artifact yet.  (e.g. On initial clone.)

Since even under SHA-1, a collision currently takes something like $100,000 and 
one month of compute time to produce, that means you can’t currently cause this 
to happen at all if everyone is syncing at least monthly. 

That time will shrink, but if all clients are using Fossil 2.0 or higher, even 
with SHA-1 we now have the protection of the Hardened SHA-1 algorithm, which 
closes all known holes in SHA-1 that make it possible to produce collisions 
even with $100,000 and a month of compute time.

> After all, it's the "improbable" corner cases that
> accumulate

In the case of SHA-3, we’re probably talking “not even until the heat death of 
the universe” levels of “improbable.”  You might as well worry over the 
possibility of the Sun quantum tunneling into the gap between the moon-Earth 
orbit.  Possible?  Yes.  Will it ever happen?  Not in a billion Big Bounces.

https://en.wikipedia.org/wiki/Big_Bounce

> Everything works fine for a
> long-long-long period of time, until one day, in the midst
> of being overwhelmed with some other task that
> uses software X as one of its main tools…

If you will not accept a statistical argument with cosmological odds against 
failure, what argument would you accept?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Is Fossil Hash-collision proof?

[Martin Vahi]

I haven't encountered any collisions yet, but
I was wondering, what will happen, if 2 different
files that have the same size, same timestamps,
different bitstreams, but the same hash (regardless of hash algorithm)
were to be committed simultaneously, at the same commit?

After all, it's the "improbable" corner cases that
accumulate and trash even those projects that are
not slammed together by sloppy-or-just-lacks-the-self-esteem-to-care
type of developers. Everything works fine for a
long-long-long period of time, until one day, in the midst
of being overwhelmed with some other task that
uses software X as one of its main tools...

Thank You.


___
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] Bugs in file_wd_isdir()

[Reimer Behrends]

Joe Mistachkin wrote:

Perhaps changing the exec-rel-paths setting might impact this?  Not sure 
without further research.


The bug has nothing to do with exec-rel-paths. The --command option 
simply forces the creation of a temporary directory, which is what 
triggers the bug on macOS (due to the /tmp -> private/tmp symlink).


The problem is that after blob_read_link() has been called, the code 
fails to test for a leading slash in the link and if it's a relative 
path, to properly append it to the parent directory of the source. 
Currently, file_is_wdir() simply handles relative paths in symlinks 
wrong. The code should look something like the following:


blob_read_link(, zFN); /* It exists and is a link. */
char *zLink = mprintf("%s", blob_str());
blob_reset();
if (zLink[0] != '/') {
  char *zParent = file_dirname(zFN);
  char *zLinkSave = zLink;
  zLink = mprintf("%s/%s", zParent, zLink);
  free(zLinkSave);
  free(zParent);
}
free(zFN);
zFN = zLink;

Plus, of course, guarding against infinite recursion and ignoring 
db_allow_symlinks(1) when creating temporary directories.


Reimer Behrends
___
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_v_2_0 Bug: Abandoning commit due to long lines in Foo

[Warren Young]

On Mar 21, 2017, at 5:49 PM, Martin Vahi  wrote:
> 
> I tried to commit the batch of small files
> individually. No luck:

The error tells you why:

> ...facebook.html
> contains long lines. Use --no-warnings or the "binary-glob" setting to
> disable this warning.
>Commit anyhow (a=all/y/N)?

So either:

1. Say “yes” or “all” to the query

2. Give --no-warnings with the commit command

3. Add an *.html rule to your binary-glob setting to make it skip the “looks 
like UTF-8 text” check during the commit.

That check exists because Fossil is primarily meant to store text, and the 
exceptions are generally easy to match with binary-glob rules (e.g. *.png).  
Fossil is warning that you may be committing something you didn’t mean to 
commit, like an executable.

The only reason it thinks these long-line HTML files are “binary” is that the 
“looks like UTF-8” heuristic doesn’t scan the entire file looking for newlines 
and such.  It gives up after a certain number of bytes checked, since proper 
text files rarely have very long lines.  But, all heuristics are imperfect by 
definition, which is why there are workarounds.

Fossil will store and reliably retrieve binary data.  This is one of those “are 
you sure you want to do that?” things, not a “you’re an idiot if you do that” 
things.

Fossil is second-guessing you only because binary files defeat many features of 
Fossil:

1. Many binary file types are also compressed, so that as little as one bit 
changed in the raw data format could potentially change every byte in the 
output file format, utterly defeating Fossil’s delta compression algorithm.  If 
you’re storing bitmaps, therefore, store Windows BMPs in preference to PNG or 
JPEG.  If you need PNG or JPEG outputs, generate them from the stored BMPs as 
part of the build process.

Bonus: this lets you change things like color space or transparency rules 
without re-storing all the bitmap files, simply by changing the conversion 
script.

(Incidentally, “uncompressed” bitmap formats like TIFF can also be a problem 
because they may contain metadata that changes with each save, like timestamps 
and GUIDs.  In one test I did here, changing one pixel in a TIFF image caused 
something like 10 kB of deltas in the resulting TIFF!)

2. Most binary file formats can’t be displayed in Fossil UI unless it’s one of 
a small number of well-known web file formats.  There may be an alternative 
file format that will avoid these problems and still solve the same problem, 
such as SVG instead of Adobe Illustrator format, or Markdown over PDF.  (And 
plain-text SVG over compressed SVGZ to avoid problem #1.  Let Fossil compress 
your data, so it can see inside the file.)

3. A “fossil diff” command can’t do anything useful with binary data.

4. Fossil can usually merge two changes to a single text file automatically, 
without user intervention, and when it can’t, it writes conflict data to disk 
to help you merge the files manually.  Fossil can’t help you at all if two 
users edit a binary file at the same time unless the changes are 
well-separated, and they’ll only be so if you avoid problem #1 above.

Again, none of this prevents you from storing binary files in Fossil.  They 
just give you…encouragement…to use some equivalent text based file format 
instead.

> I received a spam email that used my own subject

These emails are typically similar enough that spam filters learn about them 
pretty quickly.  About once every few months, whoever is doing this changes the 
emails enough to start slipping them through the filters again.

It’s possible that info is outdated, since I haven’t seen such spam since 
changing our company email servers over to a provider with a reputation for 
strong spam filtering with a low false positive rate.
___
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_v_2_0 Bug: Abandoning commit due to long lines in Foo

[Richard Hipp]

On 3/21/17, Martin Vahi  wrote:
>
> P.S. Right after sending my previous Bug report
> to this list, like, literally in 10 seconds,
> I received a spam email that used my own subject
> line with the "Re:" prefix as its email subject.

From "Eboni"?  I'm very sorry about this.  I wish I was able to track
down who is doing this, but I don't know how.  Eboni has been a curse
on this mailing list for a long time.

I managed to stop the Eboni porn-spam coming to me by blocking the
following IP addresses on my email server:

  144.217.94.196
  144.217.165.151
  2607:5300:201:3000::/64

Those servers are all hosed by OVH at https://www.ovh.com/us/ - to
whom I have written multiple time and who seem utterly unconcerned.
Be sure to say bad things about OVH on all your social media posts.

-- 
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] Bugs in file_wd_isdir()

[Joe Mistachkin]

Perhaps changing the exec-rel-paths setting might impact this?  Not sure 
without further research.

Sent from my iPhone
https://urn.to/r/mistachkin

> On Mar 21, 2017, at 12:50 PM, Reimer Behrends  wrote:
> 
> Richard Hipp wrote:
>> I wonder if you could provide a more concrete example of the problem,
>> perhaps in a the form of a "fossil test-file-environment" command that
>> gives an incorrect answer?
> 
> I'm afraid not. As I recall, the reason I ran into this originally was 
> because "fossil diff --checkin ..." blew up on my Mac in file_mkfolder() with 
> an "unable to create directory" error. The reason was that on macOS, /tmp is 
> a symlink to private/tmp; rather than resolving to /private/tmp, Fossil 
> resolved it to private/tmp (without a leading slash). The presence of the 
> bugs should be obvious from a code inspection, however.
> 
> Reproducing it can be a bit tricky, because "fossil diff --checkin ..." does 
> not always seem to trigger it, but providing a --command option does seem to 
> cause it fairly reliably for checkins other than the current one. Example:
> 
> [/tmp/fossil]$ ./fossil version
> This is fossil version 2.0 [1d407cff32] 2017-03-03 12:00:30 UTC
> [/tmp/fossil]$ ./fossil up version-2.0
> ---
> checkout: 1d407cff32978b6ed57138da36787d547ce6887d 2017-03-03 12:00:30 UTC
> tags: trunk, release, version-2.0
> comment:  Version 2.0 (user: drh)
> changes:  None. Already up-to-date
> [/tmp/fossil]$ ./fossil diff --checkin prev --command "diff"
> Index: src/shell.c
> ==
> unable to create directory /var
> 
> The problem is that after blob_read_link() is called, even if the result is a 
> relative path, it is directly passed to file_is_wdir() again without 
> appending it to the link's directory. This means that the code will 
> (inaccurately) try to use it relative to the current directory.
> 
> The infinite recursion occurs if there's an absolute link that links to 
> itself along the path, simply because file_wd_isdir() will call itself over 
> without having a way to terminate.
> 
> Also, the !db_allow_symlinks(1) check can prevent the code from even 
> following the /tmp -> private/tmp link in the first place, even though the 
> setting is meant only for working tree directories and files.
> 
>Reimer Behrends
> ___
> 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] Fossil_v_2_0 Bug: Abandoning commit due to long lines in Foo

[Martin Vahi]

I unpakced the stblob that I tried to commit
at the case that I described at my previous bug report
and I tried to commit the batch of small files
individually. No luck:

---citation--start

./wiki_references/2017/software/MaidSafe_net/doc/2017_03_21_wget_copy_of_blog_maidsafe_net/bonnet/blog.maidsafe.net/2013/07/25/open-source-more-freedom/index.html?share=facebook.html
contains long lines. Use --no-warnings or the "binary-glob" setting to
disable this warning.
Commit anyhow (a=all/y/N)?
Abandoning commit due to long lines in
./wiki_references/2017/software/MaidSafe_net/doc/2017_03_21_wget_copy_of_blog_maidsafe_net/bonnet/blog.maidsafe.net/2013/07/25/open-source-more-freedom/index.html?share=facebook.html
Push to
http://martin_v...@www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/
Round-trips: 1   Artifacts sent: 0  received: 0
Push done, sent: 1237  received: 334  ip: 185.7.252.74
---citation--end---


P.S. Right after sending my previous Bug report
to this list, like, literally in 10 seconds,
I received a spam email that used my own subject
line with the "Re:" prefix as its email subject.
I suspect that either spam bots have been signing
up to this mailing list or someone, who receives the
mailing lists posts individually in stead of ordering
a Digest is using some crappy, bot-infested, email
service that scrapes email addresses from
all incoming email. I know that it is not me, because
it has not happened to me with other mailing lists or
at least I haven't noticed.

___
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] Using child projects/repositories effectively

[Ross Berteig]

On 3/21/2017 6:52 AM, Richard Hipp wrote:

Apparently I checked that feature in.  But I don't remember doing it.
I do not use it myself and do not remember how it works.

Maybe you can look at the source code and figure it out, and write up
some improved documentation for us?

And some test cases?

Even just hints as to what scenarios are interesting, what should work, 
and what should not work would be helpful. That will make it easier for 
I (or one of the others who occasionally wear the testing hat) will add 
coverage of it to the test suite.


As an aside, tip of trunk currently passes all the tests in the suite 
except one (stash-1-diff) which I marked as a known bug until I get the 
test case fixed. I'm actively pushing the boundaries of our test 
coverage hoping to document edge cases, so now is a good time to bring 
up features that could use more or better testing.



On 3/21/17, John P. Rouillard  wrote:

Hi Everybody:

I am currently using a child project/repository as described
in:

   http://www.fossil-scm.org/index.html/doc/trunk/www/childprojects.wiki

In this child repo I have files that should not be pushed to
the main repo. So my locally added files, configuration file
changes etc. all happily live in the child repo.

However when I do a:

fossil pull --from-parent-project

I usually end up forking the trunk which requires a merge to
get things back in order. Is that how this is supposed to
work?  I was envisioning the parent project would be
something more like a branch that I could merge/integrate
from at will. Should I change the child project's
main-branch from "trunk" to "mainline" to reserve the trunk
tag for the parent project.

If I should rename to mainline, I have a bunch of commits in
the repo. So how do I move all the child's trunk commits to
the new mainline branch and establish the mainline branch
going forward?

Also I would like to use fossil as the method people use to
manage the software at their own sites, so understanding how
to use the child project feature effectively is a big win.

Thanks for any ideas on how to use this feature successfully.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users





--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602

___
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] Bugs in file_wd_isdir()

[Reimer Behrends]

Richard Hipp wrote:

I wonder if you could provide a more concrete example of the problem,
perhaps in a the form of a "fossil test-file-environment" command that
gives an incorrect answer?


I'm afraid not. As I recall, the reason I ran into this originally was 
because "fossil diff --checkin ..." blew up on my Mac in file_mkfolder() 
with an "unable to create directory" error. The reason was that on 
macOS, /tmp is a symlink to private/tmp; rather than resolving to 
/private/tmp, Fossil resolved it to private/tmp (without a leading 
slash). The presence of the bugs should be obvious from a code 
inspection, however.


Reproducing it can be a bit tricky, because "fossil diff --checkin ..." 
does not always seem to trigger it, but providing a --command option 
does seem to cause it fairly reliably for checkins other than the 
current one. Example:


[/tmp/fossil]$ ./fossil version
This is fossil version 2.0 [1d407cff32] 2017-03-03 12:00:30 UTC
[/tmp/fossil]$ ./fossil up version-2.0
---
checkout: 1d407cff32978b6ed57138da36787d547ce6887d 2017-03-03 
12:00:30 UTC

tags: trunk, release, version-2.0
comment:  Version 2.0 (user: drh)
changes:  None. Already up-to-date
[/tmp/fossil]$ ./fossil diff --checkin prev --command "diff"
Index: src/shell.c
==
unable to create directory /var

The problem is that after blob_read_link() is called, even if the result 
is a relative path, it is directly passed to file_is_wdir() again 
without appending it to the link's directory. This means that the code 
will (inaccurately) try to use it relative to the current directory.


The infinite recursion occurs if there's an absolute link that links to 
itself along the path, simply because file_wd_isdir() will call itself 
over without having a way to terminate.


Also, the !db_allow_symlinks(1) check can prevent the code from even 
following the /tmp -> private/tmp link in the first place, even though 
the setting is meant only for working tree directories and files.


Reimer Behrends
___
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] Using child projects/repositories effectively

[Richard Hipp]

Apparently I checked that feature in.  But I don't remember doing it.
I do not use it myself and do not remember how it works.

Maybe you can look at the source code and figure it out, and write up
some improved documentation for us?

On 3/21/17, John P. Rouillard  wrote:
>
> Hi Everybody:
>
> I am currently using a child project/repository as described
> in:
>
>   http://www.fossil-scm.org/index.html/doc/trunk/www/childprojects.wiki
>
> In this child repo I have files that should not be pushed to
> the main repo. So my locally added files, configuration file
> changes etc. all happily live in the child repo.
>
> However when I do a:
>
>fossil pull --from-parent-project
>
> I usually end up forking the trunk which requires a merge to
> get things back in order. Is that how this is supposed to
> work?  I was envisioning the parent project would be
> something more like a branch that I could merge/integrate
> from at will. Should I change the child project's
> main-branch from "trunk" to "mainline" to reserve the trunk
> tag for the parent project.
>
> If I should rename to mainline, I have a bunch of commits in
> the repo. So how do I move all the child's trunk commits to
> the new mainline branch and establish the mainline branch
> going forward?
>
> Also I would like to use fossil as the method people use to
> manage the software at their own sites, so understanding how
> to use the child project feature effectively is a big win.
>
> Thanks for any ideas on how to use this feature successfully.
>
> --
>   -- rouilj
> John Rouillard
> ===
> My employers don't acknowledge my existence much less my opinions.
> ___
> 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] Using child projects/repositories effectively

[John P. Rouillard]

Hi Everybody:

I am currently using a child project/repository as described
in:

  http://www.fossil-scm.org/index.html/doc/trunk/www/childprojects.wiki

In this child repo I have files that should not be pushed to
the main repo. So my locally added files, configuration file
changes etc. all happily live in the child repo.

However when I do a:

   fossil pull --from-parent-project

I usually end up forking the trunk which requires a merge to
get things back in order. Is that how this is supposed to
work?  I was envisioning the parent project would be
something more like a branch that I could merge/integrate
from at will. Should I change the child project's
main-branch from "trunk" to "mainline" to reserve the trunk
tag for the parent project.

If I should rename to mainline, I have a bunch of commits in
the repo. So how do I move all the child's trunk commits to
the new mainline branch and establish the mainline branch
going forward?

Also I would like to use fossil as the method people use to
manage the software at their own sites, so understanding how
to use the child project feature effectively is a big win.

Thanks for any ideas on how to use this feature successfully.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Bugs in file_wd_isdir()

[Richard Hipp]

On 3/21/17, Reimer Behrends  wrote:
> The function file_wd_isdir() seems to have a number of bugs when used
> with symbolic links. This manifests on macOS in particular (where /tmp
> links to private/tmp – note that the link is relative), when temporary
> directories are created, e.g. for "fossil diff --checkin ...".
>
> * Relative links are not properly followed. They are treated as being
> relative to the current directory, rather than the source of the symlink.
> * Symlinks pointing to themselves will trigger infinite recursion.
> * The db_allow_symlinks() logic should probably not apply to directories
> outside a checkout (such as /tmp).
>

I wonder if you could provide a more concrete example of the problem,
perhaps in a the form of a "fossil test-file-environment" command that
gives an incorrect answer?


-- 
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] Bugs in file_wd_isdir()

[Reimer Behrends]

The function file_wd_isdir() seems to have a number of bugs when used 
with symbolic links. This manifests on macOS in particular (where /tmp 
links to private/tmp – note that the link is relative), when temporary 
directories are created, e.g. for "fossil diff --checkin ...".


* Relative links are not properly followed. They are treated as being 
relative to the current directory, rather than the source of the symlink.

* Symlinks pointing to themselves will trigger infinite recursion.
* The db_allow_symlinks() logic should probably not apply to directories 
outside a checkout (such as /tmp).


Reimer Behrends
___
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_v_2_0 Bug: SQLITE_TOOBIG when Committing 1.6GiB size file

[Richard Hipp]

By recompiling with SQLITE_MAX_LENGTH=20 or so, you might be
able to get a little more size out of Fossil.  But the underlying
SQLite storage is size limited to 2GB blobs, so beyond that, Fossil
just wont work.  And it will stop being efficient long before you get
into giga-byte sized files.  Actually, the whole DVCS concept kind of
breaks down with gigabyte-sized files.  You may want to look into
using a centralized VCS, like SVN.

On 3/21/17, Martin Vahi  wrote:
>
> --citation--start-
>
> ./wiki_references/2017/software/2017_03_21_maidsafe_net_tar_gz/f59c44f4cfae80319685fc8abdbc374039c22b421141951ai_278e5c783e9d982543415b569b6095bde7f1e409077208c4bb6bc48ee3fefe3fh_0481949961s_1000v.stblob
> contains binary data. Use --no-warnings or the "binary-glob" setting to
> disable this warning.
> Commit anyhow (a=all/y/N)? all
> SQLITE_TOOBIG: statement aborts at 8: [INSERT INTO
> blob(rcvid,size,uuid,content)VALUES(53,1699491840,'7514aa336e0c015e4363859df996ee30ee81538c',:data)]
> string or blob too big
> fossil: SQL error: string or blob too big
> Push to
> http://martin_v...@www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/
> Round-trips: 1   Artifacts sent: 0  received: 0
> Push done, sent: 1234  received: 334  ip: 185.7.252.74
> --citation--end---
>
> I tried to commit
>
> (About 1.6GiB)
>
> http://temporary.softf1.com/2017/bugs/f59c44f4cfae80319685fc8abdbc374039c22b421141951ai_278e5c783e9d982543415b569b6095bde7f1e409077208c4bb6bc48ee3fefe3fh_0481949961s_1000v.stblob
>
>
> to a clone of the
>
> http://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/
>
> If You download .stblob, then
> its integrity can be checked by
>
>
> wget
> http://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/raw/milestone_releases/silktorrent_packager_t1_2017_03_14.bash?name=433efaa35a360ddcdfba723979c682975286cd83
>   --output-document=`pwd`/silktorrent_packager_t1.bash
>
> chmod 0755 ./silktorrent_packager_t1.bash
> silktorrent_packager_t1.bash verify `pwd`/.stblob
>
> The .stblob files are just plain tar-files that have
> multiple hashes(Tiger, SHA256) and their file size as part of
> their file name. For example, the start of the .stblob file
> can be generated by
>
> cp .stblob ./x.stblob # can take time for the 1.6GiB
> ruby -e "puts(ARGV[0].to_s.match(/^[abcdef\d]+/)[0].reverse)"
> `tigerdeep ./x.stblob`
>
>
> My environment:
>
> --citation--start-
> ts2@linux-0fiz:~/tmp$ uname -a
> Linux linux-0fiz 3.16.7-53-desktop #1 SMP PREEMPT Fri Dec 2 13:19:28
> UTC 2016 (7b4a1f9) x86_64 x86_64 x86_64 GNU/Linux
> ts2@linux-0fiz:~/tmp$ fossil version
> This is fossil version 2.0 [1d407cff32] 2017-03-03 12:00:30 UTC
> ts2@linux-0fiz:~/tmp$ date
> Tue Mar 21 09:34:59 EET 2017
> ts2@linux-0fiz:~/tmp$
> --citation--end---
>
>
> P.S. A bit out of topic comment, but the idea
> behind the tar-files that have their sizes and hashes
> as part of their file names is that this way even the
> No_Such_Agency/KGB/FSB/STASI/KAPO/SUPO/SÄPO can offer
> drop-box-service over Tor to anybody without having
> an ability to modify any of the files without getting
> caught. If the guys at the various intelligence agencies
> were smarter than they currently are, then they would
> understand that in the future wars are fought with robots,
> which need targets, which need target-detection, which
> takes a lot of computing power to do if 3D models of
> battle fields are calculated bit-hospital-MRI-style from
> radar images and drones that have to stay up long and be
> light can not carry energy hungry computers that are stacked
> in piles in data centers and special data-center-warships,
> meaning: the https://en.wikipedia.org/wiki/Utah_Data_Center
> would be one of the first targets for China/Russia/whomever,
> but if the Utah datacenter offered an economically relevant
> drop-box service or something similar to the
> https://www.clockss.org/
> to everybody, including Chinese/Russian/European/whoeverElse
> businesses and governments, then sending a rocket to the
> Utah data center would hurt the adversary's own businesses.
> After all: the most important service of the nasty
> European_Union/Brussles bureaucracy is to keep Europe in piece
> by using economic inter-dependencies. But, of course, hoping
> that a huge giga-government-bureaucracy, like the Washington is,
> would thing that strategically, specially given, how the last
> presidential elections in the U.S. were won, is a really tall order :-/
>
> Anyways, Thank You for reading. That was just the background story
> that answers the question, how can something as primitive as
> plain tar-files with hashes in their names be of any huge,
> strategic, importance :-)
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> 

[fossil-users] Fossil_v_2_0 Bug: SQLITE_TOOBIG when Committing 1.6GiB size file

[Martin Vahi]

--citation--start-

./wiki_references/2017/software/2017_03_21_maidsafe_net_tar_gz/f59c44f4cfae80319685fc8abdbc374039c22b421141951ai_278e5c783e9d982543415b569b6095bde7f1e409077208c4bb6bc48ee3fefe3fh_0481949961s_1000v.stblob
contains binary data. Use --no-warnings or the "binary-glob" setting to
disable this warning.
Commit anyhow (a=all/y/N)? all
SQLITE_TOOBIG: statement aborts at 8: [INSERT INTO
blob(rcvid,size,uuid,content)VALUES(53,1699491840,'7514aa336e0c015e4363859df996ee30ee81538c',:data)]
string or blob too big
fossil: SQL error: string or blob too big
Push to
http://martin_v...@www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/
Round-trips: 1   Artifacts sent: 0  received: 0
Push done, sent: 1234  received: 334  ip: 185.7.252.74
--citation--end---

I tried to commit

(About 1.6GiB)

http://temporary.softf1.com/2017/bugs/f59c44f4cfae80319685fc8abdbc374039c22b421141951ai_278e5c783e9d982543415b569b6095bde7f1e409077208c4bb6bc48ee3fefe3fh_0481949961s_1000v.stblob


to a clone of the

http://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/

If You download .stblob, then
its integrity can be checked by


wget
http://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/raw/milestone_releases/silktorrent_packager_t1_2017_03_14.bash?name=433efaa35a360ddcdfba723979c682975286cd83
  --output-document=`pwd`/silktorrent_packager_t1.bash

chmod 0755 ./silktorrent_packager_t1.bash
silktorrent_packager_t1.bash verify `pwd`/.stblob

The .stblob files are just plain tar-files that have
multiple hashes(Tiger, SHA256) and their file size as part of
their file name. For example, the start of the .stblob file
can be generated by

cp .stblob ./x.stblob # can take time for the 1.6GiB
ruby -e "puts(ARGV[0].to_s.match(/^[abcdef\d]+/)[0].reverse)"
`tigerdeep ./x.stblob`


My environment:

--citation--start-
ts2@linux-0fiz:~/tmp$ uname -a
Linux linux-0fiz 3.16.7-53-desktop #1 SMP PREEMPT Fri Dec 2 13:19:28
UTC 2016 (7b4a1f9) x86_64 x86_64 x86_64 GNU/Linux
ts2@linux-0fiz:~/tmp$ fossil version
This is fossil version 2.0 [1d407cff32] 2017-03-03 12:00:30 UTC
ts2@linux-0fiz:~/tmp$ date
Tue Mar 21 09:34:59 EET 2017
ts2@linux-0fiz:~/tmp$
--citation--end---


P.S. A bit out of topic comment, but the idea
behind the tar-files that have their sizes and hashes
as part of their file names is that this way even the
No_Such_Agency/KGB/FSB/STASI/KAPO/SUPO/SÄPO can offer
drop-box-service over Tor to anybody without having
an ability to modify any of the files without getting
caught. If the guys at the various intelligence agencies
were smarter than they currently are, then they would
understand that in the future wars are fought with robots,
which need targets, which need target-detection, which
takes a lot of computing power to do if 3D models of
battle fields are calculated bit-hospital-MRI-style from
radar images and drones that have to stay up long and be
light can not carry energy hungry computers that are stacked
in piles in data centers and special data-center-warships,
meaning: the https://en.wikipedia.org/wiki/Utah_Data_Center
would be one of the first targets for China/Russia/whomever,
but if the Utah datacenter offered an economically relevant
drop-box service or something similar to the
https://www.clockss.org/
to everybody, including Chinese/Russian/European/whoeverElse
businesses and governments, then sending a rocket to the
Utah data center would hurt the adversary's own businesses.
After all: the most important service of the nasty
European_Union/Brussles bureaucracy is to keep Europe in piece
by using economic inter-dependencies. But, of course, hoping
that a huge giga-government-bureaucracy, like the Washington is,
would thing that strategically, specially given, how the last
presidential elections in the U.S. were won, is a really tall order :-/

Anyways, Thank You for reading. That was just the background story
that answers the question, how can something as primitive as
plain tar-files with hashes in their names be of any huge,
strategic, importance :-)



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