Re: [PATCH] contrib: Honor symbolic port in git-credential-netrc.

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]

On 2025-06-21 at 13:29:28, Maxim Cournoyer wrote:
> I'm quite new to the credential-manager of git, so I do not have an
> answer to these excellent questions.  But, as some perhaps useful
> datapoint, at least using Emacs's auth-source library with a
> ~/.authinfo.gpg file (which is in the netrc format), if you use a
> symbolic port name, you have to use it everywhere if you want
> auth-source to match it correctly (it doesn't translate smtps to 465 for
> example). If you put 'port smtps' in the .authinfo.gpg but specify the
> SMTP port in the your Emacs MTA to a integer like 465, it won't match.
> 
> This could be considered a bug in auth-source.el, and git
> credential-manager can do better by converting all port input values to
> their integer form, as you suggested.  Then mismatched configurations
> (e.g.: smtps in netrc and sendemail.smtpServerPort = 465 or vice-versa)
> would be handled correctly.

Yes, I would say that we should be using numeric ports everywhere in the
credential protocol.  If `git send-email` receives "submission" as the
port, then it needs to convert that to "587" before it even requests a
credential.

The git-credential(1) documentation says this for the `host` entry in
the protocol:

    The remote hostname for a network credential. This includes the port
    number if one was specified (e.g., "example.com:8088").

Note that that says "port number", not "symbolic port".

So I think we'd need some answers as to what's going over the protocol
first and how it works for built-in Git functionality (e.g., HTTPS)
before we decide if this is a change we want to make.

> Did I understand correctly with my suggestion/rewording of yours above?
> git-credential-netrc reads its input from the netrc file, which may well
> have a symbolic port, so it should itself convert from symbolic to
> actual port numbers, IIUC.

The netrc format is actually underspecified and libcurl doesn't support
ports at all, so I would not say that using a symbolic port is a good
idea or reliably supported in general.  In fact, I would say that the
netrc credential helper is the only tool I can find that accepts ports
at all.  I've looked at multiple different tools and manual pages online
and the `port` or `protocol` key is not even mentioned.

If we do accept symbolic ports in the netrc file, then we need to
convert them to a numeric port before sending anything over the
protocol, which I don't believe your patch does.  Perl does offer
`getservbyname` for this purpose, so it shouldn't be too difficult to
make this change.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]