Mailing List Archive

On February 29, 2024 12:56:47 PM UTC, Andrew C Aitchison via clamav-users <clamav-users@lists.clamav.net> wrote:
>
>I haven't fully understood this yet, but Debian is planning a flag-day
>on 29 March to fix the y2038 bug on 32bit systems (possibly excluding
>intel).
>
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063130
>
>Since clamav uses libmspack it is listed at
> https://tracker.debian.org/pkg/libmspack
>(under "action needed/Marked for autoremoval on 29 March:")
>as being affected:
> Version 0.11-1 of libmspack is marked for autoremoval from testing
> on Fri 29 Mar 2024. It is affected by #1063130. The removal of
> libmspack will also cause the removal of (transitive) reverse
> dependencies: c-icap-modules, cabextract, clamassassin, clamav,
> clamsmtp, clamtk, cyrus-imapd, dtrx, e2guardian, evolution-ews,
> forensics-extra, libclamunrar, lutris, msttcorefonts, open-vm-tools,
> pg-snakeoil, playonlinux. You should try to prevent the removal by
> fixing these RC bugs.
>which suggests that because libmspack will have an incompatible change
>(source?) packages that use it will be dropped (from 32bit systems ?)
>*unless* they are updated too.
>
>The discussion suggests that some other distributions that
>still support 32bits are not planning to fix y2038 for 32bit.
>
>Not sure what the implications are for Ubuntu, but the next release
>- 24.04 LTS, "Noble Numbat" - will have 15 years paid support, which
>is beyond the y2038 bug.
>
>I guess that the ClamAV and the Debian packages will need to be given
>separate consideration.
>

Ubuntu is also doing the same transition. The developer who is coordinating this in Debian is also doing it for Ubuntu, although I don't know their schedule.

There is nothing end users need to worry about. If you are running a 64 bit architecture (which is almost everyone), then your sys already uses 64 but time and there should be no 2038 worry.

I understand that other distros are dropping support for 32 but. We are planning to retain it in Debian, but switch to 64 bit time, which breaks the ABI. This necessitates library package renames and a bunch of other stuff that end users will never directly see.

We are keeping 32 bit time for i386 to support compatibility with proprietary packages from outside Debian that can't be rebuilt. Our research indicated that virtually all current i386 usage is as an additional architecture on amd64 systems to support such software. This is not ideal, but the only choices were to keep such working, albeit with 2038 problems, or to make the change to 64 bit time and have it not work at all.

The auto removal notices that you're seeing are a transient aspect of how Debian handles serious bugs and not any kind of an indication of intent not to have these packages in a future release.

As long as upstream keeps clamav working on 32 bit architectures, we should be able to support it.

Scott K
_______________________________________________

Manage your clamav-users mailing list subscription / unsubscribe:
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/Cisco-Talos/clamav-documentation

https://docs.clamav.net/#mailing-lists-and-chat

Thanks Scott.
Glad to hear that this is under control.

On Thu, 29 Feb 2024, Scott Kitterman via clamav-users wrote:

> On February 29, 2024 12:56:47 PM UTC, Andrew C Aitchison via clamav-users <clamav-users@lists.clamav.net> wrote:
>>
>> I haven't fully understood this yet, but Debian is planning a flag-day
>> on 29 March to fix the y2038 bug on 32bit systems (possibly excluding
>> intel).
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063130
>>
>> Since clamav uses libmspack it is listed at
>> https://tracker.debian.org/pkg/libmspack
>> (under "action needed/Marked for autoremoval on 29 March:")
>> as being affected:
>> Version 0.11-1 of libmspack is marked for autoremoval from testing
>> on Fri 29 Mar 2024. It is affected by #1063130. The removal of
>> libmspack will also cause the removal of (transitive) reverse
>> dependencies: c-icap-modules, cabextract, clamassassin, clamav,
>> clamsmtp, clamtk, cyrus-imapd, dtrx, e2guardian, evolution-ews,
>> forensics-extra, libclamunrar, lutris, msttcorefonts, open-vm-tools,
>> pg-snakeoil, playonlinux. You should try to prevent the removal by
>> fixing these RC bugs.
>> which suggests that because libmspack will have an incompatible change
>> (source?) packages that use it will be dropped (from 32bit systems ?)
>> *unless* they are updated too.
>>
>> The discussion suggests that some other distributions that
>> still support 32bits are not planning to fix y2038 for 32bit.
>>
>> Not sure what the implications are for Ubuntu, but the next release
>> - 24.04 LTS, "Noble Numbat" - will have 15 years paid support, which
>> is beyond the y2038 bug.
>>
>> I guess that the ClamAV and the Debian packages will need to be given
>> separate consideration.
>>
>
> Ubuntu is also doing the same transition. The developer who is coordinating this in Debian is also doing it for Ubuntu, although I don't know their schedule.
>
> There is nothing end users need to worry about. If you are running a 64 bit architecture (which is almost everyone), then your sys already uses 64 but time and there should be no 2038 worry.
>
> I understand that other distros are dropping support for 32 but. We are planning to retain it in Debian, but switch to 64 bit time, which breaks the ABI. This necessitates library package renames and a bunch of other stuff that end users will never directly see.
>
> We are keeping 32 bit time for i386 to support compatibility with proprietary packages from outside Debian that can't be rebuilt. Our research indicated that virtually all current i386 usage is as an additional architecture on amd64 systems to support such software. This is not ideal, but the only choices were to keep such working, albeit with 2038 problems, or to make the change to 64 bit time and have it not work at all.
>
> The auto removal notices that you're seeing are a transient aspect of how Debian handles serious bugs and not any kind of an indication of intent not to have these packages in a future release.
>
> As long as upstream keeps clamav working on 32 bit architectures, we should be able to support it.
>
> Scott K
> _______________________________________________
>
> Manage your clamav-users mailing list subscription / unsubscribe:
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/Cisco-Talos/clamav-documentation
>
> https://docs.clamav.net/#mailing-lists-and-chat
>

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk
_______________________________________________

Manage your clamav-users mailing list subscription / unsubscribe:
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/Cisco-Talos/clamav-documentation

https://docs.clamav.net/#mailing-lists-and-chat