Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?
Hi Walter, On Sunday, 21 January 2024 04:23:34 GMT Walter Dnes wrote: > On Thu, Jan 18, 2024 at 06:42:48PM +, Michael wrote > > > openssl s_client -connect smtp.ebox.ca\:587 -starttls smtp -showcerts > > openssl s_client -connect smtp.ebox.ca\:587 -starttls smtp -showcerts > > x.txt > > For output to x.txt, see file x.txt in attachment logs.tgz > > Output to the terminal (stderr ???) is... > > depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = > Go Daddy Root Certificate Authority - G2 verify return:1 > depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = > http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate > Authority - G2 verify return:1 > depth=0 CN = *.ebox.ca > verify return:1 > 40F73DC2087F:error:0A00014D:SSL routines:tls_process_key_exchange:legacy > sigalg disallowed or > unsupported:../openssl-3.0.12/ssl/statem/statem_clnt.c:2254: > > > That last line about "legacy sigalg disallowed or unsupported:" looks > rather ominous. I think you have found the cause of the problem. The signature algorithm SHA1 has been deprecated[1], because SHA1 has known weaknesses to some collision and pre-image attacks. Theoretically some evil actor could concoct a rogue certificate which will produce the same SHA1 digest as the Root CA your smtp server is using. Practically, this is of little concern for a Root CA, IF your OS trusts directly the Root CA certificate by having it stored in /etc/ ssl/certs/, or in your user's local store for mutt trusted certificates. Both openssl and gnutls report a successful verification of the certificate chain. > > or with gnutls-cli: > > > > gnutls-cli --starttls-proto smtp smtp.ebox.ca -p 587 > > > > then try to negotiate a connection: > > > > ehlo there > > ... > > Ctrl+D > > > > Gnutls should run starttls and when you enter "Ctrl+D" it will print out > > what > See file y.txt in logs.tgz Same warning shown in y.txt: "... RSA key 2048 bits, signed using RSA-SHA1 (broken!)" > My fibre upgrade is delayed, so I'm testing an unneceassary handoff to > port 587 on cable when an "insecure" handoff to port 25 will do. Sending user authentication credentials in the clear is not advisable for the security conscious. > I just > asked the ISP's direct support to confirm that I'm using the correct > credentials. And one last try at "mutt -d 4". Here's a snippet... > > > [2024-01-20 23:08:56] mwoh: buf[Subject: Test message 1] is short enough > [2024-01-20 23:08:56] Looking up smtp.ebox.ca... > [2024-01-20 23:08:56] Connecting to smtp.ebox.ca... > [2024-01-20 23:08:56] Connected to smtp.ebox.ca:587 on fd=4 > [2024-01-20 23:08:56] 4< 220 smtp.ebox.ca ESMTP Postfix (Debian/GNU) > [2024-01-20 23:08:56] 4> EHLO waltdnes.org > [2024-01-20 23:08:56] 4< 250-smtp.ebox.ca > [2024-01-20 23:08:56] 4< 250-PIPELINING > [2024-01-20 23:08:56] 4< 250-SIZE 2000 > [2024-01-20 23:08:56] 4< 250-VRFY > [2024-01-20 23:08:56] 4< 250-ETRN > [2024-01-20 23:08:56] 4< 250-STARTTLS > [2024-01-20 23:08:56] 4< 250-ENHANCEDSTATUSCODES > [2024-01-20 23:08:56] 4< 250-8BITMIME > [2024-01-20 23:08:56] 4< 250 DSN > [2024-01-20 23:08:56] 4> STARTTLS > [2024-01-20 23:08:56] 4< 220 2.0.0 Ready to start TLS > [2024-01-20 23:08:56] gnutls_handshake: A packet with illegal or unsupported > version was received. [2024-01-20 23:08:58] Could not negotiate TLS > connection > > > "illegal or unsupported version" ominous again. TLS 1.0 was deprecated in 2021 and there have been up to date Root certificates issued by this CA using SHA256[2]. Perhaps the server sysadmins have not yet updated their smtp server's Root CA? Anyway, to take you forward you can: 1. Keyword the latest gnutls package in case the gnutls verification criteria have been loosened. 2. Copy the Root CA into the users ~/ and point muttrc to it: set certificate_file = "~/.mutt/certificates" 3. If everything else fails, having verified yourself the server's Root CA and child certificates are all legit you can set: unset ssl_verify_host Obviously this would not be satisfactory from a security perspective. [1] https://datatracker.ietf.org/doc/html/rfc8996 [2] https://certs.godaddy.com/repository signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Kernel questions. Availability and upgrading from old kernel.
On Sunday, 21 January 2024 07:03:43 GMT Dale wrote: > Howdy, > > I did my update and noticed the message about changes to kernel > packages. Depending on how I read it, it sounds like gentoo-sources is > still available just that older versions are no longer updated as long. > If I read it a different way, it sounds like gentoo-sources is about to > stop existing. That last one doesn't sound right. I can't imagine it > just going away since there are Gentoo specific stuff in there, openrc I > think being one option lurking about somewhere. I think there is others > but been a while since I been poking around in there. gentoo-sources is > hanging around right? What was the message? > Currently I'm running 5.14.15 gentoo-sources kernel. This is no longer in the tree. You can update to the next stable release 5.15.142, or keyword 5.15.147, if you want to remain on the 5.x.x series. > I tried a good while back to > upgrade to 6.1.55 which sort of boots I think but something doesn't work > and all I get is a console. It's been a while since I tried it but it > did fail several times. What messages were printed on the console by the kernel? Did it segfault? > I did the upgrade the usual way. I used make > oldconfig and went through all the answers which are mostly no since I > still have old hardware. Is there a better way than oldconfig? This has served me well for ever and a day. The only time I recall having a problem was when I missed out some graphics drivers change. The error message in the console pointed me to the right direction. > Is > there a way to start from scratch and list all the stuff that is on in > the old kernel and then compare that to the newer kernel so I can just > enable what is different but I need? I'd rather avoid going through all > the menus hoping I recognize everything. I forget what I went to the > kitchen for. Remembering kernel options from years ago is likely to not > end well. :/ You can run oldconfig and *carefully* examine the new options proposed, before you accept of reject them. Use the kernel's /usr/src/linux/scripts/diffconfig tool to compare and contrast differences between the old config and the new config. This will show you what's changed. You could start with the latest ~amd64 kernel and work backward, or start with the next stable release from the one you're running. If you try to report a bug the devs will ask you to start with the latest ~amd64 release anyway, so this could save you time. Post boot errors and messages in case someone has a clue as to what may be missing from your kernel config. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?
On Sun, Jan 21, 2024 at 12:05:45PM +, Michael wrote > > Anyway, to take you forward you can: > > 1. Keyword the latest gnutls package in case the gnutls verification criteria > have been loosened. > > 2. Copy the Root CA into the users ~/ and point muttrc to it: > > set certificate_file = "~/.mutt/certificates" > > 3. If everything else fails, having verified yourself the server's > Root CA and child certificates are all legit you can set: > > unset ssl_verify_host > > Obviously this would not be satisfactory from a security perspective. Nothing above works, and I wonder if it's something at my end. I keep getting the same message... > gnutls_handshake: A packet with illegal or unsupported version was received. The current net-libs/gnutls-3.8.0 ebuild (and 3.8.1 and 3.8.2) has sslv2 and sslv3 enabled in IUSE ...but... "emerge -pv gnutls" shows them hard-masked. Is my system forcing sslv1 and the server rejecting me??? [ebuild R] net-libs/gnutls-3.8.0:0/30.30::gentoo USE="cxx idn nls openssl seccomp tls-heartbeat tools zlib -brotli -dane -doc -examples -pkcs11 (-sslv2) (-sslv3) -static-libs -test (-test-full) -verify-sig -zstd" 0 KiB Do you get the same? Do I have to set something in... make menuconfig -*- Cryptographic API ---> "emerge -pv mutt" [ebuild R] mail-client/mutt-2.2.12::gentoo USE="debug gnutls gpgme hcache imap lmdb mbox nls pop sasl smtp ssl -autocrypt -berkdb -doc -gdbm -gsasl -idn -kerberos -pgp-classic (-prefix) -qdbm (-selinux) -slang -smime-classic -tokyocabinet -vanilla" 0 KiB I copied certificates from x.txt to .mutt/certificates (see attachment). Is this correct? And how do I securely pass credentials? -- Roses are red Roses are blue Depending on their velocity Relative to you -BEGIN CERTIFICATE- MIIGgDCCBWigAwIBAgIIQdcTd20TTxAwDQYJKoZIhvcNAQELBQAwgbQxCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQHEwpTY290dHNkYWxlMRow GAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UECxMkaHR0cDovL2NlcnRz LmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQDEypHbyBEYWRkeSBTZWN1 cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwHhcNMjMwOTI2MDEwMDI1WhcN MjQxMDI3MDEwMDI1WjAUMRIwEAYDVQQDDAkqLmVib3guY2EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC1kgJlaAqSUNfZd2jPfxSlH0HTzvFV344iJdd3 zf01XwSySxtAKB3bwrmxfq0ppmVU4CTlj1IOTaY7uA3Fpy5V0CAE38HOpT/xsv1n 7ZXAm7jVA8UOJbFMtCwCtLArhEeGZS8ssrO51uzZquj6O2zCQeoG7cYqeQTh0Z3X x1DmsdP5Tvyot82p3SKiCoFurk/ZIMXeDbG3K+Vxw+wiFgmYYl1rBAOJpyqxIwuX NFlkNCU2K7M2LqohyO10FI/RJOn0hwuY+t7a6kZbNKLGWuuUXg29Y9TrqUXAa5yN mmJtTD6UsHfGKPZN5n1GlqgNSUDlxLKBedA7gTzHQKh+BYBhAgMBAAGjggMzMIID LzAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAO BgNVHQ8BAf8EBAMCBaAwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5nb2Rh ZGR5LmNvbS9nZGlnMnMxLTk0MDUuY3JsMF0GA1UdIARWMFQwSAYLYIZIAYb9bQEH FwEwOTA3BggrBgEFBQcCARYraHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNv bS9yZXBvc2l0b3J5LzAIBgZngQwBAgEwdgYIKwYBBQUHAQEEajBoMCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5nb2RhZGR5LmNvbS8wQAYIKwYBBQUHMAKGNGh0dHA6 Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9nZGlnMi5jcnQw HwYDVR0jBBgwFoAUQMK9J47MNIMwojPX+2yz8LQsgM4wHQYDVR0RBBYwFIIJKi5l Ym94LmNhggdlYm94LmNhMB0GA1UdDgQWBBQKTRI2+yZaO2QIMLlRwVy3A5EslTCC AX4GCisGAQQB1nkCBAIEggFuBIIBagFoAHUA7s3QZNXbGs7FXLedtM0TojKHRny8 7N7DUUhZRnEftZsAAAGKzwBtGQAABAMARjBEAiB+c8AeqWVcH6tLIN3K+jxvyrcS bezMfVwxregY56O9uwIgfdjEFhw0w7dvv6O7kyrYFLXd1KmLtZZUBkg/pSr72ScA dgBIsONr2qZHNA/lagL6nTDrHFIBy1bdLIHZu7+rOdiEcwAAAYrPAG3/AAAEAwBH MEUCIGniWz36pvx9BThv4yxeEqoAk1pEqJz9vggQfm1nsABKAiEA4DE0bNlpa90J JBpJk+ane6GP3Ycu0zG/kfjPRKGWaT4AdwDatr9rP7W2Ip+bwrtca+hwkXFsu1GE hTS9pD0wSNf7qwAAAYrPAG55AAAEAwBIMEYCIQCnqbkMcFiLX1Gc9EHlyo4Rm/T7 pCmjJV1ylgVQhk5tMQIhALGmRhmJmH77RRh0+CBKX+MZ6EtKBnci+j6jGHus7Xj4 MA0GCSqGSIb3DQEBCwUAA4IBAQBK852eVZVAZmuKFg/37ywvp1p3Otq1Iy6093pR QEoKUN5OVxLcAYJTcQSrGMZdytVNGuOe9F3mm2tP4NxOT32ERyowAFx3DOIFIJRP 6XDO9V2tUgoJ4hxMdNnzoAcnXh/naTLtWD29OpjEzsMYjFQuaeeKXa0Nk4/1bUhm Nugmmm3z2DLOumVKILzi/uZLDYdrO4vOkIxXLgBdHZFV+6ZZVR26bffvS3q3owRG 8d/eXulLowCoblX8PbNBedRVll18+t2j/FzVD7N7L7qF5076/LODbfk6fRHEXN/w 65NjrQ1RiRekUHXMjFrlTraSIEWQOAaGaDCOmcOyjcjfuk7/ -END CERTIFICATE- -BEGIN CERTIFICATE- MIIE0DCCA7igAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCVVMx EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNVBAoT EUdvRGFkZHkuY29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRp ZmljYXRlIEF1dGhvcml0eSAtIEcyMB4XDTExMDUwMzA3MDAwMFoXDTMxMDUwMzA3 MDAwMFowgbQxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQH EwpTY290dHNkYWxlMRowGAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UE CxMkaHR0cDovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQD EypHbyBEYWRkeSBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC54MsQ1K92vdSTYuswZLiBCGzD BNliF44v/z5lz4/OYuY8UhzaFkVLVat4a2ODYpDOD2lsmcgaFItMzEUz6ojcnqOv K/6AYZ15V8TPLvQ/MDxdR/yaFrzDN5ZBUY4RS1T4KL7QjL7wMDge87Am+GZHY23e cSZHjzhHU9FGHbTj3ADqRay9vHHZqm8A29vNMDp5T19MR/gd71vCxJ1gO7GyQ5HY pDNO6rPWJ0+tJYqlxvTV0KaudAVkV4i1RFXULSo6Pvi4vekyCgKUZMQWOlDxSq7n eTOvDCAHf+jfBDnCaQJsY1L6d8
Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?
On 1/21/24 11:09, Walter Dnes wrote: On Sun, Jan 21, 2024 at 12:05:45PM +, Michael wrote Anyway, to take you forward you can: 1. Keyword the latest gnutls package in case the gnutls verification criteria have been loosened. 2. Copy the Root CA into the users ~/ and point muttrc to it: set certificate_file = "~/.mutt/certificates" 3. If everything else fails, having verified yourself the server's Root CA and child certificates are all legit you can set: unset ssl_verify_host Obviously this would not be satisfactory from a security perspective. Nothing above works, and I wonder if it's something at my end. I keep getting the same message... gnutls_handshake: A packet with illegal or unsupported version was received. The current net-libs/gnutls-3.8.0 ebuild (and 3.8.1 and 3.8.2) has sslv2 and sslv3 enabled in IUSE ...but... "emerge -pv gnutls" shows them hard-masked. Is my system forcing sslv1 and the server rejecting me??? [ebuild R] net-libs/gnutls-3.8.0:0/30.30::gentoo USE="cxx idn nls openssl seccomp tls-heartbeat tools zlib -brotli -dane -doc -examples -pkcs11 (-sslv2) (-sslv3) -static-libs -test (-test-full) -verify-sig -zstd" 0 KiB I'm no expert, but I think you are mixing versions of SSL and versions of TLS. It seems both sslv2 and sslv3 have been deprecated, and my weak memory says they were replaced by TLS. Now it looks like you are having problems trying to use an older TLS which has been replaced by a newer TLS, although there are no direct use flags for that. Do you get the same? Do I have to set something in... make menuconfig -*- Cryptographic API ---> "emerge -pv mutt" [ebuild R] mail-client/mutt-2.2.12::gentoo USE="debug gnutls gpgme hcache imap lmdb mbox nls pop sasl smtp ssl -autocrypt -berkdb -doc -gdbm -gsasl -idn -kerberos -pgp-classic (-prefix) -qdbm (-selinux) -slang -smime-classic -tokyocabinet -vanilla" 0 KiB I copied certificates from x.txt to .mutt/certificates (see attachment). Is this correct? And how do I securely pass credentials?
Re: [gentoo-user] Kernel questions. Availability and upgrading from old kernel.
Michael wrote: > On Sunday, 21 January 2024 07:03:43 GMT Dale wrote: >> Howdy, >> >> I did my update and noticed the message about changes to kernel >> packages. Depending on how I read it, it sounds like gentoo-sources is >> still available just that older versions are no longer updated as long. >> If I read it a different way, it sounds like gentoo-sources is about to >> stop existing. That last one doesn't sound right. I can't imagine it >> just going away since there are Gentoo specific stuff in there, openrc I >> think being one option lurking about somewhere. I think there is others >> but been a while since I been poking around in there. gentoo-sources is >> hanging around right? > What was the message? > This was a good while back. I mostly remember it not giving me a GUI like usual. I do recall emerging the video drivers for that kernel tho. I'm pretty sure it didn't panic, just left me at a console. I'm not 100% sure tho. >> Currently I'm running 5.14.15 gentoo-sources kernel. > This is no longer in the tree. You can update to the next stable release > 5.15.142, or keyword 5.15.147, if you want to remain on the 5.x.x series. > I'm wanting to upgrade to whatever the latest is that nvidia will work with. >> I tried a good while back to >> upgrade to 6.1.55 which sort of boots I think but something doesn't work >> and all I get is a console. It's been a while since I tried it but it >> did fail several times. > What messages were printed on the console by the kernel? Did it segfault? > No clue. It was months ago at least. >> I did the upgrade the usual way. I used make >> oldconfig and went through all the answers which are mostly no since I >> still have old hardware. Is there a better way than oldconfig? > This has served me well for ever and a day. The only time I recall having a > problem was when I missed out some graphics drivers change. The error > message > in the console pointed me to the right direction. > > That has always been my case as well. I've used make oldconfig and it just worked. This time was the exception. >> Is >> there a way to start from scratch and list all the stuff that is on in >> the old kernel and then compare that to the newer kernel so I can just >> enable what is different but I need? I'd rather avoid going through all >> the menus hoping I recognize everything. I forget what I went to the >> kitchen for. Remembering kernel options from years ago is likely to not >> end well. :/ > You can run oldconfig and *carefully* examine the new options proposed, > before > you accept of reject them. > > Use the kernel's /usr/src/linux/scripts/diffconfig tool to compare and > contrast differences between the old config and the new config. This will > show > you what's changed. > > You could start with the latest ~amd64 kernel and work backward, or start > with > the next stable release from the one you're running. If you try to report a > bug the devs will ask you to start with the latest ~amd64 release anyway, so > this could save you time. > > Post boot errors and messages in case someone has a clue as to what may be > missing from your kernel config. I'll keep this in mind. I'm working on gentoo-sources-6.7.1 if nvidia-drivers will work with it. Sometimes they won't emerge, to new or something. It usually spits out a error why and how to work around it, usually a slightly older kernel version or enable some option. ;-) With this info, at least it doesn't look like something has changed and I'm far afield. Thanks. Dale :-) :-)
Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?
On Sunday, 21 January 2024 16:09:47 GMT Walter Dnes wrote: > On Sun, Jan 21, 2024 at 12:05:45PM +, Michael wrote > > > Anyway, to take you forward you can: [snip ...] > Nothing above works, and I wonder if it's something at my end. I keep > getting the same message... > > > gnutls_handshake: A packet with illegal or unsupported version was > > received. > The current net-libs/gnutls-3.8.0 ebuild (and 3.8.1 and 3.8.2) has > sslv2 and sslv3 enabled in IUSE ...but... "emerge -pv gnutls" shows > them hard-masked. Is my system forcing sslv1 and the server rejecting me??? > > [ebuild R] net-libs/gnutls-3.8.0:0/30.30::gentoo USE="cxx idn nls > openssl seccomp tls-heartbeat tools zlib -brotli -dane -doc -examples > -pkcs11 (-sslv2) (-sslv3) -static-libs -test (-test-full) -verify-sig > -zstd" 0 KiB > > Do you get the same? Do I have to set something in... > > make menuconfig > -*- Cryptographic API ---> > > "emerge -pv mutt" > > [ebuild R] mail-client/mutt-2.2.12::gentoo USE="debug gnutls gpgme > hcache imap lmdb mbox nls pop sasl smtp ssl -autocrypt -berkdb -doc -gdbm > -gsasl -idn -kerberos -pgp-classic (-prefix) -qdbm (-selinux) -slang > -smime-classic -tokyocabinet -vanilla" 0 KiB > > I copied certificates from x.txt to .mutt/certificates (see > attachment). Is this correct? And how do I securely pass credentials? Starting from the end; to securely pass credentials you need an encrypted connection to the server. For SMTP server authentication this normally takes place using STARTTLS on port 587, or explicit TLS typically on port 465 or port 25 depending on your mail provider. Your locally stored certificate chain should be in multiple .pem files, one for each certificate. Normally only the Root CA is needed since this was used to sign all its children certificates in the chain. In the first instance just store in your ~/.mutt/certificates/ directory the Root CA certificate, to see if mutt accepts it without gnutls complaining. In your attachment you have 4 certificates: 1. The certificate used by the SMTP server (a wildcard ebox.ca domain certificate): Subject: CN = *.ebox.ca which is issued by "CN = Go Daddy Secure Certificate Authority - G2". 2. The "Go Daddy Secure Certificate Authority - G2" was in turn issued by "CN = Go Daddy Root Certificate Authority - G2". 3. The "CN = Go Daddy Root Certificate Authority - G2" was issued by "OU = Go Daddy Class 2 Certification Authority". 4. Finally, the last certificate "OU = Go Daddy Class 2 Certification Authority" is the self-signed Root CA. This is the certificate you could copy into your ~/.mutt/certificates/. A copy of this certificate should be available in your /etc/ssl/certs/, so you could copy it and also hash it: cp /etc/ssl/certs/Go_Daddy_Class_2_CA.pem ~/.mutt/certificates/ cd ~/.mutt/certificates/ ln -s Go_Daddy_Class_2_CA.pem `openssl x509 -hash -noout -in Go_Daddy_Class_2_CA.pem`.0 Please note the backticks in the above. If this still won't work, have you considered ditching gnutls on mutt and trying with vanilla openssl? $ emerge -pv mutt These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 23.29 s (backtrack: 0/20). [ebuild N ] mail-client/mutt-2.2.12::gentoo USE="gdbm hcache imap lmdb nls sasl smtp ssl -autocrypt -berkdb -debug -doc -gnutls -gpgme -gsasl -idn - kerberos -mbox -pgp-classic -pop (-prefix) -qdbm (-selinux) -slang -smime- classic -tokyocabinet -vanilla" 5432 KiB $ emerge -pv gnutls These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 1.45 s (backtrack: 0/20). [ebuild R] net-libs/gnutls-3.8.0:0/30.30::gentoo USE="cxx idn nls openssl seccomp tls-heartbeat zlib -brotli -dane -doc -examples -pkcs11 (- sslv2) (-sslv3) -static-libs -test (-test-full) -tools -verify-sig -zstd" ABI_X86="(64) -32 (-x32)" 0 KiB It may be the openssl is more accommodating for Root CAs using SHA1 and will allow the connection to complete. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Kernel questions. Availability and upgrading from old kernel.
240121 Michael wrote: > On Sunday, 21 January 2024 07:03:43 GMT Dale wrote: >> Currently I'm running 5.14.15 gentoo-sources kernel. > This is no longer in the tree. You can update to the next stable release > 5.15.142, or keyword 5.15.147, if you want to remain on the 5.x.x series. I need to add 'fuse' support to my kernel to allow file transfer from my cell phone, so it seemed sensible to update to the latest stable version. The current version is 6.1.27-gentoo-r1 , which I compiled 230726. I was very surprised to find that the latest stable version is 6.1.67 , tho' 6.7.1 is listed as testing with others in between. Isn't this a bit slow ? -- no complaint re the hard-working dev's, of course. Have there been problems with more recent versions ? I'm reluctant to use a testing-version kernel. All are 'Gentoo-sources', which is what I've always used since 2003. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatcadotinterdotnet
Re: [gentoo-user] Kernel questions. Availability and upgrading from old kernel.
On 1/21/24 14:55, Philip Webb wrote: 240121 Michael wrote: On Sunday, 21 January 2024 07:03:43 GMT Dale wrote: Currently I'm running 5.14.15 gentoo-sources kernel. This is no longer in the tree. You can update to the next stable release 5.15.142, or keyword 5.15.147, if you want to remain on the 5.x.x series. I need to add 'fuse' support to my kernel to allow file transfer from my cell phone, so it seemed sensible to update to the latest stable version. The current version is 6.1.27-gentoo-r1 , which I compiled 230726. I was very surprised to find that the latest stable version is 6.1.67 , tho' 6.7.1 is listed as testing with others in between. Isn't this a bit slow ? -- no complaint re the hard-working dev's, of course. Have there been problems with more recent versions ? I'm reluctant to use a testing-version kernel. All are 'Gentoo-sources', which is what I've always used since 2003. The policy must be/should be around somewhere, but I recall discussions about how many and which kernels (gentoo-sources, and possibly others) will ever get marked Stable. I believe it is something like only series marked "longterm" at kernel.org will get marked stable, and I think it is not even all of them, although I don't recall how they choose which in each series do get stabilized. As 6.6 and 6.7 are "stable" at kernel.org, none of them will be "stable" in Gentoo.
Re: [gentoo-user] Kernel questions. Availability and upgrading from old kernel.
On 2024.01.21 15:51, Jack wrote: On 1/21/24 14:55, Philip Webb wrote: 240121 Michael wrote: On Sunday, 21 January 2024 07:03:43 GMT Dale wrote: Currently I'm running 5.14.15 gentoo-sources kernel. This is no longer in the tree. You can update to the next stable release 5.15.142, or keyword 5.15.147, if you want to remain on the 5.x.x series. I need to add 'fuse' support to my kernel to allow file transfer from my cell phone, so it seemed sensible to update to the latest stable version. The current version is 6.1.27-gentoo-r1 , which I compiled 230726. I was very surprised to find that the latest stable version is 6.1.67 , tho' 6.7.1 is listed as testing with others in between. Isn't this a bit slow ? -- no complaint re the hard-working dev's, of course. Have there been problems with more recent versions ? I'm reluctant to use a testing-version kernel. All are 'Gentoo-sources', which is what I've always used since 2003. The policy must be/should be around somewhere, but I recall discussions about how many and which kernels (gentoo-sources, and possibly others) will ever get marked Stable. I believe it is something like only series marked "longterm" at kernel.org will get marked stable, and I think it is not even all of them, although I don't recall how they choose which in each series do get stabilized. As 6.6 and 6.7 are "stable" at kernel.org, none of them will be "stable" in Gentoo. And clearly I'm wrong, at least partly, as 6.6.13 was just marked stable.
[gentoo-user] system wants to emerge unstable package
In: package.mask ... >net-misc/asterisk-20 current stable versions are; asterisk-18.18.1 but : emerge -avq asterisk wants to pull 'net-misc/asterisk-18.20.2" (which is marked as unstable, why?)
Re: [gentoo-user] system wants to emerge unstable package
syscon edm wrote: > In: package.mask > ... >> net-misc/asterisk-20 > > current stable versions are; > asterisk-18.18.1 > > but : emerge -avq asterisk > wants to pull 'net-misc/asterisk-18.20.2" (which is marked as unstable, why?) > > If you add the -t option to emerge, it should show what is pulling it in. Worth a try at least. That would be 'emerge -atvq asterisk' and check the output. Dale :-) :-)
Re: [gentoo-user] system wants to emerge unstable package
Hm..., it still wants to emerge unstable version: emerge -atvq asterisk [ebuild U ] net-misc/asterisk-18.20.2 On Sun, Jan 21, 2024 at 8:19 PM Dale wrote: > > syscon edm wrote: > > In: package.mask > > ... > >> net-misc/asterisk-20 > > > > current stable versions are; > > asterisk-18.18.1 > > > > but : emerge -avq asterisk > > wants to pull 'net-misc/asterisk-18.20.2" (which is marked as unstable, > > why?) > > > > > > > If you add the -t option to emerge, it should show what is pulling it > in. Worth a try at least. That would be 'emerge -atvq asterisk' and > check the output. > > Dale > > :-) :-) >
[gentoo-user] Kmail does not show all imap folders
Hi there, I'm using dovecot as imap server, some sieve scripts sorting incoming mails into a folder structure and kmail on multiple different machines as client. The folder structure on the server looks fine, I can access the folders via command line and I don't see anything obviously wrong. Some of those target folders are not shown on all machines, they are simply ignored; Unfortunately these folders contain important mails which I need to react to (which is bad if I do not see them on my main machine, only in some test VM). I checked folder subscriptions in kmail, but I do not see the missing folders there either. Also akonadi-console does not show them. I also tried curl imaps:/// Showing all of the missing folders, so I think its an akonadi/kmail problem and not an imap problem. Any ideas? BR Alex Kde-apps/kmail-23.08.3 Kde-frameworks/kjobwidgets-5.112.0 kde-apps/akonadi-23.08.3-r1
