adding meeting keyword for next week.
adding maintainer.

FWIW, from https://bugzilla.redhat.com/show_bug.cgi?id=787434 , there doesn't seem to be any problem with responsiveness, I'd call the time to respond above-average - it's a technical disagreement; given that, the recommendation is not really applicable (especially because FESCo does not have a pool of maintainers they could tap to "find" a new one).

OTOH the clamav packaging is clearly unusual; %description from clamav-server:

This package contains files which are needed to execute the clamd-daemon.
This daemon does not provide a system-wide service. Instead of, an instance
of this daemon should be started for each service requiring it.

See the README file how this can be done with a minimum of effort.

And the relevant README ends with:

[Disclaimer:
this file and the script/configfiles are not part of the official
clamav package.

Please send complaints and comments to
mailto:enrico.scholz@informatik.tu-chemnitz.de!]

I remember that this was discussed widely several years ago, but I'm not sure what the goals, rationale or result of that discussion was (the package doesn't document any of it).

Enrico, could you find the links to the goals/rationale and previous discussion?

Replying to [comment:2 mitr]:

I'd call the time to respond above-average
sigh... that's "the time to respond below-average" or "the responsiveness above-average".

Replying to [comment:2 mitr]:

FWIW, from https://bugzilla.redhat.com/show_bug.cgi?id=787434 , there doesn't seem to be any problem with responsiveness, I'd call the time to respond above-average - it's a technical disagreement; given that, the recommendation is not really applicable (especially because FESCo does not have a pool of maintainers they could tap to "find" a new one).

Keep in mind that 787434 was created because I commented on 754555 suggesting that it should be pulled from "testing" and not proceed on to "updates", but it did anyway.

OTOH the clamav packaging is clearly unusual; %description from clamav-server:

This package contains files which are needed to execute the clamd-daemon.
This daemon does not provide a system-wide service. Instead of, an instance
of this daemon should be started for each service requiring it.

See the README file how this can be done with a minimum of effort.

And the relevant README ends with:

[Disclaimer:
this file and the script/configfiles are not part of the official
clamav package.

Please send complaints and comments to
mailto:enrico.scholz@informatik.tu-chemnitz.de!]

I remember that this was discussed widely several years ago, but I'm not sure what the goals, rationale or result of that discussion was (the package doesn't document any of it).

Enrico, could you find the links to the goals/rationale and previous discussion?

My chief objections are two-fold:

(1) Changing the directory permissions to prevent access to the socket (when the socket permissions are easily changeable themselves) doesn't solve the root-cause;
(2) It breaks the "LocalSocketMode" and "LocalSocketGroup" functionality which was included to provide flexibility.

It's not necessary to stray from the upstream design, especially since there's a trivial means to address the security issues while remaining 100% compatible with upstream.

And for what it's worth, I don't see the point of including a "sample" that in itself isn't actually usable. What's the point? You install it, figure out why it '''doesn't''' work the way you need it to, clone it, modify it, and then remove the original sample... Why do any of that when you can just as easily provide a trivial working sample that's usable as-is or with trivial modification (such as changing group memberships)?

Resolution at 2012-02-13 FESCo meeting.
* AGREED: Ask ensc to document (at least by a link) the packaging
rationale inside the package; close ticket and let philipp reopen
with a specific proposal

Replying to [comment:5 sgallagh]:

Resolution at 2012-02-13 FESCo meeting.
* AGREED: Ask ensc to document (at least by a link) the packaging
rationale inside the package; close ticket and let philipp reopen
with a specific proposal

Already did that:

https://bugzilla.redhat.com/show_bug.cgi?id=787434#c9

https://bugzilla.redhat.com/show_bug.cgi?id=754276#c1

The specifics of the Packaging Guidelines violations are section 1.42:

• Permissions on files must be set properly. Executables should be set with executable permissions, for example.

And the Updates Policy clearly states:

