Re: ffmpeg6 and SSP?

[Vitaly Shevtsov]

Hello!

What if you put -D_FORTIFY_SOURCE=0 into Makefile, will it help?

On Tue, Nov 14, 2023 at 9:05 AM pin  wrote:
>
> Hi all,
>
> I've reported off-list to wiz@ that building ffmpeg6 on current from Saturday 
> Nov. 11 2023 failed for me.
>
> The error is/was the same as reported here, 
> https://mail-index.netbsd.org/pkgsrc-users/2023/11/13/msg038461.html
>
> I can now confirm that downgrading userland to Nov. 8 2023 allows the build 
> to complete successfully.
> It's highly likely the issue is related to the changes introduced to ssp on 
> Nov. 10 2023
>
> Regards,
>


-- 
Vitaly

Re: ffmpeg6 and SSP?

[pin]

Hi all,

I've reported off-list to wiz@ that building ffmpeg6 on current from Saturday 
Nov. 11 2023 failed for me.

The error is/was the same as reported here, 
https://mail-index.netbsd.org/pkgsrc-users/2023/11/13/msg038461.html

I can now confirm that downgrading userland to Nov. 8 2023 allows the build to 
complete successfully.
It's highly likely the issue is related to the changes introduced to ssp on 
Nov. 10 2023

Regards,

Re: openssl3+postfix issue (ca md too weak)

[Brian Buhrow]

Hello Taylor.  Just as a point of reference, smtp clients that connect 
to domains hosted by
Microsoft, i.e. outlook.com and any other domains that use their infrastructure 
for e-mail, will
have to present a valid SSL certificate in order to submit mail to their smtp 
servers.  But
that is a different issue than Manuel is describing, as I understand it.  I 
think he is saying
that the server is presenting an SSL certificate that his client doesn't like 
when he tries to
send mail to an external smtp server.  In that case, I agree with you, his 
client shouldn't be
overly concerned about whether the server presented SSL certificate can be 
verified all the way
down the verification chain.  I guess it's fine if it does the verification and 
puts a note in
the headers, but it shouldn't stop mail from going out.

-thanks
-Brian

Re: openssl3+postfix issue (ca md too weak)

[Jörg Sonnenberger]

On Tuesday, November 14, 2023 3:39:53 AM CET Taylor R Campbell wrote:
> Unless anything has changed in the past couple years, I don't think
> there is any widespread deployment of SMTP TLS server authentication
> that means anything for general MTAs -- at best, TLS in SMTP serves as
> opportunistic encryption to defend against passive eavesdroppers.

MTA-STS, the equivalent to HTTP's HSTS, is support for all outgoing mail by at 
least Google Mail and Outlook, which covers a significant chunk of all mails.

Joerg

daily CVS update output

[NetBSD source update]

Updating src tree:
P src/distrib/notes/Makefile.inc
P src/sys/dev/ic/dwc_eqos.c
P src/sys/dev/ic/dwc_eqos_reg.h
P src/sys/dev/pci/pcidevs
P src/sys/dev/pci/pcidevs.h
P src/sys/dev/pci/pcidevs_data.h
P src/sys/dev/pci/ixgbe/ix_txrx.c
P src/sys/lib/libkern/Makefile.compiler-rt

Updating xsrc tree:


Killing core files:




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  41986084 Nov 14 03:03 ls-lRA.gz

Re: openssl3+postfix issue (ca md too weak)

[Taylor R Campbell]

[trimming tech-crypto from cc because this is a policy and
configuration issue, not a cryptography issue]

> Date: Mon, 13 Nov 2023 20:34:04 +0100
> From: Manuel Bouyer 
> 
> I'm facing an issue with postfix+openssl3 which may be critical (depending
> on how it can be fixed).
> 
> Now my postfix setup fails to send mails with
> Nov 13 20:20:53 comore postfix/smtp[6449]: warning: TLS library problem: 
> error:0A00018E:SSL routines::ca md too 
> weak:/usr/src/crypto/external/bsd/openssl/dist/ssl/statem/statem_lib.c:984:

1. This says `warning'; does the mail actually fail to go through, or
   are you just alarmed by the warning?

2. Can you describe your mail topology?

3. Can you describe the postfix configuration on every node involved
   in the topology?

  diff -u <(postconf -d) <(postconf)

   (not sure if there's an easier way to show the non-default
   settings; if there is, feel free to use that instead)

4. Can you share master.cf on every node involved if it's not the
   default?

5. If you connect to the server with `openssl s_client', what happens?

> So, as far as I understand, we end up with a postfix installation which
> can't talk to servers with valid certificates.

Unless anything has changed in the past couple years, I don't think
there is any widespread deployment of SMTP TLS server authentication
that means anything for general MTAs -- at best, TLS in SMTP serves as
opportunistic encryption to defend against passive eavesdroppers.

So I assume you must be talking about your own personal SMTP relay, or
your own personal submission endpoint, or something like that, meaning
this is not a general problem with sending mail on the internet.

(If a sender demanded that any receiving MTA show a valid certificate,
it would be a very lonely sender in the real world today -- there's no
mechanism (that I know of) for a sender to know which receiving MTAs
are expected to answer TLS with valid certificates, like writing http
vs https in the URL bar of a browser.)

Re: openssl3+postfix issue (ca md too weak)

[Steffen Nurpmeso]

Manuel Bouyer wrote in
 :
 ...
 |No, I need a strong encrypted connection

