On Thu, 07 Feb 2013 08:08:59 +0100 Matthieu Moy
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 "unsubscribe git" in
the bod
Ted Zlatanov 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 query() to send
On Wed, 6 Feb 2013 16:57:24 -0500 Jeff King 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, that in turn
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.
>
On Wed, 06 Feb 2013 17:41:01 +0100 Matthieu Moy
wrote:
MM> Ted Zlatanov 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. But
MM> credential_write is essentially
Ted Zlatanov 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 an output to
On Wed, 06 Feb 2013 16:10:12 +0100 Matthieu Moy
wrote:
MM> Ted Zlatanov 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 indeed very useful. If it's put in a libr
Ted Zlatanov 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 indeed very useful. If it's put in a library, I'd
> use credential_read() and credential_write() in my
On Wed, 06 Feb 2013 09:11:17 +0100 Matthieu Moy
wrote:
MM> Junio C Hamano 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 question, but git-remote-mediawiki supports the
On Wed, 06 Feb 2013 14:26:46 +0100 Michal Nazarewicz wrote:
MN> On Wed, Feb 06 2013, Junio C Hamano 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 someone had, but if not I can ta
On Wed, Feb 06 2013, Junio C Hamano 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 server, server-po
Junio C Hamano 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?
Not answering the question, but git-remote-mediawiki supports the
credential framework. It is written in perl, and the credential supp
Jeff King 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 this
>>
On Mon, 4 Feb 2013 16:22:03 -0500 Jeff King 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 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 unspec
On Mon, 4 Feb 2013 15:59:11 -0500 Jeff King 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, prot
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 unspecifi
On Mon, 4 Feb 2013 15:10:40 -0500 Jeff King 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 .autoinfo
On Mon, Feb 04, 2013 at 12:00:34PM -0500, Ted Zlatanov wrote:
> On Mon, 04 Feb 2013 17:33:58 +0100 Michal Nazarewicz
> 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”,
On Mon, 04 Feb 2013 17:33:58 +0100 Michal Nazarewicz 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 support port
On Sun, 3 Feb 2013 14:41:49 -0500 Jeff King 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 han
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 alre
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 ~/.authin
On Thu, 31 Jan 2013 14:38:45 -0500 Jeff King 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 internal
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'
On Wed, 30 Jan 2013 07:57:29 -0800 Junio C Hamano wrote:
JCH> Jeff King 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
Jeff King 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 support wri
On Tue, 29 Jan 2013 11:53:19 -0800 Junio C Hamano 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 .netr
JCH>
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 min
Michal Nazarewicz writes:
> From: Michal Nazarewicz
>
> 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 .netrc;
http://www.gnu.org/softw
From: Michal Nazarewicz
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 letting users use it
31 matches
Mail list logo
