Re: [gentoo-user] Using binary packages
On Tuesday, 23 January 2024 16:12:05 GMT I wrote: --->8 > At the moment, the only way I can see to change portage's behaviour like > that is to keep editing FEATURES in make.conf. It's obvious, really: just pass FEATURES="-getbinpkg -binpkg-request-signature" to the emerge command. Or perhaps just the -getbinpkg will do; I haven't tried it. -- Regards, Peter.
Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outbound smtp on port 587?
I'm back after several minutes backing up to two USB drives. On Tue, Jan 23, 2024 at 09:41:16PM +, Michael wrote > For SMTP server use: > > set smtp_url = "smtp://your_user_n...@www.cotse.net:465" Just one change... change "smtp://" to "smtps://", otherwise mutt won't connect... set smtp_pass="cotse_password" set smtp_url="smtps://cotse_use...@www.cotse.net:465" Sending a test message I got a prompt... This certificate belongs to: Sectigo RSA Domain Validation Secure Server CA Sectigo Limited Salford Greater Manchester GB yada, yada, yada It asked whether I wanted to (r)eject, accept (o)nce, accept (a)lways and I chose always. This post is coming to you via port 587 via fibre and via cotse.net. Thank you very much. I couldn't have done it without your deatailed help. -- Roses are red Roses are blue Depending on their velocity Relative to you
Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outbound smtp on port 587?
On Tuesday, 23 January 2024 19:09:19 GMT Walter Dnes wrote: > On Tue, Jan 23, 2024 at 04:12:05PM +, Michael wrote > > > You can also try to set deprecated TLS protocols in ~/.muttrc > > to see if this will allow for a successful connection: > > > > http://mutt.org/doc/manual/#ssl-use-tlsv1 > > Thanks. I commented out the "no" lines. TLS 1.1 failed, but TLS 1.0 > seems to work... > > # set ssl_starttls=no > # set ssl_force_tls=no > set ssl_use_tlsv1=yes > set smtp_url=smtp://smtp.ebox.ca:587 > > > You had a good crack at this, but TBH it would be easier and safer to > > find an email hosting company who use up to date TLS certificates. ;-) > > I currently use cotse.net to handle incoming email. It's served me > well, allowing me to keep the same email address over the years as I've > changed ISPs. I could do outbound email through them, but I don't like > webmail interfaces. Notice the mention of "mutt" in the subject. O_O STOP RIGHT THERE! http://cotse.net/support.html They offer SMTP on any number of ports AND require TLS authentication. No need to dance around deprecated hash algos and certificates. Remove the 'ssl_use_tlsv1=yes' directive. For SMTP server use: set smtp_url = "smtp://your_user_n...@www.cotse.net:465" You can use port 465 without STARTTLS. Mutt will negotiate an encrypted connection over TLS right off the bat. Use your username and password to login, as you do for POP3/IMAP4. Job done. > This post is coming to you via port 587 *VIA FIBRE*... whe! The > support desk phoned this morning, and we went spelunking through the > config menus of the fibre modem, and set it up. It doesn't matter what connection/IP address you use to authenticate on cotse to receive and send messages. They appear to be running a more up to date professional setup. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outbound smtp on port 587?
On Tue, Jan 23, 2024 at 04:12:05PM +, Michael wrote > You can also try to set deprecated TLS protocols in ~/.muttrc > to see if this will allow for a successful connection: > > http://mutt.org/doc/manual/#ssl-use-tlsv1 Thanks. I commented out the "no" lines. TLS 1.1 failed, but TLS 1.0 seems to work... # set ssl_starttls=no # set ssl_force_tls=no set ssl_use_tlsv1=yes set smtp_url=smtp://smtp.ebox.ca:587 > You had a good crack at this, but TBH it would be easier and safer to > find an email hosting company who use up to date TLS certificates. ;-) I currently use cotse.net to handle incoming email. It's served me well, allowing me to keep the same email address over the years as I've changed ISPs. I could do outbound email through them, but I don't like webmail interfaces. Notice the mention of "mutt" in the subject. This post is coming to you via port 587 *VIA FIBRE*... whe! The support desk phoned this morning, and we went spelunking through the config menus of the fibre modem, and set it up. -- Roses are red Roses are blue Depending on their velocity Relative to you
Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outbound smtp on port 587?
On Tuesday, 23 January 2024 15:47:28 GMT Walter Dnes wrote: > On Tue, Jan 23, 2024 at 09:36:13AM +, Michael wrote > > > Since gnutls is playing up with mutt, you can try setting USE="-gnutls" > > and re-emerge mutt to see if it succeeds establishing a connection. > > If I emerge mutt with USE="-gnutls" and comment out > "set ssl_starttls=no", email fails... > > [2024-01-23 09:38:07] Looking up smtp.ebox.ca... > [2024-01-23 09:38:07] Connecting to smtp.ebox.ca... > [2024-01-23 09:38:07] Connected to smtp.ebox.ca:587 on fd=4 > [2024-01-23 09:38:07] 4< 220 smtp.ebox.ca ESMTP Postfix (Debian/GNU) > [2024-01-23 09:38:07] 4> EHLO waltdnes.org > [2024-01-23 09:38:07] 4< 250-smtp.ebox.ca > [2024-01-23 09:38:07] 4< 250-PIPELINING > [2024-01-23 09:38:07] 4< 250-SIZE 2000 > [2024-01-23 09:38:07] 4< 250-VRFY > [2024-01-23 09:38:07] 4< 250-ETRN > [2024-01-23 09:38:07] 4< 250-STARTTLS > [2024-01-23 09:38:07] 4< 250-ENHANCEDSTATUSCODES > [2024-01-23 09:38:07] 4< 250-8BITMIME > [2024-01-23 09:38:07] 4< 250 DSN > [2024-01-23 09:38:07] 4> STARTTLS > [2024-01-23 09:38:07] 4< 220 2.0.0 Ready to start TLS > [2024-01-23 09:38:07] ssl_load_certificates: loading trusted certificates > [2024-01-23 09:38:07] mutt_ssl_starttls: Error loading trusted certificates > [2024-01-23 09:38:07] SSL failed: error:0A000102:SSL routines::unsupported > protocol [2024-01-23 09:38:08] Could not negotiate TLS connection OpenSSL bails out just as gnutls did. I was hoping it could have been more forgiving. :-( > ssl_starttls (and ssl_force_tls) default to "yes" in muttrc. If > ssl_starttls and ssl_force_tls are not explicitly set to "no", mutt > *WILL* attempt a TLS connection if advertised. Whem mutt is built with > USE="-gnutls" and attempts a TLS connection, let's just say "it does not > end well". Both OpenSSL and GnuTLS fail to negotiate an encrypted connection with the server. From the logs you have shared we can safely guess this is because the Root CA used by the server is still using a SHA1 hash. > tldr; > > It's easier for me to build in gnutls support and then (un)comment one > or two lines in ~/.mutt/muttrc as needed rather than... > > * pop up an xterm > * su - (and enter password to root) > * emerge mutt with appropriate flag(s) > * exit to regular user You can revert/keep mutt compiled with USE="gnutls". It makes no difference in this case. You can also try to set deprecated TLS protocols in ~/.muttrc to see if this will allow for a successful connection: http://mutt.org/doc/manual/#ssl-use-tlsv1 You had a good crack at this, but TBH it would be easier and safer to find an email hosting company who use up to date TLS certificates. ;-) signature.asc Description: This is a digitally signed message part.
[gentoo-user] Using binary packages
Hello list, The new ability to pull packages from Gentoo servers is useful [1]. It does require something close to neutral USE flags, though, as well as -march and - mtune. My little Celeron box only took 19 minutes (!) to fetch and install gcc, not the 23 hours it took before. I'd like to be able to tell portage to ignore the Gentoo packages in certain instances - something like half those 19 minutes were spent in checking the local indexes against the server's. And if I know I have a good local package, I don't want to have to go and make coffee or something while it goes through that checking process before ignoring the upstream packages. At the moment, the only way I can see to change portage's behaviour like that is to keep editing FEATURES in make.conf. -- Regards, Peter.
Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outbound smtp on port 587?
On Tue, Jan 23, 2024 at 09:36:13AM +, Michael wrote > Since gnutls is playing up with mutt, you can try setting USE="-gnutls" > and re-emerge mutt to see if it succeeds establishing a connection. If I emerge mutt with USE="-gnutls" and comment out "set ssl_starttls=no", email fails... [2024-01-23 09:38:07] Looking up smtp.ebox.ca... [2024-01-23 09:38:07] Connecting to smtp.ebox.ca... [2024-01-23 09:38:07] Connected to smtp.ebox.ca:587 on fd=4 [2024-01-23 09:38:07] 4< 220 smtp.ebox.ca ESMTP Postfix (Debian/GNU) [2024-01-23 09:38:07] 4> EHLO waltdnes.org [2024-01-23 09:38:07] 4< 250-smtp.ebox.ca [2024-01-23 09:38:07] 4< 250-PIPELINING [2024-01-23 09:38:07] 4< 250-SIZE 2000 [2024-01-23 09:38:07] 4< 250-VRFY [2024-01-23 09:38:07] 4< 250-ETRN [2024-01-23 09:38:07] 4< 250-STARTTLS [2024-01-23 09:38:07] 4< 250-ENHANCEDSTATUSCODES [2024-01-23 09:38:07] 4< 250-8BITMIME [2024-01-23 09:38:07] 4< 250 DSN [2024-01-23 09:38:07] 4> STARTTLS [2024-01-23 09:38:07] 4< 220 2.0.0 Ready to start TLS [2024-01-23 09:38:07] ssl_load_certificates: loading trusted certificates [2024-01-23 09:38:07] mutt_ssl_starttls: Error loading trusted certificates [2024-01-23 09:38:07] SSL failed: error:0A000102:SSL routines::unsupported protocol [2024-01-23 09:38:08] Could not negotiate TLS connection ssl_starttls (and ssl_force_tls) default to "yes" in muttrc. If ssl_starttls and ssl_force_tls are not explicitly set to "no", mutt *WILL* attempt a TLS connection if advertised. Whem mutt is built with USE="-gnutls" and attempts a TLS connection, let's just say "it does not end well". tldr; It's easier for me to build in gnutls support and then (un)comment one or two lines in ~/.mutt/muttrc as needed rather than... * pop up an xterm * su - (and enter password to root) * emerge mutt with appropriate flag(s) * exit to regular user -- Roses are red Roses are blue Depending on their velocity Relative to you
Re: [gentoo-user] Wine problems
Finally got it to work.
I added the working xorg.conf for nvidia prime as an attachment.
Maybe it will help someone else too.
Please tell me if you see anything in it that shouldn't be there.
Thanks to all who helped me with this.
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz
COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=32
-fgraphite-identity -floop-nest-optimize"
USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji"# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig: version 525.147.05
Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0"
Screen 0 "Screen1"
InputDevice"Keyboard0" "CoreKeyboard"
InputDevice"Mouse0" "CorePointer"
EndSection
Section "Files"
EndSection
Section "InputDevice"
# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/input/mice"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection
Section "InputDevice"
# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName "Unknown"
Option "DPMS"
EndSection
Section "Device"
Identifier "Device0"
Driver "modesetting"
VendorName "NVIDIA Corporation"
ChipId 0x0
ChipRev 0x0
IRQ 0
EndSection
Section "Device"
Identifier "Device1"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BusID "PCI:1:0:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
DefaultDepth24
SubSection "Display"
Depth 24
EndSubSection
Option "metamodes" "1920x1080 +0+0 {ForceCompositionPipeline=On}"
EndSection
Section "Screen"
Identifier "Screen1"
Device "Device1"
Monitor"Monitor0"
DefaultDepth24
SubSection "Display"
Depth 24
EndSubSection
Option "metamodes" "1920x1080 +0+0 {ForceCompositionPipeline=On}"
EndSection
Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outboung smtp on port 587?
On Tuesday, 23 January 2024 04:21:13 GMT Walter Dnes wrote: > The message from my ISP about port 587 said... > > >> It has to be set with SSL, without any authentication. Since gnutls is playing up with mutt, you can try setting USE="-gnutls" and re-emerge mutt to see if it succeeds establishing a connection. > Does SSL help privacy at all? Yes. Data transferred between client and server will be encrypted. Secure Socket Layer (SSL) as it was and its evolved successor Transport Layer Security (TLS) are cryptographic protocols used to encrypt and authenticate data transferred between servers and applications. The concept of TLS and use of TLS certificates is to ensure clients know (can verify) the server they are connecting with is hosted on the intended domain and data transferred back and forth has not been tampered with. In addition encryption of the transport layer allows encapsulated data between client and server to remain private. Client authentication credentials transferred between two parties over TLS ensure only legitimate users are allowed to access their data on the server. Server authentication verifies the legitimacy of the user usually by means of a username and password, although client TLS certificates, tokens and what not can be used for the same purpose. The client's IP address can be used as an additional verification check, but this is usually implemented between static network end points between machines - e.g. VPN between HQ and satellite offices. User authentication based on the mail client's IP address only is a weak verification mechanism, both because of the potential for IP address spoofing by malicious actors and because the user may want to retain their privacy from other hosts who happen to share the same IP address. > BTW, if mutt does *ANY* external > ccommunication it seems to require the "ssl" USE flag. Trying... > > USE="-ssl" emerge -pv mutt > > ...on my system dies with... > > The following REQUIRED_USE flag constraints are unsatisfied: > imap? ( ssl ) pop? ( ssl ) smtp? ( ssl ) The SSL flag on mutt ensures the package is compiled with TLS support: $ euse -i ssl global use flags (searching: ssl) [+ D ] ssl - Add support for SSL/TLS connections (Secure Socket Layer / Transport Layer Security) [snip ...] This is because TLS is ubiquitous today across web site and email server implementations. The WWW days of innocence are long gone, if they ever really existed. > > This message coming to you via port 587 Port 587 is used for message submission as per RFC6409, using ESMTP, but an encrypted connection is optional and a matter of server implementation. Depending on how the mail server has been configured, TLS encryption may be implemented or indeed required on any port conventionally used to send messages (25, 465, 587, 2525). signature.asc Description: This is a digitally signed message part.
