Good Afternoon

I can host Debian Je= ssie i386 and amd64 slaves.=C2=A0 I'll get them setup tonight.

<= /div>-Nathan

On Wed, Jan 21, 2015 at 3:57 PM, Garrett Wollman <= ;wollman@csail.m= it.edu> wrote:

<<On Tue, 20 Jan 2015 20:43:18 -0500, Jason Edgecombe <jason@rampaginggeek.com> said:=

> What types of management do you need others to provide?
> * initial installation of OS

Since VMs would be set up from images this is not required.

> * general maintenance and patching of OS

For our (CSAIL's) managed Ubuntu VMs this happens semi-automatic= ally.
For a generic Debian I would want someone else to be keeping an eye on
it.=C2=A0 (I already do this for the FreeBSD buildslaves.)

> * installation and management of the buildslave software (without root=
> access)

Installation and configuration of the actual buildslave is something=
that I can do, but since I'm not familiar with doing it on Debianoid systems it would be nicer to have a recipe to follow.=C2=A0 (On our managed=
Ubuntu platform we would get Puppet to do this, if there was any
chance of having more than one VM.)

-GAWollman

_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org<= br> https://lists.openafs.org/mailman/listinfo/openafs-devel

--001a1135ebe457345e050e355be6-- From jaltman@your-file-system.com Tue Feb 3 22:01:46 2015 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Tue, 03 Feb 2015 17:01:46 -0500 Subject: [OpenAFS-devel] Retiring the debian-i386 buildbot slave. Do we need a replacement? In-Reply-To: References: <54BD7984.4060701@rampaginggeek.com> <21694.60248.90061.809201@khavrinen.csail.mit.edu> <54BF0436.90401@rampaginggeek.com> <21696.4799.526318.805959@khavrinen.csail.mit.edu> Message-ID: <54D1454A.1050309@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms090301060507060105080501 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/3/2015 4:00 PM, Nathaniel Hatley wrote: > Good Afternoon >=20 > I can host Debian Jessie i386 and amd64 slaves. I'll get them setup > tonight. >=20 > -Nathan Thank you. Jeffrey Altman --------------ms090301060507060105080501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhAW xDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMzg2MTAyMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCteTFLbuPm2vx85lH2 Y6LHdMIqcKQPN9m4XYVTe0L8ZvMvnJ1YQ720ET52CF18RYdTc4to92+ffdmjWlBedK4YtLam htsUkJ6WL3krwNVTYfeej0wgF9kVQ2FI8XTNngxnJ2CRkQX4Z9/1TI4wTkSNcAw5T0Y2HKM9 4p7wAJOefl+3oPwxXn338w8T7LsfwS9FOADZ8uRItv/J7S8BJEP0XtjZZlBoSyqQ4qxl5PtI uybHVdwoo2PlK8LxU6r8Vcje1+OXmc5VoCBlXiYDWHl/wSDtZEWR6431/az1Z45n1AHHber2 G+Ijb0nF4RLiiFMkyJl3qx+46wqcqWrjrRxDAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFBUlv/9jizZz4uwaFtPzwdX6FsqwMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBAJIvoMatM56/QjaVAlEUbeWZNOPkwuiC gaaekWJi1h33fAVfdF+WZqh7dF4hBNalyPuxRcyZX7HxuPyBc3ajDCqew9MlmCJ3Cm4Co3fZ Yh50OX4jnem2RmpHeKbJW6zUjZcAGqV6DPMl04kgrI2whJX7729HoRyUPwZS7CZSRFZO147X 2+/JogDYKffa/+q5AwgrHYvdECHxc3Iz9KnHSmit+DhWS9t+XxE0gHr3sW7zwcQ/GYyrJ3s3 VdWHTjM+3iGFeTOI06h1aBgFR/+8fTmuZXZz9+OdWVar0Crt9bn0cFN3u00Q6YAyjYhRnbXy zYVIOS4oJmRoK79p/xodeDUxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBbEMEm4oBwlVrtv5MmH C8QwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwMjAzMjIwMTQ2WjAjBgkqhkiG9w0BCQQxFgQURw9L4mRtKh1wF+oQiFu+FM6O 4pEwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQFsQwSbigHCVWu2/kyYcLxDCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAWxDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEB AQUABIIBAHaF6m3tfyurJrIRRekv0HPvMyM+WbV/3tpFSk/OBR1e2SNSjVmFh0qqrDNkPOvn DweXlIYsXRbzgyhTS7hOM++WOBw7LKGbQWvzHBdynv0Gz1ktcDbuunEuJH0pF+h+niKvjdMp /jnWGPPmXhKXOlwW9piTRufZWDkDy2D7mj03K/x1t7vn+S1IrvHnw+sy2Oisc/6ZqZgFFKpj PyUcL6nJEdgERUhP63/RaCxydbJDVEISa9Uje+kDBLVTmpXDLZvO650cG2t11zuuDPrLU8f5 EkQzXZXT4F8kD0yljhLvZTc4MmTbhi9CnSV/Hck1BWCeYLMo2qi/OiZ1G3+K6EYAAAAAAAA= --------------ms090301060507060105080501-- From kaduk@MIT.EDU Wed Feb 4 22:33:49 2015 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Wed, 4 Feb 2015 17:33:49 -0500 (EST) Subject: [OpenAFS-devel] encrypting server-to-server traffic by default? Message-ID: Hi all, In the leadup to 1.8, there's been some talk about encrypting server-to-server traffic by default; gerrit 11349 for VolForward traffic has been sitting around for a while, but viced traffic to the dbservers could also get encrypted, and the ubik traffic as well. This would of course need to be configurable for sites which are not willing to pay the performance penalty. It seems like we may not need or want to introduce individual knobs for each place where afsconf_ClientAuth is used, and could instead have a single knob for the everything that lives under the afsconf abstraction. Keeping it under the afsconf abstraction would give us a lot of flexibility in implementation, and also a convenient place to put a knob for using rxgk for client connections as well. At the moment, I'm thinking about a flat text file with key/value pairs. (Well, just one to start.) Does that seem reasonable? (Any ideas for what to name it?) Thoughts about whether we should encrypt server-to-server traffic by default are also welcome, including suggesting that discussion move to -info. -Ben From jaltman@your-file-system.com Wed Feb 4 22:45:02 2015 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Wed, 04 Feb 2015 17:45:02 -0500 Subject: [OpenAFS-devel] encrypting server-to-server traffic by default? In-Reply-To: References: Message-ID: <54D2A0EE.2050107@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms070602010107060306000105 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/4/2015 5:33 PM, Benjamin Kaduk wrote: > > Thoughts about whether we should encrypt server-to-server traffic by > default are also welcome, including suggesting that discussion move to > -info. Any discussion of behavior change that impacts end user sites (as opposed to how to implement said behavior change) should be held on openafs-info. Thanks. Jeffrey Altman --------------ms070602010107060306000105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhAW xDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMzg2MTAyMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCteTFLbuPm2vx85lH2 Y6LHdMIqcKQPN9m4XYVTe0L8ZvMvnJ1YQ720ET52CF18RYdTc4to92+ffdmjWlBedK4YtLam htsUkJ6WL3krwNVTYfeej0wgF9kVQ2FI8XTNngxnJ2CRkQX4Z9/1TI4wTkSNcAw5T0Y2HKM9 4p7wAJOefl+3oPwxXn338w8T7LsfwS9FOADZ8uRItv/J7S8BJEP0XtjZZlBoSyqQ4qxl5PtI uybHVdwoo2PlK8LxU6r8Vcje1+OXmc5VoCBlXiYDWHl/wSDtZEWR6431/az1Z45n1AHHber2 G+Ijb0nF4RLiiFMkyJl3qx+46wqcqWrjrRxDAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFBUlv/9jizZz4uwaFtPzwdX6FsqwMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBAJIvoMatM56/QjaVAlEUbeWZNOPkwuiC gaaekWJi1h33fAVfdF+WZqh7dF4hBNalyPuxRcyZX7HxuPyBc3ajDCqew9MlmCJ3Cm4Co3fZ Yh50OX4jnem2RmpHeKbJW6zUjZcAGqV6DPMl04kgrI2whJX7729HoRyUPwZS7CZSRFZO147X 2+/JogDYKffa/+q5AwgrHYvdECHxc3Iz9KnHSmit+DhWS9t+XxE0gHr3sW7zwcQ/GYyrJ3s3 VdWHTjM+3iGFeTOI06h1aBgFR/+8fTmuZXZz9+OdWVar0Crt9bn0cFN3u00Q6YAyjYhRnbXy zYVIOS4oJmRoK79p/xodeDUxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBbEMEm4oBwlVrtv5MmH C8QwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwMjA0MjI0NTAyWjAjBgkqhkiG9w0BCQQxFgQUuImo7Q/P6xJmRS+a9QGg/WuS 1/owbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQFsQwSbigHCVWu2/kyYcLxDCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAWxDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEB AQUABIIBAIm2lTh/8lDnG3GSmFRS6ltuCQ1bS0sM3vA3npf6AmsDdWYhM7mUWNsVJ/hAOzJn qcY4vRq50gVWnmC422AJM4fZ4yI2C8jiALf+lSm5XLE1jbd+cU3hViZ7T+JbyI7GhEBx6bUU oMsQQVklznFHIc2RFXKV88+fkSIPOqOEAb0nRahNe6FK4VO2t0/CLVoZpoMQ8UlXbflSb2hW wCN+aVBVWkkOZI9gAUDe8d+tn4RVJiBrBijkpX5snrTq7+YWOfrrKoi5g9VXO1iIoBa/luBC v9Jh1XCHuHw0xc2v9DrJZUTNHXBuODUTGNWBeeplKSD0y+sA5Q9wSp0+ypMvahkAAAAAAAA= --------------ms070602010107060306000105-- From kaduk@MIT.EDU Wed Feb 4 23:34:50 2015 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Wed, 4 Feb 2015 18:34:50 -0500 (EST) Subject: [OpenAFS-devel] encrypting server-to-server traffic by default? In-Reply-To: <54D2A0EE.2050107@your-file-system.com> References: <54D2A0EE.2050107@your-file-system.com> Message-ID: On Wed, 4 Feb 2015, Jeffrey Altman wrote: > On 2/4/2015 5:33 PM, Benjamin Kaduk wrote: > > > > Thoughts about whether we should encrypt server-to-server traffic by > > default are also welcome, including suggesting that discussion move to > > -info. > > Any discussion of behavior change that impacts end user sites (as > opposed to how to implement said behavior change) should be held on > openafs-info. So, the implementation discussion should continue here and I will start a new thread on -info about what the default should/could be, okay. -Ben From jaltman@your-file-system.com Wed Feb 4 23:42:45 2015 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Wed, 04 Feb 2015 18:42:45 -0500 Subject: [OpenAFS-devel] encrypting server-to-server traffic by default? In-Reply-To: References: <54D2A0EE.2050107@your-file-system.com> Message-ID: <54D2AE75.6030802@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms050806040505000601050605 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/4/2015 6:34 PM, Benjamin Kaduk wrote: > > So, the implementation discussion should continue here and I will start= a > new thread on -info about what the default should/could be, okay. >=20 > -Ben Sounds good. --------------ms050806040505000601050605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhAW xDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMzg2MTAyMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCteTFLbuPm2vx85lH2 Y6LHdMIqcKQPN9m4XYVTe0L8ZvMvnJ1YQ720ET52CF18RYdTc4to92+ffdmjWlBedK4YtLam htsUkJ6WL3krwNVTYfeej0wgF9kVQ2FI8XTNngxnJ2CRkQX4Z9/1TI4wTkSNcAw5T0Y2HKM9 4p7wAJOefl+3oPwxXn338w8T7LsfwS9FOADZ8uRItv/J7S8BJEP0XtjZZlBoSyqQ4qxl5PtI uybHVdwoo2PlK8LxU6r8Vcje1+OXmc5VoCBlXiYDWHl/wSDtZEWR6431/az1Z45n1AHHber2 G+Ijb0nF4RLiiFMkyJl3qx+46wqcqWrjrRxDAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFBUlv/9jizZz4uwaFtPzwdX6FsqwMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBAJIvoMatM56/QjaVAlEUbeWZNOPkwuiC gaaekWJi1h33fAVfdF+WZqh7dF4hBNalyPuxRcyZX7HxuPyBc3ajDCqew9MlmCJ3Cm4Co3fZ Yh50OX4jnem2RmpHeKbJW6zUjZcAGqV6DPMl04kgrI2whJX7729HoRyUPwZS7CZSRFZO147X 2+/JogDYKffa/+q5AwgrHYvdECHxc3Iz9KnHSmit+DhWS9t+XxE0gHr3sW7zwcQ/GYyrJ3s3 VdWHTjM+3iGFeTOI06h1aBgFR/+8fTmuZXZz9+OdWVar0Crt9bn0cFN3u00Q6YAyjYhRnbXy zYVIOS4oJmRoK79p/xodeDUxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBbEMEm4oBwlVrtv5MmH C8QwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwMjA0MjM0MjQ1WjAjBgkqhkiG9w0BCQQxFgQUYS4x+WC5rNGVHH2/wOk/yz6U 4ZowbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQFsQwSbigHCVWu2/kyYcLxDCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAWxDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEB AQUABIIBAAC4BicpjL58Q83q3w141xGHjBxsXueFRfA8q9fBTHcEFSTn+CYuv5Y7KBCC4xwJ VzN0gjA5eeWAnqz63lo9iNR5DtcRN4HhY5+9n0Y2OG+AaDEOZeus7tV/SNCD1/MO3ig+GWJD YQ7MFu7xVjzRI46RccdJFM6+Zo4LRBhDsi/8PnDGWmuOrzdFufZppTcS5vjizezG9DbKF3UU /7d2ArUngiQ1drqQ6H4PjcX5EA13S9WR8shEz6pCBFlSo0qQSEG2t0IP5HEsLoOicmxdR4+m 4kKuKrCBrnD0f8uOJzCgDaGAxvkUn+hcd2ylJVT00Dc9Wyv2j/x9CRB5VSiQ9zUAAAAAAAA= --------------ms050806040505000601050605-- From kaduk@MIT.EDU Thu Feb 5 04:56:21 2015 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Wed, 4 Feb 2015 23:56:21 -0500 (EST) Subject: [OpenAFS-devel] any interest in testing a volscan patch? Message-ID: The change in http://gerrit.openafs.org/#change,11377 is basically just sitting around waiting for runtime testing; it's the sort of cleanup that would be a good fit for 1.8. -Ben From jason@rampaginggeek.com Sun Feb 8 15:09:22 2015 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Sun, 08 Feb 2015 10:09:22 -0500 Subject: [OpenAFS-devel] ubuntu nightly build failed Message-ID: <54D77C22.9090407@rampaginggeek.com> Hi everyone, The nightly build on ubuntu is failing. The log file is at: http://buildbot.openafs.org:8010/builders/ubuntu14-x86_64-builder/builds/3/steps/compile/logs/stdio Here is a snippet of the log: make[3]: Entering directory `/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-builder/build/src/uss' ( VERSION=`/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-builder/build/build-tools/git-version /var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-builder/build "1.5.76-4578-g73cad"` && \ echo 'char cml_version_number[]="@(#)OpenAFS '$VERSION `date +"%Y-%m-%d"` $USER@`hostname`'";' >AFS_component_version_number.c.NEW && \ echo 'char* AFSVersion = "openafs '$VERSION'";' >>AFS_component_version_number.c.NEW && \ if cmp AFS_component_version_number.c.NEW AFS_component_version_number.c > /dev/null 2>&1 ; then : ; else \ mv AFS_component_version_number.c.NEW AFS_component_version_number.c ; fi ) rm -f AFS_component_version_number.c.NEW gcc -fPIC -O -Wall -Wstrict-prototypes -Wold-style-definition -Werror -fdiagnostics-show-option -Wpointer-arith -I/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-builder/build/src/config -I/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-builder/build/include -I. -I. -o uss.o -c uss.c gcc -fPIC -O -Wall -Wstrict-prototypes -Wold-style-definition -Werror -fdiagnostics-show-option -Wpointer-arith -I/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-builder/build/src/config -I/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-builder/build/include -I. -I. -o uss_procs.o -c uss_procs.c uss_procs.c: In function ‘Copy’: uss_procs.c:541:7: error: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Werror=unused-result] write(fd1, buf, cnt); ^ uss_procs.c:543:10: error: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Werror=unused-result] write(fd1, buf, cnt); ^ uss_procs.c: In function ‘Echo’: uss_procs.c:611:10: error: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Werror=unused-result] write(fd, a_s, strlen(a_s)); ^ uss_procs.c:612:10: error: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Werror=unused-result] write(fd, "\n", 1); ^ cc1: all warnings being treated as errors From kaduk@MIT.EDU Sun Feb 8 21:24:25 2015 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Sun, 8 Feb 2015 16:24:25 -0500 (EST) Subject: [OpenAFS-devel] ubuntu nightly build failed In-Reply-To: <54D77C22.9090407@rampaginggeek.com> References: <54D77C22.9090407@rampaginggeek.com> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-399284304-1423430665=:3953 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE I started working on a patch but got distracted. The warnings are for the most part pointing out real bugs, so it will not be a trivial patch. -Ben On Sun, 8 Feb 2015, Jason Edgecombe wrote: > Hi everyone, > > The nightly build on ubuntu is failing. > The log file is at: > http://buildbot.openafs.org:8010/builders/ubuntu14-x86_64-builder/builds/= 3/steps/compile/logs/stdio > > Here is a snippet of the log: > > make[3]: Entering directory > `/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-build= er/build/src/uss' > ( > VERSION=3D`/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x8= 6_64-builder/build/build-tools/git-version > /var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-builde= r/build > "1.5.76-4578-g73cad"` && \ > =09echo 'char cml_version_number[]=3D"@(#)OpenAFS '$VERSION `date > +"%Y-%m-%d"` $USER@`hostname`'";' >AFS_component_version_number.c.NEW && = \ > =09echo 'char* AFSVersion =3D "openafs '$VERSION'";' > >>AFS_component_version_number.c.NEW && \ > =09if cmp AFS_component_version_number.c.NEW > AFS_component_version_number.c > /dev/null 2>&1 ; then : ; else \ > =09mv AFS_component_version_number.c.NEW AFS_component_version_number.c ; > fi ) > rm -f AFS_component_version_number.c.NEW > gcc -fPIC -O -Wall -Wstrict-prototypes -Wold-style-definition -Werror > -fdiagnostics-show-option -Wpointer-arith > -I/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-buil= der/build/src/config > -I/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-buil= der/build/include > -I. -I. -o uss.o -c uss.c > gcc -fPIC -O -Wall -Wstrict-prototypes -Wold-style-definition -Werror > -fdiagnostics-show-option -Wpointer-arith > -I/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-buil= der/build/src/config > -I/var/lib/buildbot/slaves/openafs-ubuntu1404-x86_64/ubuntu14-x86_64-buil= der/build/include > -I. -I. -o uss_procs.o -c uss_procs.c > uss_procs.c: In function =E2=80=98Copy=E2=80=99: > uss_procs.c:541:7: error: ignoring return value of =E2=80=98write=E2=80= =99, declared with > attribute warn_unused_result [-Werror=3Dunused-result] > write(fd1, buf, cnt); > ^ > uss_procs.c:543:10: error: ignoring return value of =E2=80=98write=E2=80= =99, declared with > attribute warn_unused_result [-Werror=3Dunused-result] > write(fd1, buf, cnt); > ^ > uss_procs.c: In function =E2=80=98Echo=E2=80=99: > uss_procs.c:611:10: error: ignoring return value of =E2=80=98write=E2=80= =99, declared with > attribute warn_unused_result [-Werror=3Dunused-result] > write(fd, a_s, strlen(a_s)); > ^ > uss_procs.c:612:10: error: ignoring return value of =E2=80=98write=E2=80= =99, declared with > attribute warn_unused_result [-Werror=3Dunused-result] > write(fd, "\n", 1); > ^ > cc1: all warnings being treated as errors > > > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel > ---559023410-399284304-1423430665=:3953-- From saket.sinha89@gmail.com Tue Feb 10 03:50:11 2015 From: saket.sinha89@gmail.com (Saket Sinha) Date: Tue, 10 Feb 2015 09:20:11 +0530 Subject: [OpenAFS-devel] OpenAFS Participation in GSOC 2015 Message-ID: --001a113d2bdea56189050eb3c8aa Content-Type: text/plain; charset=UTF-8 Hi , This is to enquire as to whether OpenAFS will be participating in GSOC this year? The Mentoring Organization applications are now being accepted for Google Summer of Code 2015. http://google-opensource.blogspot.in/2015/02/mentoring-organization-applications-now.html Regards, Saket Sinha --001a113d2bdea56189050eb3c8aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi ,
=C2=A0 This is to enq= uire as to whether=C2=A0OpenAFS =C2=A0will be participating in GSOC this ye= ar?

