From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: First results from running build without python2 Date: Thu, 19 Aug 2021 18:28:03 +0200 Message-ID: In-Reply-To: <1E622E0B-2AED-4AAA-A62E-BC2C8C668A08@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1439913234524338276==" List-Id: --===============1439913234524338276== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 19/08/2021 15:54, Michael Tremer wrote: > Hello Adolf, >=20 > This sounds very good. >=20 >> On 18 Aug 2021, at 22:08, Adolf Belka wrote: >> >> Hi All, >> >> I have successfully built ca-certificates with the new p11-kit approach. T= he only difference is that the certificate data such as Version, Serial Numbe= r, Signature Algorithm etc is no longer included in the created bundle files.= There is only the actual certificate itself. >=20 > I do not exactly understand what you mean. Can you post a file system listi= ng or something that would help me?The first certificate in the new ca-bundle= .crt looks like the following:- # ACCVRAIZ1 -----BEGIN CERTIFICATE----- MIIH0zCCBbugAwIBAgIIXsO3pkN/pOAwDQYJKoZIhvcNAQEFBQAwQjESMBAGA1UE AwwJQUNDVlJBSVoxMRAwDgYDVQQLDAdQS0lBQ0NWMQ0wCwYDVQQKDARBQ0NWMQsw CQYDVQQGEwJFUzAeFw0xMTA1MDUwOTM3MzdaFw0zMDEyMzEwOTM3MzdaMEIxEjAQ BgNVBAMMCUFDQ1ZSQUlaMTEQMA4GA1UECwwHUEtJQUNDVjENMAsGA1UECgwEQUND VjELMAkGA1UEBhMCRVMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCb qau/YUqXry+XZpp0X9DZlv3P4uRm7x8fRzPCRKPfmt4ftVTdFXxpNRFvu8gMjmoY HtiP2Ra8EEg2XPBjs5BaXCQ316PWywlxufEBcoSwfdtNgM3802/J+Nq2DoLSRYWo G2ioPej0RGy9ocLLA76MPhMAhN9KSMDjIgro6TenGEyxCQ0jVn8ETdkXhBilyNpA lHPrzg5XPAOBOp0KoVdDaaxXbXmQeOW1tDvYvEyNKKGno6e6Ak4l0Squ7a4DIrhr IA8wKFSVf+DuzgpmndFALW4ir50awQUZ0m/A8p/4e7MCQvtQqR0tkw8jq8bBD5L/ 0KIV9VMJcRz/RROE5iZe+OCIHAr8Fraocwa48GOEAqDGWuzndN9wrqODJerWx5eH k6fGioozl2A3ED6XPm4pFdahD9GILBKfb6qkxkLrQaLjlUPTAYVtjrs78yM2x/47 4KElB0iryYl0/wiPgL/AlmXz7uxLaL2diMMxs0Dx6M/2OLuc5NF/1OVYm3z61PMO m3WR5LpSLhl+0fXNWhn8ugb2+1KoS5kE3fj5tItQo05iifCHJPqDQsGH+tUtKSpa cXpkatcnYGMN285J9Y0fkIkyF/hzQ7jSWpOGYdbhdQrqeWZ2iE9x6wQl1gpaepPl uUsXQA+xtrn13k/c4LOsOxFwYIRKQ26ZIMApcQrAZQIDAQABo4ICyzCCAscwfQYI KwYBBQUHAQEEcTBvMEwGCCsGAQUFBzAChkBodHRwOi8vd3d3LmFjY3YuZXMvZmls ZWFkbWluL0FyY2hpdm9zL2NlcnRpZmljYWRvcy9yYWl6YWNjdjEuY3J0MB8GCCsG AQUFBzABhhNodHRwOi8vb2NzcC5hY2N2LmVzMB0GA1UdDgQWBBTSh7Tj3zcnk1X2 VuqB5TbMjB4/vTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNKHtOPfNyeT VfZW6oHlNsyMHj+9MIIBcwYDVR0gBIIBajCCAWYwggFiBgRVHSAAMIIBWDCCASIG CCsGAQUFBwICMIIBFB6CARAAQQB1AHQAbwByAGkAZABhAGQAIABkAGUAIABDAGUA cgB0AGkAZgBpAGMAYQBjAGkA8wBuACAAUgBhAO0AegAgAGQAZQAgAGwAYQAgAEEA QwBDAFYAIAAoAEEAZwBlAG4AYwBpAGEAIABkAGUAIABUAGUAYwBuAG8AbABvAGcA 7QBhACAAeQAgAEMAZQByAHQAaQBmAGkAYwBhAGMAaQDzAG4AIABFAGwAZQBjAHQA cgDzAG4AaQBjAGEALAAgAEMASQBGACAAUQA0ADYAMAAxADEANQA2AEUAKQAuACAA QwBQAFMAIABlAG4AIABoAHQAdABwADoALwAvAHcAdwB3AC4AYQBjAGMAdgAuAGUA czAwBggrBgEFBQcCARYkaHR0cDovL3d3dy5hY2N2LmVzL2xlZ2lzbGFjaW9uX2Mu aHRtMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly93d3cuYWNjdi5lcy9maWxlYWRt aW4vQXJjaGl2b3MvY2VydGlmaWNhZG9zL3JhaXphY2N2MV9kZXIuY3JsMA4GA1Ud DwEB/wQEAwIBBjAXBgNVHREEEDAOgQxhY2N2QGFjY3YuZXMwDQYJKoZIhvcNAQEF BQADggIBAJcxAp/n/UNnSEQU5CmH7UwoZtCPNdpNYbdKl02125DgBS4OxnnQ8pdp D70ER9m+27Up2pvZrqmZ1dM8MJP1jaGo/AaNRPTKFpV8M9xii6g3+CfYCS0b78gU JyCpZET/LtZ1qmxNYEAZSUNUY9rizLpm5U9EelvZaoErQNV/+QEnWCzI7UiRfD+m AM/EKXMRNt6GGT6d7hmKG9Ww7Y49nCrADdg9ZuM8Db3VlFzi4qc1GwQA9j9ajepD vV+JHanBsMyZ4k0ACtrJJ1vnE5Bc5PUzolVt3OAJTS+xJlsndQAJxGJ3KQhfnlms tn6tn1QwIgPBHnFk/vk4CpYY3QIUrCPLBhwepH2NDd4nQeit2hW3sCPdK6jT2iWH 7ehVRE2I9DZ+hJp4rPcOVkkO1jMl1oRQQmwgEh0q1b688nCBpHBgvgW1m54ERL5h I6zppSSMEYCUWqKiuUnSwdzRp+0xESyeGabu4VXhwOrPDYTkF7eifKXeVSUG7szA h1xA2syVP1XgNce4hL60Xc16gwFy7ofmXx2utYXGJt/mwZrpHgJHnyqobalbz+xF d3+YJ5oyXSrjhO7FmGYvliAd3djDJ9ew+f7Zfc3Qn48LFFhRny+Lwzgt3uiP1o2H pPVWQxaZLPSkVrQ0uGE3ycJYgBugl6H8WY3pEfbRD0tVNEYqi4Y7 -----END CERTIFICATE----- The version currently in place has the following content for the first certif= icate:- Certificate: Data: Version: 3 (0x2) Serial Number: 6828503384748696800 (0x5ec3b7a6437fa4e0) Signature Algorithm: sha1WithRSAEncryption Issuer: CN =3D ACCVRAIZ1, OU =3D PKIACCV, O =3D ACCV, C =3D ES Validity Not Before: May 5 09:37:37 2011 GMT Not After : Dec 31 09:37:37 2030 GMT Subject: CN =3D ACCVRAIZ1, OU =3D PKIACCV, O =3D ACCV, C =3D ES Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) Modulus: 00:9b:a9:ab:bf:61:4a:97:af:2f:97:66:9a:74:5f: d0:d9:96:fd:cf:e2:e4:66:ef:1f:1f:47:33:c2:44: a3:df:9a:de:1f:b5:54:dd:15:7c:69:35:11:6f:bb: c8:0c:8e:6a:18:1e:d8:8f:d9:16:bc:10:48:36:5c: f0:63:b3:90:5a:5c:24:37:d7:a3:d6:cb:09:71:b9: f1:01:72:84:b0:7d:db:4d:80:cd:fc:d3:6f:c9:f8: da:b6:0e:82:d2:45:85:a8:1b:68:a8:3d:e8:f4:44: 6c:bd:a1:c2:cb:03:be:8c:3e:13:00:84:df:4a:48: c0:e3:22:0a:e8:e9:37:a7:18:4c:b1:09:0d:23:56: 7f:04:4d:d9:17:84:18:a5:c8:da:40:94:73:eb:ce: 0e:57:3c:03:81:3a:9d:0a:a1:57:43:69:ac:57:6d: 79:90:78:e5:b5:b4:3b:d8:bc:4c:8d:28:a1:a7:a3: a7:ba:02:4e:25:d1:2a:ae:ed:ae:03:22:b8:6b:20: 0f:30:28:54:95:7f:e0:ee:ce:0a:66:9d:d1:40:2d: 6e:22:af:9d:1a:c1:05:19:d2:6f:c0:f2:9f:f8:7b: b3:02:42:fb:50:a9:1d:2d:93:0f:23:ab:c6:c1:0f: 92:ff:d0:a2:15:f5:53:09:71:1c:ff:45:13:84:e6: 26:5e:f8:e0:88:1c:0a:fc:16:b6:a8:73:06:b8:f0: 63:84:02:a0:c6:5a:ec:e7:74:df:70:ae:a3:83:25: ea:d6:c7:97:87:93:a7:c6:8a:8a:33:97:60:37:10: 3e:97:3e:6e:29:15:d6:a1:0f:d1:88:2c:12:9f:6f: aa:a4:c6:42:eb:41:a2:e3:95:43:d3:01:85:6d:8e: bb:3b:f3:23:36:c7:fe:3b:e0:a1:25:07:48:ab:c9: 89:74:ff:08:8f:80:bf:c0:96:65:f3:ee:ec:4b:68: bd:9d:88:c3:31:b3:40:f1:e8:cf:f6:38:bb:9c:e4: d1:7f:d4:e5:58:9b:7c:fa:d4:f3:0e:9b:75:91:e4: ba:52:2e:19:7e:d1:f5:cd:5a:19:fc:ba:06:f6:fb: 52:a8:4b:99:04:dd:f8:f9:b4:8b:50:a3:4e:62:89: f0:87:24:fa:83:42:c1:87:fa:d5:2d:29:2a:5a:71: 7a:64:6a:d7:27:60:63:0d:db:ce:49:f5:8d:1f:90: 89:32:17:f8:73:43:b8:d2:5a:93:86:61:d6:e1:75: 0a:ea:79:66:76:88:4f:71:eb:04:25:d6:0a:5a:7a: 93:e5:b9:4b:17:40:0f:b1:b6:b9:f5:de:4f:dc:e0: b3:ac:3b:11:70:60:84:4a:43:6e:99:20:c0:29:71: 0a:c0:65 Exponent: 65537 (0x10001) X509v3 extensions: Authority Information Access: CA Issuers - URI:http://www.accv.es/fileadmin/Archivos/certi= ficados/raizaccv1.crt OCSP - URI:http://ocsp.accv.es X509v3 Subject Key Identifier: D2:87:B4:E3:DF:37:27:93:55:F6:56:EA:81:E5:36:CC:8C:1E:3F:BD X509v3 Basic Constraints: critical CA:TRUE X509v3 Authority Key Identifier: keyid:D2:87:B4:E3:DF:37:27:93:55:F6:56:EA:81:E5:36:CC:8C:1E:= 3F:BD X509v3 Certificate Policies: Policy: X509v3 Any Policy User Notice: Explicit Text: CPS: http://www.accv.es/legislacion_c.htm X509v3 CRL Distribution Points: Full Name: URI:http://www.accv.es/fileadmin/Archivos/certificados/rai= zaccv1_der.crl X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Alternative Name: email:accv(a)accv.es Signature Algorithm: sha1WithRSAEncryption 97:31:02:9f:e7:fd:43:67:48:44:14:e4:29:87:ed:4c:28:66: d0:8f:35:da:4d:61:b7:4a:97:4d:b5:db:90:e0:05:2e:0e:c6: 79:d0:f2:97:69:0f:bd:04:47:d9:be:db:b5:29:da:9b:d9:ae: a9:99:d5:d3:3c:30:93:f5:8d:a1:a8:fc:06:8d:44:f4:ca:16: 95:7c:33:dc:62:8b:a8:37:f8:27:d8:09:2d:1b:ef:c8:14:27: 20:a9:64:44:ff:2e:d6:75:aa:6c:4d:60:40:19:49:43:54:63: da:e2:cc:ba:66:e5:4f:44:7a:5b:d9:6a:81:2b:40:d5:7f:f9: 01:27:58:2c:c8:ed:48:91:7c:3f:a6:00:cf:c4:29:73:11:36: de:86:19:3e:9d:ee:19:8a:1b:d5:b0:ed:8e:3d:9c:2a:c0:0d: d8:3d:66:e3:3c:0d:bd:d5:94:5c:e2:e2:a7:35:1b:04:00:f6: 3f:5a:8d:ea:43:bd:5f:89:1d:a9:c1:b0:cc:99:e2:4d:00:0a: da:c9:27:5b:e7:13:90:5c:e4:f5:33:a2:55:6d:dc:e0:09:4d: 2f:b1:26:5b:27:75:00:09:c4:62:77:29:08:5f:9e:59:ac:b6: 7e:ad:9f:54:30:22:03:c1:1e:71:64:fe:f9:38:0a:96:18:dd: 02:14:ac:23:cb:06:1c:1e:a4:7d:8d:0d:de:27:41:e8:ad:da: 15:b7:b0:23:dd:2b:a8:d3:da:25:87:ed:e8:55:44:4d:88:f4: 36:7e:84:9a:78:ac:f7:0e:56:49:0e:d6:33:25:d6:84:50:42: 6c:20:12:1d:2a:d5:be:bc:f2:70:81:a4:70:60:be:05:b5:9b: 9e:04:44:be:61:23:ac:e9:a5:24:8c:11:80:94:5a:a2:a2:b9: 49:d2:c1:dc:d1:a7:ed:31:11:2c:9e:19:a6:ee:e1:55:e1:c0: ea:cf:0d:84:e4:17:b7:a2:7c:a5:de:55:25:06:ee:cc:c0:87: 5c:40:da:cc:95:3f:55:e0:35:c7:b8:84:be:b4:5d:cd:7a:83: 01:72:ee:87:e6:5f:1d:ae:b5:85:c6:26:df:e6:c1:9a:e9:1e: 02:47:9f:2a:a8:6d:a9:5b:cf:ec:45:77:7f:98:27:9a:32:5d: 2a:e3:84:ee:c5:98:66:2f:96:20:1d:dd:d8:c3:27:d7:b0:f9: fe:d9:7d:cd:d0:9f:8f:0b:14:58:51:9f:2f:8b:c3:38:2d:de: e8:8f:d6:8d:87:a4:f5:56:43:16:99:2c:f4:a4:56:b4:34:b8: 61:37:c9:c2:58:80:1b:a0:97:a1:fc:59:8d:e9:11:f6:d1:0f: 4b:55:34:46:2a:8b:86:3b -----BEGIN CERTIFICATE----- MIIH0zCCBbugAwIBAgIIXsO3pkN/pOAwDQYJKoZIhvcNAQEFBQAwQjESMBAGA1UE AwwJQUNDVlJBSVoxMRAwDgYDVQQLDAdQS0lBQ0NWMQ0wCwYDVQQKDARBQ0NWMQsw CQYDVQQGEwJFUzAeFw0xMTA1MDUwOTM3MzdaFw0zMDEyMzEwOTM3MzdaMEIxEjAQ BgNVBAMMCUFDQ1ZSQUlaMTEQMA4GA1UECwwHUEtJQUNDVjENMAsGA1UECgwEQUND VjELMAkGA1UEBhMCRVMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCb qau/YUqXry+XZpp0X9DZlv3P4uRm7x8fRzPCRKPfmt4ftVTdFXxpNRFvu8gMjmoY HtiP2Ra8EEg2XPBjs5BaXCQ316PWywlxufEBcoSwfdtNgM3802/J+Nq2DoLSRYWo G2ioPej0RGy9ocLLA76MPhMAhN9KSMDjIgro6TenGEyxCQ0jVn8ETdkXhBilyNpA lHPrzg5XPAOBOp0KoVdDaaxXbXmQeOW1tDvYvEyNKKGno6e6Ak4l0Squ7a4DIrhr IA8wKFSVf+DuzgpmndFALW4ir50awQUZ0m/A8p/4e7MCQvtQqR0tkw8jq8bBD5L/ 0KIV9VMJcRz/RROE5iZe+OCIHAr8Fraocwa48GOEAqDGWuzndN9wrqODJerWx5eH k6fGioozl2A3ED6XPm4pFdahD9GILBKfb6qkxkLrQaLjlUPTAYVtjrs78yM2x/47 4KElB0iryYl0/wiPgL/AlmXz7uxLaL2diMMxs0Dx6M/2OLuc5NF/1OVYm3z61PMO m3WR5LpSLhl+0fXNWhn8ugb2+1KoS5kE3fj5tItQo05iifCHJPqDQsGH+tUtKSpa cXpkatcnYGMN285J9Y0fkIkyF/hzQ7jSWpOGYdbhdQrqeWZ2iE9x6wQl1gpaepPl uUsXQA+xtrn13k/c4LOsOxFwYIRKQ26ZIMApcQrAZQIDAQABo4ICyzCCAscwfQYI KwYBBQUHAQEEcTBvMEwGCCsGAQUFBzAChkBodHRwOi8vd3d3LmFjY3YuZXMvZmls ZWFkbWluL0FyY2hpdm9zL2NlcnRpZmljYWRvcy9yYWl6YWNjdjEuY3J0MB8GCCsG AQUFBzABhhNodHRwOi8vb2NzcC5hY2N2LmVzMB0GA1UdDgQWBBTSh7Tj3zcnk1X2 VuqB5TbMjB4/vTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNKHtOPfNyeT VfZW6oHlNsyMHj+9MIIBcwYDVR0gBIIBajCCAWYwggFiBgRVHSAAMIIBWDCCASIG CCsGAQUFBwICMIIBFB6CARAAQQB1AHQAbwByAGkAZABhAGQAIABkAGUAIABDAGUA cgB0AGkAZgBpAGMAYQBjAGkA8wBuACAAUgBhAO0AegAgAGQAZQAgAGwAYQAgAEEA QwBDAFYAIAAoAEEAZwBlAG4AYwBpAGEAIABkAGUAIABUAGUAYwBuAG8AbABvAGcA 7QBhACAAeQAgAEMAZQByAHQAaQBmAGkAYwBhAGMAaQDzAG4AIABFAGwAZQBjAHQA cgDzAG4AaQBjAGEALAAgAEMASQBGACAAUQA0ADYAMAAxADEANQA2AEUAKQAuACAA QwBQAFMAIABlAG4AIABoAHQAdABwADoALwAvAHcAdwB3AC4AYQBjAGMAdgAuAGUA czAwBggrBgEFBQcCARYkaHR0cDovL3d3dy5hY2N2LmVzL2xlZ2lzbGFjaW9uX2Mu aHRtMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly93d3cuYWNjdi5lcy9maWxlYWRt aW4vQXJjaGl2b3MvY2VydGlmaWNhZG9zL3JhaXphY2N2MV9kZXIuY3JsMA4GA1Ud DwEB/wQEAwIBBjAXBgNVHREEEDAOgQxhY2N2QGFjY3YuZXMwDQYJKoZIhvcNAQEF BQADggIBAJcxAp/n/UNnSEQU5CmH7UwoZtCPNdpNYbdKl02125DgBS4OxnnQ8pdp D70ER9m+27Up2pvZrqmZ1dM8MJP1jaGo/AaNRPTKFpV8M9xii6g3+CfYCS0b78gU JyCpZET/LtZ1qmxNYEAZSUNUY9rizLpm5U9EelvZaoErQNV/+QEnWCzI7UiRfD+m AM/EKXMRNt6GGT6d7hmKG9Ww7Y49nCrADdg9ZuM8Db3VlFzi4qc1GwQA9j9ajepD vV+JHanBsMyZ4k0ACtrJJ1vnE5Bc5PUzolVt3OAJTS+xJlsndQAJxGJ3KQhfnlms tn6tn1QwIgPBHnFk/vk4CpYY3QIUrCPLBhwepH2NDd4nQeit2hW3sCPdK6jT2iWH 7ehVRE2I9DZ+hJp4rPcOVkkO1jMl1oRQQmwgEh0q1b688nCBpHBgvgW1m54ERL5h I6zppSSMEYCUWqKiuUnSwdzRp+0xESyeGabu4VXhwOrPDYTkF7eifKXeVSUG7szA h1xA2syVP1XgNce4hL60Xc16gwFy7ofmXx2utYXGJt/mwZrpHgJHnyqobalbz+xF d3+YJ5oyXSrjhO7FmGYvliAd3djDJ9ew+f7Zfc3Qn48LFFhRny+Lwzgt3uiP1o2H pPVWQxaZLPSkVrQ0uGE3ycJYgBugl6H8WY3pEfbRD0tVNEYqi4Y7 -----END CERTIFICATE----- The bit between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- is = the same in both cases, it is all the other information that is missing. >=20 >> This is also the case for the bundles that Arch Linux has created on my sy= stems, that also uses the p11-kit approach. >> >> I did a diff on the current ca-bundle.crt/ca-bundle.trust.crt files and th= e ones created by the new approach as used by Fedora and all the same certifi= cates are present, it is only the certificate data that is missed. >> >> There is a --comment option in the trust extract command that looks like i= t should add the comments that are in the .p11-kit file into the extracted bu= ndle files but nothing changes if it is used or not. I will ask into the p11-= kit git repository whether this should work or not. >> >> >> I did a build just with the new ca-certificate files into Core Update 160 = and then installed the created iso into a vm on my testbed system. >> >> Everything worked that I tested out but I am not 100% sure what needs to b= e exercised to test the ca-bundle.crt and ca-bundle.trust.crt files. If someo= ne can give me some guidance on this then I can do that final test and submit= a patch for this change. >=20 > If you can download something with wget using HTTPS and the certificate can= be validated, things should be working fine. I will give that a try. >=20 >> I also then did a test build with all python2 programs removed, including = python2 itself and with the python 3 fixes for spice, frr and ca-certificates= installed. The build for every program in the ipfire build section completed= successfully but then I had a stop in the cdrom stage for collectd. It has a= python2 plugin module defined which was of course missing. The module could = be disabled in the rootfile or in the build config if the python plugin is no= t required for IPFire - I could not find any python modules defined. >=20 > You can just pass =E2=80=9C=E2=80=94-without-python=E2=80=9D or =E2=80=9C= =E2=80=94-disable-python=E2=80=9D and then the module won=E2=80=99t be built = any more. >=20 >> I have been able to successfully define the path to the python interpreter= in the ./configure statement to point to the python3 program and collectd su= ccessfully built with this so if the python plugin is required then a python3= version can be created. I have not yet tested this in my vm but will do so. >=20 > We do not use this module, so I suppose it isn=E2=80=99t worth building it = in the first place. >=20 >> I also found that freeradius has a python2 module defined. This can be dis= abled. I will do that for collectd and freeradius then. I will also do it for alsa as that is the next one I found with a python2 lib= rary entry. >=20 > Please do that. If someone needs the Python 3 module, we can still build it= >=20 >> There is a python3 module available since 2.0.20. To use it with 3.0.21 (c= urrent version) you have to have --with-experimental-modules defined. I am lo= oking at latest version 2.0.23 to see if that also needs the experimental mod= ules enabled or if it has become part of the normal modules now and will test= the build to see if it works successfully or not. >=20 > Thank you for all the research that you invested into this. Looks like we a= re not far away to drop Python 2. I also think we are very close now. Hopefully in time for Core Update 160. Regards, Adolf. >=20 > -Michael >=20 >> >> Regards, >> >> Adolf. >> >> On 12/08/2021 21:30, Adolf Belka wrote: >>> Hi Michael, >>> >>> On 12/08/2021 21:23, Adolf Belka wrote: >>>> Hi Michael, >>>> >>>> On 12/08/2021 15:38, Michael Tremer wrote: >>>>> Hello, >>>>> >>>>> Yes, this is the way to go :) >>>>> >>>>> Reach out here if you need any help. >>>> I am trying to build p11-kit and it has flagged up libtasn1. It is an op= tional dependency and I can disable it but I would like to check if that is t= he correct thing to do or not. >>>> >>>> libtasn1 is said to be required to allow the trust policy module to be b= uilt as well as other code that interacts with certificates. >>>> Is this something that would be needed for IPFire or can I disable it in= the p11-kit build. >>>> >>> Ignore this question. I just did a quick test of disabling libtasn1 and p= 11-kit built ok but then my ca-certificates build failed due to the lack of t= he trust tool, so that makes it clear that it is required. I will add it in t= o the build. >>> >>> Slowly getting there. >>> >>> Regards, >>> >>> Adolf. >>> >>>> Regards, >>>> Adolf. >>>>> >>>>> -Michael >>>>> >>>>>> On 12 Aug 2021, at 13:10, Adolf Belka wrote: >>>>>> >>>>>> Hi Michael, >>>>>> >>>>>> On 12/08/2021 13:36, Adolf Belka wrote: >>>>>>> Hi Michael, >>>>>>> >>>>>>> On 12/08/2021 11:17, Michael Tremer wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>>> On 11 Aug 2021, at 15:03, Adolf Belka wr= ote: >>>>>>>>> >>>>>>>>> Hi Michael, >>>>>>>>> >>>>>>>>> On 11/08/2021 12:43, Michael Tremer wrote: >>>>>>>>>> Hello, >>>>>>>>>> Is this the one with the broken sed command? >>>>>>>>>> https://src.fedoraproject.org/rpms/ca-certificates/blob/rawhide/f/= certdata2pem.py >>>>>>>>> Yes, this is that one. Confirmed with a diff. >>>>>>>>>> This should run if you execute it in the right directory: >>>>>>>>>> pushd %{name}/certs >>>>>>>>>> pwd >>>>>>>>>> cp certdata.txt . >>>>>>>>>> python3 certdata2pem.py >>>>>>>>>> popd >>>>>>>>> I have just learnt about the pushd and popd commands. by doing a qu= ick search. Never heard of them before. >>>>>>>> >>>>>>>> It is just a version of =E2=80=9Ccd=E2=80=9D that remembers where it= has been. >>>>>>>> >>>>>>>> So if you call =E2=80=9Cpushd some-directory=E2=80=9D, then =E2=80= =9Cpopd=E2=80=9D will bring you back to where you have been before. >>>>>>>> >>>>>>>> =E2=80=9Ccd -=E2=80=9C does the same as popd now. >>>>>>>> >>>>>>>>>> The fedora version no longer has the build.sh script. >>>>>>>>> That was the bit I didn't realise. >>>>>>>> >>>>>>>> No problem. >>>>>>> >>>>>>> Not as simple as I hoped. >>>>>>> >>>>>>> The new certdata2pem.py script no longer creates .crt files but .tmp-= p11-kit files but that is as far as that script goes. >>>>>>> >>>>>>> There is an update-ca-trust file in fedora which splits the various c= erts to their respective locations, with the openssl ones ending up in ca-bun= dle.trust.crt but this uses p11-kit. I suspect that it uses ca-bundle.trust.p= 11-kit generated later on in the %build section of the ca-certificate.spec fi= le from the tmp-p11-kit files generated by the certdata2pem.py script. So it = looks like p11-kit needs to be installed to make this work. >>>>>>> >>>>>>> Alternatively I have found the following in LFS. >>>>>>> https://www.linuxfromscratch.org/blfs/view/svn/postlfs/make-ca.html >>>>>>> which seems to also create the bundled cert file but also requiring p= 11-kit but then talking about different certdata.txt versions that have vario= us tunings. The one from LFS comes from the mozilla release branch but is mod= ified to something called the Mercurial revision, or the different ones shipp= ed by RedHat or OpenSUSE which use the version that comes with NSS. >>>>>>> >>>>>>> All in all I am not sure which approach to use or how to actually bui= ld it in IPFire. >>>>>>> >>>>>>> Definitely help required to know the correct way to go further with t= his. >>>>>>> >>>>>> Having said I needed help, I thought I would have another go and copie= d the lines from the %build section of the fedora ca-certificate.spec that cr= eated the ca-bundle.trust.p11.kit >>>>>> >>>>>> As I have p11-kit installed on my Arch Linux system I then ran the com= mand >>>>>> >>>>>> p11-kit extract --format=3Dopenssl-bundle --filter=3Dcertificates --ov= erwrite --comment ~/openssl/ca-bundle.trust.crt >>>>>> >>>>>> and I successfully created the ca-bundle.trust.crt which is needed by = the IPFire ca-certificates lfs file. >>>>>> >>>>>> I will now try and create a new build script that will do all the new = type stuff and also install the p11-kit library files and see how things go. >>>>>> >>>>>> :crossed_fingers: >>>>>> >>>>>> Adolf >>>>>> >>>>>>> Regards, >>>>>>> Adolf. >>>>>>> >>>>>>>> -Michael >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Adolf. >>>>>>>>>> -Michael >>>>>>>>>>> On 8 Aug 2021, at 14:47, Adolf Belka w= rote: >>>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> I had another go at the ca-certificates problem, the last barrier= to getting rid of python2. >>>>>>>>>>> >>>>>>>>>>> I found certdata2pem.py files from fedora and 2 from suse. I crea= ted build subdirectories for each version so I could just test running the bu= ild.sh file with each version of certdata2pem.py, including the IPFire curren= t version after running through the 2to3 convertor. >>>>>>>>>>> >>>>>>>>>>> fedora >>>>>>>>>>> >>>>>>>>>>> The fedora certdata2pem.py file runs successfully with python3 bu= t has sed commands built into it which fail to find certain files. The sed co= mmands are not in the IPFire version. >>>>>>>>>>> >>>>>>>>>>> The error message is >>>>>>>>>>> >>>>>>>>>>> -> written as 'Certum_Trusted_Root_CA:2.16.30.191.89.80.184.2= 01.128.55.76.6.247.235.85.79.181.237.tmp-p11-kit', trust =3D ['CKA_TRUST_SERV= ER_AUTH', 'CKA_TRUST_EMAIL_PROTECTION'], openssl-trust =3D ['serverAuth', 'em= ailProtection'], distrust =3D [], openssl-distrust =3D [] >>>>>>>>>>> sed: can't read certs/*.crt: No such file or directory >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> suse >>>>>>>>>>> >>>>>>>>>>> The first suse version runs successfully with python3 but also ha= s the sed commands in it with the same error message. >>>>>>>>>>> >>>>>>>>>>> The second suse version runs successfully with python3, does not = have the sed commands and completes the build.sh script with no errors. Howev= er this certdata2pem.py file has a section that is in the IPFire version comp= letely missing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> IPfire version after running through the 2to3 convertor >>>>>>>>>>> >>>>>>>>>>> The following error message occurs >>>>>>>>>>> >>>>>>>>>>> producing trust for "GlobalSign Root CA"2.11.4.0.0.0.0.1.21.75.90= .195.148 >>>>>>>>>>> Traceback (most recent call last): >>>>>>>>>>> File "/mnt/File_Server/Computers/Linux/ipfire/sandbox/patch = in progress/python/ca-certificates/orig-2to3-build/certs/../certdata2pem.py",= line 224, in >>>>>>>>>>> f.write("\n".join(textwrap.wrap(base64.b64encode(obj['CKA_VALUE']= ), 64))) >>>>>>>>>>> File "/usr/lib/python3.9/base64.py", line 58, in b64encode >>>>>>>>>>> encoded =3D binascii.b2a_base64(s, newline=3DFalse) >>>>>>>>>>> TypeError: a bytes-like object is required, not 'str' >>>>>>>>>>> >>>>>>>>>>> The section that is failing is the section that is missing in the= 2nd suse version. There is an identical fwrite line at line 206 but that doe= s not seem to flag up the same TypeError message. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As the certdata2pem.py files from the other distributions vary si= gnificantly in content, with some having nearly double the number of lines of= code, I think the best alternative is to fix the IPFire version so we stay c= onsistent but I am unable to figure out how to fix the python code that is ca= using the " TypeError: a bytes-like object is required, not 'str' " error me= ssage and need someone's help with that. >>>>>>>>>>> >>>>>>>>>>> Let me know if there is any other information that I need to prov= ide. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Adolf. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 07/08/2021 15:54, Adolf Belka wrote: >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> On 04/08/2021 16:45, Michael Tremer wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>>> On 4 Aug 2021, at 13:40, Adolf Belka wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have resolved the frr program build. The version currently i= n IPFire (6.0) only works with python2. Python3 support came in with version = 7.4. I have now built frr with version 8.0 including libyang as a new depende= ncy but only for the build, so nothing installed into IPFire itself, and that= has successfully built without python2 being present. >>>>>>>>>>>>> >>>>>>>>>>>>> Great. This could also resolve Matthias=E2=80=99 problem with b= uilding frr. >>>>>>>>>>>>> >>>>>>>>>>>>>> Will now go back and have another go with spice-protocol. >>>>>>>>>>>>> >>>>>>>>>>>>> Maybe it has a =E2=80=94-disable-python switch? >>>>>>>>>>>> I just removed the line in the spice-protocol lfs that ran autom= ake/py-compile on the python modules from spice. >>>>>>>>>>>> Spice and spice-protocol are present for qemu and with the py-co= mpile line removed all three successfully built without python2 being present= . I have submitted a patch for this combined with updating spice and spice-pr= otocol, both from 2017. >>>>>>>>>>>> >>>>>>>>>>>> This now only leaves the ca-certificates script that needs to be= updated to work with python3. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Adolf. >>>>>>>>>>>>> >>>>>>>>>>>>> -Michael >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 03/08/2021 23:38, Adolf Belka wrote: >>>>>>>>>>>>>>> Hi Michael & all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 03/08/2021 17:11, Michael Tremer wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thank you for looking into this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is a third-party script that came from either Mozilla o= r RedHat. Maybe they have ported it. If not, it should not be rocket science = to do it ourselves. If we do it, we should of course upstream it. >>>>>>>>>>>>>>> I found an updated script from fedora and gave that a try. Th= is time the script went all the way through but then the build.sh script fail= ed at the point where it should find all the .crt files in the certs director= y and it came back and said there weren't any. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, can you comment out this package and continue the b= uild? This should be required until you reach the cdrom stage. >>>>>>>>>>>>>>> I then commented ca-certificates out in make.sh and ran the b= uild. >>>>>>>>>>>>>>> This time it stopped at spice-protocol which is an addon and = uses the py-compile script that is in automake to compile some python modules. >>>>>>>>>>>>>>> py-compile is python2 based and the build stopped because it = could not find python >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is a py_compile.py script that is python3 based but whe= n I ran that in place of the py-compile script I got a Permission denied erro= r when it tried to carry out the compile. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I then commented out spice-protocol and ran the build. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It then failed on frr which did look for python3-config but t= hen failed due to not finding python-config or pkg-config python >>>>>>>>>>>>>>> It looks like I should be able to tell it to use python3 in t= he ./configure >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I commented out frr and nothing else failed before cdrom was = reached. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So the packages that need to be made to work with python3 are >>>>>>>>>>>>>>> ca-certificates >>>>>>>>>>>>>>> spice-protocol >>>>>>>>>>>>>>> frr >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I also converted client175 with 2to3 converter and built it a= nd installed the .ipfire package into a vm and successfully got the WUI page = for Media Player IPFire to render. What I haven't tested yet is if the audio = works. I will need to get audio set up in my vm to try that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If this is the only thing that flags up, we should port the = script. If we find another, stronger reason to keep Python 2 around, we do no= t need to bother and can keep the script this way. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Michael >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3 Aug 2021, at 13:31, Adolf Belka wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So with crda and the remaining python2 modules removed the = question was if removing python2 from the build ran without any problem or if= something was flagged up. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ca-certificates was flagged up. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is a python2 script, certdata2pem.py, which fails if = python2 is not present. Running that script with python3 flags up some invali= d syntax, unsurprisingly. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I found some patches in Debian from 2015 for certdata2pem.p= y to provide python3 compatibility. Unfortunately looking at the patch approx= half could not be applied because the lines don't exist in the IPFire versio= n of certdata2pem.py (sections to do with blacklisted certs) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I then ran the 2to3 converter on certdata2pem.py and tried = that in the build but it came up with the following error. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> TypeError: a bytes-like object is required, not 'str' >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I don't know how to further move forward with this as I am = totally unfamiliar with the python language. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adolf. >>>>> >=20 --===============1439913234524338276==--