Mailing List Archive

On 2021-07-28 23:53:35, Micah Snyder (micasnyd) via clamav-users wrote:
>
> I would like your feedback.
>

Starting with v0.103 will be really helpful. I've already voiced my
concerns about CMake... As the Gentoo maintainer, the switch is a bit
annoying, since we've been fixing autotools issues for years with many
of our patches forgotten upstream. With CMake, our users are going to
have to re-experience and re-report those bugs, and then we're going
to have to re-fix and re-submit them all (and someone is going to have
to re-write my open OpenRC pull request for CMake -- no easy task).

But in the end, everything will be OK. I plan to step down as
maintainer and let someone else deal with it =) In the meantime,
having security support for a version that supports our init system
will be nice.

The rust requirement, on the other hand, is a personal deal-breaker. I
don't mean to pile on more negativity, but tl;dr we'll be replacing
(or just removing) clamav at work when there are no more secure,
rust-free versions available. And I'll be glad to not have to deal
with that for a few more years!

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Sounds fair and gives a lot more time to migrate

_____

From: clamav-users [mailto:clamav-users-bounces@lists.clamav.net] On Behalf
Of Micah Snyder (micasnyd) via clamav-users
Sent: Wednesday, July 28, 2021 7:54 PM
To: ClamAV users ML
Cc: Micah Snyder (micasnyd); ClamAV Development
Subject: [clamav-users] Long Term Support (LTS) program proposal





Hi All,



For the past couple of months I've been promoting the idea of having Long
Term Support (LTS) feature releases for ClamAV within internal Talos
communications.



For the purposes of this discussion:

* A "feature release" is a version starting with MAJOR.MINOR.0 to
include all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1, 0.103.2, and
0.103.3 are all within the same "feature release".

* A "patch version" is a specific MAJOR.MINOR.PATCH version. E.g.
0.103.4 would be the next "patch version" in the 0.103 "feature release".



My interest in starting an LTS program came about because we have been
getting (understandable) pressure from management to have shorter
development times for feature versions with more targeted feature sets.
What this means is that you would see more frequent feature releases,
possibly as many as ~5 per year. Some of the features in a given feature
release would be things the community cares about, while others may be by
request of a different team within Talos or Cisco.



But I couldn't in good conscience start pumping out new feature releases
every 2-4 months and expect everyone to keep up. And at that rate it would
not be possible for us to make critical patch versions for every feature
release within the two years, or even one year. So in order to get features
out faster it became clear to me that we will need to define specific
feature release for which we promise to backport security fixes for some
amount of time.



This raised a few obvious questions:

* Which feature release do we start with?

* Do we have to continue serving signature database content to every
patch version in an LTS release?

* How often should we select a new feature release for LTS?

* How long is "long term support" anyways?



We've been talking about this off and on for the past couple of month. This
is what I came up with..



Which feature version do we start with?



We had initially settled on 0.104 as the first LTS version, for basically
two reasons:

- Joel really wants to make sure people have the latest freshclam
features, particularly those found in 0.103.2 and 0.103.3, to reduce
bandwidth cost.

- I don't want to keep fixing glitchy autotools package detection
issues for years to come.



But after seeing the (very much unexpected) reaction to the switch CMake.
it's clear to me now that we need to start the LTS program with 0.103.



Do we have to continue serving database content to every patch version in an
LTS release?



No.



LTS means that we will promise to continue providing patch versions for a
given feature release.

I.e. you will get critical fixes in 0.103.4, 0.103.5, 0.103.6, etc. as
needed until End of Life (EOL) for the 0.103 feature release.



I need to stress that it doesn't mean people should or will be allowed to
continue using vulnerable or otherwise problematic versions such as 0.103.0
and 0.103.1 just because they belong to an LTS feature release. We will
reserve the right to at some point begin to block older patch versions like
0.103.0 from downloading databases to force people to use newer patch
versions.



How often should we select a new feature release for LTS?



Some products, like Ubuntu, do a new LTS ever 2 years with support for 5
years. 2 years feels like a long time but, as much as I want to get people
using the latest features, our team is pretty small. The more frequently we
a release for long term support, the more work each security release will
be. We would be required to create and test a new patch version for the
current stable feature release plus a collection of LTS releases. If we did
an LTS every year, that would be too much.

I think 2 years is probably a good number.



How long is "long term support" anyways?



As noted above and elsewhere, Ubuntu and RHEL/CentOS support LTS versions
for 5 years. That's a long time, and more than our team could agree to.

After a bunch of discussion, we think 3 years is a good number.



