Re: Minor feature additions

[Chris Backas <chb@xxxxxxxxxxxxxxxxxx>]

On Jul 8, 2009, at 4:25 AM, Aris Adamantiadis wrote:

> Hello,
> Andreas Schneider a écrit :
> > On Tuesday 07 July 2009 21:05:11 Chris Backas wrote:
> >
> > > Hello all,
> >
> > Hi Chris,
> >
> >
> > > 1) The known hosts file: Current libssh considers it an error
> > > condition if this does not exist. I don't really see why, but it
> > > causes us problems on our production machines because typically no
> > > one's ever run ssh on them directly before, so the file isn't  
> > > there to
> > > begin with. We see no reason to have to go around to every machine  
> > > and
> > > ensure this file exists first, so I did a simple modification in the
> > > 0.2 release that changes "file not found"  in ssh_parse_knownhost()
> > > from an error condition to a simple "return NULL", meaning "No match
> > > found".
> >
> > I think there should be know error if the known_hosts file doesn't  
> > exist. At
> > least it should be the choice of the application developer to fail  
> > here or
> > not. Feel free to send a git patch.
> Returning a constant saying "known host file not found" should be
> enough. Legacy code (not handling this constant) would not change
> behaviour since the previous behaviour was to return an error. I am in
> favor of this change (both branches).

That would be fine with me, and solves my need. I just need to discern  
"Known Hosts Not Found" from something that's actually an error.

> > > Could there be a simple option which determines whether not having a
> > > known hosts file is a real problem?
> >
> > I don't think so and if then the application developer should  
> > handle it in
> > this case. Maybe set the errno here.
> We have a mechanism for this.
> > > 2) In getai(), it saves a lot of futile DNS querying time to do
> > > something like this:
> > > hints.ai_flags |= AI_NUMERICHOST;
> > >
> > > Obviously, if you know ahead of time that you're supplying a plain  
> > > IP
> > > Address. Could there be a way to tell libssh that this is the case  
> > > and
> > > add that flag to the hints conditionally?
> >
> > I think we could add a function for this. Aris?
> Hmm, I think we don't have to add a function but rather understand why
> it tries to make a DNS lookup even when we give out an IP address.
> Almost no highlevel framework adds an option to hint the resolver that
> we gave a numeric IP, I think it should not be exported to the public
> functions.
> I'm going to see what we do wrong, in worst case, doing a regexplike
> search on [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+ is not that hard. (a bit  
> harder
> for ipv6).

In my own modification I did exactly that, had it detect when the host  
name 'looks like' an IP address, and then set the flag.
getaddrinfo(), at least on Mac OS X (where I'm using this) isn't clear  
about its resolution behavior. It says in the man page:

"An acceptable value for nodename is either a valid host name or a  
numeric host address string consisting of a dotted decimal IPv4  
address or an IPv6 address."

But that doesn't say how it treats them. Experimentally its seems to  
be "assume this is a host name, and if that fails then try it as a  
numeric address".  The AI_NUMERICHOST flag says:

"AI_NUMERICHOST  If the AI_NUMERICHOST bit is set, it indicates that  
nodename should be treated as a numeric string defining an IPv4 or  
IPv6 address and no name resolution should be attempted."

My reading of that is that the flag wouldn't need to exist if  
getaddrinfo() itself made any attempt to realize that the supplied  
value is not a host name.

The man page claims that the function is POSIX standard, and Google  
tells me the flag exists in at least FreeBSD and AIX as well. Is it  
missing from Linux or Windows?

Chris Backas
Software Developer
Bristol Capital, Inc.