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
29 lines
1.7 KiB
Markdown
29 lines
1.7 KiB
Markdown
Currently [[xmpp]] relies on the SSL connection to the server for security.
|
|
The server can see git repository data pushed through it. (Also, the SSL
|
|
connection is not pinned or really checked well at all.)
|
|
|
|
Add an encryption layer that does not rely on trusting the XMPP server's
|
|
security. There are a few options for how to generate the key for eg,
|
|
AES encryption:
|
|
|
|
* Do a simple Diffie-Hellman shared key generation when starting each XMPP
|
|
push session. Would not protect the users from active MITM by the
|
|
XMPP server, but would prevent passive data gathering attacks from
|
|
getting useful data. Since the key is ephemeral, would provide
|
|
Forward Security.
|
|
* Do D-H key generation, but at pairing, not push time. Allows for an
|
|
optional confirmation step, using eg, BubbleBabble to compare the
|
|
keys out of band. ("I see xebeb-dibyb-gycub-kacyb-modib-pudub-sefab-vifuc-bygoc-daguc-gohec-kuxax .. do you too?")
|
|
* Prompt both users for a passphrase when XMPP pairing, and
|
|
use SPEKE (or similar methods like J-PAKE) to generate a shared key.
|
|
Avoids active MITM attacks. Makes pairing harder, especially pairing
|
|
between one's own devices, since the passphrase has to be entered on
|
|
all devices. Also problimatic when pairing more than 2 devices,
|
|
especially when adding a device to the set later, since there
|
|
would then be multiple different keys in use.
|
|
* Rely on the user's gpg key, and do gpg key verification during XMPP
|
|
pairing. Problimatic because who wants to put their gpg key on their
|
|
phone? Also, require the users be in the WOT and be gpg literate.
|
|
|
|
Update: This seems unlikely to be worth doing. [[Telehash]] is better.
|
|
--[[Joey]]
|