On Thu, 20 Dec 2012 19:37:35 +0100, Mike Meyer <m...@mired.org> wrote:
On Thu, Dec 20, 2012 at 11:56 AM, j. van den hoff
<veedeeh...@googlemail.com> wrote:
I would find it far more intuitive if _after_ a `clone' of the above
sort
(password query for `myname' and all) the corresponding local user would
be created automagically and also be set to the default user so that I'm
Nothing to do with computers is "intuitive". At best, it's familiar
because it acts like something else you had to learn to use.
I don't quite agree but let's not argue.
Personally, I'd be *very* surprised if I cloned a repo and it copied
*any* password information, no matter what auth* was done during the
clone. That's just a huge security faux pas. Creating users without
passwords is even worse.
which again 99.9% of the time should be what the user wants anyway (and
might be really surprised to not have happened autmatically).
???... in the considered scenario, after the initial (password
protected/queried) clone I _can_ push and do anything else the respective
user
is allowed to do "upstreams". the only thing is: all this happens using my
local $USER name instead of the name chosen for the remote account.
I'm only proposing it would be nice to set up the clone including a local
user of the remote name as the default user (he might very well get
a different password as far as I can see). what security holes do you see
here?
I disagree. It might be what the user wants to happen 99% of the time
for local clones, but I'd say that the current default (current login
name) does that 99% of the time as well, without opening up the
possibility of unknowingly handing someone a clone that includes your
password.
if I _can_ push directly after issuing the respective password _once_
during the initial clone (even if that happens with the "wrong" ID, namely
the
local $USER ID), the password info necessary for the remote access seems
to be in the repo anyway, no?
For remote clones - things change. I almost never want the same
password on the two ends (again, a security faux pas) and don't really
care whether or not the username is the same. Given that it takes one
command to create a user & password vs. one command to set the
password, automatically creating the same username with a new password
is at best a meh.
I'm just proposing to automate what you do manually in the considered
situation (including chosing a different local password, why not?): create
the user, make him the default, choose some (local) password. where'd be
the problem?
maybe there _is_ an essential problem but I don't see it. let's stop it at
that
thx for responding.
j.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
