From: Jakub Narebski <jnareb@gmail.com>
To: Tay Ray Chuan <rctay89@gmail.com>
Cc: git@vger.kernel.org, Shawn Pearce <spearce@spearce.org>
Subject: Re: [GSoC] Google Summer of Code 2009 - new ideas
Date: Mon, 9 Mar 2009 00:59:36 +0100 [thread overview]
Message-ID: <200903090059.36699.jnareb@gmail.com> (raw)
In-Reply-To: <be6fef0d0903061856s21fdb4c4q9d52957dade96e94@mail.gmail.com>
On Sat, 7 Mar 2009, Tay Ray Chuan wrote:
> On 3/7/09, Jakub Narebski <jnareb@gmail.com> wrote:
> > == Single credentials ==
> >
> > Currently if you don't save your username and password in plain-text
> > `.netrc` file (for HTTP transport), or avoid need for interactive
> > credentials using public key / private key pair (for SSH), you need to
> > repeat credentials many times during single git-fetch or git-clone
> > command. The goal is to reuse existing connections if possible, so the
> > whole transaction occurs using single connection and single
> > credentials; if that is not possible cache credentials (in secure way)
> > so user need to provide username and password at most once.
> >
> > '''Goal:''' git-fetch and git-clone over HTTPS and git://
> > requiring providing username and password at most once
> > '''Language:''' C (perhaps also shell script)
>
> Perhaps you might want to look at this:
>
> http://marc.info/?l=git&m=123599968929476&w=4
Thank you for the link.
> At that time, I was thinking more of removing git's reliance on curl's
> multi interface so that it could use older versions of libcurl. But,
> on this point, Daniel convinced me otherwise. In fact, it doesn't make
> sense if you could have a up-to-date git, but not an up-to-date curl.
>
> I didn't really get a reply on my point of "minimized credential
> prompting", though, and I think this GSoC proposal kinda gives support
> to it.
>
> From a learning standpoint, I don't think this project would be too
> challenging, nor can it sustain for a whole summer -- the basic
> strategy to allow non-curl multi usage (ie. single connections) would
> be to "fork" the current http slot methods and make them
> non-curl_multi, then finding and replacing instances of them
> throughout the code base.
I was thinking more about caching credentials by git rather than forcing
to use single connection. Additionally you are solving the problem for
the HTTP(S) transport; admittedly for SSH there is much better solution
of using public/private keys, instead of asking for password.
I guess you are right and "minimized credential prompting" (aka "single
credentials") is too small a project for Google Summer of Code...
I won't add it to SoC2009Ideas page.
> I already have a patch series that does that, plus a --persistent
> option for push. I'm fairly sure that it takes place on a single
> connection (I'm relying on my firewall log though I'm doubting it's
> reliability on this issue).
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2009-03-09 0:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-07 0:44 [GSoC] Google Summer of Code 2009 - new ideas Jakub Narebski
2009-03-07 1:09 ` Jan Janak
2009-03-07 2:56 ` Tay Ray Chuan
2009-03-08 23:59 ` Jakub Narebski [this message]
[not found] ` <20090309115026.obsvt34miowwcw8w@webmail.fussycoder.id.au>
2009-03-09 1:18 ` Jakub Narebski
2009-03-07 19:59 ` P Baker
2009-03-07 20:55 ` Shawn O. Pearce
2009-03-10 0:49 ` Shawn O. Pearce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200903090059.36699.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=rctay89@gmail.com \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.