You surely have stripped the most relevant quote.
Other than that i cannot help.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: openssl3+postfix issue (ca md too weak)

[Steffen Nurpmeso]

Manuel Bouyer wrote in
 :
 |On Mon, Nov 13, 2023 at 10:24:56PM +0100, Steffen Nurpmeso wrote:
 |> Manuel Bouyer wrote in
 |>  :
 |>|Hello
 |>|I'm facing an issue with postfix+openssl3 which may be critical (dependi\
 |>|ng
 |>|on how it can be fixed).
 |>|
 |>|Now my postfix setup fails to send mails with
 ...
 |>|>From what I understood, this is the remote certificate which is not \
 |>|>accepted:
 |>|openssl 3 deprecated some signature algorithm, which are no longer \
 |>|accepted
 ...
 |> Isn't that just postfix config.
 |
 |It's possible; but I didn't find anything relevant in the postfix docs
 |
 |> Btw *i* have no problem with
 |> 
 |>   smtpd_tls_ask_ccert = no
 |>   smtpd_tls_auth_only = yes
 |>   smtpd_tls_loglevel = 1
 |>   #SMART The next is usually nice but when using client certificates
 |>   smtpd_tls_received_header = no
 |>   smtpd_tls_fingerprint_digest = sha256
 |>   smtpd_tls_mandatory_protocols = >=TLSv1.2
 |>   smtpd_tls_protocols = $smtpd_tls_mandatory_protocols
 |>   # super modern, forward secrecy TLSv1.2 / TLSv1.3 selection..
 |>   tls_high_cipherlist = EECDH+AESGCM:EECDH+AES256:EDH+AESGCM:CHACHA20
 |>   smtpd_tls_mandatory_ciphers = high
 |>   smtpd_tls_mandatory_exclude_ciphers = TLSv1
 |> 
 |> ^ This works in practice without any noticeable trouble.
 |> (But then i again i do not have to make money from that or my
 |> customers who must talk to ten year old refrigerators.)
 |
 |this is only server-side configuration; my problem is with client-side
 |rejecting the server's certificate

Well i have

  #SMART comment out next
  smtp_tls_security_level = may
  # To always go directly SMTPS/SUBMISSIONS
  #smtp_tls_wrappermode = yes
  smtp_tls_fingerprint_digest = $smtpd_tls_fingerprint_digest
  smtp_tls_mandatory_protocols = $smtpd_tls_mandatory_protocols
  smtp_tls_protocols = $smtpd_tls_protocols
  #SMART When only relaying to smarthost, the next should be =high _or_better_!
  smtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
  smtp_tls_mandatory_exclude_ciphers = $smtpd_tls_mandatory_exclude_ciphers
  smtp_tls_ciphers = $smtpd_tls_ciphers
  smtp_tls_exclude_ciphers = $smtpd_tls_exclude_ciphers
  smtp_tls_connection_reuse = yes

But if you have a problem with only one permanent remote partner
you surely want a dedicated map for that one.
Now by sheer accident i am subscribed to postfix-users for about
two years (one permanently), and in
4pksdg3w7vzj...@spike.porcupine.org Wietse Venema answered on
March 25 this year in the thread "Re: smtp_tls_security_level per
user"

  Use sender_dependent_default_transport_maps to choose a delivery
  agent from:

  /etc/postfix/master.cf:
  smtp-may  unix  ..  ..  ..  ..  ..  smtp
  -o { smtp_tls_security_level = may }
  smtp-encrypt  unix  ..  ..  ..  ..  ..  smtp
  -o { smtp_tls_security_level = encrypt }
  smtp-whatever unix  ..  ..  ..  ..  ..  smtp
  -o { smtp_tls_security_level = whatever }

  Keep in mind that SMTP is not HTTP. A destination can have multiple
  MXes, and you have no contol over TLS usage between them.

This surely can be extended to configure ciphers etc.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: openssl3+postfix issue (ca md too weak)

[Lloyd Parkes]

Maybe rebuild Postfix with the option -DSSL_SECOP_PEER ? That causes 
Postfix to always set security level 0 when using TLS.


Cheers,
Lloyd

Re: openssl3+postfix issue (ca md too weak)

[Manuel Bouyer]

On Tue, Nov 14, 2023 at 11:10:16AM +1300, Lloyd Parkes wrote:
> 
> 
> On 14/11/23 10:56, Joerg Sonnenberger wrote:
> > 
> > NIST has been sunsetting SHA1 for a long time, 2016 in fact. In many cases, 
> > there is a better trust chain
> > for Comodo intermediary certificates and admins should be installing those.
> 
> I'm not sure that's what Comodo has, even though it is the normal way of
> doing things.
> 
> I found a Comodo web page that said SHA1 will be fine, so don't worry, and
> if you are worried, you can buy a different certificate. That same web
> page's link to their intermediate certificates is a dead link. Comodo does
> not fill me with confidence.

Unfortunably I don't have the choise for this one.

> 
> I'm going to guess that the default @SECLEVEL of openssl needs to be
> adjusted if there is no Postfix specific way to adjust it. Apparently you
> can set the environment variable OPENSSL_CONF to run with a custom openssl
> configuration which can avoid reducing the security level of the rest of
> your system. Searching for "openssl @SECLEVEL" gave me the usual levels of
> StackExchange clarity, so ymmv.

