[PATCH 2 of 3 RFC] url: remember http password database in ui object

[Augie Fackler]

> On Jun 11, 2016, at 9:29 AM, Piotr Listkiewicz <piotr.listkiewicz at gmail.com> wrote:
> 
> My question is whether or not commandserver should keep the passwords in
> memory, permanently. It would be sometimes useful as you can avoid retyping
> the same password in GUI programs like TortoiseHg, but it might be undesired
> and less secure.
> That said, the direction of this patch looks good to me.
> 
>  OK, so should I resend series without RFC to go through plain review process?
> 
> 2016-06-11 7:56 GMT+02:00 Yuya Nishihara <yuya at tcha.org <mailto:yuya at tcha.org>>:
> On Thu, 9 Jun 2016 23:41:06 -0400, Augie Fackler wrote:
> > On Thu, Jun 09, 2016 at 01:02:56PM +0200, liscju wrote:
> > > # HG changeset patch
> > > # User liscju <piotr.listkiewicz at gmail.com <mailto:piotr.listkiewicz at gmail.com>>
> > > # Date 1465465296 -7200
> > > #      Thu Jun 09 11:41:36 2016 +0200
> > > # Node ID 4d9b3b414988081cb9b8bc19f8533cf2f13195f4
> > > # Parent  45be12e882c975ff1acfa368d65bff7729eae593
> > > url: remember http password database in ui object
> 
> > I've added Jun for chg expertise, because I suspect you're right that
> > this code is problematic for chg.
> 
> As of now, chg should have no issue since it forks per runcommand().
> 
> > > This makes http password database stored permanently
> > > in ui object. The question is when this database should
> > > be cleared, usually there is no need to do this,
> > > but with commandserver.runcommand it probably should but
> > > I don't know where to do this.
> 
> My question is whether or not commandserver should keep the passwords in
> memory, permanently.

I think that the commandserver holding passwords in memory permanently is probably a little too magical - if a user enters a pw interactively and screws it up, how will they fix it short of shutting down the commandserver?

> It would be sometimes useful as you can avoid retyping
> the same password in GUI programs like TortoiseHg, but it might be undesired
> and less secure.
> 
> That said, the direction of this patch looks good to me.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160611/1c6aace5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160611/1c6aace5/attachment.sig>