• Avoid changing the user experience if at all possible.

Yet disabling the functionality of the LocalSocketGroup and LocalSocketMode commands does exactly that.

The patch that I've suggested restores the user experience to what's expected.

I've also reopened 787434 and pointed out several issues with the existing install directions.

Waiting for feedback/acknowledgment.

Replying to [comment:7 philipp]:

The specifics of the Packaging Guidelines violations are section 1.42:

• Permissions on files must be set properly. Executables should be set with executable permissions, for example.

Which executable files are not executable? In which clamav versions?

And the Updates Policy clearly states:

• Avoid changing the user experience if at all possible.

Yet disabling the functionality of the LocalSocketGroup and LocalSocketMode commands does exactly that.

The patch that I've suggested restores the user experience to what's expected.

When were these features enabled and when were they disabled?

Waiting for feedback/acknowledgment.

FESCo didn't meet last week, but we will next week. Sorry for the delay.

Replying to [comment:9 kevin]:

Replying to [comment:7 philipp]:

The specifics of the Packaging Guidelines violations are section 1.42:

• Permissions on files must be set properly. Executables should be set with executable permissions, for example.

Which executable files are not executable? In which clamav versions?

The /var/run/clamd.scan/ directory wasn't world readable... so that whatever client wanted to use the service had to be in the clamscan group just to open the socket.

And the Updates Policy clearly states:

• Avoid changing the user experience if at all possible.

Yet disabling the functionality of the LocalSocketGroup and LocalSocketMode commands does exactly that.

The patch that I've suggested restores the user experience to what's expected.

When were these features enabled and when were they disabled?

It seems to be a side-effect of F16 and the introduction of /etc/tmpfiles.d/ ... changeset 69c6c9fa according to "git blame".

Waiting for feedback/acknowledgment.

FESCo didn't meet last week, but we will next week. Sorry for the delay.

I'm waiting more from the maintainer, in this case.

At this weeks meeting, FESCo agreed to close ticket and ask for reporter to reopen with a real violation, or with a specific use case (as opposed to a single configuration item) that is broken by this packaging

NOTE: FESco required rationale for the current packaging, which has not been documented yet

Replying to [comment:11 kevin]:

At this weeks meeting, FESCo agreed to close ticket and ask for reporter to reopen with a real violation, or with a specific use case (as opposed to a single configuration item) that is broken by this packaging

NOTE: FESco required rationale for the current packaging, which has not been documented yet

Did comment #9 somehow get overlooked, where I wrote:

"I've also reopened 787434 and pointed out several issues with the existing install directions. Waiting for feedback/acknowledgment."

Replying to [comment:12 philipp]:

Did comment #9 somehow get overlooked, where I wrote:

"I've also reopened 787434 and pointed out several issues with the existing install directions. Waiting for feedback/acknowledgment."

If you are referring to [https://bugzilla.redhat.com/show_bug.cgi?id=787434#c25], that seems to have been addressed: [http://pkgs.fedoraproject.org/gitweb/?p=clamav.git;a=commitdiff;h=55b25f143b51d705a12572f62b6cd99ff3802965]

Replying to [comment:13 mitr]:

Replying to [comment:12 philipp]:

Did comment #9 somehow get overlooked, where I wrote:

"I've also reopened 787434 and pointed out several issues with the existing install directions. Waiting for feedback/acknowledgment."

If you are referring to [https://bugzilla.redhat.com/show_bug.cgi?id=787434#c25], that seems to have been addressed: [http://pkgs.fedoraproject.org/gitweb/?p=clamav.git;a=commitdiff;h=55b25f143b51d705a12572f62b6cd99ff3802965]

Yes, those would be the issues.

I was naively assuming that the resolution would be mentioned in the bug description (i.e. in bugzilla), and not merely in the sources (i.e. git), since other persons facing this same issue might not have a propensity for groveling around the sources to know if a bug has in fact been fixed or not.