I tried this; but nothing that I've tried in /etc/openssl/openssl.cnf
did seems to have any effect. I wonder if postfix is doing some specific
openssl setup that overrides the openssl.cnf settings.

But also note that I could not reproduce the problem with openssl s_client

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: openssl3+postfix issue (ca md too weak)

[Manuel Bouyer]

On Mon, Nov 13, 2023 at 10:56:00PM +0100, Joerg Sonnenberger wrote:
> On Monday, November 13, 2023 8:34:04 PM CET Manuel Bouyer wrote:
> > Hello
> > I'm facing an issue with postfix+openssl3 which may be critical (depending
> > on how it can be fixed).
> > 
> > Now my postfix setup fails to send mails with
> > Nov 13 20:20:53 comore postfix/smtp[6449]: warning: TLS library problem: 
> > error:0A00018E:SSL routines::ca md too 
> > weak:/usr/src/crypto/external/bsd/openssl/dist/ssl/statem/statem_lib.c:984:
> > 
> > From what I understood, this is the remote certificate which is not 
> > accepted:
> > openssl 3 deprecated some signature algorithm, which are no longer accepted
> > with @SECLEVEL=1 (which is the default).
> > In server's certificate chain all but the last one are signed with
> > sha384WithRSAEncryption (which should be OK). The last one (the root
> > certificate) is signed with RSA-SHA1 and I don't think this will change
> > soon:
> >  3 s:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, 
> > CN = A
> >  AA Certificate Services
> >i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, 
> > CN = A
> >  AA Certificate Services
> >a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1
> >v:NotBefore: Jan  1 00:00:00 2004 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
> > 
> > So, as far as I understand, we end up with a postfix installation which
> > can't talk to servers with valid certificates.
> 
> NIST has been sunsetting SHA1 for a long time, 2016 in fact. In many cases, 
> there is a better trust chain
> for Comodo intermediary certificates and admins should be installing those.

My chain is from October, not that old.
Maybe our CA is not completely up to date; I will have to check that.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: openssl3+postfix issue (ca md too weak)

[Lloyd Parkes]

On 14/11/23 10:56, Joerg Sonnenberger wrote:


NIST has been sunsetting SHA1 for a long time, 2016 in fact. In many cases, 
there is a better trust chain
for Comodo intermediary certificates and admins should be installing those.


I'm not sure that's what Comodo has, even though it is the normal way of 
doing things.


I found a Comodo web page that said SHA1 will be fine, so don't worry, 
and if you are worried, you can buy a different certificate. That same 
web page's link to their intermediate certificates is a dead link. 
Comodo does not fill me with confidence.


I'm going to guess that the default @SECLEVEL of openssl needs to be 
adjusted if there is no Postfix specific way to adjust it. Apparently 
you can set the environment variable OPENSSL_CONF to run with a custom 
openssl configuration which can avoid reducing the security level of the 
rest of your system. Searching for "openssl @SECLEVEL" gave me the usual 
levels of StackExchange clarity, so ymmv.


Cheers,
Lloyd

Re: openssl3+postfix issue (ca md too weak)

[Manuel Bouyer]

On Mon, Nov 13, 2023 at 10:58:38PM +0100, Steffen Nurpmeso wrote:
> Manuel Bouyer wrote in
>  :
>  |On Mon, Nov 13, 2023 at 10:24:56PM +0100, Steffen Nurpmeso wrote:
>  |> Manuel Bouyer wrote in
>  |>  :
>  |>|Hello
>  |>|I'm facing an issue with postfix+openssl3 which may be critical (dependi\
>  |>|ng
>  |>|on how it can be fixed).
>  |>|
>  |>|Now my postfix setup fails to send mails with
>  ...
>  |>|>From what I understood, this is the remote certificate which is not \
>  |>|>accepted:
>  |>|openssl 3 deprecated some signature algorithm, which are no longer \
>  |>|accepted
>  ...
>  |> Isn't that just postfix config.
>  |
>  |It's possible; but I didn't find anything relevant in the postfix docs
>  |
>  |> Btw *i* have no problem with
>  |> 
>  |>   smtpd_tls_ask_ccert = no
>  |>   smtpd_tls_auth_only = yes
>  |>   smtpd_tls_loglevel = 1
>  |>   #SMART The next is usually nice but when using client certificates
>  |>   smtpd_tls_received_header = no
>  |>   smtpd_tls_fingerprint_digest = sha256
>  |>   smtpd_tls_mandatory_protocols = >=TLSv1.2
>  |>   smtpd_tls_protocols = $smtpd_tls_mandatory_protocols
>  |>   # super modern, forward secrecy TLSv1.2 / TLSv1.3 selection..
>  |>   tls_high_cipherlist = EECDH+AESGCM:EECDH+AES256:EDH+AESGCM:CHACHA20
>  |>   smtpd_tls_mandatory_ciphers = high
>  |>   smtpd_tls_mandatory_exclude_ciphers = TLSv1
>  |> 
>  |> ^ This works in practice without any noticeable trouble.
>  |> (But then i again i do not have to make money from that or my
>  |> customers who must talk to ten year old refrigerators.)
>  |
>  |this is only server-side configuration; my problem is with client-side
>  |rejecting the server's certificate
> 
> Well i have
> 
>   #SMART comment out next
>   smtp_tls_security_level = may

I have
smtp_tls_security_level = verify

and this is what I need because a username/passwd is sent as part of
the smtp transaction

