On Thu, 07 Feb 2013 08:08:59 +0100 Matthieu Moy matthieu@grenoble-inp.fr
wrote:
MM Plus, read/write has already been used for a while in the C API, so I'd
MM rather keep the same names for the Perl equivalent.
That makes perfect sense.
Ted
--
To unsubscribe from this list: send the line
On Wed, Feb 06 2013, Junio C Hamano gits...@pobox.com wrote:
I see a lot of rerolls on the credential helper front, but is there
anybody working on hooking send-email to the credential framework?
I assumed someone had, but if not I can take a stab at it. I'm not sure
however how should I map
On Wed, 06 Feb 2013 14:26:46 +0100 Michal Nazarewicz min...@mina86.com wrote:
MN On Wed, Feb 06 2013, Junio C Hamano gits...@pobox.com wrote:
I see a lot of rerolls on the credential helper front, but is there
anybody working on hooking send-email to the credential framework?
MN I assumed
On Wed, 06 Feb 2013 09:11:17 +0100 Matthieu Moy matthieu@grenoble-inp.fr
wrote:
MM Junio C Hamano gits...@pobox.com writes:
I see a lot of rerolls on the credential helper front, but is there
anybody working on hooking send-email to the credential framework?
MM Not answering the
On Wed, 06 Feb 2013 16:10:12 +0100 Matthieu Moy matthieu@grenoble-inp.fr
wrote:
MM Ted Zlatanov t...@lifelogs.com writes:
MM [...] so the way to go for send-email is probably to libify the
MM credential support in git-remote-mediawiki, and to use it in send-email.
I looked and that's
Ted Zlatanov t...@lifelogs.com writes:
None of these are a big deal, and Michal said he's working on libifying
this anyhow:
- making 'fill' a special operation is weird
Well, 'fill' is the only operation that mutates the credential structure
(i.e. the only one for which git credential emits
On Wed, 06 Feb 2013 17:41:01 +0100 Matthieu Moy matthieu@grenoble-inp.fr
wrote:
MM Ted Zlatanov t...@lifelogs.com writes:
- sort the output tokens (after 'url' is extracted) so the output is
consistent and testable
MM Why not, if you want to use the output of credential_write in tests.
On Wed, Feb 06, 2013 at 10:58:13AM -0500, Ted Zlatanov wrote:
MM I don't know about the netrc credential helper, but I guess that's
MM another layer. The git-remote-mediawiki code is the code to call the
MM credential C API, that in turn may (or may not) call a credential
MM helper.
Yup.
On Wed, 6 Feb 2013 16:57:24 -0500 Jeff King p...@peff.net wrote:
JK On Wed, Feb 06, 2013 at 10:58:13AM -0500, Ted Zlatanov wrote:
MM I don't know about the netrc credential helper, but I guess that's
MM another layer. The git-remote-mediawiki code is the code to call the
MM credential C API,
Ted Zlatanov t...@lifelogs.com writes:
Logically they are different steps (query and response), even though the
data protocol is the same. But it's really not a big deal, I know what
it means either way.
Yes, but if you rename write() to query(), then on the helper side,
you'll have to call
Jeff King p...@peff.net writes:
On Tue, Jan 29, 2013 at 11:53:19AM -0800, Junio C Hamano wrote:
Either way it still encourages a plaintext password to be on disk,
which may not be what we want, even though it may be slight if not
really much of an improvement. Again the Help-for-users has
On Wed, Jan 30 2013, Jeff King wrote:
I do not mind a .netrc or .authinfo parser, because while those formats
do have security problems, they are standard files that may already be
in use. So as long as we are not encouraging their use, I do not see a
problem in supporting them (and we already
On Sun, 3 Feb 2013 14:41:49 -0500 Jeff King p...@peff.net wrote:
JK On Sat, Feb 02, 2013 at 06:57:29AM -0500, Ted Zlatanov wrote:
If the file name ends with .gpg, it will run gpg --decrypt FILE and
use the output. So non-interactively, that could hang if GPG was
waiting for input. Does Git
On Mon, 04 Feb 2013 17:33:58 +0100 Michal Nazarewicz min...@mina86.com wrote:
MN As far as I understand, there could be a git-credential helper that
MN reads ~/.authinfo and than git-send-email would just call “git
MN credential fill”, right?
MN I've noticed though, that git-credential does not
On Mon, Feb 04, 2013 at 12:00:34PM -0500, Ted Zlatanov wrote:
On Mon, 04 Feb 2013 17:33:58 +0100 Michal Nazarewicz min...@mina86.com
wrote:
MN As far as I understand, there could be a git-credential helper that
MN reads ~/.authinfo and than git-send-email would just call “git
MN
On Mon, 4 Feb 2013 15:10:40 -0500 Jeff King p...@peff.net wrote:
JK Technically you can speak a particular protocol on an alternate port:
JK https://example.com:31337/repo.git
JK In this case, git will send you the host as:
JK example.com:31337
JK You might want to map this to port in
On Mon, Feb 04, 2013 at 03:28:52PM -0500, Ted Zlatanov wrote:
JK You might want to map this to port in .autoinfo separately if it's
JK available.
That would create the following possibilities:
* host example.com:31337, protocol https
* host example.com:31337, protocol unspecified
* host
On Mon, 4 Feb 2013 15:59:11 -0500 Jeff King p...@peff.net wrote:
JK On Mon, Feb 04, 2013 at 03:28:52PM -0500, Ted Zlatanov wrote:
JK You might want to map this to port in .autoinfo separately if it's
JK available.
That would create the following possibilities:
* host example.com:31337,
On Mon, Feb 04, 2013 at 04:08:52PM -0500, Ted Zlatanov wrote:
That would create the following possibilities:
* host example.com:31337, protocol https
* host example.com:31337, protocol unspecified
* host example.com, protocol https
* host example.com, protocol unspecified
JK
On Mon, 4 Feb 2013 16:22:03 -0500 Jeff King p...@peff.net wrote:
Currently, we map both the port and protocol netrc tokens to the
credential helper protocol's protocol. So this will have undefined
results. To do what you specify could be pretty simple: we could do a
preliminary scan of the
On Sat, Feb 02, 2013 at 06:57:29AM -0500, Ted Zlatanov wrote:
I wrote a Perl credential helper for netrc parsing which is pretty
robust, has built-in docs with -h, and doesn't depend on external
modules. The netrc parser regex was stolen from Net::Netrc.
It will by default use
On Thu, 31 Jan 2013 14:38:45 -0500 Jeff King p...@peff.net wrote:
JK On Thu, Jan 31, 2013 at 10:23:51AM -0500, Ted Zlatanov wrote:
Jeff, is there a way for git-credential to currently support
authinfo/netrc parsing? I assume that's the right way, instead of using
Michal's proposal to parse
On Wed, 30 Jan 2013 07:57:29 -0800 Junio C Hamano gits...@pobox.com wrote:
JCH Jeff King p...@peff.net writes:
But it would probably make sense for send-email to support the existing
git-credential subsystem, so that it can take advantage of secure
system-specific storage. And that is where
On Thu, Jan 31, 2013 at 10:23:51AM -0500, Ted Zlatanov wrote:
Jeff, is there a way for git-credential to currently support
authinfo/netrc parsing? I assume that's the right way, instead of using
Michal's proposal to parse internally?
I'd like to add that, plus support for the 'string' and
On Tue, 29 Jan 2013 11:53:19 -0800 Junio C Hamano gits...@pobox.com wrote:
JCH Makes one wonder why .authinfo and not .netrc;
JCH http://www.gnu.org/software/emacs/manual/html_node/auth/Help-for-users.html
JCH phrases it amusingly:
JCH “Netrc” files are usually called .authinfo or
Jeff King p...@peff.net writes:
But it would probably make sense for send-email to support the existing
git-credential subsystem, so that it can take advantage of secure
system-specific storage. And that is where we should be pointing new
users. I think contrib/mw-to-git even has credential
From: Michal Nazarewicz min...@mina86.com
Make git-send-email read password from a ~/.authinfo file instead of
requiring it to be stored in git configuration, passed as command line
argument or typed in.
There are various other applications that use this file for
authentication information so
Michal Nazarewicz m...@google.com writes:
From: Michal Nazarewicz min...@mina86.com
Make git-send-email read password from a ~/.authinfo file instead of
requiring it to be stored in git configuration, passed as command line
argument or typed in.
Makes one wonder why .authinfo and not
On Tue, Jan 29, 2013 at 11:53:19AM -0800, Junio C Hamano wrote:
Either way it still encourages a plaintext password to be on disk,
which may not be what we want, even though it may be slight if not
really much of an improvement. Again the Help-for-users has this
amusing bit:
I do not mind a
29 matches
Mail list logo
