view release on metacpan or  search on metacpan

libcares/CHANGES.0  view on Meta::CPAN

  the other side could always close the connection, which is a valid event
  which should be responded to.

* September 22 2007 (Daniel Stenberg)

- Steinar H. Gunderson fixed: Correctly clear sockets from the fd_set on in
  several functions (write_tcp_data, read_tcp_data, read_udp_packets) so that
  if it fails and the socket is closed the following code doesn't try to use
  the file descriptor.

- Steinar H. Gunderson modified c-ares to now also do to DNS retries even when
  TCP is used since there are several edge cases where it still makes sense.

- Brad House provided a fix for ares_save_options():

  Apparently I overlooked something with the ares_save_options() where it
  would try to do a malloc(0) when no options of that type needed to be saved.
  On most platforms, this was fine because malloc(0) doesn't actually return
  NULL, but on AIX it does, so ares_save_options would return ARES_ENOMEM.

* July 14 2007 (Daniel Stenberg)

- Vlad Dinulescu fixed two outstanding valgrind reports:

  1. In ares_query.c , in find_query_by_id we compare q->qid (which is a short
  int variable) with qid, which is declared as an int variable.  Moreover,
  DNS_HEADER_SET_QID is used to set the value of qid, but DNS_HEADER_SET_QID
  sets only the first two bytes of qid. I think that qid should be declared as
  "unsigned short" in this function.

  2. The same problem occurs in ares_process.c, process_answer() .  query->qid
  (an unsigned short integer variable) is compared with id, which is an
  integer variable. Moreover, id is initialized from DNS_HEADER_QID which sets
  only the first two bytes of id. I think that the id variable should be
  declared as "unsigned short" in this function.

  Even after declaring these variables as "unsigned short", the valgrind
  errors are still there. Which brings us to the third problem.

  3. The third problem is that Valgrind assumes that query->qid is not
  initialised correctly. And it does that because query->qid is set from
  DNS_HEADER_QID(qbuf); Valgrind says that qbuf has unitialised bytes. And
  qbuf has uninitialised bytes because of channel->next_id . And next_id is
  set by ares_init.c:ares__generate_new_id() . I found that putting short r=0
  in this function (instead of short r) makes all Valgrind warnings go away.
  I have studied ares__rc4() too, and this is the offending line:

        buffer_ptr[counter] ^= state[xorIndex];   (ares_query.c:62)

  This is what triggers Valgrind.. buffer_ptr is unitialised in this function,
  and by applying ^= on it, it remains unitialised.

Version 1.4.0 (June 8, 2007)

* June 4 2007 (Daniel Stenberg)

- James Bursa reported a major memory problem when resolving multi-IP names
  and I found and fixed the problem. It was added by Ashish Sharma's patch
  two days ago.

  When I then tried to verify multiple entries in /etc/hosts after my fix, I
  got another segfault and decided this code was not ripe for inclusion and I
  reverted the patch.

* June 2 2007

- Brad Spencer found and fixed three flaws in the code, found with the new
  gcc 4.2.0 warning: -Waddress

- Brad House fixed VS2005 compiler warnings due to time_t being 64bit.
  He also made recent Microsoft compilers use _strdup() instead of strdup().

- Brad House's man pages for ares_save_options() and ares_destroy_options()
  were added.

- Ashish Sharma provided a patch for supporting multiple entries in the
  /etc/hosts file. Patch edited for coding style and functionality by me
  (Daniel).

* May 30 2007

- Shmulik Regev brought cryptographically secure transaction IDs:

  The c-ares library implementation uses a DNS "Transaction ID" field that is
  seeded with a pseudo random number (based on gettimeofday) which is
  incremented (++) between consecutive calls and is therefore rather
  predictable. In general, predictability of DNS Transaction ID is a well
  known security problem (e.g.
  http://bak.spc.org/dms/archive/dns_id_attack.txt) and makes a c-ares based
  implementation vulnerable to DNS poisoning. Credit goes to Amit Klein
  (Trusteer) for identifying this problem.

  The patch I wrote changes the implementation to use a more secure way of
  generating unique IDs. It starts by obtaining a key with reasonable entropy
  which is used with an RC4 stream to generate the cryptographically secure
  transaction IDs.

  Note that the key generation code (in ares_init:randomize_key) has two
  versions, the Windows specific one uses a cryptographically safe function
  provided (but undocumented :) by the operating system (described at
  http://blogs.msdn.com/michael_howard/archive/2005/01/14/353379.aspx).  The
  default implementation is a bit naive and uses the standard 'rand'
  function. Surely a better way to generate random keys exists for other
  platforms.

  The patch can be tested by using the adig utility and using the '-s' option.

- Brad House added ares_save_options() and ares_destroy_options() that can be
  used to keep options for later re-usal when ares_init_options() is used.

  Problem: Calling ares_init() for each lookup can be unnecessarily resource
         intensive.  On windows, it must LoadLibrary() or search the registry
         on each call to ares_init().  On unix, it must read and parse
         multiple files to obtain the necessary configuration information.  In
         a single-threaded environment, it would make sense to only
         ares_init() once, but in a heavily multi-threaded environment, it is
         undesirable to ares_init() and ares_destroy() for each thread created
         and track that.

  Solution: Create ares_save_options() and ares_destroy_options() functions to
         retrieve and free options obtained from an initialized channel.  The