This exception was declined.

Explanation of reasoning?

Sure, I guess I should have provided that in all of these tickets. In the end, we declined all exceptions except for one (FF/TB/XR), and the approval of that one was based on legal issues (the Mozilla trademark license) and not anything technical.

There are lots of packages that one could touch in order to make a system not boot that are highly complex. these are just a few of them. We also made it very clear in the meeting summary that went to f-devel that this does NOT imply a free-for-all, and that any provenpackager that touches a package without first consulting with the owner should expect censure.

Does this effectively answer the question?

(1) In view of the security incident last year, I'd have thought it would be prudent not to be giving out distro-wide access to accounts that don't need it. Have the people on FESCO who are privy to the full details of that incident carried out a risk analysis of this policy? (Arguably should those not privy to the details exclude themselves from votes?)

(2) "any provenpackager that touches a package without first consulting with the owner should expect censure". But then why give the provenpackagers access in the first place? It's simply unneeded: You are stating that the provenpackager concerned must discuss whatever it is with the owner first, who would either give them access to the package through pkgdb as happens today, or will agree to apply the changes in a timely manner him or herself. That has advantages, including encouraging dialogue between the parties concerned, allowing for finer-grained access control (including an option to limit access to the period of time needed to carry out the specific work), and less committee-based bureaucracy.

I can see several additional risks to the integrity of the distro introduced by allowing 'provenpackager' access to change every package with virtually no exceptions - what I can't see are any practical gains.

Is the FESCO view on provenpackager unanimous or is there any dissent?

"we declined all exceptions except for one"
Then the wording on https://fedoraproject.org/wiki/Provenpackager_policy seems rather disingenuous: "It is possible for a maintainer to deny access to provenpackagers for his particular package," - except in practice, it seems to be not.

The security incident is a red herring here. A hypothetical attacker could modify any package to make the system unbootable or compromise its security; they don't actually need access to LVM or any other "special" packages.

"Could modify", yes of course: but things that make an attack harder and slow an attacker down should be done as they increase the chance of a security breach being detected earlier.

The thrust of my argument is that I cannot envisage any circumstances where accounts in the "provenpackager" group would have a valid reason to use that global access on packages such as these, given the alternative existing process I outlined above, and therefore that a general basic security principle of only granting the minimum access necessary should be applied and the "provenpackager" group should not be granted access.

Two related things I'd prefer to see progress on:

1) Rather than "provenpackager" for the entire distro and requiring a single package owner for each package, enhance pkgdb to make it easier to specify and manage deputy package maintainers or a group of maintainers responsible for a group of packages;

2) Enhance the tools such that packages in a group can opt into a requirement for signoff of changes from another maintainer account in the pool before packages can be built. (A quick way to implement that might be to require that a build be submitted by a different committer account from any that committed changes since the last successful build.) Or go half-way and have "provenpackager" accounts able to commit changes to these packages but not submit builds.

Where did we leave this? If a representative from the LVM team would be willing to attend a FESCo meeting, either tomorrow or at any later time, we'd like to have a more interactive discussion on this.

ping?

At Friday's FESCo meeting, it was decided that we are giving you one last opportunity to work with us. If there is no response in this ticket in the next two weeks (which has been festering since April), the ACL's will be opened.

Please either respond, or your lack of response indicates that you are OK with the ACL's on these items being opened.

There's no change to my position - I reckon the policy decision should be reviewed for security reasons.

Please attend today's FESCo meeting at 17:00UTC (1:00PM EDT) so that this can be discussed further.

How do I attend?

IRC.

But keeping the LVM ACLs closed on security grounds while kernel and others are open makes no sense at all. The provenpackager group is actually very strictly controlled, we can really expect to trust those people. That was already a compromise to alleviate security concerns. I think going back to an even stricter ACL regime would be really detrimental to our project and bring no actual added security.

It was agreed at the meeting that there will be no exception for the LVM packages. However, as Fedora critical path packages, they will be subject to that process.