To summarize, I'm proposing a Long Term Support (LTS) program for ClamAV
starting with the 0.103 feature release. This means:



1. We will promise to provide critical patch versions (0.103.4, .5.,
.6, etc.) as needed until the LTS end-of-life.
This does not mean that the original 0.103.0 or other problematic patch
versions within the series will continue to "work".
Users MUST be willing to upgrade to newer patch versions within a given LTS
release.



2. Each LTS release would be supported for three (3) years from the
first (.0) version.

0.103.0 was published in August 2020. This means we would continue to
provide critical patch versions for 0.103 until August 2023.



3. We will aim to select a new LTS feature release every two (2) years.


With 0.103 starting the LTS program, that means that whichever feature
release is to be published near abouts August 2022 is the likely candidate
for the next LTS release.



4. When a security fix is required, we'll publish a patch version for
the latest feature release as well as all affected active LTS feature
releases.



5. We will document the LTS policy and add an end-of-life version table
to https://docs.clamav.net/faq/faq-eol.html.





I would like your feedback.



Respectfully,

Micah


Micah Snyder
ClamAV
Talos
Cisco Systems, Inc.

On July 28, 2021 11:53:35 PM UTC, "Micah Snyder (micasnyd) via clamav-users" <clamav-users@lists.clamav.net> wrote:
>
>Hi All,
>
>For the past couple of months I've been promoting the idea of having Long Term Support (LTS) feature releases for ClamAV within internal Talos communications.
>
>For the purposes of this discussion:
>
> * A "feature release" is a version starting with MAJOR.MINOR.0 to include all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1, 0.103.2, and 0.103.3 are all within the same "feature release".
> * A "patch version" is a specific MAJOR.MINOR.PATCH version. E.g. 0.103.4 would be the next "patch version" in the 0.103 "feature release".
>
>My interest in starting an LTS program came about because we have been getting (understandable) pressure from management to have shorter development times for feature versions with more targeted feature sets. What this means is that you would see more frequent feature releases, possibly as many as ~5 per year. Some of the features in a given feature release would be things the community cares about, while others may be by request of a different team within Talos or Cisco.
>
>But I couldn't in good conscience start pumping out new feature releases every 2-4 months and expect everyone to keep up. And at that rate it would not be possible for us to make critical patch versions for every feature release within the two years, or even one year. So in order to get features out faster it became clear to me that we will need to define specific feature release for which we promise to backport security fixes for some amount of time.
>
>This raised a few obvious questions:
>
> * Which feature release do we start with?
> * Do we have to continue serving signature database content to every patch version in an LTS release?
> * How often should we select a new feature release for LTS?
> * How long is "long term support" anyways?
>
>We've been talking about this off and on for the past couple of month. This is what I came up with....
>
>Which feature version do we start with?
>
>We had initially settled on 0.104 as the first LTS version, for basically two reasons:
>
>- Joel really wants to make sure people have the latest freshclam features, particularly those found in 0.103.2 and 0.103.3, to reduce bandwidth cost.
>
>- I don't want to keep fixing glitchy autotools package detection issues for years to come.
>
>But after seeing the (very much unexpected) reaction to the switch CMake... it's clear to me now that we need to start the LTS program with 0.103.
>
>Do we have to continue serving database content to every patch version in an LTS release?
>
>No.
>
>LTS means that we will promise to continue providing patch versions for a given feature release.
>I.e. you will get critical fixes in 0.103.4, 0.103.5, 0.103.6, etc. as needed until End of Life (EOL) for the 0.103 feature release.
>
>I need to stress that it doesn't mean people should or will be allowed to continue using vulnerable or otherwise problematic versions such as 0.103.0 and 0.103.1 just because they belong to an LTS feature release. We will reserve the right to at some point begin to block older patch versions like 0.103.0 from downloading databases to force people to use newer patch versions.
>
>How often should we select a new feature release for LTS?
>
>Some products, like Ubuntu, do a new LTS ever 2 years with support for 5 years. 2 years feels like a long time but, as much as I want to get people using the latest features, our team is pretty small. The more frequently we a release for long term support, the more work each security release will be. We would be required to create and test a new patch version for the current stable feature release plus a collection of LTS releases. If we did an LTS every year, that would be too much.
>
>I think 2 years is probably a good number.
>
>How long is "long term support" anyways?
>
>As noted above and elsewhere, Ubuntu and RHEL/CentOS support LTS versions for 5 years. That's a long time, and more than our team could agree to.
>After a bunch of discussion, we think 3 years is a good number.
>
>To summarize, I'm proposing a Long Term Support (LTS) program for ClamAV starting with the 0.103 feature release. This means:
>
>
> 1. We will promise to provide critical patch versions (0.103.4, .5., .6, etc.) as needed until the LTS end-of-life.
>This does not mean that the original 0.103.0 or other problematic patch versions within the series will continue to "work".
>Users MUST be willing to upgrade to newer patch versions within a given LTS release.
>
> 2. Each LTS release would be supported for three (3) years from the first (.0) version.
>
>0.103.0 was published in August 2020. This means we would continue to provide critical patch versions for 0.103 until August 2023.
>
> 3. We will aim to select a new LTS feature release every two (2) years.
>
>With 0.103 starting the LTS program, that means that whichever feature release is to be published near abouts August 2022 is the likely candidate for the next LTS release.
>
>
>
> 1. When a security fix is required, we'll publish a patch version for the latest feature release as well as all affected active LTS feature releases.
>
> 2. We will document the LTS policy and add an end-of-life version table to https://docs.clamav.net/faq/faq-eol.html.
>
>
>I would like your feedback.

