Your message dated Tue, 14 Aug 2018 13:10:49 +0200
with message-id <[email protected]>
and subject line Re: sparkleshare potentially poisons ~/.ssh/known_hosts
has caused the Debian Bug report #671864,
regarding sparkleshare potentially poisons ~/.ssh/known_hosts
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
671864: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671864
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: sparkleshare
Version: 0.8.2-1
Severity: important
Dear Maintainer,
When adding a new hosting project, sparkleshare appears to temporarily
disable host key checking. From the debug.log:
11:41:35 [Fetcher][/home/jamie/SparkleShare/.tmp/blah] Fetching folder:
ssh://[email protected]/path/to/blah
11:41:35 [Fetcher] Disabled host key checking for EXAMPLE.ORG
11:41:35 [Cmd] git clone --progress "ssh://[email protected]/path/to/blah"
"/local/path/to/SparkleShare/.tmp/blah"
11:41:42 [Git] Exit code 0
11:41:42 [Config] Added configuration to
'/local/path/to/SparkleShare/.tmp/blah/.git/config'
11:41:42 [Cmd] git config --global core.excludesfile
11:41:42 [Fetcher] Finished
11:41:42 [Fetcher] Enabled host key checking for EXAMPLE.ORG
I tested by adding a new hosting project with a server that was not
listed in my ~/.ssh/known_hosts. After adding it, it was added to my
~/.ssh/known_hosts file without any confirmation from me.
If I delete the line from my known_hosts file, then I get a request to
confirm the connection when sparkleshare communicates with the server
(as I would expect).
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages sparkleshare depends on:
ii git 1:1.7.10-1
ii gnome-icon-theme 3.4.0-2
ii gvfs 1.12.0-1
ii libc6 2.13-30
ii libglib2.0-cil 2.12.10-3
ii libgtk2.0-cil 2.12.10-3
ii libmono-corlib4.0-cil 2.10.8.1-1
ii libmono-posix4.0-cil 2.10.8.1-1
ii libmono-system-core4.0-cil 2.10.8.1-1
ii libmono-system-xml4.0-cil 2.10.8.1-1
ii libmono-system4.0-cil 2.10.8.1-1
ii libnotify0.4-cil 0.4.0~r3032-5
ii libwebkit1.1-cil 0.3-6
ii mono-runtime 2.10.8.1-1
Versions of packages sparkleshare recommends:
ii python 2.7.2-10
ii python-nautilus 1.1-3
sparkleshare suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 2.0.1-1
On Mon, 07 May 2012 11:58:56 -0400 Jamie McClelland <[email protected]> wrote:
> Package: sparkleshare
> Version: 0.8.2-1
> Severity: important
>
> Dear Maintainer,
>
> When adding a new hosting project, sparkleshare appears to temporarily
> disable host key checking. From the debug.log:
>
> 11:41:35 [Fetcher][/home/jamie/SparkleShare/.tmp/blah] Fetching folder:
> ssh://[email protected]/path/to/blah
> 11:41:35 [Fetcher] Disabled host key checking for EXAMPLE.ORG
> 11:41:35 [Cmd] git clone --progress "ssh://[email protected]/path/to/blah"
> "/local/path/to/SparkleShare/.tmp/blah"
> 11:41:42 [Git] Exit code 0
> 11:41:42 [Config] Added configuration to
> '/local/path/to/SparkleShare/.tmp/blah/.git/config'
> 11:41:42 [Cmd] git config --global core.excludesfile
> 11:41:42 [Fetcher] Finished
> 11:41:42 [Fetcher] Enabled host key checking for EXAMPLE.ORG
>
> I tested by adding a new hosting project with a server that was not
> listed in my ~/.ssh/known_hosts. After adding it, it was added to my
> ~/.ssh/known_hosts file without any confirmation from me.
>
> If I delete the line from my known_hosts file, then I get a request to
> confirm the connection when sparkleshare communicates with the server
> (as I would expect).
This has been fixed upstream for some time, and now in Debian too.
--
Cheers,
Andrej
--- End Message ---