• Replacing master/slave terminology

    From Nate Coraor@21:1/5 to All on Wed Jun 10 15:48:19 2020
    Hi all,

    I'd like to propose that an effort be made to replace master/slave
    terminology in MIT and Heimdal implementations at some future milestone. I suspect this would be a fairly large undertaking, but hopefully it could be done incrementally and in a largely backwards compatible way. For example,
    ISC BIND now accepts "primary" and "secondary" as synonyms for "master" and "slave" in configuration files and documentation.

    I looked for a prior discussion on this, tracked issues/bugs, etc. but
    didn't find anything, so I apologize if this has been brought up before. I
    am aware that this has been a contentious issue with other projects and I
    am certainly not trying to cause any disagreement, but avoiding these terms
    is a small piece of fostering inclusivity in the world of free and open
    source software. I know that "master" and "slave" are terms in long use in computer science in general and Kerberos in specific, but their direct connection to the institution of slavery should relegate their use where it
    can be helped.

    Thanks,
    --nate

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Hudson@21:1/5 to Nate Coraor on Wed Jun 10 17:03:44 2020
    To: kerberos@mit.edu

    On 6/10/20 3:48 PM, Nate Coraor wrote:
    I'd like to propose that an effort be made to replace master/slave terminology in MIT and Heimdal implementations at some future milestone.

    MIT krb5 switched to using "replica" for non-primary KDCs as of release
    1.17. This was an easy change technically, as the old term was only
    used in a user-visible way in documentation and in the name of one
    profile relation. The pull request for that change was here: https://github.com/krb5/krb5/pull/851

    Replacing the term "master" is a larger technical challenge. We use
    that term in a DNS SRV record label (_master_kdc), and migrating that
    would come with a cost in network traffic and latency. Aside from the
    kprop architecture, we also use the term "master key" to describe the
    key used to encrypt long-term keys in the KDC database.

    I have rationalized to myself that the term "master" is the less
    problematic of the two terms, as it is used in a lot of different
    contexts (such as physical master keys, martial arts masters, master
    plumbers, and master recordings of records). But I don't know if that rationalization is adequate; from recent discussion I know that git's
    use of "master" for the initial default branch name has become a point
    of contention.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nate Coraor@21:1/5 to Greg Hudson on Wed Jun 10 17:26:56 2020
    Copy: kerberos@mit.edu

    On Wed, Jun 10, 2020 at 5:04 PM Greg Hudson <ghudson@mit.edu> wrote:

    MIT krb5 switched to using "replica" for non-primary KDCs as of release
    1.17. This was an easy change technically, as the old term was only
    used in a user-visible way in documentation and in the name of one
    profile relation. The pull request for that change was here: https://github.com/krb5/krb5/pull/851


    Hi Greg,

    This is fantastic and encouraging news, thanks! I'm not sure how I missed
    this. If I can find the time I'll see if it'd be as simple for Heimdal, or perhaps someone from the Heimdal side will chime in. In specific, iprop
    uses "slave" even more prominently than kprop did, I believe.


    Replacing the term "master" is a larger technical challenge. We use
    that term in a DNS SRV record label (_master_kdc), and migrating that
    would come with a cost in network traffic and latency. Aside from the
    kprop architecture, we also use the term "master key" to describe the
    key used to encrypt long-term keys in the KDC database.


    Technical considerations are certainly factors. I wonder if it'd be
    reasonable to allow clients to specify a preference when performing the SRV record lookup?

    I have rationalized to myself that the term "master" is the less
    problematic of the two terms, as it is used in a lot of different
    contexts (such as physical master keys, martial arts masters, master plumbers, and master recordings of records). But I don't know if that rationalization is adequate; from recent discussion I know that git's
    use of "master" for the initial default branch name has become a point
    of contention.


    I largely agree here, it's less problematic. I do think it'd be preferable
    to refer to the "master" server as e.g. "primary", but master key seems
    fine as it has an established unencumbered meaning.

    Thanks,
    --nate

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey Altman@21:1/5 to " on Wed Jun 10 20:00:38 2020
    To: ghudson@mit.edu (Greg Hudson)
    Copy: kerberos@mit.edu

    On 6/10/2020 5:26 PM, Nate Coraor (nate@bx.psu.edu) wrote:
    On Wed, Jun 10, 2020 at 5:04 PM Greg Hudson <ghudson@mit.edu> wrote:

    MIT krb5 switched to using "replica" for non-primary KDCs as of release
    1.17. This was an easy change technically, as the old term was only
    used in a user-visible way in documentation and in the name of one
    profile relation. The pull request for that change was here:
    https://github.com/krb5/krb5/pull/851


    Hi Greg,

    This is fantastic and encouraging news, thanks! I'm not sure how I missed this. If I can find the time I'll see if it'd be as simple for Heimdal, or perhaps someone from the Heimdal side will chime in. In specific, iprop
    uses "slave" even more prominently than kprop did, I believe.

    For Heimdal, the term "slave" is part of the both the iprop process name
    and command line switches for the iprop_master. Changing these could
    adversely impact end user deployments that are not expecting their configuration scripts and packaging to break.

    Replacing the term "master" is a larger technical challenge. We use
    that term in a DNS SRV record label (_master_kdc), and migrating that
    would come with a cost in network traffic and latency. Aside from the
    kprop architecture, we also use the term "master key" to describe the
    key used to encrypt long-term keys in the KDC database.


    Changing the name in DNS SRV records is really untenable. The impact on
    end user organizations would be significant. The support for master_kdc lookups and configuration parsing could not be removed because doing so
    would result in interop failures. Likewise end user organizations would
    be required to publish both the new record and the old.

    Technical considerations are certainly factors. I wonder if it'd be reasonable to allow clients to specify a preference when performing the SRV record lookup?

    Not really. It doesn't change anything other than adding a new
    configuration option that must reference the "master_kdc" service name
    in its documentation.

    As a real world example, in 2011 the IETF deprecated the use of AFSDB
    records in favor of SRV records for AFS services. This was an official standardization action that took more than a year to complete. It has
    been nearly a decade and by my most recent inventory nearly 2/3 of AFS
    cells are still configured with AFSDB records and only 40% have SRV
    records. Approximately five percent support both. As a result it has
    been impossible to even consider removing the support for AFSDB records
    and the additional delays that result from trying one and falling back
    to the other.

    I have rationalized to myself that the term "master" is the less
    problematic of the two terms, as it is used in a lot of different
    contexts (such as physical master keys, martial arts masters, master
    plumbers, and master recordings of records). But I don't know if that
    rationalization is adequate; from recent discussion I know that git's
    use of "master" for the initial default branch name has become a point
    of contention.

    I largely agree here, it's less problematic. I do think it'd be preferable
    to refer to the "master" server as e.g. "primary", but master key seems
    fine as it has an established unencumbered meaning.

    The term "master" applies to the database not the server. The question
    is whether or not the answer to a query is definitive. All of the KDCs
    can serve data from the "master" database. The client needs to know
    that it should retry against another server when it can determine that
    the database isn't a "master" as a noun; its "master" as an adjective.
    Where the use of "master" indicates being an expert, principal or
    instructor.

    Heimdal's documentation should be rewritten to remove the master-slave relationship. If and when there is ever a volunteer to perform that
    work along with all of the other changes that Heimdal's documentation
    requires I will happily merge the pull request.

    Jeffrey Altman




    MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJowggYBMIIE6aADAgECAhBAAWz+KYD2VMyFQOAs831nMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE5MDkwNDIxMjM0OFoXDTIyMTEwMjIxMjM0OFowgZUxNTAzBgNVBAsMLFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMS8wLQYKCZImiZPyLGQBARMfQTAxNDEwRDAw MDAwMTZDRkUyOTgwRTQwMDAwMzlFQjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALRdw150e8iZjFFewsrI/Q5nQtYINFrVpOdYR5RnrrNUvwRrBkkYcFwNWP/wzHOPiaFgthaX ydoQXKqFH0gZ6EaipfJ1L/r8NKAELVf1mTY7Yw+M6EuApsT9X8Ix6DPyhRc9D/rZ4KuBaszA gdpqdBYkkNlcogKPuM6jCzCHfOW3l9Hj1P98GjLmvhK7bDV56kz5NP13rFYe8dln9dvAKY/a MS1Ghrmvuu2VudoYgPPMXYWnhtrLhxuvLiGUXrKissrBuh3JedDdmSAPNrKxpgVP2m7TrH3u 4FY+MFO+Vv8Z9aGtz5FRdLObgQpq1IyQfoMBJtgqBeqaCkuQGCSJo/UCAwEAAaOCAqUwggKh MA4GA1UdDwEB/wQEAwIFoDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8v Y29tbWVyY2lhbC5vY3NwLmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxp ZGF0aW9uLmlkZW50cnVzdC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAW gBSkc9rvaTWKdcygGXsIMvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEb BgtghkgBhvkvAAYLATCCAQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVz dC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCB rgyBq1RoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3Jk YW5jZSB3aXRoIApJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3Vu ZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kv dHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVu dHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTIuY3JsMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2Vj dXJlLWVuZHBvaW50cy5jb20wHQYDVR0OBBYEFM/QuJwMCA6dvJZmfEpnpbYkoY3iMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAuAcupiA1Vgby jH7ldWXvQAHFyI3a2WUfHyPlPkVnFdyRKv8Fo4qwZ6xkHq49lnV6kRKVn88CCFCYb4XOpzUl Q0JXqzD+PYpM90MEixEpFZTVhRnnA9ypB87K16Pq2zEGmC6dyKYFQTS6lWiO5g5/xOPnO6mm mz3lRGXMuLKNSwThnR4fQcFJjV/yuJ0wCdFSHPRflxf3dZ44fkd/AFnA/99w+HpONT94ZR6k foemXuAHnYE9FmOotguxzAIcldwrR795fHTDDyRkiRqwVE7lh5YSkX1kImPMYuDTUw21D7HI mEJsb/+b3HGUpRrnrVOl9UXadEunddldgOp7UB2wUzCCBpEwggR5oAMCAQICEQD53lZ/yU0M d3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAy MTgyMjI1MTlaFw0yMzAyMTgyMjI1MTlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQla3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZ oCx3wef1kwC4pQQV2XHk+AKR+7uMvnOCIw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDT QoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO 1HS2Mfk9LnINeyzjxiXU/iENK07YvjBOxbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45 FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdXsaieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQAB o4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNp YWwub2NzcC5pZGVudHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5p ZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTt RBnA0/AGi+6ke75C5yZUyI42djAPBgNVHRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMw ggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUFBwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50 cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlz IFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0 aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRw czovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXgu aHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L2NybC9jb21tZXJjaWFscm9vdGNhMS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJ KoZIhvcNAQELBQADggIBAA3hgq7S+/TrYxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBb PGWvzdkmbSgYgXo8GxuAon9+HLIjNv68BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/ twQJeRfxHg3I+0Sfwp5xs10YF0RobhrsCRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrT A6045zQTKGzb370whliPLFo+hNL6XzEty5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCm KCPIVPq/+9GqggGvtakM5K3VXNc9VtKPU9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7 yE03nh2jLV7XAkcqad9vS4EB4hKjFFsmcwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6 mYkzqrPigPazF2rgYw3lp0B1gSzCRj+jRtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg 6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCm unLMtaZ2vSai7du/VKrg64GGZNAKerEBevjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q /0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJK32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEw TjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMgIQQAFs/imA9lTMhUDgLPN9ZzANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjExMDAwMDQwWjAvBgkqhkiG 9w0BCQQxIgQge74blke2HufMrtZBx6oMamfbnRM1Gv4hd1rCUde0k7EwXQYJKwYBBAGCNxAE MVAwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVz dElEIENBIEExMgIQQAFs/imA9lTMhUDgLPN9ZzBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkG A1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTIC EEABbP4pgPZUzIVA4CzzfWcwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAxsouorYiMBQgJ0r/3Vcy5 JOLYXC3F203gCoaMvJ/eRF1Am/21G9wgXzTkRhvlX/X3g3JvzLCfqH4/B3vQjXKAmycEc+Y7 aTLDpjbNY/aBvp+OP8uUTwb+bCKNFeySa2H8lqueE0j8zFuVa5dtVGb1uoG3KKS2/W20jf+E LmCk4PfXXyGG4YkTP9sVjoKUbcbaOygXEQ2w+ZfrymHc+RRJwLBQZ46Jdwt+J55IJIHxtnuE m5DvO+oi2Vz4KnuFJMwou2mUdWV3Le02GH4TFBlzIHg6aKjNU44UkJerwXaEjccLX/i6h++T k7oI3iO7Dr7lYawTpCPCd65+qbwYO3/UAAAAAAAA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nate Coraor@21:1/5 to Jeffrey Altman on Thu Jun 11 10:33:10 2020
    Copy: kerberos@mit.edu

    On Wed, Jun 10, 2020 at 8:01 PM Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

    For Heimdal, the term "slave" is part of the both the iprop process name
    and command line switches for the iprop_master. Changing these could adversely impact end user deployments that are not expecting their configuration scripts and packaging to break.


    People installing by hand aside, isn't this more of a vendor packaging
    issue? They deal with changes like this pretty regularly.

    Can the switch to iprop_master can be deprecated but left in place, and ipropd-slave linked to ipropd-replica and similarly deprecated?


    As a real world example, in 2011 the IETF deprecated the use of AFSDB
    records in favor of SRV records for AFS services. This was an official standardization action that took more than a year to complete. It has
    been nearly a decade and by my most recent inventory nearly 2/3 of AFS
    cells are still configured with AFSDB records and only 40% have SRV
    records. Approximately five percent support both. As a result it has
    been impossible to even consider removing the support for AFSDB records
    and the additional delays that result from trying one and falling back
    to the other.


    I'm not suggesting removing support, simply for providing a path forward.

    The term "master" applies to the database not the server. The question
    is whether or not the answer to a query is definitive. All of the KDCs
    can serve data from the "master" database. The client needs to know
    that it should retry against another server when it can determine that
    the database isn't a "master" as a noun; its "master" as an adjective.
    Where the use of "master" indicates being an expert, principal or
    instructor.


    This seems like reasonable framing to me.


    Heimdal's documentation should be rewritten to remove the master-slave relationship. If and when there is ever a volunteer to perform that
    work along with all of the other changes that Heimdal's documentation requires I will happily merge the pull request.


    I'm glad to hear that these changes will be accepted. I'll have a look and
    see what the scope would be.

    Thanks,
    --nate

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)