I can see advantages to Debian if we can stay on an LTS release.

I would suggest adding maintaining stable ABI in libclamav throughout the LTS should also be a requirement. We've had to do soname bumps in our stable release before and it's pretty painful. It'd be nice not to have to worry about that anymore.

If you would make the LTS support lifetime 4 years instead of three that would give you a consistent 2 LTS releases to support and would allow us to get on an LTS release during development and stick to it for the normal support period of a Debian release. Please consider.

Scott K

P. S. I haven't been active on Debian clamav maintenance for awhile, so if Sebastian has a different view, definitely go with that.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Executive Summary:
An LTS release every two years, supported for three, starting with 0.103
sound good to me. Thank you.


On Wed, 28 Jul 2021, Micah Snyder (micasnyd) via clamav-users wrote:

> For the past couple of months I've been promoting the idea of having
> Long Term Support (LTS) feature releases for ClamAV within internal
> Talos communications.
>
> For the purposes of this discussion:
>
> * A "feature release" is a version starting with MAJOR.MINOR.0 to
> include all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1,
> 0.103.2, and 0.103.3 are all within the same "feature release".
> * A "patch version" is a specific MAJOR.MINOR.PATCH
> version. E.g. 0.103.4 would be the next "patch version" in the
> 0.103 "feature release".
>
> My interest in starting an LTS program came about because we have
> been getting (understandable) pressure from management to have
> shorter development times for feature versions with more targeted
> feature sets. What this means is that you would see more frequent
> feature releases, possibly as many as ~5 per year. Some of the
> features in a given feature release would be things the community
> cares about, while others may be by request of a different team
> within Talos or Cisco.

I don't *think* I want ever more features (though I may say "yes" when
you suggest X and Y ... and Z ...). What I want is better detection
(though I don't currently have an SMTP listener, so the number of
pieces of malware my installation could detect is vanishingly small).

I can see management wanting you to work on one new feature at a time,
releasing it and moving on to the next. If that works for your team, fine.
If you work better by being able to switch between a couple of projects
and release several at once, that is fine too.
However, please make a release when it is ready; don't go down the
Firefox route of a release timetable with features trying to catch the
release train where they can (not that I think your team is big
enough to do that).


> But I couldn't in good conscience start pumping out new feature
> releases every 2-4 months and expect everyone to keep up. And at
> that rate it would not be possible for us to make critical patch
> versions for every feature release within the two years, or even one
> year. So in order to get features out faster it became clear to me
> that we will need to define specific feature release for which we
> promise to backport security fixes for some amount of time.
>
> This raised a few obvious questions:
>
> * Which feature release do we start with?
> * Do we have to continue serving signature database content
> to every patch version in an LTS release?
> * How often should we select a new feature release for LTS?
> * How long is "long term support" anyways?
>
> We've been talking about this off and on for the past couple of
> month. This is what I came up with....
>
> Which feature version do we start with?
>
> We had initially settled on 0.104 as the first LTS version, for
> basically two reasons:
>
> - Joel really wants to make sure people have the latest
> - freshclam features, particularly those found in 0.103.2
> - and 0.103.3, to reduce bandwidth cost.
>
> - I don't want to keep fixing glitchy autotools package
> - detection issues for years to come.
>
> But after seeing the (very much unexpected) reaction to the switch
> CMake... it's clear to me now that we need to start the LTS program
> with 0.103.

Thanks.
Sorry if that means you have to put up with a build system
you don't like for another two years.

