Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On 8/19/24 7:26 PM, Peter N. M. Hansteen wrote: On Mon, Aug 19, 2024 at 02:57:28PM +0200, Renaud Allard wrote: That's indeed quite odd if connecting with openssl s_client works. I really think you should try out asking exim devs. reported as https://bugs.exim.org/show_bug.cgi?id=3108 I will go after stack traces, would you be able to dig out the git hash used for the build? I suppose they mean 8cb2cf17f0aba94df3a5a1109b28337949e3f7c1 as in https://git.exim.org/exim.git/commit/8cb2cf17f0aba94df3a5a1109b28337949e3f7c1 smime.p7s Description: S/MIME Cryptographic Signature
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On 8/19/24 4:13 PM, Stuart Henderson wrote: (If it _does_ stay, perhaps it should switch to using gnutls). I am not sure this is a good idea. In the past I had quite a lot of issues when built with gnutls. This was under linux and lots of time ago, but this might still bring some issues that we don't have for now. smime.p7s Description: S/MIME Cryptographic Signature
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On 8/19/24 3:26 PM, Theo Buehler wrote: On Mon, Aug 19, 2024 at 02:57:28PM +0200, Renaud Allard wrote: On 8/19/24 12:04 PM, Peter Nicolai Mathias Hansteen wrote: So quite odd, the whole thing. That's indeed quite odd if connecting with openssl s_client works. I really think you should try out asking exim devs. It would be helpful to have a reproducer or a backtrace. It is impossible to gather much info from this discussion. I tried to check simple things since I am unable to reproduce it. But, indeed, nothing really came from there. While it is impossible to be sure where exactly the bug lies, it sure looks as if exim had another pretty bad bug in a release. The diff doesn't show much information since it's mostly pointless churn. They did change some things in TLS, but there is not enough info in the changelog to say what really changed and why. I think it is about time to seriously consider removing exim from the ports tree for good. I must admit Peter's config is simple enough to be migrated to opensmtpd quite easily. smime.p7s Description: S/MIME Cryptographic Signature
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On 8/19/24 12:04 PM, Peter Nicolai Mathias Hansteen wrote: So quite odd, the whole thing. That's indeed quite odd if connecting with openssl s_client works. I really think you should try out asking exim devs. smime.p7s Description: S/MIME Cryptographic Signature
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On 8/19/24 11:45 AM, Peter N. M. Hansteen wrote: And the log has the same errors as before - 2024-08-19 11:41:30 1sfytD-8rO-2Mur Completed 2024-08-19 11:42:17 1sfyu1-Eqn-0YUe SIGSEGV (fault address: 0xc126c7df) 2024-08-19 11:42:17 1sfyu1-Eqn-0YUe SIGSEGV (maybe attempt to write to immutable memory) 2024-08-19 11:42:17 1sfyu1-Eqn-0YUe SIGSEGV (57089 handling TLS incoming connection from mail.openbsd.org [199.185.178.25] ) 2024-08-19 11:42:17 1sfyu1-Eqn-0YUe backtrace 2024-08-19 11:42:17 1sfyu1-Eqn-0YUe --- 2024-08-19 11:42:17 1sfyu1-Eqn-0YUe 0xda8d6366c98 at /usr/local/bin/exim 2024-08-19 11:42:17 1sfyu1-Eqn-0YUe --- 2024-08-19 11:42:22 1sfyu6-9TK-22hb SIGSEGV (fault address: 0xce7bfcd7) 2024-08-19 11:42:22 1sfyu6-9TK-22hb SIGSEGV (maybe attempt to write to immutable memory) 2024-08-19 11:42:22 1sfyu6-9TK-22hb SIGSEGV (36414 handling TLS incoming connection from geekbay.nuug.no [158.36.191.213] ) 2024-08-19 11:42:22 1sfyu6-9TK-22hb backtrace 2024-08-19 11:42:22 1sfyu6-9TK-22hb --- 2024-08-19 11:42:22 1sfyu6-9TK-22hb 0xda8d6366c98 at /usr/local/bin/exim 2024-08-19 11:42:22 1sfyu6-9TK-22hb --- 2024-08-19 11:42:23 1sfyu7-F55-3YPd SIGSEGV (fault address: 0x31cb4d47) 2024-08-19 11:42:23 1sfyu7-F55-3YPd SIGSEGV (maybe attempt to write to immutable memory) 2024-08-19 11:42:23 1sfyu7-F55-3YPd SIGSEGV (57975 handling TLS incoming connection from portal.nuug.no [158.36.191.225] ) 2024-08-19 11:42:23 1sfyu7-F55-3YPd backtrace 2024-08-19 11:42:23 1sfyu7-F55-3YPd --- 2024-08-19 11:42:23 1sfyu7-F55-3YPd 0xda8d6366c98 at /usr/local/bin/exim 2024-08-19 11:42:23 1sfyu7-F55-3YPd --- 2024-08-19 11:42:53 no host name found for IP address 134.209.237.226 2024-08-19 11:43:09 1sfyur-6u5-1ccL SIGSEGV (fault address: 0x1082660f) 2024-08-19 11:43:09 1sfyur-6u5-1ccL SIGSEGV (maybe attempt to write to immutable memory) 2024-08-19 11:43:09 1sfyur-6u5-1ccL SIGSEGV (26541 handling TLS incoming connection from mail-vk1-xa31.google.com [2607:f8b0:4864:20::a31] ) 2024-08-19 11:43:09 1sfyur-6u5-1ccL backtrace 2024-08-19 11:43:09 1sfyur-6u5-1ccL --- 2024-08-19 11:43:09 1sfyur-6u5-1ccL 0xda8d6366c98 at /usr/local/bin/exim 2024-08-19 11:43:09 1sfyur-6u5-1ccL --- 2024-08-19 11:43:37 Warning: purging the environment. Suggested action: use keep_environment. 2024-08-19 11:43:37 1sfyvJ-Agd-40yI <= pe...@skapet.bsdly.net U=peter P=local S=4537 id=zsmtyzvgwjscd...@skapet.bsdly.net 2024-08-19 11:43:38 1sfyvJ-Agd-40yI failed to open DB file /var/spool/exim/db/wait-remote_smtp: File exists 2024-08-19 11:43:39 1sfyvJ-Agd-40yI => ren...@allard.it R=dnslookup T=remote_smtp H=mail.arnor.org [91.183.56.64] X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=yes C="250 2.0.0 0bd1fc54 Message accepted for delivery" 2024-08-19 11:43:39 1sfyvJ-Agd-40yI failed to open DB file /var/spool/exim/db/wait-remote_smtp: File exists 2024-08-19 11:43:39 1sfyvJ-Agd-40yI => bugs@openbsd.org R=dnslookup T=remote_smtp H=mail.openbsd.org [199.185.178.25] X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=yes C="250 2.0.0 ed3c8300 Message accepted for delivery" 2024-08-19 11:43:39 1sfyvJ-Agd-40yI Completed Is 134.209.237.226 the IP you tested your "s_client" from? Because I can't see any "error handling TLS incoming connection" from that IP. Besides, the SSL connection worked in your former mail. Also, do you have any custom vm.malloc_conf settings? smime.p7s Description: S/MIME Cryptographic Signature
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On 8/19/24 11:16 AM, Peter N. M. Hansteen wrote: On Mon, Aug 19, 2024 at 11:11:40AM +0200, Peter N. M. Hansteen wrote: On Mon, Aug 19, 2024 at 10:54:00AM +0200, Renaud Allard wrote: Your configuration looks indeed very simple without anything unusual. I added your tls_require_ciphers as this is the only thing that is really different from my test server at connection time, but I still couldn't reproduce the issue. Your certificate contains multiple wildcard SAN names, that might be part of the issues, although I don't see why it would be that. As a suggestion, you should consider disabling rfc1413 requests unless you know you need them (it's disabled by default in 4.86+). Yes, I can comment out that section. I was never entirely sure it adds any actual value. Unfortunately commenting out that section, running a new pkg_add -vurm to get a new exim produced identical results 2024-08-19 11:12:47 1sec8H-P17-2SB8 == dh_iws...@vps59238.dreamhostps.com R=dnslookup T=remote_smtp defer (-54): retry time not reached for any host for 'vps59238.dreamhostps.com' 2024-08-19 11:12:47 End queue run: pid=33271 2024-08-19 11:13:00 1sfyRg-IJK-0m6Q SIGSEGV (fault address: 0xe3aa2caf) 2024-08-19 11:13:00 1sfyRg-IJK-0m6Q SIGSEGV (maybe attempt to write to immutable memory) 2024-08-19 11:13:00 1sfyRg-IJK-0m6Q SIGSEGV (70390 handling TLS incoming connection from mail.openbsd.org [199.185.178.25] ) 2024-08-19 11:13:00 1sfyRg-IJK-0m6Q backtrace 2024-08-19 11:13:00 1sfyRg-IJK-0m6Q --- 2024-08-19 11:13:00 1sfyRg-IJK-0m6Q 0xbe2ced3bc98 at /usr/local/bin/exim 2024-08-19 11:13:00 1sfyRg-IJK-0m6Q --- so I reinstalled the locally built older one for now It would have surprised me if it was rfc1413 requests, but that was something to test. Does it also do the same error if you just connect with "openssl s_client -starttls smtp -connect localhost:25"? smime.p7s Description: S/MIME Cryptographic Signature
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On 8/19/24 10:12 AM, Peter N. M. Hansteen wrote: On Mon, Aug 19, 2024 at 10:05:01AM +0200, Renaud Allard wrote: There are no secrets in my config, so I can give you a copy if that helps at all. Well, if you have no secrets inside that configuration, it might help if I can see/try it. sure, my /etc/exim/configure follows attached. Please let me know if you need anything else. All the best, Peter Your configuration looks indeed very simple without anything unusual. I added your tls_require_ciphers as this is the only thing that is really different from my test server at connection time, but I still couldn't reproduce the issue. Your certificate contains multiple wildcard SAN names, that might be part of the issues, although I don't see why it would be that. As a suggestion, you should consider disabling rfc1413 requests unless you know you need them (it's disabled by default in 4.86+). smime.p7s Description: S/MIME Cryptographic Signature
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On 8/19/24 10:02 AM, Peter N. M. Hansteen wrote: On Mon, Aug 19, 2024 at 09:17:03AM +0200, Renaud Allard wrote: I still cannot reproduce this on latest snapshot from today and package from repo. OpenBSD current.arnor.org 7.6 GENERIC.MP#265 amd64 I have noticed that the same kind of error has already been seen in other versions of exim and it was a little bit configuration dependent. It might be a good idea to work out with exim dev team directly if it doesn't work with the same snapshot as the one I tried. There are no secrets in my config, so I can give you a copy if that helps at all. Well, if you have no secrets inside that configuration, it might help if I can see/try it. smime.p7s Description: S/MIME Cryptographic Signature
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On 8/19/24 8:46 AM, Renaud Allard wrote:
On 8/18/24 4:58 PM, Peter N. M. Hansteen wrote:
On Sun, Aug 18, 2024 at 01:57:11PM +0100, Stuart Henderson wrote:
Is this exim 4.97.1 or 4.98? If it's 4.98 can you try building 4.97.1
('cvs up -D 2024/07/29' in mail/exim) to see whether it was the update
or something else causing it?
downgrading to exim 4.97.1 has tls mail flowing again, thanks!
All the best,
Peter
I am unable to replicate the problem on snapshot
OpenBSD 7.6 GENERIC.MP#242 amd64
But package has been built by me.
I will sysupgrade and install package from ports repo to check if I can
reproduce.
I still cannot reproduce this on latest snapshot from today and package
from repo.
OpenBSD current.arnor.org 7.6 GENERIC.MP#265 amd64
I have noticed that the same kind of error has already been seen in
other versions of exim and it was a little bit configuration dependent.
It might be a good idea to work out with exim dev team directly if it
doesn't work with the same snapshot as the one I tried.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On 8/18/24 4:58 PM, Peter N. M. Hansteen wrote:
On Sun, Aug 18, 2024 at 01:57:11PM +0100, Stuart Henderson wrote:
Is this exim 4.97.1 or 4.98? If it's 4.98 can you try building 4.97.1
('cvs up -D 2024/07/29' in mail/exim) to see whether it was the update
or something else causing it?
downgrading to exim 4.97.1 has tls mail flowing again, thanks!
All the best,
Peter
I am unable to replicate the problem on snapshot
OpenBSD 7.6 GENERIC.MP#242 amd64
But package has been built by me.
I will sysupgrade and install package from ports repo to check if I can
reproduce.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: acme-client canary corrupted issue
On 12/14/22 15:56, Otto Moerbeek wrote:
On Wed, Dec 14, 2022 at 03:51:44PM +0100, Renaud Allard wrote:
On 12/14/22 14:44, Theo de Raadt wrote:
sysctl kern.nosuidcoredump=3
mkdir /var/crash/acme-client
and then try to reproduce, and see if a core file is delivered there.
This coredump mechanism was added to capture some hard-to-capture coredumps,
you can see more info in core(5) and sysctl(3)
Thanks
I have been able to reproduce it reliably with the staging API, however,
there is no core dump generated in /var/crash/acme-client.
To reproduce it, you need a certificate with alternative names using
multiple different domains. Generate a cert, then fully remove one of the
domains and ask for a forced reissue.
I tried with following Otto patch from today, and it seems it solves the
issue.
Are you sure you attached the right patch?
-Otto
Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.23
diff -u -p -r1.23 acctproc.c
--- acctproc.c 14 Jan 2022 09:20:18 - 1.23
+++ acctproc.c 14 Dec 2022 11:06:45 -
@@ -439,6 +439,7 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc
rc = 1;
out:
+ ECDSA_SIG_free(ec_sig);
EVP_MD_CTX_free(ctx);
free(pay);
free(sign);
OK, with both patches (one from Otto and the other from Theo B (sorry I
mistaken the first patch author)) and 4 tries, I have not got the crash
anymore.
Index: revokeproc.c
===
RCS file: /home/cvs/src/usr.sbin/acme-client/revokeproc.c,v
retrieving revision 1.19
diff -u -p -r1.19 revokeproc.c
--- revokeproc.c22 Nov 2021 08:26:08 - 1.19
+++ revokeproc.c14 Dec 2022 14:16:46 -
@@ -239,6 +239,7 @@ revokeproc(int fd, const char *certfile,
goto out;
}
force = 2;
+ continue;
}
if (found[j]++) {
if (revocate) {
smime.p7s
Description: S/MIME Cryptographic Signature
Re: acme-client canary corrupted issue
On 12/14/22 15:56, Otto Moerbeek wrote: On Wed, Dec 14, 2022 at 03:51:44PM +0100, Renaud Allard wrote: On 12/14/22 14:44, Theo de Raadt wrote: sysctl kern.nosuidcoredump=3 mkdir /var/crash/acme-client and then try to reproduce, and see if a core file is delivered there. This coredump mechanism was added to capture some hard-to-capture coredumps, you can see more info in core(5) and sysctl(3) Thanks I have been able to reproduce it reliably with the staging API, however, there is no core dump generated in /var/crash/acme-client. To reproduce it, you need a certificate with alternative names using multiple different domains. Generate a cert, then fully remove one of the domains and ask for a forced reissue. I tried with following Otto patch from today, and it seems it solves the issue. Are you sure you attached the right patch? -Otto Ahh, that's a strange one. On the first run, the crash didn't happen anymore with that patch, but I retried again to be sure and the crash is still there. I will try again with your "continue" patch too, and make 3 tries to be sure. Would a ktrace help? Index: acctproc.c === RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v retrieving revision 1.23 diff -u -p -r1.23 acctproc.c --- acctproc.c 14 Jan 2022 09:20:18 - 1.23 +++ acctproc.c 14 Dec 2022 11:06:45 - @@ -439,6 +439,7 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc rc = 1; out: + ECDSA_SIG_free(ec_sig); EVP_MD_CTX_free(ctx); free(pay); free(sign); smime.p7s Description: S/MIME Cryptographic Signature
Re: acme-client canary corrupted issue
On 12/14/22 14:44, Theo de Raadt wrote: sysctl kern.nosuidcoredump=3 mkdir /var/crash/acme-client and then try to reproduce, and see if a core file is delivered there. This coredump mechanism was added to capture some hard-to-capture coredumps, you can see more info in core(5) and sysctl(3) Thanks I have been able to reproduce it reliably with the staging API, however, there is no core dump generated in /var/crash/acme-client. To reproduce it, you need a certificate with alternative names using multiple different domains. Generate a cert, then fully remove one of the domains and ask for a forced reissue. I tried with following Otto patch from today, and it seems it solves the issue. Index: acctproc.c === RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v retrieving revision 1.23 diff -u -p -r1.23 acctproc.c --- acctproc.c 14 Jan 2022 09:20:18 - 1.23 +++ acctproc.c 14 Dec 2022 11:06:45 - @@ -439,6 +439,7 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc rc = 1; out: + ECDSA_SIG_free(ec_sig); EVP_MD_CTX_free(ctx); free(pay); free(sign); smime.p7s Description: S/MIME Cryptographic Signature
Re: acme-client canary corrupted issue
Hi Otto, On 12/14/22 12:01, Otto Moerbeek wrote: On Tue, Dec 13, 2022 at 10:34:53AM +0100, Renaud Allard wrote: Hello, I was force renewing some certs because I removed some domains from the cert, and got this: acme-client(53931) in free(): chunk canary corrupted 0xa06cb09db00 0xb0@0xb0 I am using vm.malloc_conf=SUR>> Best Regards I cannot reproduce with several attempts. Please include details on platform and version. Can you show a run with -v on? That gives a hint where the problem occurs. Do you get a core dump? If so, try to get a backtrace. It's quite hard to reproduce, I only had it once when I shrank the alternative names involved in one certificate. There was no core dump. This was produced on 7.2-stable amd64 account and domain keys are ecdsa I ran it with -vvF and could get my run log thanks to tmux back buffer. I will skip all the verification/certs babble isildur# acme-client -vvF arnor.org acme-client: /somewhere/arnor.org.key: loaded domain key acme-client: /etc/acme/letsencrypt-privkey.pem: loaded account key acme-client: /somewhere/arnor.org.crt: certificate valid: 74 days left acme-client: /somewhere/arnor.org.crt: domain list changed, forcing renewal acme-client: https://acme-v02.api.letsencrypt.org/directory: directories acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248 lots of standard certs/verif dialog * -END CERTIFICATE- ] (5800 bytes) acme-client(53931) in free(): chunk canary corrupted 0xa06cb09db00 0xb0@0xb0 acme-client: /somewhere/arnor.org.crt: created acme-client: /somewhere/arnor.org.fullchain.pem: created acme-client: signal: revokeproc(53931): Abort trap Best Regards smime.p7s Description: S/MIME Cryptographic Signature
acme-client canary corrupted issue
Hello, I was force renewing some certs because I removed some domains from the cert, and got this: acme-client(53931) in free(): chunk canary corrupted 0xa06cb09db00 0xb0@0xb0 I am using vm.malloc_conf=SUR>> Best Regards smime.p7s Description: S/MIME Cryptographic Signature
Re: [7.2] pkg-readmes - synapse : wrong command in "Register a user"
OK for me, the location of the commands changed to /usr/local/bin in newer version and the example page was not updated On 11/21/22 14:09, nabbi...@scqr.net wrote: Hello. Description === In `/usr/local/share/doc/pkg-readmes/synapse` , I found wrong command in "Register a user" section. How to reproduce 1. Install synapse via `pkg_add synapse` 2. Run the command lines in the section. `/usr/local/share/synapse/register_new_matrix_user` is missing. How to fix == 1. The command lines should be: ```diff doas -u _synapse \ - /usr/local/share/synapse/register_new_matrix_user \ + /usr/local/bin/register_new_matrix_user \ -c /var/synapse/homeserver.yaml \ http://localhost:8008 Thank you for your reading and always for your great projects. smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenSMTPd crash
On 9/22/22 13:05, Stuart Henderson wrote: Note that this domain has bogus DNS records and mail will fail anyway. habitium.fr mail is handled by 10 _dc-mx.4063971290c7.habitium.fr. # host _dc-mx.4063971290c7.habitium.fr _dc-mx.4063971290c7.habitium.fr has address 212.63.111.139 Host _dc-mx.4063971290c7.habitium.fr not found: 3(NXDOMAIN) btw I don't see anything _all_ that wrong with DNS, the underscore is not really legit but lookup/connections do work The underscore is clearly not the best practices and should be avoided. But the NXDOMAIN after the resolve is not normal either, and it's not DNSSEC related. smime.p7s Description: S/MIME Cryptographic Signature
OpenSMTPd crash
Hello, I opened a bug report on github for smtpd, but I am not really sure if it's read, so I am also posting it here. It's all described in https://github.com/OpenSMTPD/OpenSMTPD/issues/1183 Basically, I am able to reliably crash OpenSMTPd by sending a mail to cont...@habitium.fr when either vm.malloc_conf flags S, U or F are set. Note that this domain has bogus DNS records and mail will fail anyway. habitium.fr mail is handled by 10 _dc-mx.4063971290c7.habitium.fr. # host _dc-mx.4063971290c7.habitium.fr _dc-mx.4063971290c7.habitium.fr has address 212.63.111.139 Host _dc-mx.4063971290c7.habitium.fr not found: 3(NXDOMAIN) Best Regards smime.p7s Description: S/MIME Cryptographic Signature
Re: sysupgrade lives in 2021
On 5/25/20 1:57 PM, Kevin Chadwick wrote: . did you ever saw something like this? for instance when you want to upgrade java, is says: open-jre 14 does not exist. I'm not an OpenBSD dev but are you asking for a more user friendly message ratter than a more pertinent one? Seems reasonable, but when I got that message. I actually wanted to upgrade to a snapshot and this messsge helped. I might have wanted to switch from snaps to release. Not sure that switch is supported but I may find the accurate message helpful there too. Better than Windows hex code, atleast 😉 You can always modify /usr/sbin/sysupgrade which is a shell script and set NEXT_VERSION to whatever you want. Just be aware that this is unsupported at best. smime.p7s Description: S/MIME Cryptographic Signature
Re: autoinstall vs install behaviour and response file
On 3/31/20 3:49 PM, Renaud Allard wrote: On 3/31/20 11:54 AM, Renaud Allard wrote: The funny part is that if I relaunch /autoinstall manually after the failure, it partitions everything as expected. It seems that when (linux) extended partitions are present, the first execution of "fdisk -iy /dev/rsd0c" doesn't correctly write the MBR and some partitions are still present. Executing it a second time correctly reinits everything. Please note that I am testing on a VM running under VMware, but this is typically a case where you want that to work if you don't have a console. While solving this in install would be as trivial as executing fdisk twice, I feel there is a need to find the root cause of this. It might be due to the macppc fix in sbin/fdisk/mbr.c r1.64 I don't know exactly the reasons why the change in r1.59 was done. smime.p7s Description: S/MIME Cryptographic Signature
Re: autoinstall vs install behaviour and response file
On 3/31/20 11:54 AM, Renaud Allard wrote: The funny part is that if I relaunch /autoinstall manually after the failure, it partitions everything as expected. It seems that when (linux) extended partitions are present, the first execution of "fdisk -iy /dev/rsd0c" doesn't correctly write the MBR and some partitions are still present. Executing it a second time correctly reinits everything. Please note that I am testing on a VM running under VMware, but this is typically a case where you want that to work if you don't have a console. While solving this in install would be as trivial as executing fdisk twice, I feel there is a need to find the root cause of this. smime.p7s Description: S/MIME Cryptographic Signature
Re: autoinstall vs install behaviour and response file
On 3/31/20 11:38 AM, Renaud Allard wrote:
On 3/31/20 11:25 AM, Stuart Henderson wrote:
On 2020/03/31 11:05, Renaud Allard wrote:
Hello,
I was trying to autoinstall OpenBSD over an existing installation of
linux.
So I used a modified (with upobsd) bsd.rd containing an
auto_install.conf.
But it seems the (MBR) partitioning line is never taken into account.
Using:
"MBR = G"
"Use (W)hole disk MBR, whole disk (G)PT or (E)dit = G"
never matches, so autoinstall is always using the default ("whole").
Pretty sure it is a "start of line" match rather than a substring match -
try "Use (W)hole = G".
Well, actually, no, if I use "your keyboard layout = be" (without the
first word "Choose", it matches. Just like the man page says.
It seems all the fdisk part is arch dependent, which might explain why
it doesn't match.
Actually using whatever is before the first parenthesis will match. So
in this case using "Use = G" matches.
It seems the issue is parentheses in this script fu:
_autorespond() {
typeset -l _q=$1 _key
local _def=$2 _l _val
[[ -f $AI_RESPFILE && -n $_q ]] || return
mv /tmp/ai/ai.conf /tmp/ai/ai.conf.tmp
while IFS=' ' read -r _l; do
[[ $_l == [!#=]*=?* ]] || continue
_key=${_l%%*([[:blank:]])=*}
_val=${_l##*([!=])=*([[:blank:]])}
[[ $_q == @(|*[[:blank:]])"$_key"@([[:blank:]?]*|) ]] &&
resp=$_val && cat && return
print -r " $_l"
done /tmp/ai/ai.conf
[[ -n $_def ]] && resp=$_def && return
err_exit "\nQuestion has no answer in response file: \"$_q\""
}
smime.p7s
Description: S/MIME Cryptographic Signature
Re: autoinstall vs install behaviour and response file
On 3/31/20 11:46 AM, Raf Czlonka wrote:
On Tue, Mar 31, 2020 at 10:25:53AM BST, Stuart Henderson wrote:
On 2020/03/31 11:05, Renaud Allard wrote:
Hello,
I was trying to autoinstall OpenBSD over an existing installation of linux.
So I used a modified (with upobsd) bsd.rd containing an auto_install.conf.
But it seems the (MBR) partitioning line is never taken into account.
Using:
"MBR = G"
"Use (W)hole disk MBR, whole disk (G)PT or (E)dit = G"
never matches, so autoinstall is always using the default ("whole").
Pretty sure it is a "start of line" match rather than a substring match -
try "Use (W)hole = G".
Also, the whole thing hinges on whether the machine boots in (U)EFI
mode and/or the latter is properly detected. If you already boot
using it, then you don't need to provide the answer to that installer
question at all as it is being taken care of automatically:
while :; do
_d=whole
_q="Use (W)hole disk MBR, whole disk (G)PT"
[[ $MDEFI == y ]] && _d=gpt
otherwise, if you know what you're doing(!), you need to answer an
additional question:
[gG]*)
if [[ $MDEFI != y ]]; then
ask_yn "An EFI/GPT disk may not boot. Proceed?"
[[ $resp == n ]] && continue
fi
I used G, just to see if it was matching the line. Using W would have
resulted in the default behaviour, so I wouldn't have seen the
difference. But also, using W doesn't give the expected results either
as the disk is not fully repartitioned for OpenBSD. So, there are
actually 2 bugs, one for not matching the line and one for not
repartitioning correctly when whole is used.
The funny part is that if I relaunch /autoinstall manually after the
failure, it partitions everything as expected.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: autoinstall vs install behaviour and response file
On 3/31/20 11:25 AM, Stuart Henderson wrote:
On 2020/03/31 11:05, Renaud Allard wrote:
Hello,
I was trying to autoinstall OpenBSD over an existing installation of linux.
So I used a modified (with upobsd) bsd.rd containing an auto_install.conf.
But it seems the (MBR) partitioning line is never taken into account.
Using:
"MBR = G"
"Use (W)hole disk MBR, whole disk (G)PT or (E)dit = G"
never matches, so autoinstall is always using the default ("whole").
Pretty sure it is a "start of line" match rather than a substring match -
try "Use (W)hole = G".
Well, actually, no, if I use "your keyboard layout = be" (without the
first word "Choose", it matches. Just like the man page says.
It seems all the fdisk part is arch dependent, which might explain why
it doesn't match.
smime.p7s
Description: S/MIME Cryptographic Signature
autoinstall vs install behaviour and response file
Hello,
I was trying to autoinstall OpenBSD over an existing installation of
linux. So I used a modified (with upobsd) bsd.rd containing an
auto_install.conf.
But it seems the (MBR) partitioning line is never taken into account.
Using:
"MBR = G"
"Use (W)hole disk MBR, whole disk (G)PT or (E)dit = G"
never matches, so autoinstall is always using the default ("whole").
Also, when using autoinstall "whole" over the already installed linux
doesn't partition anything besides some unused free space. While using
"whole" in install partitions everything as expected.
Regards
smime.p7s
Description: S/MIME Cryptographic Signature
Re: ipsec issue since at least 6.2 on VIA CPUs with padlock
On 02/14/2018 11:26 PM, Mike Belopuhov wrote:
>
> Hi,
>
> Thank you for your report, I think I forgot to convert bits to bytes.
> Please test the diff below.
>
> Cheers,
> Mike
>
>
> diff --git sys/arch/amd64/amd64/via.c sys/arch/amd64/amd64/via.c
> index c0e1e540b12..818c35f53d0 100644
> --- sys/arch/amd64/amd64/via.c
> +++ sys/arch/amd64/amd64/via.c
> @@ -177,13 +177,13 @@ viac3_crypto_newsession(u_int32_t *sidp, struct
> cryptoini *cri)
> ses->ses_klen = c->cri_klen;
> ses->ses_cw0 = cw0;
>
> /* Build expanded keys for both directions */
> AES_KeySetup_Encrypt(ses->ses_ekey, c->cri_key,
> - c->cri_klen);
> + c->cri_klen / 8);
> AES_KeySetup_Decrypt(ses->ses_dkey, c->cri_key,
> - c->cri_klen);
> + c->cri_klen / 8);
> for (i = 0; i < 4 * (AES_MAXROUNDS + 1); i++) {
> ses->ses_ekey[i] = ntohl(ses->ses_ekey[i]);
> ses->ses_dkey[i] = ntohl(ses->ses_dkey[i]);
> }
>
> diff --git sys/arch/i386/i386/via.c sys/arch/i386/i386/via.c
> index 860fa45c0ac..83a092c24b7 100644
> --- sys/arch/i386/i386/via.c
> +++ sys/arch/i386/i386/via.c
> @@ -178,13 +178,13 @@ viac3_crypto_newsession(u_int32_t *sidp, struct
> cryptoini *cri)
> ses->ses_klen = c->cri_klen;
> ses->ses_cw0 = cw0;
>
> /* Build expanded keys for both directions */
> AES_KeySetup_Encrypt(ses->ses_ekey, c->cri_key,
> - c->cri_klen);
> + c->cri_klen / 8);
> AES_KeySetup_Decrypt(ses->ses_dkey, c->cri_key,
> - c->cri_klen);
> + c->cri_klen / 8);
> for (i = 0; i < 4 * (AES_MAXROUNDS + 1); i++) {
> ses->ses_ekey[i] = ntohl(ses->ses_ekey[i]);
> ses->ses_dkey[i] = ntohl(ses->ses_dkey[i]);
> }
>
>
Hi Mike,
That patch solved the issue. I was only able to test on i386, but I
suppose it's the same for amd64.
Thank you
Cheers
smime.p7s
Description: S/MIME Cryptographic Signature
Re: ipsec issue since at least 6.2 on VIA CPUs with padlock
On 02/12/2018 01:32 PM, Renaud Allard wrote:
> Hello,
>
> I am running OpenBSD 6.2 i386 on a VIA CPU with padlock.
> cpu0: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1 GHz
> cpu0: RNG AES AES-CTR SHA1 SHA256 RSA
>
> ipsec with SHA/AES was running fine until I upgraded to 6.2. I could not
> reproduce this issue anywhere else than on that hardware.
>
> When I run an ipsec tunnel (ikev1) with AES and SHA, I can see flows and
> SA with ipsecctl -s. But no packet ever goes through enc0.
>
> If I configure the tunnel to use hmac-md5 and 3des, for which there is
> no padlock support (everything else being the same), the tunnel just
> works fine.
>
> I am now running -current and the issue is still present.
>
> I suppose there is an issue that appeared some time between 6.1 and 6.2
> which made the crypto acceleration fail with that CPU (and probably with
> other padlock enabled CPUs too).
>
I tried multiple configurations, and actually, only AES doesn't work.
SHA1 till SHA2-512 work, 3DES and blowfish work.
smime.p7s
Description: S/MIME Cryptographic Signature
ipsec issue since at least 6.2 on VIA CPUs with padlock
Hello,
I am running OpenBSD 6.2 i386 on a VIA CPU with padlock.
cpu0: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1 GHz
cpu0: RNG AES AES-CTR SHA1 SHA256 RSA
ipsec with SHA/AES was running fine until I upgraded to 6.2. I could not
reproduce this issue anywhere else than on that hardware.
When I run an ipsec tunnel (ikev1) with AES and SHA, I can see flows and
SA with ipsecctl -s. But no packet ever goes through enc0.
If I configure the tunnel to use hmac-md5 and 3des, for which there is
no padlock support (everything else being the same), the tunnel just
works fine.
I am now running -current and the issue is still present.
I suppose there is an issue that appeared some time between 6.1 and 6.2
which made the crypto acceleration fail with that CPU (and probably with
other padlock enabled CPUs too).
Best Regards
smime.p7s
Description: S/MIME Cryptographic Signature
Re: dhcpd leaving childrens after stopping.
On 02/14/2014 10:11 AM, Stuart Henderson wrote: > On 2014/02/14 10:01, Marcus MERIGHI wrote: >> ren...@allard.it (Renaud Allard), 2014.02.14 (Fri) 09:12 (CET): >>> Hello, >>> >>> I have configured dhcpd to fill pf tables with the leases given by starting >>> it with "-A dhcp_leases -C dhcp_leases -L dhcp_leases" >>> This went OK for some time, then at some point I tried to restart dhcpd with >>> "/etc/rc.d/dhcpd restart" and got: >>> Feb 14 08:40:01 pippin dhcpd[24771]: Can't find free bpf: No such file or >>> directory >>> >>> Then I noticed many of those still running: >>> _dhcp28376 0.0 0.0 1052 932 ?? I 6Feb140:00.02 dhcpd: pf >>> table handler (dhcpd) >>> >>> After killing them (or creating bpfs) I was able to restart dhcpd. >>> >>> So for some reason, dhcpd is not killing all its children when dying. >>> >>> This is on OpenBSD 5.4 amd64 with all errata patches applied >> For the records: a known one: >> http://marc.info/?l=openbsd-misc&m=134558065817431 >> http://marc.info/?l=openbsd-tech&m=135409469600527 >> >> Bye, Marcus >> > Yes, long-standing bug, but I think the diff in those posts is wrong, > in my opinion the bug is in dhcpd not the rc script. > And flushing the tables might not be wanted either as if you do a restart of dhcpd, you probably want already connected people to still have their accesses without having to renew their leases. [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
dhcpd leaving childrens after stopping.
Hello, I have configured dhcpd to fill pf tables with the leases given by starting it with "-A dhcp_leases -C dhcp_leases -L dhcp_leases" This went OK for some time, then at some point I tried to restart dhcpd with "/etc/rc.d/dhcpd restart" and got: Feb 14 08:40:01 pippin dhcpd[24771]: Can't find free bpf: No such file or directory Then I noticed many of those still running: _dhcp28376 0.0 0.0 1052 932 ?? I 6Feb140:00.02 dhcpd: pf table handler (dhcpd) After killing them (or creating bpfs) I was able to restart dhcpd. So for some reason, dhcpd is not killing all its children when dying. This is on OpenBSD 5.4 amd64 with all errata patches applied Best Regards
Typo in npppd.conf man page
Hello, There is a typo in npppd.conf man page (installed from a 19/03/2013 snapshot) The man page states: IPCP The icpp setting is described below: ipcp name [option ...] icpp instead of ipcp Regards
