| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
same batch run.
1 microsecond delay is ugly.. but, maintaining an queue of a list of timestamps
and taking a new one from the queue each time around, or maintaining a timestamp
counter, would probably be slower.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Old stm lacks isFullTMQueue.
To avoid needing to update stm on the Android autobuilder, I switched to
a TBMQueue. It never needs to be closed, but the overhead is minimal.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Since https://github.com/aristidb/aws/issues/206 is resolved, this
constraint is no longer necessary. However, http-conduit (>=2.2.0)
requires http-client (>=0.5.0) which introduces some breaking changes.
This commit also implements those changes depending on the version.
Fixes: https://git-annex.branchable.com/bugs/Build_with_aws_head_fails/
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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 "
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Avoid crashing when built w/o inotify..
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
10 seemed too low because more than 10 friends could be linked to a repo
over tor, and if all were running the remotedaemon, which makes a
persistent connection for change notification, then the 11th friend
would not be able to access that repo.
100 might be too low, but it's a much larger group of people. And at
that size group, it probably makes sense to structure the network so
that 100 peers are not all trying to access one central node.
|
| | |
|
| |
|
|
|
|
| |
This is more efficient. Note that the peer will get CHANGED messages for
all refs changed since the connection opened, even if those changes
happened before it sent NOTIFYCHANGE.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The attacker could just send a very lot of data, with no \n and it would
all be buffered in memory until the kernel killed git-annex or perhaps OOM
killed some other more valuable process.
This is a low impact security hole, only affecting communication between
local git-annex and git-annex-shell on the remote system. (With either
able to be the attacker). Only those with the right ssh key can do it. And,
there are probably lots of ways to construct git repositories that make git
use a lot of memory in various ways, which would have similar impact as
this attack.
The fix in P2P/IO.hs would have been higher impact, if it had made it to a
released version, since it would have allowed DOSing the tor hidden
service without needing to authenticate.
(The LockContent and NotifyChanges instances may not be really
exploitable; since the line is read and ignored, it probably gets read
lazily and does not end up staying buffered in memory.)
|
| | |
|
| | |
|
| |
|
|
|
| |
This does not change behavior, because an exception is thrown on
unsuccessful removal. But is clearer.
|
| | |
|
| | |
|
| | |
|
Joey Hess
grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f
0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730
Alper Nebi Yasak
alpernebbi