Terje Mathisen wrote: > Dave Hart wrote: >> On Jan 11, 6:04 pm, ma...@ntp.isc.org (Danny Mayer) wrote: >>> Dave Hart wrote: >>>> I am not suggesting you to go referencing Wsp* functions willy-nilly >>>> to avoid some perceived (and insignificant) overhead of using >>>> published APIs. I'm suggesting you use the published API names like >>>> getaddrinfo and let Microsoft's runtime binding implementation do what >>>> it is designed to do. That it involves macros to inline functions >>>> with names like WspiapiGetAddrInfo is an implementation detail >>>> invisible to everyone not using a symbolic debugger against ntp >>>> binaries on Windows. >>> That is not correct. These are not macros. The SPI layer is a layer >>> between Winsock2 and the base layer and there can be multiple SPI layers >>> and in fact you can specify the order. All of this gets very tricky and >>> it's one of the reasons why I don't want to go there. Just because >>> Microsoft provides something doesn't mean that we should use it. >> You are mistaken. I'm getting sick of you speaking without checking >> on the accuracy of your claims. Wspiapi.h and the Wspiapi-prefixed >> inline functions and macros have nothing to do with Winsock's Service >> Provider Interface (SPI). Rather, they are part of the pedestrian >> client application socket API. Please take a few minutes and read the >> header file, since you are so stubbornly unwilling to believe the >> documentation I've referred you to repeatedly. >> >> http://pf.itd.nrl.navy.mil/mdp/dox/html/wspiapi_8h-source.html >> >> You don't even need to have a set of Windows header files handy, the >> US Navy has kindly published the entire header file at the URL above. >> You said "these are not macros." The source code disagrees: >> >> 00027 #define getaddrinfo WspiapiGetAddrInfo >> > > Dave, I was inclined to agree with you that these headers do look like > what we need, functionality-wise they look spot on, but when I started > to read the code I found some ugly stuff, i.e.: > > 00272 __inline > 00273 int > 00274 WINAPI > 00275 WspiapiLookupNode( > 00276 IN const char *pszNodeName, > 00277 IN int iSocketType, > 00278 IN int iProtocol, > 00279 IN WORD wPort, > 00280 IN BOOL bAI_CANONNAME, > 00281 OUT struct addrinfo **pptResult) > 00282 /*++ > [snip] > > 00308 char szFQDN1[NI_MAXHOST] = ""; > 00309 char szFQDN2[NI_MAXHOST] = ""; > 00310 char *pszName = szFQDN1; > 00311 char *pszAlias = szFQDN2; > 00312 char *pszScratch = NULL; > 00313 strcpy(pszName, pszNodeName); > > I.e. the _very_ first operation of this function is to enable a stack > overflow bug/security hole! > > If you send in a too-long szNodeName, then the strcpy() will overwrite > lots of stack values. :-( > > Terje
And line 340-341 makes it clear that it's doing it's own lookups: // there was a new CNAME, look again. WspiapiSwap(pszName, pszAlias, pszScratch); That also means that it is not using the resolvers since CNAME restart is the job of a resolver and that means that this code cannot make use of DNSSEC and other security changes being added to DNS. In addition as Martin mentioned this is compile-time code. We need it to do the right thing at runtime. We won't be supporting IPv6 on Windows 2000, it's just too difficult to deal with from a support point of view. Danny _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions