b6d46c212e
* unannex, uninit: Avoid committing after every file is unannexed,
for massive speedup.
* --notify-finish switch will cause desktop notifications after each
file upload/download/drop completes
(using the dbus Desktop Notifications Specification)
* --notify-start switch will show desktop notifications when each
file upload/download starts.
* webapp: Automatically install Nautilus integration scripts
to get and drop files.
* tahoe: Pass -d parameter before subcommand; putting it after
the subcommand no longer works with tahoe-lafs version 1.10.
(Thanks, Alberto Berti)
* forget --drop-dead: Avoid removing the dead remote from the trust.log,
so that if git remotes for it still exist anywhere, git annex info
will still know it's dead and not show it.
* git-annex-shell: Make configlist automatically initialize
a remote git repository, as long as a git-annex branch has
been pushed to it, to simplify setup of remote git repositories,
including via gitolite.
* add --include-dotfiles: New option, perhaps useful for backups.
* Version 5.20140227 broke creation of glacier repositories,
not including the datacenter and vault in their configuration.
This bug is fixed, but glacier repositories set up with the broken
version of git-annex need to have the datacenter and vault set
in order to be usable. This can be done using git annex enableremote
to add the missing settings. For details, see
http://git-annex.branchable.com/bugs/problems_with_glacier/
* Added required content configuration.
* assistant: Improve ssh authorized keys line generated in local pairing
or for a remote ssh server to set environment variables in an
alternative way that works with the non-POSIX fish shell, as well
as POSIX shells.
# imported from the archive
83 lines
4.3 KiB
Markdown
83 lines
4.3 KiB
Markdown
For git-annex to be able to clone its repo to another host, it'd be good to
|
|
have some way of pairing devices.
|
|
|
|
## security
|
|
|
|
Pairing uses its own network protocol, built on top of multicast UDP.
|
|
|
|
It's important that pairing securely verifies that the right host is being
|
|
paired with. This is accomplied by having a shared secret be entered on
|
|
both the hosts that will be paired. Hopefully that secret is communicated
|
|
securely out of band.
|
|
|
|
(In practice, the security of that communication will vary. To guard against
|
|
interception, each pairing session pairs exactly two hosts and then forgets
|
|
the shared secret. So an attacker who tries to reuse an intercepted secret
|
|
will not succeed in pairing. This does not guard against an intercepted
|
|
secret that is used before the legitimate parties finish pairing.)
|
|
|
|
Each host can construct messages that the other host can verify using the
|
|
shared secret, and so know that, for example, the ssh public key it
|
|
received belongs to the right host and has not been altered by a man in the
|
|
middle.
|
|
|
|
The verification works like this: Take a HMAC SHA1 checksum of the message,
|
|
using the shared secret as the HMAC key. Include this checksum after the
|
|
message. The other host can then do the same calculation and verify the
|
|
checksum.
|
|
|
|
Additionally, a UUID is included in the message. Messages that are part of
|
|
the same pairing session all share a UUID. And all such messages should
|
|
be verifiable as described above. If a message has the same UUID but is
|
|
not verifiable, then someone on the network is up to no good. Perhaps
|
|
they are trying to brute-force the shared secret. When this is detected,
|
|
the pairing session is shut down. (Which would still let an attacker
|
|
DOS pairing, but that's not a very interesting attack.)
|
|
|
|
The protocol used for pairing consists of 3 messages, a PairReq, and
|
|
PairAck, and a PairDone. Let's consider what an attacker could accomplish
|
|
by replaying these:
|
|
|
|
* PairReq: This would make the webapp pop up an alert about an incoming
|
|
pair request. If the user thought it was real and for some reason
|
|
entered the right shared secret used in the real one earlier, the
|
|
ssh key inside the PairReq would be added to `authorized_keys`. Which
|
|
allows the host that originally sent the PairReq to access its git
|
|
repository, but doesn't seem to do the attacker any good.
|
|
* PairAck: If the host that originally sent
|
|
the PairReq is still pairing, it'll add the ssh key from the PairAck,
|
|
and start syncing, which again does the attacker no good.
|
|
* PairDone: If the host that sent the PairAck is still syncing, it'll
|
|
add the ssh key from the PairDone, and start syncing, and stop
|
|
sending PairAcks. But probably, it's not syncing, because it would have
|
|
seen the original PairDone.. and anyway, this seems to do the attacker no
|
|
good.
|
|
|
|
So replay attacks don't seem to be a problem.
|
|
|
|
So far I've considered security from a third-party attacker, but either the
|
|
first or second parties in pairing could also be attackers. Presumably they
|
|
trust each other with access to their files as mediated by
|
|
[[git-annex-shell]]. However, one could try to get shell access to the
|
|
other's computer by sending malicious data in a pairing message. So the
|
|
pairing code always checks every data field's content, for example the ssh
|
|
public key is rejected if it looks at all unusual. Any control characters
|
|
in the pairing message cause it to be rejected, to guard against console
|
|
poisoning attacks. Furthermore, git-annex is careful not to expose data to
|
|
the shell, and the webapp uses Yesod's type safety to ensure all user input
|
|
is escaped before going to the browser.
|
|
|
|
## TODO
|
|
|
|
* pairing over IPV6 only networks does not work. Haskell's
|
|
`network-multicast` library complains "inet_addr: Malformed address: ff02::1"
|
|
.. seems it just doesn't support IPv6. The pairing code in git-annex
|
|
does support ipv6, apart from this, it's just broadcasting the messages
|
|
that fails. (Pairing over mixed networks is fine.)
|
|
* If there are three assistants on the network, and 2 pair, the third is
|
|
left displaying a "Pair request from foo" alert, until it's close.
|
|
Or, if the user clicks the button to pair, it'll get to the
|
|
"Pairing in progress" alert, which will show forever (until canceled).
|
|
|
|
It should be possible for third parties to tell when pairing is done,
|
|
but it's actually rather hard since they don't necessarily share the secret.
|