>   # To always go directly SMTPS/SUBMISSIONS
>   #smtp_tls_wrappermode = yes
>   smtp_tls_fingerprint_digest = $smtpd_tls_fingerprint_digest
>   smtp_tls_mandatory_protocols = $smtpd_tls_mandatory_protocols
>   smtp_tls_protocols = $smtpd_tls_protocols
>   #SMART When only relaying to smarthost, the next should be =high 
> _or_better_!
>   smtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
>   smtp_tls_mandatory_exclude_ciphers = $smtpd_tls_mandatory_exclude_ciphers
>   smtp_tls_ciphers = $smtpd_tls_ciphers
>   smtp_tls_exclude_ciphers = $smtpd_tls_exclude_ciphers
>   smtp_tls_connection_reuse = yes
> 
> But if you have a problem with only one permanent remote partner

In my config I have 2 possible relays (depending on the from of the email)
and both shows the same problem (yet with different certificates signed by
different CAs).

> you surely want a dedicated map for that one.

No, I need a strong encrypted connection

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: openssl3+postfix issue (ca md too weak)

[Joerg Sonnenberger]

On Monday, November 13, 2023 8:34:04 PM CET Manuel Bouyer wrote:
> Hello
> I'm facing an issue with postfix+openssl3 which may be critical (depending
> on how it can be fixed).
> 
> Now my postfix setup fails to send mails with
> Nov 13 20:20:53 comore postfix/smtp[6449]: warning: TLS library problem: 
> error:0A00018E:SSL routines::ca md too 
> weak:/usr/src/crypto/external/bsd/openssl/dist/ssl/statem/statem_lib.c:984:
> 
> From what I understood, this is the remote certificate which is not accepted:
> openssl 3 deprecated some signature algorithm, which are no longer accepted
> with @SECLEVEL=1 (which is the default).
> In server's certificate chain all but the last one are signed with
> sha384WithRSAEncryption (which should be OK). The last one (the root
> certificate) is signed with RSA-SHA1 and I don't think this will change
> soon:
>  3 s:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN 
> = A
>  AA Certificate Services
>i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN 
> = A
>  AA Certificate Services
>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1
>v:NotBefore: Jan  1 00:00:00 2004 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
> 
> So, as far as I understand, we end up with a postfix installation which
> can't talk to servers with valid certificates.

NIST has been sunsetting SHA1 for a long time, 2016 in fact. In many cases, 
there is a better trust chain
for Comodo intermediary certificates and admins should be installing those.

Joerg

Re: openssl3+postfix issue (ca md too weak)

[Manuel Bouyer]

