~graywolf/acme-client-portable#5: 
Segfaults in keyproc and netproc

Linux-5.10.15, musl-1.2.2, libressl-3.2.2, acme-client-portable-1.2.0 (tarball, not git).

Attempting to run acme-client yields:

acme-client: signal: keyproc(6099): Segmentation fault
Assertion failed: ex != NULL (revokeproc.c: revokeproc: 181)
acme-client: read: csr: Connection reset by peer
acme-client: unknown operation from netproc
acme-client: signal: netproc(6098): Segmentation fault
acme-client: bad exit: acctproc(6100): 1
acme-client: signal: revokeproc(6105): Aborted

Where could it come from?

Status
RESOLVED FIXED
Submitter
~skarnet
Assigned to
No-one
Submitted
1 year, 2 months ago
Updated
3 months ago
Labels
No labels applied.

~graywolf 1 year, 2 months ago

On 2021-02-28 19:40:38 -0000, ~skarnet wrote:

Linux-5.10.15, musl-1.2.2, libressl-3.2.2

In #2 someone reported issue that I suspect is caused by libressl (well, or rather by my usage of it I guess).

Attempting to run acme-client yields:

acme-client: signal: keyproc(6099): Segmentation fault
Assertion failed: ex != NULL (revokeproc.c: revokeproc: 181)
acme-client: read: csr: Connection reset by peer
acme-client: unknown operation from netproc
acme-client: signal: netproc(6098): Segmentation fault
acme-client: bad exit: acctproc(6100): 1
acme-client: signal: revokeproc(6105): Aborted

Where could it come from?

Possibly the ifdef in revokeproc.c:170 is not correct for libressl, not sure.

Would it be possible for you to try with openssl to see if that fixes the issue?

I might try looking into this later, but cannot guarantee when. All my machines do use openssl, so I did not test this with libressl, I just assumed it is compatible. Seems not.

W.

-- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

~skarnet 1 year, 2 months ago

I'll try with openssl, but it will take some time because I don't have it installed, and I don't have perl either for the openssl build. Which is the main reason why I use libressl: fewer dependencies.

Since OpenBSD uses libressl, why wouldn't you just keep it as is? I don't know what changes you made to "port" it to openssl, but it must have been additional effort (which, to me, is end-negative!) that you could have just spared. Unless acme-client uses libtls, the SSL_* primitives shouldn't need modification to work with openssl!

~graywolf 1 year, 2 months ago

On 2021-02-28 22:00:42 -0000, ~skarnet wrote:

I'll try with openssl, but it will take some time because I don't have it installed, and I don't have perl either for the openssl build. Which is the main reason why I use libressl: fewer dependencies.

I do see the advantage :) But I'm surprised your distro does not package openssl at all.

Since OpenBSD uses libressl, why wouldn't you just keep it as is? I don't know what changes you made to "port" it to openssl, but it must have been additional effort (which, to me, is end-negative!) that you could have just spared.

It is some time now, but if I remember, the original version did not work with openssl 1.0. So I've ported and tested it against 1.0 and 1.1 assuming libressl would provide proper version defines and just-work(tm).

Unless acme-client uses libtls, the SSL_* primitives shouldn't need modification to work with openssl!

If by this you mean tls.h, then yes, that is used in the original openbsd version. I know that was another reason why I had to change stuff.

I will try to look into this as well, but the time should be measured in weeks, I have some other things that need to be finished first. Long term I obviously want this to work in my port, since it's supposed to be portable.

W.

PS: If you just want to get something working quickly, I think you could just take original openbsd source code, and just define pledge and veil to no ops.

-- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

~skarnet 1 year, 2 months ago

I managed to get perl and openssl working and I can confirm acme-client-portable-1.2.0 works with openssl.

The reason why I didn't have it in the first place is that I do not use a distro on my servers. I build my systems by hand, bootstrapped from source; that's part of my skillset. And part of why I want to use a C client for ACME instead of the monstrosities advertised by LetsEncrypt. :-)

I would love to see a version of acme-client using LibreSSL, unchanged except for the removal of OpenBSD-specific calls. What prevents me from doing it is that now that acme-client has been integrated into OpenBSD, it's difficult to access its source without having an OpenBSD machine installed, which takes more time and resources than I want to devote to this.

tls.h is a decent interface and replacing it with the horrendous OpenSSL interface can't have been nice work - and if it your replacement actually breaks with LibreSSL, chances are it's not doing everything correctly. Anyway, with OpenSSL things appear to work, so it will do until you can take a deeper look. Thanks!

~graywolf closed duplicate ticket #2 1 year, 2 months ago

~graywolf 8 months ago

Hello,

sorry for taking so long to get back to you. Could you please try current master? In order to use tls from libressl (which you likely want), pass --with-libtls to the configure script.

Based on my testing it should work with libressl now. So please give it a shot.

If it is fine I will release 1.3.0 which will contain some more bug fixes.

