| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
To prevent any further mistakes like 1a497cefb47557f0b4788c606f9071be422b2511
This commit was sponsored by Francois Marier on Patreon.
|
| |
|
|
|
|
|
|
| |
This reverts commit 6aa7e136b5d246228723f4c9996bda11f66c4445.
On second thought, this was an overcomplication of what should be the
lowest-level primitive. Let's build bi-directional links at the pairing
level with eg magic wormhole.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both the local and remote git repositories get remotes added
pointing at one-another.
Makes pairing twice as easy!
Security: The new LINK command in the protocol can be sent repeatedly,
but only by a peer who has authenticated with us. So, it's entirely safe to
add a link back to that peer, or to some other peer it knows about.
Anything we receive over such a link, the peer could send us over the
current connection.
There is some risk of being flooded with LINKs, and adding too many
remotes. To guard against that, there's a hard cap on the number of remotes
that can be set up this way. This will only be a problem if setting up
large p2p networks that have exceptional interconnectedness.
A new, dedicated authtoken is created when sending LINK.
This also allows, in theory, using a p2p network like tor, to learn about
links on other networks, like telehash.
This commit was sponsored by Bruno BEAUFILS on Patreon.
|
| |
|
|
|
|
|
| |
Seems that git upload-pack outputs a "ONCDN " that is not read by the
remote git receive-pack. This fixes:
[2016-12-09 17:08:32.77159731] P2P > ERROR protocol parse error: "ONCDN "
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added to change notification to P2P protocol.
Switched to a TBChan so that a single long-running thread can be
started, and serve perhaps intermittent requests for change
notifications, without buffering all changes in memory.
The P2P runner currently starts up a new thread each times it waits
for a change, but that should allow later reusing a thread. Although
each connection from a peer will still need a new watcher thread to run.
The dependency on stm-chans is more or less free; some stuff in yesod
uses it, so it was already indirectly pulled in when building with the
webapp.
This commit was sponsored by Francois Marier on Patreon.
|
| | |
|
| |
|
|
|
|
|
| |
I'm unsure why this fixed it, but it did. Seems to suggest that the
memory leak is not due to a bug in my code, but that ghc didn't manage
to take full advantage of laziness, or was failing to gc something it
could have.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Display progress meter on send and receive from remote.
Added a new hGetMetered that can read an exact number of bytes (or
less), updating a meter as it goes.
This commit was sponsored by Andreas on Patreon.
|
| |
|
|
| |
This commit was sponsored by Thom May on Patreon.
|
| |
|
|
|
|
|
|
| |
This is needed in addition to StoreContent, because retrieveKeyFile can
be used to retrieve to different destination files, not only the tmp
file for a key.
This commit was sponsored by Ole-Morten Duesund on Patreon.
|
| |
|
|
|
|
|
|
|
|
| |
ReadContent can't update the log, since it reads lazily. This part of
the P2P monad will need to be rethought.
Associated files are heavily sanitized when received from a peer;
they could be an exploit vector.
This commit was sponsored by Jochen Bartl on Patreon.
|
| |
|
|
| |
This will allow updating transfer logs with the uuid.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Untested, and it does not yet update transfer logs.
Verifying transferred content is modeled on git-annex-shell recvkey.
In a direct mode or annex.thin repository, content can change while it's
being transferred. So, verification is always done, even if annex.verify
would normally prevent it.
Note that a WORM or URL key could change in a way the verification
doesn't catch. That can happen in git-annex-shell recvkey too. We don't
worry about it, because those key backends don't guarantee preservation
of data. (Which is to say, I worried about it, and then convinced myself
again it was ok.)
|
| | |
|
| | |
|
| |
|
Joey Hess