The Mentoring Organization applications a= re now being accepted for Google Summer of Code 2015.

http://google-opensource.b= logspot.in/2015/02/mentoring-organization-applications-now.html<= br style=3D"font-size:12.8000001907349px">

Regards,
Saket Sinha

--001a113d2bdea56189050eb3c8aa-- From kaduk@MIT.EDU Tue Feb 10 19:17:52 2015 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Tue, 10 Feb 2015 14:17:52 -0500 (EST) Subject: [OpenAFS-devel] OpenAFS Participation in GSOC 2015 In-Reply-To: References: Message-ID: On Mon, 9 Feb 2015, Saket Sinha wrote: > Hi , > > This is to enquire as to whether OpenAFS will be participating in GSOC > this year? > > The Mentoring Organization applications are now being accepted for Google > Summer of Code 2015. > http://google-opensource.blogspot.in/2015/02/mentoring-organization-applications-now.html My understanding (as someone with no official capacity) is that in the past few years OpenAFS has decided to not apply to be a mentoring organization due to a lack of mentors able to commit the requisite amount of time. I don't have any particular reason to believe that the situation is different this year. -Ben Kaduk From botsch@cnf.cornell.edu Tue Feb 10 19:28:41 2015 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Tue, 10 Feb 2015 14:28:41 -0500 Subject: [OpenAFS-devel] OpenAFS Participation in GSOC 2015 In-Reply-To: References: Message-ID: <20150210192840.GC18684@cnf.cornell.edu> So, the question for this year is, is there anyone that has ideas for a project that has time/would be willing to mentor? On Tue, Feb 10, 2015 at 02:17:52PM -0500, Benjamin Kaduk wrote: > On Mon, 9 Feb 2015, Saket Sinha wrote: > > > Hi , > > > > This is to enquire as to whether OpenAFS will be participating in GSOC > > this year? > > > > The Mentoring Organization applications are now being accepted for Google > > Summer of Code 2015. > > http://google-opensource.blogspot.in/2015/02/mentoring-organization-applications-now.html > > My understanding (as someone with no official capacity) is that in the > past few years OpenAFS has decided to not apply to be a mentoring > organization due to a lack of mentors able to commit the requisite amount > of time. I don't have any particular reason to believe that the situation > is different this year. > > -Ben Kaduk > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel -- ******************************** David William Botsch Programmer/Analyst @CNFComputing botsch@cnf.cornell.edu ******************************** From kaduk@MIT.EDU Mon Feb 23 21:09:27 2015 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Mon, 23 Feb 2015 16:09:27 -0500 (EST) Subject: [OpenAFS-devel] test jenkins hash conversions? Message-ID: Hi all, In order to enable increasing the size of some hash tables in the tree, we put together some patches to switch the hash tables to using the jenkins hash from opr (instead of just using modular division) in gerrit 11673 and 11679. It would be nice if these changes get some runtime testing before getting merged, if anyone is in a position to do so. -Ben From kaduk@MIT.EDU Wed Feb 25 17:54:34 2015 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Wed, 25 Feb 2015 12:54:34 -0500 (EST) Subject: [OpenAFS-devel] Fwd: On desupporting Linux 2.4 Message-ID: I probably should have (b)cc'd -devel on this one, sorry. -Ben ---------- Forwarded message ---------- Date: Wed, 25 Feb 2015 12:51:30 -0500 From: Benjamin Kaduk To: openafs-info@openafs.org Subject: [OpenAFS] On desupporting Linux 2.4 Hi all, Linux 2.4 is getting long in the tooth, and it is becoming clear that attempting to continue to support it is a drain on the scarce OpenAFS development resources which could be better used to modernize the codebase and implement security and performance improvements such as rxgk and fine-grained pthreaded locking. In particular, the threading library used by Linux 2.4, LinuxThreads, is not compliant to the POSIX (pthread) standard, and the non-standard behaviors are preventing improvements to OpenAFS such as http://gerrit.openafs.org/#change,6947 . Even attempting to retain the old OpenAFS behavior on systems with LinuxThreads and provide improved functionality for other systems seems to be beyond the available developer resources. When discussion on http://gerrit.openafs.org/#change,6947 began in 2012, it was claimed that dropping support for Linux 2.4 was premature at that time. It is now nearly three years later, and no progress has been made on that change in gerrit, because of the difficulty of dealing with LinuxThreads and Linux 2.4. As such, I propose that OpenAFS drop support for Linux 2.4 (and thus LinuxThreads) starting with the forthcoming 1.8 release. Because this is a substantial change, I invite comments from the community as to whether it is appropriate and acceptable to desupport Linux 2.4, and what the scope of the impact of such a change would be. Thank you, Ben Kaduk _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From wollman@csail.mit.edu Thu Feb 26 20:53:50 2015 From: wollman@csail.mit.edu (Garrett Wollman) Date: Thu, 26 Feb 2015 15:53:50 -0500 Subject: [OpenAFS-devel] FreeBSD 10.x buildslave upgrade Message-ID: <21743.34782.432336.425764@khavrinen.csail.mit.edu> The FreeBSD 10.x buildslave has been upgraded from 10.0 to 10.1, as support for FreeBSD 10.0 ends on Friday. There should be no differences as far as the OpenAFS code base is concerned; however, the upgrade does update clang to 3.4.1 (as the system compiler). -GAWollman From openafs-info@openafs.org Fri Feb 27 20:26:07 2015 From: openafs-info@openafs.org (Benjamin Kaduk) Date: Fri, 27 Feb 2015 15:26:07 -0500 (EST) Subject: [OpenAFS-devel] Encrypted connections by default in OpenAFS 1.8? Message-ID: Hi all, The progress towards a 1.8 release is well underway, and it is time to consider what behavior changes are desired for the major release boundary. One change which has been proposed is to encrypt connections by default. There has long been the 'fs setcrypt' command (introduced in 2001) to allow the connections from a cache manager to the servers in the cell (which most distributions' packaging enable by default). However, there is not currently an option to enable encryption for the intra-dbserver connections which effect ubik replication, or for other server-to-server connections such as fileserver queries to the protection server, and volume forwarding traffic. Given events in the news in recent years, it seems to me that we do our users a disservice by not using a "secure" mode operation by default. (Quote around "secure" are necessary given the known weaknesses of the fcrypt encryption used by rxkad, but with the rxkad-k5 extension, there does remain some level of protection to offer.) Though rxkad encryption is known to introduce severe performance penalties, administrators who require the extra performance should be able to discover that and use the documented procedure for disabling encryption. Administrators who just want to set something up and have it running would be protected, without needing to know that they need to go through the effort of finding the documentation and enabling encryption everywhere. I propose that the OpenAFS 1.8 major release introduce encryption by default, for all(*) connections, whether client-to-server or server-to-server. There would of course be knobs to disable encryption for sites which do not need it, but the default value would be "on". In addition to feedback on the general proposal for encrypt-by-default, I would appreciate feedback on more detailed questions, which might shape the structure of an implementation: (1) Is it sufficient to have one single knob that controls all connections from a given host, whether cache manager or server? (2) (Assuming that the answer to (1) is "no") Should there be separate knobs knob for intra-ubik connections, fileserver-to-ptserver, and volserver-to-volserver connections? (3) What downsides do you see as possible for a new text-based configuration file to control the various behaviors? (Looking forward, this could also be a place to configure selection of rxgk vs. rxkad.) No decisions have been made; this thread is me seeking feedback from the community on an issue where I have an opinion but do not know the position of the community as a whole. Thank you, Ben (*) My current proposal affects mostly the cache manager; encryption-by-default for the standalong client tools (vos, pts, bos, etc.) would be configurable in a different way, presumably with a command-line option. From jason@rampaginggeek.com Sat Feb 28 02:51:18 2015 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Fri, 27 Feb 2015 21:51:18 -0500 Subject: [OpenAFS-devel] Re: [OpenAFS] Encrypted connections by default in OpenAFS 1.8? In-Reply-To: References: Message-ID: <54F12D26.5000301@rampaginggeek.com> On 02/27/2015 03:26 PM, Benjamin Kaduk wrote: > Hi all, > > The progress towards a 1.8 release is well underway, and it is time to > consider what behavior changes are desired for the major release boundary. > > One change which has been proposed is to encrypt connections by default. > There has long been the 'fs setcrypt' command (introduced in 2001) to > allow the connections from a cache manager to the servers in the cell > (which most distributions' packaging enable by default). However, there > is not currently an option to enable encryption for the intra-dbserver > connections which effect ubik replication, or for other server-to-server > connections such as fileserver queries to the protection server, and > volume forwarding traffic. > > Given events in the news in recent years, it seems to me that we do our > users a disservice by not using a "secure" mode operation by default. > (Quote around "secure" are necessary given the known weaknesses of the > fcrypt encryption used by rxkad, but with the rxkad-k5 extension, there > does remain some level of protection to offer.) Though rxkad encryption > is known to introduce severe performance penalties, administrators who > require the extra performance should be able to discover that and use > the documented procedure for disabling encryption. Administrators who > just want to set something up and have it running would be protected, > without needing to know that they need to go through the effort of finding > the documentation and enabling encryption everywhere. > > I propose that the OpenAFS 1.8 major release introduce encryption by > default, for all(*) connections, whether client-to-server or > server-to-server. There would of course be knobs to disable encryption > for sites which do not need it, but the default value would be "on". > > In addition to feedback on the general proposal for encrypt-by-default, I > would appreciate feedback on more detailed questions, which might shape > the structure of an implementation: > > (1) Is it sufficient to have one single knob that controls all connections > from a given host, whether cache manager or server? > > (2) (Assuming that the answer to (1) is "no") Should there be separate > knobs knob for intra-ubik connections, fileserver-to-ptserver, and > volserver-to-volserver connections? > > (3) What downsides do you see as possible for a new text-based > configuration file to control the various behaviors? (Looking forward, > this could also be a place to configure selection of rxgk vs. rxkad.) > > > No decisions have been made; this thread is me seeking feedback from the > community on an issue where I have an opinion but do not know the position > of the community as a whole. > > Thank you, > > Ben > > > (*) My current proposal affects mostly the cache manager; > encryption-by-default for the standalong client tools (vos, pts, bos, > etc.) would be configurable in a different way, presumably with a > command-line option. I suggest the following knobs: * client ** fs set crypt ** option/config file for vos and friends if they can't read 'fs getcrypt' * server ** file server option to force authenticated access to use encryption ** option to force/disable encryption for ubik ** option to force/disable other server-to-server stuff I wouldn't object to having knobs for the ptserver-fileserver and volserver connections, but I don't see much point. As an admin, I look at this according to the likely upgrade scenarios and exposure. I tend to upgrade in batches of clients, file servers, and cell servers. I think the biggest exposure, in an on-premise set up, is client-to-fileserver. server-to-server traffic is often on at least a semi-trusted network. From jaltman@your-file-system.com Sat Feb 28 03:09:12 2015 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Fri, 27 Feb 2015 22:09:12 -0500 Subject: [OpenAFS-devel] Re: [OpenAFS] Encrypted connections by default in OpenAFS 1.8? In-Reply-To: <54F12D26.5000301@rampaginggeek.com> References: <54F12D26.5000301@rampaginggeek.com> Message-ID: <54F13158.8050507@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms080909060802000002000903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/27/2015 9:51 PM, Jason Edgecombe wrote: > ** file server option to force authenticated access to use encryption A file server cannot force authenticated access from a client to use encryption. The client chooses the property of the connection and uses that to send data to the file server prior to the file server deciding whether or not to issue an authentication challenge. The client needs to be told the connection policy prior to connection establishment (that is what "fs setcrypt" does). A file server can choose to ignore a connection but by that time the data you wish to be secure has already been transmitted in the clear. If the connection is rejected by the file server and the clear retransmits the same request using a new encryption connection, the client has now given known plaintext to an attacker to use to determine the encryption key. This is where AuriStor's policy framework comes into play. It is a mechanism by which the clients are told ahead of time which authentication and wire privacy modes are to be used for each file server connection. That way if your volume is to be accessed only using an rxgk authenticated aes256-sha1 encrypted/integrity protected connection the client knows what to do and the file server knows what to enforce. Only then can there be a guarantee that there will be no information leakage. Jeffrey Altman --------------ms080909060802000002000903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhAW xDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMzg2MTAyMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCteTFLbuPm2vx85lH2 Y6LHdMIqcKQPN9m4XYVTe0L8ZvMvnJ1YQ720ET52CF18RYdTc4to92+ffdmjWlBedK4YtLam htsUkJ6WL3krwNVTYfeej0wgF9kVQ2FI8XTNngxnJ2CRkQX4Z9/1TI4wTkSNcAw5T0Y2HKM9 4p7wAJOefl+3oPwxXn338w8T7LsfwS9FOADZ8uRItv/J7S8BJEP0XtjZZlBoSyqQ4qxl5PtI uybHVdwoo2PlK8LxU6r8Vcje1+OXmc5VoCBlXiYDWHl/wSDtZEWR6431/az1Z45n1AHHber2 G+Ijb0nF4RLiiFMkyJl3qx+46wqcqWrjrRxDAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFBUlv/9jizZz4uwaFtPzwdX6FsqwMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBAJIvoMatM56/QjaVAlEUbeWZNOPkwuiC gaaekWJi1h33fAVfdF+WZqh7dF4hBNalyPuxRcyZX7HxuPyBc3ajDCqew9MlmCJ3Cm4Co3fZ Yh50OX4jnem2RmpHeKbJW6zUjZcAGqV6DPMl04kgrI2whJX7729HoRyUPwZS7CZSRFZO147X 2+/JogDYKffa/+q5AwgrHYvdECHxc3Iz9KnHSmit+DhWS9t+XxE0gHr3sW7zwcQ/GYyrJ3s3 VdWHTjM+3iGFeTOI06h1aBgFR/+8fTmuZXZz9+OdWVar0Crt9bn0cFN3u00Q6YAyjYhRnbXy zYVIOS4oJmRoK79p/xodeDUxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBbEMEm4oBwlVrtv5MmH C8QwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwMjI4MDMwOTEyWjAjBgkqhkiG9w0BCQQxFgQU37wjzchNWbZmCTr3h0V5Qqwx +zUwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQFsQwSbigHCVWu2/kyYcLxDCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAWxDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEB AQUABIIBAAwF0fbltjdp4YUT7Tq2aWCvZKSaTrkWBtq64lH6Qv6pCcz6xhXXClhR3C5/YF4n Myp+Oc/871TKckSLZRl3WiWgCyrAiTjqISuRvJHdBalK74lQkSHtqO/bQ4ik8V/A4Sxd+sG2 qIQxPtgmINkDBDJ9S1tWbNwIAfPVaByToK8+sB73jjhcOlDXp7neiN9IqsuryMX91R0DHdAF htjHb45tyKPx8Wb7gnZ/D77PGgzmSZzs1jKBIdu46xXfoub1KwyVq3UhCpNL3/Uz/ULLHJTe RW19XQu/TjTnU1DEuGa96IjIAKlHdk6aFRxwXGW4hFbI/JbaSQlaZ01Vj6QETLgAAAAAAAA= --------------ms080909060802000002000903-- From jason@rampaginggeek.com Sat Feb 28 04:33:00 2015 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Fri, 27 Feb 2015 23:33:00 -0500 Subject: [OpenAFS-devel] Re: [OpenAFS] Encrypted connections by default in OpenAFS 1.8? In-Reply-To: <54F13158.8050507@your-file-system.com> References: <54F12D26.5000301@rampaginggeek.com> <54F13158.8050507@your-file-system.com> Message-ID: <54F144FC.3020806@rampaginggeek.com> On 02/27/2015 10:09 PM, Jeffrey Altman wrote: > On 2/27/2015 9:51 PM, Jason Edgecombe wrote: >> ** file server option to force authenticated access to use encryption > A file server cannot force authenticated access from a client to use > encryption. The client chooses the property of the connection and uses > that to send data to the file server prior to the file server deciding > whether or not to issue an authentication challenge. > > The client needs to be told the connection policy prior to connection > establishment (that is what "fs setcrypt" does). A file server can > choose to ignore a connection but by that time the data you wish to be > secure has already been transmitted in the clear. If the connection is > rejected by the file server and the clear retransmits the same request > using a new encryption connection, the client has now given known > plaintext to an attacker to use to determine the encryption key. > > This is where AuriStor's policy framework comes into play. It is a > mechanism by which the clients are told ahead of time which > authentication and wire privacy modes are to be used for each file > server connection. That way if your volume is to be accessed only using > an rxgk authenticated aes256-sha1 encrypted/integrity protected > connection the client knows what to do and the file server knows what to > enforce. Only then can there be a guarantee that there will be no > information leakage. > > Jeffrey Altman > > Hmmm, hadn't thought of the plain text attack angle. Thanks, Jason From jaltman@your-file-system.com Sat Feb 28 19:28:17 2015 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Sat, 28 Feb 2015 14:28:17 -0500 Subject: [OpenAFS-devel] Re: [OpenAFS] Encrypted connections by default in OpenAFS 1.8? In-Reply-To: References: Message-ID: <54F216D1.1060500@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms010003000104060004040007 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/27/2015 3:26 PM, Benjamin Kaduk wrote: > One change which has been proposed is to encrypt connections by default= =2E > There has long been the 'fs setcrypt' command (introduced in 2001) to > allow the connections from a cache manager to the servers in the cell > (which most distributions' packaging enable by default). However, ther= e > is not currently an option to enable encryption for the intra-dbserver > connections which effect ubik replication, or for other server-to-serve= r > connections such as fileserver queries to the protection server, and > volume forwarding traffic. >=20 > Given events in the news in recent years, it seems to me that we do our= > users a disservice by not using a "secure" mode operation by default. Agreed. I am particularly troubled by the lack of wire privacy mode used for volume transfers and since organizations replicate volume data across the public Internet between sites and it never occurs to them that this data might be sent in the clear. > (Quote around "secure" are necessary given the known weaknesses of the > fcrypt encryption used by rxkad, but with the rxkad-k5 extension, there= > does remain some level of protection to offer.) Though rxkad encryptio= n > is known to introduce severe performance penalties, administrators who > require the extra performance should be able to discover that and use > the documented procedure for disabling encryption. Administrators who > just want to set something up and have it running would be protected, > without needing to know that they need to go through the effort of find= ing > the documentation and enabling encryption everywhere. Agreed. > I propose that the OpenAFS 1.8 major release introduce encryption by > default, for all(*) connections, whether client-to-server or > server-to-server. There would of course be knobs to disable encryption= > for sites which do not need it, but the default value would be "on". It is worth pointing out that the Windows client has defaulted to crypt mode since I began working on it in 2003. If I had my way at the time crypt mode would be required and not configurable. Still to this day I hear from administrators that they have no need to security because the cell is internal. This simply isn't true. It is not possible to keep attackers out all of the time. If the major banks that spend billions on IT cannot do it, neither can an organization that deploys OpenAFS. > In addition to feedback on the general proposal for encrypt-by-default,= I > would appreciate feedback on more detailed questions, which might shape= > the structure of an implementation: >=20 > (1) Is it sufficient to have one single knob that controls all connecti= ons > from a given host, whether cache manager or server? Unlikely. > (2) (Assuming that the answer to (1) is "no") Should there be separate > knobs knob for intra-ubik connections, fileserver-to-ptserver, and > volserver-to-volserver connections? One knob per service with a host configurable default. > (3) What downsides do you see as possible for a new text-based > configuration file to control the various behaviors? (Looking forward,= > this could also be a place to configure selection of rxgk vs. rxkad.) The source tree imports the Heimdal krb5 profile configuration parser. There was agreement at the last Pittsburgh hackathon on a format. Mike Meffie was scribe. The AuriStor configuration is based upon that model as presented at the CERN conference. OpenAFS should do the same. There should be a service configurable knob with a configurable default. The default should be "crypt". > No decisions have been made; this thread is me seeking feedback from th= e > community on an issue where I have an opinion but do not know the posit= ion > of the community as a whole. I believe this is a topic in which every organization that deploys OpenAFS should speak up. >=20 > Thank you, >=20 > Ben >=20 >=20 > (*) My current proposal affects mostly the cache manager; > encryption-by-default for the standalong client tools (vos, pts, bos, > etc.) would be configurable in a different way, presumably with a > command-line option. At least some of the command line tools already have a -crypt option. The Windows client enables crypt by default unless the cache manager's crypt setting has been disabled. Jeffrey Altman --------------ms010003000104060004040007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhAW xDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMzg2MTAyMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCteTFLbuPm2vx85lH2 Y6LHdMIqcKQPN9m4XYVTe0L8ZvMvnJ1YQ720ET52CF18RYdTc4to92+ffdmjWlBedK4YtLam htsUkJ6WL3krwNVTYfeej0wgF9kVQ2FI8XTNngxnJ2CRkQX4Z9/1TI4wTkSNcAw5T0Y2HKM9 4p7wAJOefl+3oPwxXn338w8T7LsfwS9FOADZ8uRItv/J7S8BJEP0XtjZZlBoSyqQ4qxl5PtI uybHVdwoo2PlK8LxU6r8Vcje1+OXmc5VoCBlXiYDWHl/wSDtZEWR6431/az1Z45n1AHHber2 G+Ijb0nF4RLiiFMkyJl3qx+46wqcqWrjrRxDAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFBUlv/9jizZz4uwaFtPzwdX6FsqwMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBAJIvoMatM56/QjaVAlEUbeWZNOPkwuiC gaaekWJi1h33fAVfdF+WZqh7dF4hBNalyPuxRcyZX7HxuPyBc3ajDCqew9MlmCJ3Cm4Co3fZ Yh50OX4jnem2RmpHeKbJW6zUjZcAGqV6DPMl04kgrI2whJX7729HoRyUPwZS7CZSRFZO147X 2+/JogDYKffa/+q5AwgrHYvdECHxc3Iz9KnHSmit+DhWS9t+XxE0gHr3sW7zwcQ/GYyrJ3s3 VdWHTjM+3iGFeTOI06h1aBgFR/+8fTmuZXZz9+OdWVar0Crt9bn0cFN3u00Q6YAyjYhRnbXy zYVIOS4oJmRoK79p/xodeDUxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBbEMEm4oBwlVrtv5MmH C8QwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwMjI4MTkyODE3WjAjBgkqhkiG9w0BCQQxFgQUEDezOddVcibicPc8N7U5IdKL 35UwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQFsQwSbigHCVWu2/kyYcLxDCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAWxDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEB AQUABIIBAIQE4MaO4cN6zQmVmlMR2L37bbVC7G+2UzsJ6SEnpoD5Z05GgdXM9aY+Dstmm5re +Tl9/ytBsiS1e5bvn2wLvehZeatnq5pGc/Cx8K8hBwrOvgDwE1lSjm2Ae29iMD02znHANH5t dZFftGWuqV7j1G4YR30Fd9G2+FMfStC3zWboi26W89JU6E9H5RcfKkpbgUMmyrFXs71Xx8tQ i1krSts9GxeFKxjwYKqKkWe3RO+ZD0/8j3Cf7GjK/3uft706SsQn31dxeIWpEuCrhaZYHyRP U0yrMAW3hn1Wzrm1AYtRYuN371MvReh0F4NQhpBvdPtfECm53wjqaUMsFpWhQ0kAAAAAAAA= --------------ms010003000104060004040007--