Package: libxdmcp-dev Version: 1:1.1.2-1.1 User: helm...@debian.org Usertags: rebootstrap File: /usr/share/doc/libxdmcp-dev/xdmcp.txt.gz
Trying to install a fresh rebuild of libxdmcp-dev (e.g. for a new architecture) results in a file conflict with the packages from the archive on the file /usr/share/doc/libxdmcp-dev/xdmcp.txt.gz. I am attaching a diff of the old and the new version. It is not the first time that this file poses problems to Multi-Arch, see #761628. Options for handling this seem dim at this point. We binNMU on all architectures and carry on. Or we could split out a tiny libxdmcp-doc package. Neither of these options seems particularly attractive. Either way, I need this issue documented somewhere and that's what this bug serves for now. Helmut
--- /dev/fd/5 2016-05-24 06:56:43.303696475 +0200 +++ - 2016-05-24 06:56:43.308400395 +0200 @@ -37,7 +37,7 @@ X Window System is a trademark of The Open Group. -âââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ +âââââââââââââââââââââââââââââââââââââââ Table of Contents @@ -73,18 +73,18 @@ collections of hosts with particular displays. We would like to support the following options: - ⢠The display has a single, fixed host to which it should connect. It should + ⢠The display has a single, fixed host to which it should connect. It should be possible to power on the display and receive a login prompt, without user intervention. - ⢠Any one of several hosts on a network or subnetwork may be acceptable for + ⢠Any one of several hosts on a network or subnetwork may be acceptable for accepting login from the display. (For example, the user's file systems can be mounted onto any such host, providing comparable environments.) It should be possible for the display to broadcast to find such hosts and to have the display either automatically choose a host or present the possible hosts to the user for selection. - ⢠The display has a fixed set of hosts that it can connect to. It should be + ⢠The display has a fixed set of hosts that it can connect to. It should be possible for the display to have that set stored in RAM, but it should also be possible for a site administrator to be able to maintain host sets for a large number of displays using a centralized facility, without having to @@ -111,18 +111,18 @@ Security is an important consideration and must be an integral part of the design. The important security goals in the context of XDMCP are: - ⢠It should be possible for the display to verify that it is communicating + ⢠It should be possible for the display to verify that it is communicating with a legitimate host login service. Because the user will present credentials (for example, password) to this service, it is important to avoid spoof attacks. - ⢠It should be possible for the display and the login service to negotiate + ⢠It should be possible for the display and the login service to negotiate the authorization mechanism to be used for the standard X protocol. - ⢠It should be possible to provide the same level of security in verifying + ⢠It should be possible to provide the same level of security in verifying the login service as is provided by the negotiated authorization mechanism. - ⢠Because there are no firm standards yet in the area of security, XDMCP must + ⢠Because there are no firm standards yet in the area of security, XDMCP must be flexible enough to accomodate a variety of security mechanisms. Chapter 2. Overview of the Protocol @@ -175,45 +175,46 @@ substantially hamper the efficiency of any implementation. Also, no padding of any sort will occur within the packets. -âââââââââââââââ¬ââââââââ¬ââââââââââââââââââââââââââââââââââââââââââââââââââââââââ -âType Name âLength âDescription â -â â(Bytes)â â -âââââââââââââââ¼ââââââââ¼âââââââââââââââââââââââââââââââââââââââââââââââââââââââ⤠-âCARD8 â1 âA single byte unsigned integer â -âââââââââââââââ¼ââââââââ¼âââââââââââââââââââââââââââââââââââââââââââââââââââââââ⤠-âCARD16 â2 âTwo byte unsigned integer â -âââââââââââââââ¼ââââââââ¼âââââââââââââââââââââââââââââââââââââââââââââââââââââââ⤠-âCARD32 â4 âFour byte unsigned integer â -âââââââââââââââ¼ââââââââ¼âââââââââââââââââââââââââââââââââââââââââââââââââââââââ⤠-â â âThis is actually a CARD16 followed by a collection of â -âARRAY8 ân+2 âCARD8. The value of the CARD16 field (n) specifies the â -â â ânumber of CARD8 values to follow â -âââââââââââââââ¼ââââââââ¼âââââââââââââââââââââââââââââââââââââââââââââââââââââââ⤠-âARRAY16 â2*m+1 âThis is a CARD8 (m) which specifies the number of â -â â âCARD16 values to follow â -âââââââââââââââ¼ââââââââ¼âââââââââââââââââââââââââââââââââââââââââââââââââââââââ⤠-âARRAY32 â4*l+1 âThis is a CARD8 (l) which specifies the number of â -â â âCARD32 values to follow â -âââââââââââââââ¼ââââââââ¼âââââââââââââââââââââââââââââââââââââââââââââââââââââââ⤠-âARRAYofARRAY8â? âThis is a CARD8 which specifies the number of ARRAY8 â -â â âvalues to follow. â -âââââââââââââââ´ââââââââ´ââââââââââââââââââââââââââââââââââââââââââââââââââââââââ +âââââââââ¬âââââ¬âââââââââââââââââââââââââ +âType Name âLength âDescription â +â â(Bytes) â â +âââââââââ¼âââââ¼ââââââââââââââââââââââââ⤠+âCARD8 â1 âA single byte unsigned integer â +âââââââââ¼âââââ¼ââââââââââââââââââââââââ⤠+âCARD16 â2 âTwo byte unsigned integer â +âââââââââ¼âââââ¼ââââââââââââââââââââââââ⤠+âCARD32 â4 âFour byte unsigned integer â +âââââââââ¼âââââ¼ââââââââââââââââââââââââ⤠+â â âThis is actually a CARD16 followed by a â +âARRAY8 ân+2 âcollection of CARD8. The value of the CARD16 â +â â âfield (n) specifies the number of CARD8 values â +â â âto follow â +âââââââââ¼âââââ¼ââââââââââââââââââââââââ⤠+âARRAY16 â2*m+1 âThis is a CARD8 (m) which specifies the number â +â â âof CARD16 values to follow â +âââââââââ¼âââââ¼ââââââââââââââââââââââââ⤠+âARRAY32 â4*l+1 âThis is a CARD8 (l) which specifies the number â +â â âof CARD32 values to follow â +âââââââââ¼âââââ¼ââââââââââââââââââââââââ⤠+âARRAYofARRAY8 â? âThis is a CARD8 which specifies the number of â +â â âARRAY8 values to follow. â +âââââââââ´âââââ´âââââââââââââââââââââââââ Chapter 4. Packet Format All XDMCP packets have the following information: -ââââââââââââââââ¬âââââââââââ¬ââââââââââââââââââââââââââââââââââââââ -âLength (Bytes)âField TypeâDescription â -ââââââââââââââââ¼âââââââââââ¼âââââââââââââââââââââââââââââââââââââ⤠-â2 âCARD16 âversion number â -ââââââââââââââââ¼âââââââââââ¼âââââââââââââââââââââââââââââââââââââ⤠-â2 âCARD16 âopcode packet header â -ââââââââââââââââ¼âââââââââââ¼âââââââââââââââââââââââââââââââââââââ⤠-â2 âCARD16 ân = length of remaining data in bytesâ -ââââââââââââââââ¼âââââââââââ¼âââââââââââââââââââââââââââââââââââââ⤠-ân â??? âpacket-specific data â -ââââââââââââââââ´âââââââââââ´ââââââââââââââââââââââââââââââââââââââ +âââââââââ¬ââââââ¬ââââââââââââââââââââ +âLength (Bytes)âField TypeâDescription â +âââââââââ¼ââââââ¼âââââââââââââââââââ⤠+â2 âCARD16 âversion number â +âââââââââ¼ââââââ¼âââââââââââââââââââ⤠+â2 âCARD16 âopcode packet header â +âââââââââ¼ââââââ¼âââââââââââââââââââ⤠+â2 âCARD16 ân = length of remaining data in bytes â +âââââââââ¼ââââââ¼âââââââââââââââââââ⤠+ân â??? âpacket-specific data â +âââââââââ´ââââââ´ââââââââââââââââââââ The fields are as follows: @@ -977,43 +978,43 @@ by a valid scope id) or to a locally assigned multicast address. The version number in all packets will be 1. Packet opcodes are 16-bit integers. -ââââââââââââââââââââââââââââââââââââââââââââââââââ¬âââââââââââââââââââââââââââââ -âPacket Name âEncoding â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âBroadcastQuery â1 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âQuery â2 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âIndirectQuery â3 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âForwardQuery â4 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âWilling â5 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âUnwilling â6 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âRequest â7 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âAccept â8 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âDecline â9 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âManage â10 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âRefuse â11 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âFailed â12 â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âKeepAlive â13 ^[a] â -ââââââââââââââââââââââââââââââââââââââââââââââââââ¼ââââââââââââââââââââââââââââ⤠-âAlive â14 ^[b] â -ââââââââââââââââââââââââââââââââââââââââââââââââââ´ââââââââââââââââââââââââââââ⤠-â^[a] A previous version of this document incorrectly reversed the opcodes of â -âAlive and KeepAlive. â -â â -â^[b] A previous version of this document incorrectly reversed the opcodes of â -âAlive and KeepAlive. â -âââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ +âââââââââââââââââââââââââ¬ââââââââââââââ +âPacket Name âEncoding â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âBroadcastQuery â1 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âQuery â2 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âIndirectQuery â3 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âForwardQuery â4 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âWilling â5 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âUnwilling â6 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âRequest â7 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âAccept â8 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âDecline â9 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âManage â10 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âRefuse â11 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âFailed â12 â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âKeepAlive â13 ^[a] â +âââââââââââââââââââââââââ¼âââââââââââââ⤠+âAlive â14 ^[b] â +âââââââââââââââââââââââââ´âââââââââââââ⤠+â^[a] A previous version of this document incorrectly reversed the opcodes â +âof Alive and KeepAlive. â +â â +â^[b] A previous version of this document incorrectly reversed the opcodes â +âof Alive and KeepAlive. â +âââââââââââââââââââââââââââââââââââââââ Per packet information follows: @@ -1216,19 +1217,19 @@ Some definitions first: - ⢠{D}^κ = encryption of plain text D by key κ + ⢠{D}^κ = encryption of plain text D by key κ - ⢠{Î}*^κ = decryption of crypto text Î with key κ + ⢠{Î}*^κ = decryption of crypto text Î with key κ - â¢ Ï = private key shared by display and manager + â¢ Ï = private key shared by display and manager - â¢ Ï = 64 bit random number generated by display + â¢ Ï = 64 bit random number generated by display - ⢠α = authentication data in XDMCP packets + ⢠α = authentication data in XDMCP packets - â¢ Ï = per-session private key, generated by manager + â¢ Ï = per-session private key, generated by manager - ⢠β = authorization data + ⢠β = authorization data Encryption will use the Data Encryption Standard (DES, FIPS 46-3); blocks shorter than 64 bits will be zero-filled on the right to 64 bits. Blocks longer @@ -1272,11 +1273,11 @@ server. The server receives the packet, decrypts the contents. To accept the connection, the following must hold: - â¢ Ï must match the value generated for the most recent XDMCP negotiation. + â¢ Ï must match the value generated for the most recent XDMCP negotiation. - ⢠T must be within 1200 seconds of the internally stored time. If no time + ⢠T must be within 1200 seconds of the internally stored time. If no time been received before, the current time is set to T. - ⢠No packet containing the same pair (N, T) can have been received in the + ⢠No packet containing the same pair (N, T) can have been received in the last 1200 seconds (20 minutes).