> Do we have to continue serving database content to every patch
> version in an LTS release?
>
> No.
>
> LTS means that we will promise to continue providing patch versions
> for a given feature release. I.e. you will get critical fixes in
> 0.103.4, 0.103.5, 0.103.6, etc. as needed until End of Life (EOL)
> for the 0.103 feature release.
>
> I need to stress that it doesn't mean people should or will be
> allowed to continue using vulnerable or otherwise problematic
> versions such as 0.103.0 and 0.103.1 just because they belong to an
> LTS feature release. We will reserve the right to at some point
> begin to block older patch versions like 0.103.0 from downloading
> databases to force people to use newer patch versions.
>
> How often should we select a new feature release for LTS?
>
> Some products, like Ubuntu, do a new LTS ever 2 years with support
> for 5 years. 2 years feels like a long time but, as much as I want
> to get people using the latest features, our team is pretty small.
> The more frequently we a release for long term support, the more
> work each security release will be. We would be required to create
> and test a new patch version for the current stable feature release
> plus a collection of LTS releases. If we did an LTS every year, that
> would be too much.
>
> I think 2 years is probably a good number.

It will be interesting to see which distros use the LTS and which
keep up with the feature releases.


> How long is "long term support" anyways?
>
> As noted above and elsewhere, Ubuntu and RHEL/CentOS support LTS
> versions for 5 years. That's a long time, and more than our team
> could agree to.
> After a bunch of discussion, we think 3 years is a good number.
>
> To summarize, I'm proposing a Long Term Support (LTS) program for
> ClamAV starting with the 0.103 feature release. This means:
>
> 1. We will promise to provide critical patch versions (0.103.4,
> .5., .6, etc.) as needed until the LTS end-of-life. This does not
> mean that the original 0.103.0 or other problematic patch versions
> within the series will continue to "work". Users MUST be willing to
> upgrade to newer patch versions within a given LTS release.
>
> 2. Each LTS release would be supported for three (3) years from
> the first (.0) version.
>
> 0.103.0 was published in August 2020. This means we would continue
> to provide critical patch versions for 0.103 until August 2023.

Tuesday, August 18, 2020 ClamAV 0.103.0 release candidate
Monday, September 14, 2020 ClamAV 0.103.0 released

So we are going by the (first) release candidate. OK.

> 3. We will aim to select a new LTS feature release every two (2) years.
>
> With 0.103 starting the LTS program, that means that whichever
> feature release is to be published near abouts August 2022 is the
> likely candidate for the next LTS release.
>
> 1. When a security fix is required, we'll publish a patch version
> for the latest feature release as well as all affected active LTS
> feature releases.
>
> 2. We will document the LTS policy and add an end-of-life version
> table to https://docs.clamav.net/faq/faq-eol.html.

Thanks,

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

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

To be extremely specific, the LTS version would start with 0.103.3. So that would be the base version we’d support for LTS.



