Bug#1034586: always reports inactive/expired certificate on armhf
On Tue, May 02, 2023 at 02:35:05AM -0400, gs-debian@gluelogic.com wrote: > On Fri, Apr 21, 2023 at 01:47:22PM -0400, gs-debian@gluelogic.com wrote: > > On Fri, Apr 21, 2023 at 06:14:25PM +0200, Marco d'Itri wrote: > > > On Apr 21, gs-debian@gluelogic.com wrote: > > > > > > > I probably should have started with the most basic thing: > > > > > > > > What is the date on your device? > > > NTP-accurate. > > > > Perhaps there is something amiss in the Debian 32-bit build of lighttpd > > or openssl for aarch64. (Is there any particular reason that you are > > running 32-bit lighttpd on aarch64 rather than running 64-bit lighttpd?) > > Apologies for the delay. I installed Debian Bookworm onto a QEMU > aarch64 VM and the (64-bit!) lighttpd package for Debian aarch64 works > as expected when I tested with an expired LE cert (warning issued), and > when I tested with a current LE cert (no warning issued). > > From where did you obtain a 32-bit build of lighttpd for aarch64? > If you know, how was that 32-bit lighttpd built? I would like to try to > reproduce (as closely as possible) the 32-bit build. Is your system based on raspbian? My understanding is that a while back, raspbian was using a 32-bit kernel and 32-bit userland, even on aarch64-capable ARM chips. Then, they upgraded the kernel to be 64-bit on aarch64-capable ARM chips, but userland may still be 32-bit. In any case, I have tested that things work as expected for me on a physical 32-bit ARM processor running 32-bit lighttpd, and on a 64-bit ARM VM running 64-bit lighttpd. I'll need more info to get any further. You might try testing using lighttpd mod_gnutls instead of mod_openssl to see if that makes a difference. If it does, then the issue might be in the 32-bit armhf build of openssl that you are running under your aarch64 kernel. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 01:47:22PM -0400, gs-debian@gluelogic.com wrote: > On Fri, Apr 21, 2023 at 06:14:25PM +0200, Marco d'Itri wrote: > > On Apr 21, gs-debian@gluelogic.com wrote: > > > > > I probably should have started with the most basic thing: > > > > > > What is the date on your device? > > NTP-accurate. > > Perhaps there is something amiss in the Debian 32-bit build of lighttpd > or openssl for aarch64. (Is there any particular reason that you are > running 32-bit lighttpd on aarch64 rather than running 64-bit lighttpd?) Apologies for the delay. I installed Debian Bookworm onto a QEMU aarch64 VM and the (64-bit!) lighttpd package for Debian aarch64 works as expected when I tested with an expired LE cert (warning issued), and when I tested with a current LE cert (no warning issued). >From where did you obtain a 32-bit build of lighttpd for aarch64? If you know, how was that 32-bit lighttpd built? I would like to try to reproduce (as closely as possible) the 32-bit build. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 06:14:25PM +0200, Marco d'Itri wrote:
> On Apr 21, gs-debian@gluelogic.com wrote:
>
> > I probably should have started with the most basic thing:
> >
> > What is the date on your device?
> NTP-accurate.
Perhaps there is something amiss in the Debian 32-bit build of lighttpd
or openssl for aarch64. (Is there any particular reason that you are
running 32-bit lighttpd on aarch64 rather than running 64-bit lighttpd?)
If you are able to build lighttpd on your aarch64, you can use my
local (internal) code to parse ASN1_TIME, rather than the openssl
ASN1_TIME_cmp_time_t() routine to parse and compare. (Be sure to build
32-bit for testing to better match your current system configuration.)
For *testing only*, the following patch "disables" the check for openssl
1.1.1, which added ASN1_TIME_cmp_time_t(), so that the local (internal)
ASN1_TIME parsing is used.
--- a/src/mod_openssl.c
+++ b/src/mod_openssl.c
@@ -1272,7 +1272,7 @@ network_ssl_servername_callback (SSL *ssl, int *al, void
*srv)
#endif
-#if OPENSSL_VERSION_NUMBER < 0x10101000L \
+#if OPENSSL_VERSION_NUMBER < 0xL \
|| defined(BORINGSSL_API_VERSION) \
||(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x306fL)
static unix_time64_t
@@ -1291,7 +1291,7 @@ mod_openssl_cert_is_active (const X509 *crt)
{
const ASN1_TIME *notBefore = X509_get0_notBefore(crt);
const ASN1_TIME *notAfter = X509_get0_notAfter(crt);
- #if OPENSSL_VERSION_NUMBER < 0x10101000L \
+ #if OPENSSL_VERSION_NUMBER < 0xL \
|| defined(BORINGSSL_API_VERSION) \
||(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER <
0x306fL)
const unix_time64_t before = mod_openssl_asn1_time_to_posix(notBefore);
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 09:38:31AM +0200, Marco d'Itri wrote: > On Apr 21, gs-debian@gluelogic.com wrote: > > > What your `uname -a` ? > Linux omitted.mi.bofh.it 6.1.0-7-arm64 #1 SMP Debian 6.1.20-2 (2023-04-08) > aarch64 GNU/Linux > > > What is the output of the following for you? > > $ lighttpd -V | grep "Y2038 support" > > + Y2038 support > Same. I probably should have started with the most basic thing: What is the date on your device? If the `date` is incorrect, e.g. starts at 1970 after reboot, then that might explain lighttpd's trace when starting lighttpd.
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 07:41:13AM +0200, Marco d'Itri wrote: > On Apr 21, gs-debian@gluelogic.com wrote: > > > Please confirm you are running an arm64 kernel, as you posted above. > Confirmed. What your `uname -a` ? What is the output of the following for you? $ lighttpd -V | grep "Y2038 support" + Y2038 support I'll build a Debian VM image this weekend to try to repro with the Debian packages. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Wed, Apr 19, 2023 at 01:39:02AM +0200, Marco d'Itri wrote: > Package: lighttpd > Version: 1.4.69-1 > Severity: normal > > I am using the latest openssl and lighttpd packages on an armhf (with an > arm64 kernel) and an amd64 system, and only on the armhf system I always > get this warning at startup even just after having created a Let's > Encrypt certificate. > > Apr 19 01:23:31 omitted.mi.bofh.it lighttpd[8876]: 2023-04-19 01:23:30: > (mod_openssl.c.1335) SSL: inactive/expired X509 certificate > '/var/lib/dehydrated/certs/omitted.mi.bofh.it/fullchain.pem' > > # openssl x509 -noout -text -in > /var/lib/dehydrated/certs/bokassa.mi.bofh.it/fullchain.pem | grep -A2 Validity > Validity > Not Before: Apr 18 22:13:45 2023 GMT > Not After : Jul 17 22:13:44 2023 GMT > > After looking at > https://github.com/lighttpd/lighttpd1.4/blob/fdb7ffed88b9dfe09a51e7fb58e5ddfe938c1ec9/src/mod_openssl.c#L1284 > > I wonder if this is common on all 32 bit systems instead. No, this is not common on all 32-bit systems, though I am curious as to why you are seeing that warning with a valid certificate. To try to reproduce this, I took some LE certs and put them on a 32-bit ARM system I have (which is running openwrt, not Debian) $ uname -m armv7l $ cat /proc/cpuinfo | egrep "model|Features" model name : ARMv7 Processor rev 1 (v7l) Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 $ file /usr/sbin/lighttpd /usr/sbin/lighttpd: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, no section header The vfpv3 and /lib/ld-musl-armhf.so.1 confirms to me this is an armhf. See also: https://www.baeldung.com/linux/arm64-armel-armhf-overview My cert: $ openssl x509 -noout -text -in /tmp/x.com/fullchain.pem | grep -A2 Validity Validity Not Before: Apr 10 22:15:43 2023 GMT Not After : Jul 9 22:15:42 2023 GMT ==> I did not get any warning trace on that system with: $ lighttpd -f test.conf -tt using my LE certificates, though that test system has only lighttpd 1.4.67 at the moment. My test system is running a 32-bit kernel. Please confirm you are running an arm64 kernel, as you posted above. What lighttpd package (from which architecture) do you have installed? $ file /usr/sbin/lighttpd might be useful. Please ensure that you have installed the proper package for your architecture. Is your system openssl-based or libressl-based? The only changes between lighttpd 1.4.67 and lighttpd 1.4.69 in lighttpd mod_openssl that seemed to be related to this issue is that lighttpd mod_openssl started using libressl ASN1_TIME_cmp_time_t() when LIBRESSL_VERSION_NUMBER >= 0x306fL and this also requires that lighttpd mod_openssl was built with libressl. The standard Debian package for lighttpd mod_openssl is built with openssl.
Bug#981347: [debian-mysql] Bug#981347: Bug#981347: Bug#981347: mariadb-10.5 FTBFS on kfreebsd
On Mon, May 10, 2021 at 08:00:00AM -0700, Otto Kekäläinen wrote: > Hello! > > If you want to help improve MariaDB in Debian in the open source way, > you could for example: > > - submit your suggestion for a fix as a Merge Request at > https://salsa.debian.org/mariadb-team/mariadb-10.5 > - help with documentation/testing to improve our understanding on what > exactly the bug is about I diagnosed and submitted a patch, which was merged a couple months ago. https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/3
Bug#983478: FAM and other arch/kernels
On Wed, Mar 31, 2021 at 08:30:24AM -0400, PICCORO McKAY Lenz wrote: > linux is so popular (wh ugh) today.. but only for enterprices.. i do > not see any help for normal users that wants more freedom .. sad and > oscure! Please go away troll. Your language is inappropriate and you are clearly uninformed on this topic. gamin supports kqueue on FreeBSD and inotify on Linux. For cross-platform servers such as lighttpd, multiple file system monitoring alternatives are implemented for portability. The default stat cache in lighttpd does not use FAM or gamin or inotify or kqueue, and in the most common use-case of infrequently-modified files, the default in lighttpd is often faster than with the added overhead of file system monitoring. Please go away troll. I will not respond to you further here. This is not an invitation to defend your gross hyperbole. Just go away.
