Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Subject: Policy extensions in 1.11 break iprop dump compatibility
X-RT-Original-Encoding: iso-8859-1
Content-Length: 1175

Ticket 7223 (commit 5829ca2b348974e52a67b553afc7f7491007c33a) extends 
password policy objects to include allowed_keysalts and some other 
fields we might use in the future.  It adds a new r1_11_version dump 
version, but simply edits the ipropx_version structure to use the new 
policy functions.

As a result, with an updated slave and a new master, ipropx full 
dumps fail, because the master generates dump files using the 1.8 
policy format and the slave tries to interpret them using the 1.11 
format.  Compatibility in the other direction (new master, old slave) 
is probably also broken; although the pre-1.11 process_r1_8_policy() 
function claims to ignore additional values on the line, it does not 
appear to do so.

By contrast, when the policy structure was extended in 1.8, a second 
version of the iprop dump format was added, so no iprop compatibility 
issue was created.  The method by which this was done is a little 
confusing (the new format has the tag "ipropx" with a sub-version, 
when it seems that simply adding an "iprop2" tag would be just as 
good).

Here is a report of the issue:

http://mailman.mit.edu/pipermail/kerberos/2015-June/020869.html