> On Jul 29, 2021, at 10:06 AM, Andrew C Aitchison via clamav-users <clamav-users@lists.clamav.net> wrote:
>
>
> Executive Summary:
> An LTS release every two years, supported for three, starting with 0.103
> sound good to me. Thank you.
>
>
> On Wed, 28 Jul 2021, Micah Snyder (micasnyd) via clamav-users wrote:
>
>> For the past couple of months I've been promoting the idea of having
>> Long Term Support (LTS) feature releases for ClamAV within internal
>> Talos communications.
>> For the purposes of this discussion:
>>
>> * A "feature release" is a version starting with MAJOR.MINOR.0 to
>> include all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1,
>> 0.103.2, and 0.103.3 are all within the same "feature release".
>> * A "patch version" is a specific MAJOR.MINOR.PATCH
>> version. E.g. 0.103.4 would be the next "patch version" in the
>> 0.103 "feature release".
>> My interest in starting an LTS program came about because we have
>> been getting (understandable) pressure from management to have
>> shorter development times for feature versions with more targeted
>> feature sets. What this means is that you would see more frequent
>> feature releases, possibly as many as ~5 per year. Some of the
>> features in a given feature release would be things the community
>> cares about, while others may be by request of a different team
>> within Talos or Cisco.
>
> I don't *think* I want ever more features (though I may say "yes" when
> you suggest X and Y ... and Z ...). What I want is better detection
> (though I don't currently have an SMTP listener, so the number of
> pieces of malware my installation could detect is vanishingly small).
>
> I can see management wanting you to work on one new feature at a time,
> releasing it and moving on to the next. If that works for your team, fine.
> If you work better by being able to switch between a couple of projects
> and release several at once, that is fine too.
> However, please make a release when it is ready; don't go down the
> Firefox route of a release timetable with features trying to catch the
> release train where they can (not that I think your team is big
> enough to do that).
>
>
>> But I couldn't in good conscience start pumping out new feature
>> releases every 2-4 months and expect everyone to keep up. And at
>> that rate it would not be possible for us to make critical patch
>> versions for every feature release within the two years, or even one
>> year. So in order to get features out faster it became clear to me
>> that we will need to define specific feature release for which we
>> promise to backport security fixes for some amount of time.
>> This raised a few obvious questions:
>>
>> * Which feature release do we start with?
>> * Do we have to continue serving signature database content
>> to every patch version in an LTS release?
>> * How often should we select a new feature release for LTS?
>> * How long is "long term support" anyways?
>> We've been talking about this off and on for the past couple of
>> month. This is what I came up with....
>> Which feature version do we start with?
>> We had initially settled on 0.104 as the first LTS version, for
>> basically two reasons:
>> - Joel really wants to make sure people have the latest
>> - freshclam features, particularly those found in 0.103.2
>> - and 0.103.3, to reduce bandwidth cost.
>> - I don't want to keep fixing glitchy autotools package
>> - detection issues for years to come.
>> But after seeing the (very much unexpected) reaction to the switch
>> CMake... it's clear to me now that we need to start the LTS program
>> with 0.103.
>
> Thanks.
> Sorry if that means you have to put up with a build system
> you don't like for another two years.
>
>> Do we have to continue serving database content to every patch
>> version in an LTS release?
>> No.
>> LTS means that we will promise to continue providing patch versions
>> for a given feature release. I.e. you will get critical fixes in
>> 0.103.4, 0.103.5, 0.103.6, etc. as needed until End of Life (EOL)
>> for the 0.103 feature release.
>> I need to stress that it doesn't mean people should or will be
>> allowed to continue using vulnerable or otherwise problematic
>> versions such as 0.103.0 and 0.103.1 just because they belong to an
>> LTS feature release. We will reserve the right to at some point
>> begin to block older patch versions like 0.103.0 from downloading
>> databases to force people to use newer patch versions.
>> How often should we select a new feature release for LTS?
>> Some products, like Ubuntu, do a new LTS ever 2 years with support
>> for 5 years. 2 years feels like a long time but, as much as I want
>> to get people using the latest features, our team is pretty small.
>> The more frequently we a release for long term support, the more
>> work each security release will be. We would be required to create
>> and test a new patch version for the current stable feature release
>> plus a collection of LTS releases. If we did an LTS every year, that
>> would be too much.
>> I think 2 years is probably a good number.
>
> It will be interesting to see which distros use the LTS and which
> keep up with the feature releases.
>
>
>> How long is "long term support" anyways?
>> As noted above and elsewhere, Ubuntu and RHEL/CentOS support LTS
>> versions for 5 years. That's a long time, and more than our team
>> could agree to.
>> After a bunch of discussion, we think 3 years is a good number.
>> To summarize, I'm proposing a Long Term Support (LTS) program for
>> ClamAV starting with the 0.103 feature release. This means:
>>
>> 1. We will promise to provide critical patch versions (0.103.4,
>> .5., .6, etc.) as needed until the LTS end-of-life. This does not
>> mean that the original 0.103.0 or other problematic patch versions
>> within the series will continue to "work". Users MUST be willing to
>> upgrade to newer patch versions within a given LTS release.
>>
>> 2. Each LTS release would be supported for three (3) years from
>> the first (.0) version.
>> 0.103.0 was published in August 2020. This means we would continue
>> to provide critical patch versions for 0.103 until August 2023.
>
> Tuesday, August 18, 2020 ClamAV 0.103.0 release candidate
> Monday, September 14, 2020 ClamAV 0.103.0 released
>
> So we are going by the (first) release candidate. OK.
>
>> 3. We will aim to select a new LTS feature release every two (2) years.
>> With 0.103 starting the LTS program, that means that whichever
>> feature release is to be published near abouts August 2022 is the
>> likely candidate for the next LTS release.
>>
>> 1. When a security fix is required, we'll publish a patch version
>> for the latest feature release as well as all affected active LTS
>> feature releases.
>>
>> 2. We will document the LTS policy and add an end-of-life version
>> table to https://docs.clamav.net/faq/faq-eol.html.
>
> Thanks,
>
> --
> Andrew C. Aitchison Kendal, UK
> andrew@aitchison.me.uk
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml

> Tuesday, August 18, 2020 ClamAV 0.103.0 release candidate
> Monday, September 14, 2020 ClamAV 0.103.0 released
>
> So we are going by the (first) release candidate. OK.