On Mon, Nov 13, 2023 at 10:24:56PM +0100, Steffen Nurpmeso wrote:
> Manuel Bouyer wrote in
>  :
>  |Hello
>  |I'm facing an issue with postfix+openssl3 which may be critical (depending
>  |on how it can be fixed).
>  |
>  |Now my postfix setup fails to send mails with
>  |Nov 13 20:20:53 comore postfix/smtp[6449]: warning: TLS library problem: \
>  |error:0A00018E:SSL routines::ca md too weak:/usr/src/crypto/external/bsd\
>  |/openssl/dist/ssl/statem/statem_lib.c:984:
>  |
>  |>From what I understood, this is the remote certificate which is not \
>  |>accepted:
>  |openssl 3 deprecated some signature algorithm, which are no longer accepted
>  |with @SECLEVEL=1 (which is the default).
>  |In server's certificate chain all but the last one are signed with
>  |sha384WithRSAEncryption (which should be OK). The last one (the root
>  |certificate) is signed with RSA-SHA1 and I don't think this will change
>  |soon:
>  | 3 s:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, \
>  | CN = A
>  | AA Certificate Services
>  |   i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, \
>  |   CN = A
>  | AA Certificate Services
>  |   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1
>  |   v:NotBefore: Jan  1 00:00:00 2004 GMT; NotAfter: Dec 31 23:59:59 \
>  |   2028 GMT
>  |
>  |So, as far as I understand, we end up with a postfix installation which
>  |can't talk to servers with valid certificates.
>  |
>  |The solution (from google) would be to force @SECLEVEL=0 but I didn't find
>  |a way to do this for postfix. The solutions I've seen were for openvpn or
>  |curl, but nothing about postfix :(
> 
> Isn't that just postfix config.

It's possible; but I didn't find anything relevant in the postfix docs

> Btw *i* have no problem with
> 
>   smtpd_tls_ask_ccert = no
>   smtpd_tls_auth_only = yes
>   smtpd_tls_loglevel = 1
>   #SMART The next is usually nice but when using client certificates
>   smtpd_tls_received_header = no
>   smtpd_tls_fingerprint_digest = sha256
>   smtpd_tls_mandatory_protocols = >=TLSv1.2
>   smtpd_tls_protocols = $smtpd_tls_mandatory_protocols
>   # super modern, forward secrecy TLSv1.2 / TLSv1.3 selection..
>   tls_high_cipherlist = EECDH+AESGCM:EECDH+AES256:EDH+AESGCM:CHACHA20
>   smtpd_tls_mandatory_ciphers = high
>   smtpd_tls_mandatory_exclude_ciphers = TLSv1
> 
> ^ This works in practice without any noticeable trouble.
> (But then i again i do not have to make money from that or my
> customers who must talk to ten year old refrigerators.)

this is only server-side configuration; my problem is with client-side
rejecting the server's certificate

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: openssl3+postfix issue (ca md too weak)

[Steffen Nurpmeso]

Manuel Bouyer wrote in
 :
 |Hello
 |I'm facing an issue with postfix+openssl3 which may be critical (depending
 |on how it can be fixed).
 |
 |Now my postfix setup fails to send mails with
 |Nov 13 20:20:53 comore postfix/smtp[6449]: warning: TLS library problem: \
 |error:0A00018E:SSL routines::ca md too weak:/usr/src/crypto/external/bsd\
 |/openssl/dist/ssl/statem/statem_lib.c:984:
 |
 |>From what I understood, this is the remote certificate which is not \
 |>accepted:
 |openssl 3 deprecated some signature algorithm, which are no longer accepted
 |with @SECLEVEL=1 (which is the default).
 |In server's certificate chain all but the last one are signed with
 |sha384WithRSAEncryption (which should be OK). The last one (the root
 |certificate) is signed with RSA-SHA1 and I don't think this will change
 |soon:
 | 3 s:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, \
 | CN = A
 | AA Certificate Services
 |   i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, \
 |   CN = A
 | AA Certificate Services
 |   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1
 |   v:NotBefore: Jan  1 00:00:00 2004 GMT; NotAfter: Dec 31 23:59:59 \
 |   2028 GMT
 |
 |So, as far as I understand, we end up with a postfix installation which
 |can't talk to servers with valid certificates.
 |
 |The solution (from google) would be to force @SECLEVEL=0 but I didn't find
 |a way to do this for postfix. The solutions I've seen were for openvpn or
 |curl, but nothing about postfix :(

Isn't that just postfix config.  Btw *i* have no problem with

  smtpd_tls_ask_ccert = no
  smtpd_tls_auth_only = yes
  smtpd_tls_loglevel = 1
  #SMART The next is usually nice but when using client certificates
  smtpd_tls_received_header = no
  smtpd_tls_fingerprint_digest = sha256
  smtpd_tls_mandatory_protocols = >=TLSv1.2
  smtpd_tls_protocols = $smtpd_tls_mandatory_protocols
  # super modern, forward secrecy TLSv1.2 / TLSv1.3 selection..
  tls_high_cipherlist = EECDH+AESGCM:EECDH+AES256:EDH+AESGCM:CHACHA20
  smtpd_tls_mandatory_ciphers = high
  smtpd_tls_mandatory_exclude_ciphers = TLSv1

^ This works in practice without any noticeable trouble.
(But then i again i do not have to make money from that or my
customers who must talk to ten year old refrigerators.)

  # ..otherwise that
  #smtpd_tls_mandatory_ciphers = high
  #smtpd_tls_mandatory_exclude_ciphers =
  #   aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH,
  #   EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDB3-SHA, KRB5-DES, CBC3-SHA
  smtpd_tls_ciphers = $smtpd_tls_mandatory_ciphers
  smtpd_tls_exclude_ciphers = $smtpd_tls_mandatory_exclude_ciphers

Ie.  This can only be a postfix config issue, no.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Aquantia AQC100 issues

[Andrius V]

This patch seems to work as well without any noticeable difference.

NetBSD is actually reporting device like this:
aq0 at pci8 dev 0 function 0: Aquantia AQC100 10 Gigabit Network
Adapter (rev. 0x02)
aq0: Atlantic revision B1, F/W version 3.1.58

On Sun, Nov 12, 2023 at 11:58 PM matthew green  wrote:
>
> Rin Okuyama writes:
> > Hi Andrius,
> >
> > If you still have this AQC100 in working condition, can you try this patch?
> >
> > https://gist.github.com/rokuyama/ab6ba1a0fac7fa15f243d63a99e14f33
> >
> > I've collected three fibre aq(4) variants (all rev 2), and link status
> > interrupts work just fine for me. I think that link intr did not work for
> > you, not due to fibre variant, but hardware revision. If this is correct,
> > the patch above should work...
>
> this reminded me that my aq(4) doesn't have working link and that
> mlelstv suggested to me that the linux driver always uses a tick
> timer to also check status, as well as interrupts.  i implemented
> this recently and now my aq(4) has link status correctly:
>
>
> aq(4): always poll for link status
>
> some devices don't have working link status and rather than have
> a likely incomplete list of issues, always poll as well as use
> the interrupt if possible.
>
> fixes link status on this device:
>
> aq0 at pci5 dev 0 function 0: Aquantia AQC107 10 Gigabit Network Adapter 
> (rev. 0x02)
> aq0: Atlantic revision B1, F/W version 3.1.88
>
> (was otherwise functional, just didn't report status, which likely
> meant eg, dhcpcd would be upset?)
>
> idea via mlelstv@ from linux.
>
> remove sc_detect_linkstat and rename sc_poll_linkstat to
> sc_no_link_intr, as the meaning has changed.  simplify the signature
> for aq_setup_msix() and aq_establish_msix_intr(), removing forward
> decls that aren't required.  obsolete AQ_FORCE_POLL_LINKSTAT.
>
>
> Index: if_aq.c
> ===
> RCS file: /cvsroot/src/sys/dev/pci/if_aq.c,v
> retrieving revision 1.45
> diff -p -u -r1.45 if_aq.c
> --- if_aq.c 29 May 2023 08:00:05 -  1.45
> +++ if_aq.c 26 Oct 2023 06:55:28 -
> @@ -1330,8 +1330,7 @@ struct aq_softc {
> int sc_rx_irq[AQ_RSSQUEUE_MAX];
> int sc_linkstat_irq;
> bool sc_use_txrx_independent_intr;
> -   bool sc_poll_linkstat;
> -   bool sc_detect_linkstat;
> +   bool sc_no_link_intr;
>
>  #if NSYSMON_ENVSYS > 0
> struct sysmon_envsys *sc_sme;
> @@ -1443,11 +1442,9 @@ static int aq_match(device_t, cfdata_t,
>  static void aq_attach(device_t, device_t, void *);
>  static int aq_detach(device_t, int);
>
> -static int aq_setup_msix(struct aq_softc *, struct pci_attach_args *, int,
> -bool, bool);
> +static int aq_setup_msix(struct aq_softc *, struct pci_attach_args *);
>  static int aq_setup_legacy(struct aq_softc *, struct pci_attach_args *,
>  pci_intr_type_t);
> -static int aq_establish_msix_intr(struct aq_softc *, bool, bool);
>
>  static int aq_ifmedia_change(struct ifnet * const);
>  static void aq_ifmedia_status(struct ifnet * const, struct ifmediareq *);
> @@ -1784,67 +1781,57 @@ aq_attach(device_t parent, device_t self
> if (msixcount >= (sc->sc_nqueues * 2 + 1)) {
> /* TX intrs + RX intrs + LINKSTAT intrs */
> sc->sc_use_txrx_independent_intr = true;
> -   sc->sc_poll_linkstat = false;
> sc->sc_msix = true;
> } else if (msixcount >= (sc->sc_nqueues * 2)) {
> /* TX intrs + RX intrs */
> sc->sc_use_txrx_independent_intr = true;
> -   sc->sc_poll_linkstat = true;
> sc->sc_msix = true;
> } else
>  #endif
> if (msixcount >= (sc->sc_nqueues + 1)) {
> /* TX/RX intrs LINKSTAT intrs */
> sc->sc_use_txrx_independent_intr = false;
> -   sc->sc_poll_linkstat = false;
> sc->sc_msix = true;
> } else if (msixcount >= sc->sc_nqueues) {
> /* TX/RX intrs */
> sc->sc_use_txrx_independent_intr = false;
> -   sc->sc_poll_linkstat = true;
> +   sc->sc_no_link_intr = true;
> sc->sc_msix = true;
> } else {
> /* giving up using MSI-X */
> sc->sc_msix = false;
> }
>
> -   /* on AQ1a0, AQ2, or FIBRE, linkstat interrupt doesn't work? */
> -   if (aqp->aq_media_type == AQ_MEDIA_TYPE_FIBRE ||
> -   (HWTYPE_AQ1_P(sc) && FW_VERSION_MAJOR(sc) == 1) ||
> -   HWTYPE_AQ2_P(sc))
> -   sc->sc_poll_linkstat = true;
> -
> -#ifdef AQ_FORCE_POLL_LINKSTAT
> -   sc->sc_poll_linkstat = true;
> -#endif
> -
> aprint_debug_dev(sc->sc_dev,
> "ncpu=%d, pci_msix_count=%d."
> " allocate %d interrupts for %d%s queues%s\n",
> ncpu, msixcount,
> (sc->sc_use_txrx_independent_intr ?
> (sc->sc_nqueues * 2) : sc->sc_nqueues) +
> -   

openssl3+postfix issue (ca md too weak)

[Manuel Bouyer]

Hello
I'm facing an issue with postfix+openssl3 which may be critical (depending
on how it can be fixed).

Now my postfix setup fails to send mails with
Nov 13 20:20:53 comore postfix/smtp[6449]: warning: TLS library problem: 
error:0A00018E:SSL routines::ca md too 
weak:/usr/src/crypto/external/bsd/openssl/dist/ssl/statem/statem_lib.c:984:

>From what I understood, this is the remote certificate which is not accepted:
openssl 3 deprecated some signature algorithm, which are no longer accepted
with @SECLEVEL=1 (which is the default).
In server's certificate chain all but the last one are signed with
sha384WithRSAEncryption (which should be OK). The last one (the root
certificate) is signed with RSA-SHA1 and I don't think this will change
soon:
 3 s:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = A
 AA Certificate Services
   i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = A
 AA Certificate Services
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1
   v:NotBefore: Jan  1 00:00:00 2004 GMT; NotAfter: Dec 31 23:59:59 2028 GMT

So, as far as I understand, we end up with a postfix installation which
can't talk to servers with valid certificates.

The solution (from google) would be to force @SECLEVEL=0 but I didn't find
a way to do this for postfix. The solutions I've seen were for openvpn or
curl, but nothing about postfix :(

Any idea ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: sys/dev/usb/if_axen.c

[sc . dying]

hi,

On 2023/11/13 12:29, Makoto Fujiwara wrote:
> Hi,
> I have following device:
>   -
>   axen0 at uhub3 port 1
>   axen0: ASIX (0x0b95) AX88179A (0x1790), rev 2.10/2.00, addr 3
>   axen0: AX88179
>   ukphy0 at axen0 phy 3: OUI 0x00e038, model 0x0006, rev. 1
>   ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
>   axen0: Ethernet address 
>   -
> And running 10.99.10,
> it emits following lines
> 
>   Nov 13 20:24:54 beebox-03 /netbsd: [ 154.8236912] axen0: autoconfiguration 
> error: invalid buffer(pkt#1), continue
> 
> I put simple checking line as:
> 
> ---
> diff --git a/sys/dev/usb/if_axen.c b/sys/dev/usb/if_axen.c
> index 423a87e5c541..6215db354c90 100644
> --- a/sys/dev/usb/if_axen.c
> +++ b/sys/dev/usb/if_axen.c
> @@ -793,6 +793,8 @@ axen_uno_rx_loop(struct usbnet *un, struct usbnet_chain 
> *c, uint32_t total_len)
>   if ((buf[0] != 0xee) || (buf[1] != 0xee)) {
>   aprint_error_dev(un->un_dev,
>   "invalid buffer(pkt#%d), continue\n", pkt_count);
> + aprint_error_dev(un->un_dev,
> + "%04d %02x %02x\n", __LINE__, buf[0], buf[1]);
>   if_statadd(ifp, if_ierrors, pkt_count);
>   return;
>   }
> ---
> 
> and then the lines show:
> 
> Nov 13 20:25:03 beebox-03 /netbsd: [ 163.6740410] axen0: autoconfiguration 
> error: invalid buffer(pkt#1), continue
> Nov 13 20:25:03 beebox-03 /netbsd: [ 163.6740410] axen0: autoconfiguration 
> error: 0797 00 08
> 
> so buf[0]:buf[1] expected 0x is 0x0008.
> 
> I've compared to openbsd: if_axen.c 
>https://raw.githubusercontent.com/openbsd/src/master/sys/dev/usb/if_axen.c
> to N, and there are so many differencies.
> 
> Does this (N) if_axen.c works on any installation ?

I've compared with freebsd.
https://cgit.freebsd.org/src/plain/sys/dev/usb/net/if_axge.c says:

>   if ((sc->sc_flags & AXGE_FLAG_179A) != 0) {
>   /*
>* 179A chip has two firmware modes that each use different
>* transfer layouts for Ethernet over USB. The newer fw mode has
>* larger rx packet headers which seem to
>* accomodate for ethernet frames up to 9K length and a VLAN
>* field for hardware tagging, but is not backward compatible
>* with 178A/179 bulk transfer code due to the change in size
>* and field alignments. The other fw mode uses the same packet
>* headers as the older 178A/179 chips, which this driver uses.
>*
>* As we do not currently have VLAN hw tagging or jumbo support
>* in this driver anyway, we're ok forcing 179A into its compat
>* mode by default.
>*/
>   axge_write_cmd_1(sc, AXGE_FW_MODE, AXGE_FW_MODE_178A179, 0);
>   }

This might help us?
I don't have 179A, I cannot try it out.

> 
> Also, I've prepared GENERIC-axen with following conf:
>   ---
>   include "arch/amd64/conf/GENERIC"
>   options AXEN_DEBUG
>   options MSGBUFSIZE=131072
>   ---
> but No debug lines appears, please let me know what is wrong,

Please raise axendebug in ddb or crash.

# echo 'w/l axendebug 1' | crash -w

> thanks

Re: sys/dev/usb/if_axen.c

[Robert Swindells]

Makoto Fujiwara  wrote:
> I have following device:
>  -
>  axen0 at uhub3 port 1
>  axen0: ASIX (0x0b95) AX88179A (0x1790), rev 2.10/2.00, addr 3
>  axen0: AX88179
>  ukphy0 at axen0 phy 3: OUI 0x00e038, model 0x0006, rev. 1
>  ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
>  axen0: Ethernet address 
>  -
> And running 10.99.10,
> it emits following lines
>
> Nov 13 20:24:54 beebox-03 /netbsd: [ 154.8236912] axen0:
> autoconfiguration error: invalid buffer(pkt#1), continue

Please could you try the patch I posted here:



There seems to be a difference in behaviour between the AX88179 and
AX88179A, the driver in the tree is reported to work for the AX88179.

I think we need a change to the driver to detect the chip revision and
choose between two different receive functions.

Re: sys/dev/usb/if_axen.c

[Michael van Elst]

mak...@ki.nu (Makoto Fujiwara) writes:

>I've compared to openbsd: if_axen.c 
>   https://raw.githubusercontent.com/openbsd/src/master/sys/dev/usb/if_axen.c
>to N, and there are so many differencies.

>Does this (N) if_axen.c works on any installation ?


axen seems to work, but I can see that the code does nonsense if
you receive something a buffer with pkt_count == 0.

I suggest to dump the whole buffer as it was received.

Re: sys/dev/usb/if_axen.c

[Lizbeth Mutterhunt, Ph.D]

I have the same problem with this Ethernet adapter! Getting a buffer problem, 
as notebook doesn’t have ether, I use the axen0, but still no net!


Wenn einem gar niets  meer einfällt, schreit man auch nix. Mijn mute reminder!

> Op 13.11.2023 om 13:30 heeft Makoto Fujiwara  het volgende 
> geschreven:
> 
> Hi,
> I have following device:
>  -
>  axen0 at uhub3 port 1
>  axen0: ASIX (0x0b95) AX88179A (0x1790), rev 2.10/2.00, addr 3
>  axen0: AX88179
>  ukphy0 at axen0 phy 3: OUI 0x00e038, model 0x0006, rev. 1
>  ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
>  axen0: Ethernet address 
>  -
> And running 10.99.10,
> it emits following lines
> 
>  Nov 13 20:24:54 beebox-03 /netbsd: [ 154.8236912] axen0: autoconfiguration 
> error: invalid buffer(pkt#1), continue
> 
> I put simple checking line as:
> 
> ---
> diff --git a/sys/dev/usb/if_axen.c b/sys/dev/usb/if_axen.c
> index 423a87e5c541..6215db354c90 100644
> --- a/sys/dev/usb/if_axen.c
> +++ b/sys/dev/usb/if_axen.c
> @@ -793,6 +793,8 @@ axen_uno_rx_loop(struct usbnet *un, struct usbnet_chain 
> *c, uint32_t total_len)
>if ((buf[0] != 0xee) || (buf[1] != 0xee)) {
>aprint_error_dev(un->un_dev,
>"invalid buffer(pkt#%d), continue\n", pkt_count);
> +aprint_error_dev(un->un_dev,
> +"%04d %02x %02x\n", __LINE__, buf[0], buf[1]);
>if_statadd(ifp, if_ierrors, pkt_count);
>return;
>}
> ---
> 
> and then the lines show:
> 
> Nov 13 20:25:03 beebox-03 /netbsd: [ 163.6740410] axen0: autoconfiguration 
> error: invalid buffer(pkt#1), continue
> Nov 13 20:25:03 beebox-03 /netbsd: [ 163.6740410] axen0: autoconfiguration 
> error: 0797 00 08
> 
> so buf[0]:buf[1] expected 0x is 0x0008.
> 
> I've compared to openbsd: if_axen.c
>   https://raw.githubusercontent.com/openbsd/src/master/sys/dev/usb/if_axen.c
> to N, and there are so many differencies.
> 
> Does this (N) if_axen.c works on any installation ?
> 
> Also, I've prepared GENERIC-axen with following conf:
>  ---
>  include "arch/amd64/conf/GENERIC"
>  options AXEN_DEBUG
>  options MSGBUFSIZE=131072
>  ---
> but No debug lines appears, please let me know what is wrong,
> thanks
> --
> Makoto Fujiwara
> m...@netbsd.org
> mak...@if.t.u-tokyo.ac.jp
> Key fingerprint = 0BFA FAEB EAD1 90BA 7498  8F85 6809 9E0B B7EF A12E
> 
> pkgsrc freshness:
> http://www.ki.nu/~makoto/pkgsrc/check-update/00_Summary.html

sys/dev/usb/if_axen.c

[Makoto Fujiwara]

Hi,
I have following device:
  -
  axen0 at uhub3 port 1
  axen0: ASIX (0x0b95) AX88179A (0x1790), rev 2.10/2.00, addr 3
  axen0: AX88179
  ukphy0 at axen0 phy 3: OUI 0x00e038, model 0x0006, rev. 1
  ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
  axen0: Ethernet address 
  -
And running 10.99.10,
it emits following lines

  Nov 13 20:24:54 beebox-03 /netbsd: [ 154.8236912] axen0: autoconfiguration 
error: invalid buffer(pkt#1), continue

I put simple checking line as:

---
diff --git a/sys/dev/usb/if_axen.c b/sys/dev/usb/if_axen.c
index 423a87e5c541..6215db354c90 100644
--- a/sys/dev/usb/if_axen.c
+++ b/sys/dev/usb/if_axen.c
@@ -793,6 +793,8 @@ axen_uno_rx_loop(struct usbnet *un, struct usbnet_chain *c, 
uint32_t total_len)
if ((buf[0] != 0xee) || (buf[1] != 0xee)) {
aprint_error_dev(un->un_dev,
"invalid buffer(pkt#%d), continue\n", pkt_count);
+   aprint_error_dev(un->un_dev,
+   "%04d %02x %02x\n", __LINE__, buf[0], buf[1]);
if_statadd(ifp, if_ierrors, pkt_count);
return;
}
---

and then the lines show:

Nov 13 20:25:03 beebox-03 /netbsd: [ 163.6740410] axen0: autoconfiguration 
error: invalid buffer(pkt#1), continue
Nov 13 20:25:03 beebox-03 /netbsd: [ 163.6740410] axen0: autoconfiguration 
error: 0797 00 08

so buf[0]:buf[1] expected 0x is 0x0008.

I've compared to openbsd: if_axen.c 
   https://raw.githubusercontent.com/openbsd/src/master/sys/dev/usb/if_axen.c
to N, and there are so many differencies.

Does this (N) if_axen.c works on any installation ?

Also, I've prepared GENERIC-axen with following conf:
  ---
  include "arch/amd64/conf/GENERIC"
  options AXEN_DEBUG
  options MSGBUFSIZE=131072
  ---
but No debug lines appears, please let me know what is wrong,
thanks
-- 
Makoto Fujiwara
m...@netbsd.org
mak...@if.t.u-tokyo.ac.jp
Key fingerprint = 0BFA FAEB EAD1 90BA 7498  8F85 6809 9E0B B7EF A12E

pkgsrc freshness:
http://www.ki.nu/~makoto/pkgsrc/check-update/00_Summary.html

audio issue on -current

[Vitaly Shevtsov]

Hello!
I'm using the current version.

When I'm listening to music I get this error after some time:
audio1(hdafg1): audio_write: device timeout, seq=16987,
usrbuf=60224/H60224, outbuf=8192/8192
audio1(hdafg1): audio_drain: device timeout, seq=16987,
usrbuf=60224/H60224, outbuf=8192/8192

I tried different values for hw.audio1.blk_ms with no luck.

Regards,
-- 
Vitaly