Re: Delay in 14.0-RELEASE cycle and blocking items
Am 2023-05-15 um 22:36 schrieb Yuri: Yuri wrote: Michael Osipov wrote: Am 2023-05-15 um 22:19 schrieb Yuri: Michael Osipov wrote: Am 2023-05-15 um 21:37 schrieb Glen Barber: On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote: Glen, do you see any chance to get this finally merged: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? It seriously affects people (in enterprises) behind a proxy, curl will be a problem and py-requests is already a serious problem. I have bumped the bug, and pinged sef@ and cc'd re@ as a result. I do not see a problem with it, as long as it is a proper fix. Thank you! I have verified the patch back then, will happily re-verify if requested to. I just tried this (without patching): $ cat ~/.login_conf me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar': $ env | egrep 'FOO|BAR|BAZ' BAZ=foo,bar BAR=baz FOO=bar Not in /etc/login.conf: $ grep NO /etc/login.conf :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4 -R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\ $ env | grep NO NO_PROXY='localhost Weird, works for me running main-n262913-bee3d4bf8ed5: $ grep NO_PROXY /etc/login.conf :setenv=BLOCKSIZE=K,NO_PROXY='localhost,*.siemens.net':\ $ env | grep NO_PROXY NO_PROXY=localhost,*.siemens.net Oh, the fix is in there: commit f32db406504ece1b28f43dc816736e081fe22826 Author: Sean Eric Fagan Date: Sat Jan 14 10:37:31 2023 -0800 Allow a comma-separated list in login class capabilities, by adding a version of strcspn that allows quoting. So what exactly are we talking about here? :-) I am on 12-STABLE, and reported on that. Tried back than on 13, it was broken as well. You might want to try 14 with double quotes and see if it works. If at least one works, docs need to be updated for sure, and also make sure that in single quotes escapes like \c for colon still work. I'll try a VM with a main snapshot as well tomorrow. M
Re: Delay in 14.0-RELEASE cycle and blocking items
Am 2023-05-15 um 22:19 schrieb Yuri: Michael Osipov wrote: Am 2023-05-15 um 21:37 schrieb Glen Barber: On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote: Glen, do you see any chance to get this finally merged: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? It seriously affects people (in enterprises) behind a proxy, curl will be a problem and py-requests is already a serious problem. I have bumped the bug, and pinged sef@ and cc'd re@ as a result. I do not see a problem with it, as long as it is a proper fix. Thank you! I have verified the patch back then, will happily re-verify if requested to. I just tried this (without patching): $ cat ~/.login_conf me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar': $ env | egrep 'FOO|BAR|BAZ' BAZ=foo,bar BAR=baz FOO=bar Not in /etc/login.conf: $ grep NO /etc/login.conf :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4 -R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\ $ env | grep NO NO_PROXY='localhost
Re: Delay in 14.0-RELEASE cycle and blocking items
Am 2023-05-15 um 21:37 schrieb Glen Barber: On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote: Glen, do you see any chance to get this finally merged: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? It seriously affects people (in enterprises) behind a proxy, curl will be a problem and py-requests is already a serious problem. I have bumped the bug, and pinged sef@ and cc'd re@ as a result. I do not see a problem with it, as long as it is a proper fix. Thank you! I have verified the patch back then, will happily re-verify if requested to. Michael
Re: Delay in 14.0-RELEASE cycle and blocking items
Glen, do you see any chance to get this finally merged: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? It seriously affects people (in enterprises) behind a proxy, curl will be a problem and py-requests is already a serious problem. Michael
Re: Dragonfly Mail Agent (dma) in the base system
Am 2022-02-06 um 23:16 schrieb Jamie Landeg-Jones: Cy Schubert wrote: In message <202202061553.216fr0yt071...@donotpassgo.dyslexicfish.net>, Jamie La ndeg-Jones writes: Cy Schubert wrote: dma doesn't support SMTP submission, we may need to review various port default options or whether ports even support it. Good catch. You misquoted me. Read my email again! Sorry, I read it again, but it still looks to me as "some ports only work via SMTP submission, so they will need to be looked at." I suggested an alternative of instead, "emulating" the SMTP submission functionality (but maybe in a better way that my suggested hack, though) After all, it isn't just ports - there could be other third party stuff that only works via submission too. It is not that easy just too look at ports. I give you three examples from work: 1. Zabbix (network monitoring), suppports only SMTP, although PHP supports sendmail(8) 2. JavaMail Transport implementation exists only for SMTP, I was not able to find any transport implementation for sendmail(8). Maybe I will write one for fun. 3. Python mail package supports SMTP only, no other package available, at least AFAIK. Unless ecosystems provide impls for sendmail(8) I see it very hard to live without localhost:25 for many cases. Michael
Re: Dragonfly Mail Agent (dma) in the base system
Am 2022-01-30 um 15:01 schrieb michael.osi...@siemens.com: Requirements for a simplistic MTA with a relay host: * Support TLS or STARTTLS through OpenSSL in base * Verify server's certificate chain against default certstore (/etc/ssl/certs) and log success/failure, e.g, sendmail does this after config * Properly rewrite FROM for local users user@localhost or even <> when delivered with sendmail executable * Accept messages on localhost:25 or a configurable loopback address in general (e.g., multihomed with cloned interface and jails) for those applications which only support SMTP (e.g., Java Mail or other programming libraries) Another feature I have forgot: * .forward support. All mails received on a Unix account shall be redirected to the user's email address. Michael
Re: Dragonfly Mail Agent (dma) in the base system
Hi Ed, thanks for raising, this is just on time for us. I'd like to describe what both cover and not cover and I would expect from a minimal MTA. I am on 12-STABLE/12.3-RELEASE. We solely use sendmail with relay via sendmail invocation or SMTP on localhost:25. Minimal configuration for scripts and applications running on hosts and jails. Our current corporate messaging service is being phased out for a new one which requires authentication via LOGIN or PLAIN and mandatory STARTTLS, previous was anonymous and unencrypted. Sendmail: The biggest problem is that authentication strictly requires Cyrus SASL, even for stupid ones like PLAIN/LOGIN, accourding to the handbook you must recompile sendmail from base with Cyrus SASL from ports to make this possible. A showstopper actually, for two reasons: 1. I don't like mixing base and ports, it just creates a messy system. 2. While this may work with hosts, when you have jails running off a RELEASE in Bastille this obviously will not work. Not going to work with sendmail easily. DMA: Disclaimer: I haven't tried, but read documentation and source code. Although it supports TLS, I don't see any of these [1], I fail to see how it verifies the peer. I have never seen something to provide the server's fingerprint to verification. It very much feels like an SSH-like approach. It does not listen, as documented, on localhost, so applications supporting SMTP only will need extra configuration to reach out to the relay host directly. Central config at MTA side not possible anymore. Although, I don't need certificate-based authentication against the relay and DMA supports it, it does not support of using a passphrase for the certificate key file like HTTPd supports through mod_ssl. Should be a no-brainer these days. Requirements for a simplistic MTA with a relay host: * Support TLS or STARTTLS through OpenSSL in base * Verify server's certificate chain against default certstore (/etc/ssl/certs) and log success/failure, e.g, sendmail does this after config * Properly rewrite FROM for local users user@localhost or even <> when delivered with sendmail executable * Accept messages on localhost:25 or a configurable loopback address in general (e.g., multihomed with cloned interface and jails) for those applications which only support SMTP (e.g., Java Mail or other programming libraries) The issues with certificates and OpenSSL in the base system I have already extensively dicussed with kevans@ [2]. I hope this can be put into consideration. Regards, Michael [1] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_default_verify_paths.html [2] https://reviews.freebsd.org/D31487#710650