~graywolf 8 months ago

I would love to see a version of acme-client using LibreSSL, unchanged except for the removal of OpenBSD-specific calls.

With the --with-libtls you should be basically getting this. Minimal changes possible (or realistic).

~skarnet 8 months ago

Sorry, I'm going to be annoying, but I can't build from a git version without a configure script. I don't have autotools on the server I would test this on, and although I did install Perl to be able to build openssl, autotools is a real red line. (I tried installing it manually once. It did not go well.) Could you please cut a pre-release, or just a tarball, with the configure script (and potentially other necessary files for a build) already prepared? Thanks a lot.

~graywolf 8 months ago

While I do not share your opinion, I kinda understand. I've packaged current master here [0]. Please ignore the version number in the name, it is not a final release, I've just run make dist on the master branch that already has the version bumped.

If you are paranoid here is a checksum:

+   $ sha256sum acme-client-1.3.0.tar.gz
0b25b31ac4e4f3479e7cf3534ba5ad124519c5dd43afb07d20e4905547f9ecf4  acme-client-1.3.0.tar.gz

I appreciate your help with testing this.

0: https://data.wolfsden.cz/tmp/acme-client-1.3.0.tar.gz

~skarnet 8 months ago

Thank you. Here are my results.

On the plus side:

  • The binary appears to work: I can verify that a certificate is valid, and I also managed to renew a certificate.
  • I don't know if it's because of your changes since 1.2.0 or because of libressl, but the x86_64 binary is much smaller than the 1.2.0 one: fully stripped static binary (linked against musl) is 1861112 bytes for pre-1.3.0, versus 2861376 bytes for 1.2.0. One megabyte shaved off the binary!

On the minus side:

  • It's unclear whether --with-libtls replaces or adds to --with-openssl. I had to specify both for configure to work. May I suggest making --with-libtls a full alternative to --with-openssl, with a directory indication? --with-libtls=libresslbasedir
  • Reliance on pkg-config. Some systems (including mine) don't have pkg-config, so I had to specify LIBTLS_CFLAGS and LIBTLS_LIBS by hand. It's fine; but it needs to be documented. The way I made it work, the build had "-lssl -lcrypto -ltls -lssl -lcrypto" as its final LIBS, which kinda works but is suboptimal ^^
  • The software relies on sys/queue.h, which is not standard. glibc provides it, but not musl; I had to fish out a sys/queue.h implementation manually. In order to make acme-client-portable really portable, I think it should provide its own sys/queue.h :-) (this problem already happened on 1.2.0, I think, but I'm using the opportunity to report it here.)

Hope this helps, and even if you don't fix the small annoyances above, I was able to make it work, so, thanks!

~graywolf 4 months ago

Hello, first, let me say that I'm sorry for taking so long. However, since it was working for you, and I have been crazy busy at work, I sadly did not manage to get to this sooner.

It's unclear whether --with-libtls replaces or adds to --with-openssl. I had to specify both for configure to work. May I suggest making --with-libtls a full alternative to --with-openssl, with a directory indication? --with-libtls=libresslbasedir

Since libtls can be used with openssl, making those options exclusive would not work I think. However I've tried to improve (well, more like add :) ) documentation, so please check if it is sufficiently documented now.

Reliance on pkg-config. Some systems (including mine) don't have pkg-config, so I had to specify LIBTLS_CFLAGS and LIBTLS_LIBS by hand. It's fine; but it needs to be documented. The way I made it work, the build had "-lssl -lcrypto -ltls -lssl -lcrypto" as its final LIBS, which kinda works but is suboptimal ^^

I've moved libtls over to same script as openssl detection. That does use pkg-config, but accepts explicit path and checks default ones if pkg-config cannot be used. Also now both libraries are configured the same way, which is probably better anyway. I've also documented the lookup order, I hope that should help.

The software relies on sys/queue.h, which is not standard. glibc provides it, but not musl; I had to fish out a sys/queue.h implementation manually. In order to make acme-client-portable really portable, I think it should provide its own sys/queue.h :-) (this problem already happened on 1.2.0, I think, but I'm using the opportunity to report it here.)

True, looking back at it it's not worth it to require user to provide the header, since it is self-contained. The build still checks if bsd/sys/queue.h is present, but if not, it falls back to vendored one.

Hope this helps, and even if you don't fix the small annoyances above, I was able to make it work, so, thanks!

I've created a proper -rc1[0] this time, would appreciate if you would find a time to give it a spin, both for functionality and for the documentation. I would like to do the release at latest by end of month, so feel free to take your time if necessary.

0: https://data.wolfsden.cz/sources/acme-client-1.3.0-rc1.tar.gz sha256sum: 02dc12880669a6cd948e20747cabe21e5a8be60dd9f1dd7c8fae33c9830b2b69

~graywolf REPORTED FIXED 3 months ago

Register here or Log in to comment, or comment via email.