On 01/21/2014 02:46 PM, Yang Chengwei wrote:
On Tue, Jan 21, 2014 at 02:03:42PM +0900, Carsten Haitzler wrote:
On 01/21/2014 12:22 PM, Yang Chengwei wrote:
On Wed, Jan 15, 2014 at 09:38:32AM +0900, Carsten Haitzler wrote:
On Tue, 14 Jan 2014 16:26:57 +0100 José Bollo
<jose.bo...@open.eurogiciel.org>
said:
On mar, 2014-01-14 at 20:45 +0900, Carsten Haitzler wrote:
On Tue, 14 Jan 2014 11:19:43 +0200 Jussi Laako
<jussi.la...@linux.intel.com>
said:
On 14.1.2014 4:16, Carsten Haitzler wrote:
having a "enable ssh" option on devices (when you
enable developer mode)
would be the best of both options. it's not on by
default, but it's a
simple click away.
Just "Enable developer mode" in device settings would be
fine. But I
wouldn't like to have a car that has ssh wide open to the
world with
some default password or key... Nor phone either.
i'm fine with that. a single simple checkbox is fine for me :)
and agree -
if enabled as a service, it should require you enter a
password at that
tome - no default passwords/accounts. perhaps limit sshd to
only listen on
usbnet and any wifi etc. networks you tags as "trusted". :)
The check box should have a time limited effect. That means that
you can
forget to uncheck it, it will uncheck itself after a while.
The check box should also be associated to a kind of password. It
is not
acceptable that a developer tool can connect to any device just
because
to check box is checked. I'm not saying that a password must be
set but
that a password can be set if wanted.
i would say a password SHOULD be set at that time - no defaults. and
that
password retained so you don't need to keep re-setting it each time
(but able
to be changed too from that menu). if there is a timeout, i would say
it should
be a timeout between successful logins on sshd. if there has not been a
successful login in let's say 7 days, turn it off. (that would mean
developers
using it all the time at least once per week don't get bothered). or
hey - make
the timeout configurable... :) let the developer decide how bothersome
they are
willing to accept things vs security.
I'm not sure it's worth a discussion or not about ship Tizen with ssh
service, for me, sdb is useful enough for developers, and it's more
security, at least one need connect a usb cable to the device, if one
can archive your device, then it's done.
ssh offers far more:
* authorized access by passoword and/or ssh key (so if someone gets hold of
your device and plugs it in they can't do anything without auth).
I think this is not a common using scenario for a *mobile* device, why
it works like server? Why you don't bring it around you?
someone stelas your device and plugs it in and starts downloading all
your data. perfectly common scenario. someone "borrows" your phone while
you are not looking and tries to download all your data, then repaces it
- someone just snarfed your data and you don't know. they needed
physical access - but thats not hard to get.
In the last word, you can setup a sdb over ssh tunnel if you like.
* sshfs. need i say more. much more useful than sdb. :)
I don't know how common sshfs be used in your daily work, but not for
me, I only used it for my tomboy notes sync-up.
For developers (I think mostly app developers), sdb is good enough,
anyone want more, I think he'll manage to root or reflash the device,
then it's a developer-version device.
if your app devsa are the "i develop for any os if you pay me enough"
crowd. if that is who we expect to dev for tizen, we had better be
putting together boatloads of cash. if you go for the "i develop because
i love linux and this tizen os is different to android and everyone
because its FAMILIAr to me.. it supprots the tools i already know and
use" then keepign ssh is a very good idea. it's playing to strengths
tizen has, not weaknesses.
--
Thanks,
Chengwei
--
Thanks,
Chengwei
--
Carsten Haitzler (The Rasterman) <ti...@rasterman.com>
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
