blob: bde1e59d1f321bd52365a972db17a0692e5e66fc (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
Fixed a bug where the locked down ssh key that the assistant sets up to
access the annex on a remote server was being used by ssh *by default* for
all logins to that server.
That should not have happened. The locked down key is written to a filename
that ssh won't use at all, by default. But, I found code in gnome-keyring
that watches for `~/.ssh/*.pub` to appear, and automatically adds all such
keys to the keyring. In at least some cases, probably when it has no other
key, it then tells ssh to go ahead and use that key. Astounding.
To avoid this, the assistant will store its keys in `~/.ssh/annex/`
instead. gnome-keyring does not look there (verified in the source).
If you use gnome-keyring and have set up a repository on a remote server
with the assistant, I'd recommend moving the keys it set up and editing
`~/.ssh/config` to point to their new location.
gnome-keyring is not the only peice of software that has a bad
interaction with git-annex. I've been working on a bug that makes git-annex
fail to authenticate to ejabberd. ejabberd 2.1.10 got support for
SCRAM-SHA-1, but its code violates the RFC, and chokes on an address
attribute that the haskell XMPP library provides. I hope to get this fixed
in ejabberd.
Also did some more work on the Evil Splicer today, integrating it into the
build of the Android app, and making it support incremental building.
Improved its code generation, and am at the milestone where it creates
valid haskell code for the entire `Assistant/WebApp/Types.hs` file,
where Template Haskell expands 2 lines into 2300 lines of code!
|
