On 19 February 2016 at 08:35, Kevin Fenzi <ke...@scrye.com> wrote: > On Thu, 18 Feb 2016 14:42:12 -0700 > Stephen John Smoogen <smo...@gmail.com> wrote: > >> >> One of the requests was to have snapshots of the guidelines that we >> worked each channel against so that it was clearer what 5 wanted >> versus 6 wanted. > > Sure, we have it divided into 5 and 6 here (I assume we don't have too > many changes from 7): > https://fedoraproject.org/wiki/EPEL:Packaging > >> > Yeah. I think we could include 2 versions of everything (at the >> > cost of 2x of the mirror space and bandwith), but then you have >> > things like foo-1.0 has a major security bug and foo-1.1 came out >> > to fix it, and you trick someone into downgrading or installing the >> > old one and exploit them. ;( >> >> If we don't delete them from koji we aren't fixing anything because if >> I can trick you to downgrade, I can trick you to go to the version in >> koji because it has the fix needed. [Since I have seen people talk >> about their systems getting broken into after they did exactly that.. >> I think it isn't going too far in assumptions :)] > > Well, it becomes a great deal harder. > > 1. Hey, you should 'yum downgrade foo' because the newest one isn't > good. > > vs > > 2. Hey, you should download this > https://kojipkgs.fedoraproject.org/blah/blah/blah/foo.rpm and 'yum > --nogpgcheck localinstall foo.rpm' because the new one is broken. > > The first one sounds a lot more legit. I think not having it in enabled > repos makes it a good deal more clear. >
Well currently people are having to be told that for every package we remove even if it isn't a security problem just because it was removed without maintainer. Once that becomes the 'norm' it becomes easier to pull off the other type. >> Or not promise it at all. I think the underlying issue is that people >> think we do have full-time people working on EPEL with the same >> controls (if not more) than we have in Fedora. > > Could be, yeah. > >> >> * EPEL only covers part of Enterprise Linux (the Server product) >> >> but a lot of packages are for the Workstation but there is no way >> >> to see when things replace/conflict with them. [People believe >> >> that we build against the equivalent of CentOS-5/6/7 versus a >> >> subchannel.] >> > >> > Yeah, not sure how to fix that without a second workstation >> > branch. :( >> >> The only monstrosities I have thought of were: >> epel-server-N >> epel-workstation-N >> epel-combined-N >> >> which sounded like a ton of work for little benefit. > > Yes. > >> OH yeah.. that was one of the items.. why is the website so old and >> dead. I told them your story about trying to fix it up and finding >> parts reverted over and over again. Someone recommended : Just start >> from scratch and kill the old stuff. Which I think was part of the >> "recharter" talks. > > I'd fullly support someone working over the wiki... always good. ;) > > Not sure I have the cycles to do it myself tho. > I believe we are going to need to do so anyway as one of the proposals coming out of the DevConf things was basically moving the wiki to be a whiteboard versus a place where actual documentation for subprojects go. However that is me listening to talks while trying to do my homework so I am not sure how I am reading that to be "what we are looking to do" to something else. > kevin > > _______________________________________________ > epel-devel mailing list > epel-devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org > -- Stephen J Smoogen. _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
