OSSP CVS Repository

ossp - Difference in ossp-pkg/uuid/HISTORY versions 1.1 and 1.2
Not logged in
[Honeypot]  [Browse]  [Home]  [Login]  [Reports
[Search]  [Ticket]  [Timeline
  [History

ossp-pkg/uuid/HISTORY 1.1 -> 1.2

--- HISTORY      2004/02/13 19:19:59     1.1
+++ HISTORY      2004/02/13 21:03:18     1.2
@@ -210,3 +210,149 @@
   -- 
    Marcel Moolenaar       USPA: A-39004          marcel@xcllnt.net
 
+  ___________________________________________________________________________
+
+  Index: ChangeLog
+  ===================================================================
+  RCS file: /e/ossp/cvs/ossp-pkg/uuid/ChangeLog,v
+  retrieving revision 1.42
+  diff -u -d -r1.42 ChangeLog
+  --- ChangeLog 13 Feb 2004 16:17:07 -0000      1.42
+  +++ ChangeLog 13 Feb 2004 21:01:07 -0000
+  @@ -13,6 +13,14 @@
+   
+     Changes between 0.9.6 and 0.9.7 (11-Feb-2004 to 13-Feb-2004)
+   
+  +   o remove --with-rfc2518 option and functionality because
+  +     even the IETF/IESG has finally approved our report about the broken
+  +     random multicast MAC address generation in the standard (and
+  +     will fix it in new versions of the draft-mealling-uuid-urn). So,
+  +     finally get rid of this broken-by-design backward compatibility
+  +     functionality.
+  +     [Ralf S. Engelschall]
+  +
+      o Add support to uuid(1) CLI for decoding from stdin for
+        both binary and string representations.
+        [Ralf S. Engelschall]
+  Index: uuid.ac
+  ===================================================================
+  RCS file: /e/ossp/cvs/ossp-pkg/uuid/uuid.ac,v
+  retrieving revision 1.10
+  diff -u -d -r1.10 uuid.ac
+  --- uuid.ac   11 Feb 2004 14:38:40 -0000      1.10
+  +++ uuid.ac   13 Feb 2004 19:20:32 -0000
+  @@ -71,12 +71,6 @@
+       AC_CHECK_SIZEOF(unsigned long long, 8)
+   
+       dnl #   options
+  -    AC_ARG_WITH(rfc2518,
+  -        AC_HELP_STRING([--with-rfc2518], [use incorrect generation of IEEE 802 multicast addresses according to RFC2518]),
+  -        [ac_cv_with_rfc2518=$withval], [ac_cv_with_rfc2518=no])
+  -    if test ".$ac_cv_with_rfc2518" = ".yes"; then
+  -        AC_DEFINE(WITH_RFC2518, 1, [whether to use incorrect generation of IEEE 802 multicast addresses according to RFC2518])
+  -    fi
+       AC_ARG_WITH(dce,
+           AC_HELP_STRING([--with-dce], [build DCE 1.1 backward compatibility API]),
+           [ac_cv_with_dce=$withval], [ac_cv_with_dce=no])
+  Index: uuid.c
+  ===================================================================
+  RCS file: /e/ossp/cvs/ossp-pkg/uuid/uuid.c,v
+  retrieving revision 1.44
+  diff -u -d -r1.44 uuid.c
+  --- uuid.c    19 Jan 2004 14:56:35 -0000      1.44
+  +++ uuid.c    13 Feb 2004 19:22:01 -0000
+  @@ -61,69 +61,9 @@
+       Unix UTC base time is January  1, 1970) */
+   #define UUID_TIMEOFFSET "01B21DD213814000"
+   
+  -/* IEEE 802 MAC address encoding/decoding bit fields
+  -
+  -   ATTENTION:
+  -
+  -   In case no real/physical IEEE 802 address is available, both
+  -   "draft-leach-uuids-guids-01" (section "4. Node IDs when no IEEE 802
+  -   network card is available") and RFC 2518 (section "6.4.1 Node Field
+  -   Generation Without the IEEE 802 Address") recommend (quoted from RFC
+  -   2518):
+  -
+  -     "The ideal solution is to obtain a 47 bit cryptographic quality
+  -     random number, and use it as the low 47 bits of the node ID, with
+  -     the most significant bit of the first octet of the node ID set to
+  -     1. This bit is the unicast/multicast bit, which will never be set
+  -     in IEEE 802 addresses obtained from network cards; hence, there can
+  -     never be a conflict between UUIDs generated by machines with and
+  -     without network cards."
+  -
+  -   This passage clearly explains the intention to use IEEE 802 multicast
+  -   addresses. Unfortunately, it incorrectly explains how to implement
+  -   this! It should instead specify the "*LEAST* significant bit of the
+  -   first octet of the node ID" as the multicast bit in a memory and
+  -   hexadecimal string representation of a 48-bit IEEE 802 MAC address.
+  -
+  -   Unfortunately, even the reference implementation included in the
+  -   expired IETF "draft-leach-uuids-guids-01" incorrectly set the
+  -   multicast bit with an OR bit operation and an incorrect mask of
+  -   0x80. Hence, several other UUID implementations found on the
+  -   Internet have inherited this bug.
+  -
+  -   Luckily, neither DCE 1.1 nor ISO/IEC 11578:1996 are affected by this
+  -   problem. They disregard the topic of missing IEEE 802 addresses
+  -   entirely, and thus avoid adopting this bug from the original draft
+  -   and code ;-)
+  -
+  -   It seems that this standards bug arises from a false interpretation,
+  -   as the multicast bit is actually the *MOST* significant bit in IEEE
+  -   802.3 (Ethernet) _transmission order_ of an IEEE 802 MAC address. The
+  -   authors were likely not aware that the bitwise order of an octet from
+  -   a MAC address memory and hexadecimal string representation is still
+  -   always from left (MSB, bit 7) to right (LSB, bit 0).
+  -
+  -   For more information, see "Understanding Physical Addresses" in
+  -   "Ethernet -- The Definitive Guide", p.43, and the section "ETHERNET
+  -   MULTICAST ADDRESSES" in http://www.iana.org/assignments/ethernet-numbers.
+  -
+  -   At OSSP, we do it the intended/correct way and generate a real
+  -   IEEE 802 multicast address. Those wanting to encode broken IEEE
+  -   802 MAC addresses (as specified) can nevertheless use a brain dead
+  -   compile-time option to switch off the correct behavior. When decoding
+  -   we always use the correct behavior of course. */
+  -
+  -/* encoding */
+  -#ifdef WITH_RFC2518
+  -#define IEEE_MAC_MCBIT_ENC BM_OCTET(1,0,0,0,0,0,0,0)
+  -#else
+  -#define IEEE_MAC_MCBIT_ENC BM_OCTET(0,0,0,0,0,0,0,1)
+  -#endif
+  -#define IEEE_MAC_LOBIT_ENC BM_OCTET(0,0,0,0,0,0,1,0)
+  -
+  -/* decoding */
+  -#define IEEE_MAC_MCBIT_DEC BM_OCTET(0,0,0,0,0,0,0,1)
+  -#define IEEE_MAC_LOBIT_DEC BM_OCTET(0,0,0,0,0,0,1,0)
+  +/* IEEE 802 MAC address encoding/decoding bit fields */
+  +#define IEEE_MAC_MCBIT BM_OCTET(0,0,0,0,0,0,0,1)
+  +#define IEEE_MAC_LOBIT BM_OCTET(0,0,0,0,0,0,1,0)
+   
+   /* IEEE 802 MAC address octet length */
+   #define IEEE_MAC_OCTETS 6
+  @@ -622,8 +562,8 @@
+               (unsigned int)uuid->obj.node[3],
+               (unsigned int)uuid->obj.node[4],
+               (unsigned int)uuid->obj.node[5],
+  -            (uuid->obj.node[0] & IEEE_MAC_LOBIT_DEC ? "local" : "global"),
+  -            (uuid->obj.node[0] & IEEE_MAC_MCBIT_DEC ? "multicast" : "unicast"));
+  +            (uuid->obj.node[0] & IEEE_MAC_LOBIT ? "local" : "global"),
+  +            (uuid->obj.node[0] & IEEE_MAC_MCBIT ? "multicast" : "unicast"));
+       }
+       else {
+           /* decode anything else as hexadecimal byte-string only */
+  @@ -843,8 +783,8 @@
+       if ((mode & UUID_MAKE_MC) || (uuid->mac[0] & BM_OCTET(1,0,0,0,0,0,0,0))) {
+           /* generate random IEEE 802 local multicast MAC address */
+           prng_data(uuid->prng, (void *)&(uuid->obj.node), sizeof(uuid->obj.node));
+  -        uuid->obj.node[0] |= IEEE_MAC_MCBIT_ENC;
+  -        uuid->obj.node[0] |= IEEE_MAC_LOBIT_ENC;
+  +        uuid->obj.node[0] |= IEEE_MAC_MCBIT;
+  +        uuid->obj.node[0] |= IEEE_MAC_LOBIT;
+       }
+       else {
+           /* use real regular MAC address */

CVSTrac 2.0.1