Ticket #124 (closed task: fixed)

Opened 5 years ago

Last modified 5 years ago

Re: Packages with closed ACL's - LVM related items

Reported by: agk Owned by:
Priority: major Keywords: meeting
Cc: Blocked By:
Blocking:

Description

On Sun, Mar 22, 2009 at 04:10:18PM -0400, Jon Stanley wrote:

If you believe that you have justifiable reason for not allowing this select group of people to commit to your packages, then please file a ticket[2] and state the reasons.

This applies to all the lvm-team packages:

  1. They are complex packages that form a critical part of booting many people's systems and changes should not be undertaken lightly as mistakes can have wide implications (including causing data corruption or security problems). Substantive changes to the code included within the packages are assessed within the team prior to the changes being applied.
  1. Irrespective of item (1), there are already sufficient people in lvm-team across various time-zones to manage the packages and to deal with patches, urgent or otherwise, so permitting the 'provenpackager' group would bring no benefits, but would only increase the risk of someone inexperienced with one of the packages causing a serious problem for lvm-team members to fix. All changes should be proposed via the proper channels - either Fedora bugzilla or upstream mailing lists.

It is my firm view that minimising the risk of problems requires that people who believe they need direct commit access to any of these packages be assessed on an individual basis by the lvm-team - independently of any 'provenpackager' assessment - so the scope of the changes they are making and any relevant processes they should follow can be discussed and agreed with them. The existing pkgdb process is quite sufficient for this.

Change History

comment:1 Changed 5 years ago by jstanley

  • Keywords meeting added

comment:2 Changed 5 years ago by jstanley

  • Summary changed from Re: Packages with closed ACL's to Re: Packages with closed ACL's - LVM related items

comment:3 Changed 5 years ago by jstanley

  • Type changed from maintainer issue to task

comment:4 Changed 5 years ago by jstanley

  • Resolution set to fixed
  • Status changed from new to closed

This exception was declined.

comment:5 Changed 5 years ago by agk

Explanation of reasoning?

comment:6 Changed 5 years ago by agk

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:7 Changed 5 years ago by jstanley

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?

comment:8 Changed 5 years ago by agk

(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.

comment:9 Changed 5 years ago by dwmw2

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.

comment:10 Changed 5 years ago by agk

"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.

comment:11 Changed 5 years ago by jstanley

  • Keywords meeting removed

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.

comment:12 Changed 5 years ago by jstanley

ping?

comment:13 Changed 5 years ago by jstanley

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.

comment:14 Changed 5 years ago by notting

  • Keywords meeting added

comment:15 Changed 5 years ago by agk

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

comment:16 Changed 5 years ago by jstanley

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

comment:17 Changed 5 years ago by agk

How do I attend?

comment:18 Changed 5 years ago by kkofler

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.

comment:19 Changed 5 years ago by jstanley

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.