On Tue, 14 Jan 2014 15:54:37 +0000 "Schaufler, Casey" <[email protected]> said:
> > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of José Bollo > > Sent: Tuesday, January 14, 2014 7:27 AM > > To: [email protected] > > Subject: Re: [Dev] pam module for Smack > > > > On mar, 2014-01-14 at 20:45 +0900, Carsten Haitzler wrote: > > > On Tue, 14 Jan 2014 11:19:43 +0200 Jussi Laako > > > <[email protected]> > > > 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. > > > > Best regards > > José > > Even having the sshd binary on a production device is criminally insane. On a > developer device, fine. Something connected to Verizon or driving down CA-1 ? > No! why is having it insane? because you think that a malicious app can run it? just set permissions so only root can (easily done). wait. what if someone gains root access? game over anyway. they can run sshd or create/generate their own binaries. hell they don't need sshd - they can just offer their own service directly from their process anyway - why be so OBVIOUS as to run sshd when you can hide it better inside your process? it's like worrying about the ice cream in the freezer will melt when the house is fully ablaze. the house is on fire. forget the ice cream. also there are no developer devices - no production ones either. (i don't count the giveaway dev devices that exist so far as you can't freely just buy one when/if you want). if/when there ever IS any production device... will you volunteer to make a separate developer device to match? reality is that developer devices HAVE to be production devices. until such a time as we have the luxury of maintaining a SEPARATE developer device line ("we" as in tizen as a platform/project). we haven't even managed to get a single production device out that is in any way generally available, let alone having the luxury of saying "well we have 20 production devices - if you are a dev - buy this other separate developer device #21 we specially made that won't annoy the daylight out of you". that is not a luxury we have. at least not at this time. a night club with such tight security that the dj or barman can't get in because he isn't "dressed smartly" is a night club that will not be in business for very long. security that drives developers away is pointless. there is a middle-ground. -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