Oops. I was reading off of a spreadsheet. It should be September then. I'll have to correct the spreadsheet.

Sorry.


_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Hi All,

In my world, 5 years is short. It use to take me 3 years to get a stable
enough uBuntu kernel to patch in my changes. The 14.0x LTS 4.4.x kernel
never became stable enough.

I will be looking to the industrial Linux at 10 to 25 years for kernels
for the future.

For most of the software I would be looking at no less than 5 years long
term support where longer term support (10+ years) is not available.

In my experience, most industry considers 5 years far too short. That is
why Windows XP was such a success. Its longevity.

Where I work they still run AT bus PCs with 2.4 series kernel because
the upgrade cost is considered prohibitive. It is not just the PC and
bespoke software. It is all the bespoke hardware that goes with it. When
the hardware becomes totally unsupportable there will be a long loss of
service as totally new software and hardware will be needed. There are
no budgeted funds for obsolescence.

Please reconsider the 3 years you proposing. 5 years should be the norm
and extra years for those prepared to pay for the privilege.

Release years. Every two years works OK. Beware of 2037. In 2037
everyone will be updating things and by 2038 it will be a mess (unix
time). Like last time (Y2K) management will, if possible, leave it to
the lasts microsecond. I suspect that most 32bit systems will be fine as
they will just ignore the sign bit. It will be all these new 64bit
systems that will fail miserably (sign extending their filing system
time stamps).

Regards
Mark.

On 29/07/2021 00:53, Micah Snyder (micasnyd) via clamav-users wrote:
> Hi All,
>
> For the past couple of months I?ve been promoting the idea of having
> Long Term Support (LTS) feature releases for ClamAV within internal
> Talos communications.
>
> For the purposes of this discussion:
>
> * A ?feature release? is a version starting with MAJOR.MINOR.0 to
> include all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1, 0.103.2,
> and 0.103.3 are all within the same ?feature release?.
> * A ?patch version? is a specific MAJOR.MINOR.PATCH version. E.g.
> 0.103.4 would be the next ?patch version? in the 0.103 ?feature
> release?.
>
> My interest in starting an LTS program came about because we have been
> getting (understandable) pressure from management to have shorter
> development times for feature versions with more targeted feature sets.
> What this means is that you would see more frequent feature releases,
> possibly as many as ~5 per year. ?Some of the features in a given
> feature release would be things the community cares about, while others
> may be by request of a different team within Talos or Cisco.
>
> But I couldn?t in good conscience start pumping out new feature releases
> every 2-4 months and expect everyone to keep up. And at that rate it
> would not be possible for us to make critical patch versions for every
> feature release within the two years, or even one year.? So in order to
> get features out faster it became clear to me that we will need to
> define /specific feature release/ for which we promise to backport
> security fixes for /some amount of time/.
>
> This raised a few obvious questions:
>
> * Which feature release do we start with?
> * Do we have to continue serving signature database content to every
> patch version in an LTS release?
> * How often should we select a new feature release for LTS?
> * How long is ?long term support? anyways?
>
> We?ve been talking about this off and on for the past couple of month.
> ?This is what I came up with?.
>
> */Which feature version do we start with?/*
>
> We /had/ initially settled on 0.104 as the first LTS version, for
> basically two reasons:
>
> -Joel really wants to make sure people have the latest freshclam
> features, particularly those found in 0.103.2 and 0.103.3, to reduce
> bandwidth cost.
>
> -I don?t want to keep fixing glitchy autotools package detection issues
> for years to come.
>
> But after seeing the (very much unexpected) reaction to the switch
> CMake? it?s clear to me now that *we need to start the LTS program with
> **0.103*.
>
> */Do we have to continue serving database content to every patch version
> in an LTS release?/*
>
> No.
>
> LTS means that we will promise to continue providing patch versions for
> a given feature release.
>
> I.e. you will get critical fixes in 0.103.4, 0.103.5, 0.103.6, etc. as
> needed until End of Life (EOL) for the 0.103 feature release.
>
> *I need to stress* *that* it doesn?t mean people should /or will be
> allowed/ to continue using vulnerable or otherwise problematic versions
> such as 0.103.0 and 0.103.1 just because they belong to an LTS feature
> release. /We will reserve the right to at some point begin to block
> older patch versions like 0.103.0 from downloading databases to force
> people to use newer patch versions./**
>
> //
>
> */How often should we select a new feature release for LTS?/*
>
> Some products, like Ubuntu, do a new LTS ever 2 years with support for 5
> years. ?2 years feels like a long time but, as much as I want to get
> people using the latest features, our team is pretty small.? The more
> frequently we a release for long term support, the more work each
> security release will be. ?We would be required to create and test a new
> patch version for the current stable feature release plus a collection
> of LTS releases. If we did an LTS every year, that would be too much.
>
> I think 2 years is probably a good number.
>
> //
>
> */How long is ?long term support? anyways?/*
>
> As noted above and elsewhere, Ubuntu and RHEL/CentOS support LTS
> versions for 5 years. ?That?s a long time, and more than our team could
> agree to.
>
> After a bunch of discussion, we think 3 years is a good number.
>
> /To summarize/, I?m proposing a Long Term Support (LTS) program for
> ClamAV starting with the 0.103 feature release. ?This means:
>
> 1. We will promise to provide critical patch versions (0.103.4, .5.,
> .6, etc.) as needed until the LTS end-of-life.
> This does not mean that the original 0.103.0 or other problematic
> patch versions within the series will continue to ?work?.
> Users MUST be willing to upgrade to newer patch versions within a
> given LTS release.
>
> 2. Each LTS release would be supported for three (3) years from the
> first (.0) version.
>
> /0.103.0 was published in August 2020/. ?This means we would
> continue to provide critical patch versions for 0.103 until August
> 2023.
>
> 3. We will aim to select a new LTS feature release every two (2) years.
>
> With 0.103 starting the LTS program, that means that whichever
> feature release is to be published near abouts August 2022 is the
> likely candidate for the next LTS release.
>
> 4. When a security fix is required, we?ll publish a patch version for
> the latest feature release as well as all affected active LTS
> feature releases.
>
> 5. We will document the LTS policy and add an end-of-life version table
> to https://docs.clamav.net/faq/faq-eol.html.
>
> I would like your feedback.
>
> Respectfully,
>
> Micah
>
>
> Micah Snyder
> ClamAV
> Talos
> Cisco Systems, Inc.
>
>
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml
>

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

LTS sounds like a great idea!

Recently, the bandwidth hogging episodes have resulted in rapid changes to ClamAV versions, followed by EOL of versions that many people (not including me) were still using. So recently I have had to spend far more time on updating ClamAV than updating anything else I use. And since I can't count on Debian (or even update-happy OpenSUSE) keeping up with these (now rapid) changes, I have always built ClamAV from source, ever since I started using it 16+ years ago.

Thus, an LTS ClamAV which allowed me to build from source only a couple of times per year would be much appreciated. And I hope that CMAKE building can be sorted out before the next Update Now! emergency.

(I don't see exactly how a LTS would have helped with the bandwidth issue, but I suppose it wouldn't have made it any more disruptive.)

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Citeren Paul Kosinski via clamav-users <clamav-users@lists.clamav.net>:

> LTS sounds like a great idea!
>
> Recently, the bandwidth hogging episodes have resulted in rapid
> changes to ClamAV versions, followed by EOL of versions that many
> people (not including me) were still using. So recently I have had
> to spend far more time on updating ClamAV than updating anything
> else I use. And since I can't count on Debian (or even update-happy
> OpenSUSE) keeping up with these (now rapid) changes, I have always
> built ClamAV from source, ever since I started using it 16+ years ago.

For openSUSE Leap, the latest version of ClamAV is usually available
within days of a new release through
https://build.opensuse.org/package/show/security/clamav or in openSUSE
Tumbleweed (if you're using the rolling release version). Version
0.104.0 will also be available through that channel, as the conversion
to cmake build is already done. If you're feeling adventurous, I have
it available in my personal build directory in the openSUSE Build
Service (OBS) (Tumbleweed only).

> Thus, an LTS ClamAV which allowed me to build from source only a
> couple of times per year would be much appreciated. And I hope that
> CMAKE building can be sorted out before the next Update Now!
> emergency.
>
> (I don't see exactly how a LTS would have helped with the bandwidth
> issue, but I suppose it wouldn't have made it any more disruptive.)
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml




_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

> On Jul 30, 2021, at 14:41, Paul Kosinski via clamav-users <clamav-users@lists.clamav.net> wrote:
>
> (I don't see exactly how a LTS would have helped with the bandwidth issue, but I suppose it wouldn't have made it any more disruptive.)

103.2 and 103.3 are much more respectful to bandwidth than any past version. We’ve been working with Cloudflare on the development of a feature that is exactly optimized to handle these changes, and they are almost ready to deploy it. We’ve tested it out and it works well, so we’re just waiting on a few more updates.


_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

On Sat, 31 Jul 2021 02:37:53 +0000
"Joel Esler (jesler)" <jesler@cisco.com> wrote:

> > On Jul 30, 2021, at 14:41, Paul Kosinski via clamav-users <clamav-users@lists.clamav.net> wrote:
> >
> > (I don't see exactly how a LTS would have helped with the bandwidth issue, but I suppose it wouldn't have made it any more disruptive.)
>
> 103.2 and 103.3 are much more respectful to bandwidth than any past version. We’ve been working with Cloudflare on the development of a feature that is exactly optimized to handle these changes, and they are almost ready to deploy it. We’ve tested it out and it works well, so we’re just waiting on a few more updates.
>


What I meant was that if (e.g.) 0.103.1 had been LTS, that alone wouldn't have solved the bandwidth overload. Making (e.g.) 0.104.x LTS will (of course) mitigate future bandwidth problems.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

On 30.07.21 14:38, Paul Kosinski via clamav-users wrote:
>Recently, the bandwidth hogging episodes have resulted in rapid changes to
> ClamAV versions, followed by EOL of versions that many people (not
> including me) were still using. So recently I have had to spend far more
> time on updating ClamAV than updating anything else I use. And since I
> can't count on Debian (or even update-happy OpenSUSE) keeping up with
> these (now rapid) changes, I have always built ClamAV from source, ever
> since I started using it 16+ years ago.

can't count on Debian?

i think clamav and spamassassin were the main reasons the volatile (now
updates) archive was created and maintainers are trying to get active clamav
into debian.

Yes, LTS debian has 0.102.4 and not 0.103, but it still works, doesn't it?

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
A day without sunshine is like, night.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

On Sat, 31 Jul 2021 20:32:23 +0200
Matus UHLAR - fantomas <uhlar@fantomas.sk> wrote:

> can't count on Debian?

They are very conservative, which is usually nice. But for security software, not so nice.

The current "stable" Debian is 10/Buster. It has ClamAV 0.103.2, patched by Debian to "deb10u1" (whatever that implies). Since it's not based directly on 0.103.3, I'd have to analyze it, and that would be more trouble than just building from source.

And, according to Debian (https://tracker.debian.org/pkg/clamav), 0.103.3 is now "unstable", and thus may need special action to be added to Debian 11/Bullseye before its Aug 14 release. (Bullseye is in "full freeze" according to https://lists.debian.org/debian-devel-announce/2021/07/msg00002.html.)


_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

> The current "stable" Debian is 10/Buster. It has ClamAV 0.103.2, patched by Debian to "deb10u1" (whatever that implies)

https://security-tracker.debian.org/tracker/source-package/clamav

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

On Tue, 3 Aug 2021 07:53:24 +0200
Damian via clamav-users <clamav-users@lists.clamav.net> wrote:

> > The current "stable" Debian is 10/Buster. It has ClamAV 0.103.2, patched by Debian to "deb10u1" (whatever that implies)
>
> https://security-tracker.debian.org/tracker/source-package/clamav


Interesting, but *much* more work to figure out how it all relates to 0.103.3 than simply building 0.103.3 from source. (Has Debian fixed any problems that the ClamAV team hasn't fixed? If so, that's scary.)

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Hi there,

On Tue, 3 Aug 2021, Paul Kosinski via clamav-users wrote:

> On Tue, 3 Aug 2021 07:53:24 +0200
> Damian via clamav-users <clamav-users@lists.clamav.net> wrote:
>
>>> The current "stable" Debian is 10/Buster. It has ClamAV 0.103.2, patched by Debian to "deb10u1" (whatever that implies)
>>
>> https://security-tracker.debian.org/tracker/source-package/clamav
>
>
> Interesting, but *much* more work to figure out how it all relates
> to 0.103.3 than simply building 0.103.3 from source.

Quite so.

> (Has Debian fixed any problems that the ClamAV team hasn't fixed? If
> so, that's scary.)

Nothing serious I think, although this is still uncorrected in 103.3:

https://sources.debian.org/patches/clamav/0.103.2+dfsg-0+deb10u1/0007-unit-tests-Fix-ck_assert_msg-call.patch/

Off their own bat they've done things which weren't done upstream like
making provision for using a 'tomsfastmath' which is provided by the
system instead of it being built into ClamAV; and I guess not fixing
the Windows vulnerability (CVE-2021-1386) was deliberate:

https://sources.debian.org/patches/clamav/0.103.2+dfsg-0+deb10u1/
https://blog.clamav.net/2021/04/clamav-01032-security-patch-release.html

--

73,
Ged.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml