From Fedora Project Wiki
Attendees
People present (lines said)
- jlaska (140)
- adamw (73)
- wwoods (68)
- Oxf13 (39)
- poelcat (26)
- Viking-Ice (21)
- kparal (20)
- spot (7)
- tibbs (2)
- zodbot (2)
- jwb (2)
- buggbot (1)
- tk009 (1)
- pjones (1)
- jeff_hann (1)
Regrets:
Agenda
Previous meeting follow-up
- jlaska will propose Common_F12_Bugs after meeting for bug#530541
Added to the list with help from User:wwoods and User:adamw (See Common_F12_bugs#preupgrade-boot). Also reorganized How_to_use_PreUpgrade and we've had several additional contributions to the troubleshooting section from User:Toshio and User:Mccann.
- preupgrade test updates
Per last weeks FESCO meeting on preupgrade, QA team took an action item to update the preupgrade test cases (QA:Testcase Preupgrade and QA:Testcase Preupgrade from older release). Fedora QA trac ticket#30 is tracking this update. User:rhe and User:Kparal have adding their thoughts to the issue.
- jlaska to send request for retrospective feedback to fedora-test-list@
Unfortunately, no action this past week. Will prioritize for this week and discuss next week.
Security Test Plan
Spot posted some great points around non-root user security expectations in his blog last week (see http://spot.livejournal.com/312216.html). This seems to me like an interesting project worth pursuing for Fedora 13.
The team discussed at length, highlights include:
- Spot updated his blog with the latest feedback from his blog -- see http://spot.livejournal.com/312216.html
- part#1 - Should involve defining a security policy ... instead of making one up
- This policy may take into account a method for each spin SIG to add spin-specific security policy.
- part#2 - The QA team can support a security policy by creating test documentation (plans/cases) and providing test results
AdamW agreed to take the first step by initiating discussion with fedora-devel-list and fedora-security-list to begin the process of reaching consensus on a security policy.
Enhancing Release Criteria
John Poelstra has been thinking about enhancements to the current Fedora release criteria and has organized his thoughts into several wiki pages, starting with Fedora_Release_Criteria. There aren't intentions that this list will be the end-all be-all of checklists for the list. I know we've all experienced some of the subjective nature of identifying blocker bugs and assessing release impact.
Please take a few moments to review the criteria, along with the following pages, and offer your suggestions/corrections.
Fedora 13 release criteria
General FAQ around escalating blocker bugs - Blocker_Bug_FAQ
User:poelstra joined the meeting and recommended reading the email announcement first. John also indicated he was hoping this would set a better stage for more info that might come from the target audience discussion. The plan was to host healthy discussion on the mailing list until FUDCon. Then, at FUDCon, hammer out the dents and formalize something we can use for Fedora 13. John asked the team if this was realistic. Adamw and jlaska felt it was.
Wwoods noted that the original release criteria was started by writing down whatever unwritten common-sense tests and policies we already had, and maybe a couple "it'd be nice if.." ones. John thanked Will for starting the release criteria process, as many of the points raised in the original page are included in the new release-specific pages.
AutoQA update
wwoods updates
autoqa-0.3 merged into the master branch (see http://git.fedorahosted.org/git/?p=autoqa.git;a=commit;h=a27a03f527a76af24bac46dd3872efc9fd4e3984). This branch adds:
- a new autoqa python library
- which includes, shared repoinfo code for the watcher scripts and utility functions/classes for tests
- the new post-koji-build hook. Which is still fairly experimental, but we have it running a simple 'rpmlint' test on every new build that comes out of koji
Wwoods outlined several FUDCon plans, including:
- An info session on current and future plans
- A hackfest on a solid depcheck test
- Work to solidify the post-koji-build hook
- Think of some possible ways to make it easy for package maintainers to add post-build tests
- Get rpmguard up and running
kparal asked how work was proceed with running autoqa locally (see ticket#52). Wwoods indicated that was a prerequisite for maintainers to be able to work on post-build tests
kparal updates
While waiting for wwoods' big merge (52 commits ahead), I was trying to improve wiki documentation. So I created a new AutoQA front page (see AutoQA), which should work as a guidepost - different kinds of user can choose interesting stuff for them and go to a link for details. The previous content was moved to "AutoQA architecture" page. there's the post: https://fedorahosted.org/pipermail/autoqa-devel/2009-November/000023.html. Kamil advised ... not to look at the front page much in detail, it's going to change soon. Jlaska proposed an improved version for review at User:Jlaska/Draft which may replace the current version soon.
Kamil's plan for this week includes working on integration of rpmguard into autoqa. Wwoods noted that they'd need to figure out what to do with the output of the test (mail it to package owners/autoqa-results?) and what to do when there's a change that should block the package. But that can wait until after the test is working.
Misc
- Use cases - AutoQA_Use_Cases - INPROGRESS
- Packaging autotest - https://fedorahosted.org/autoqa/ticket/9 - DONE
- Packaging autoqa - https://fedorahosted.org/autoqa/ticket/3 - DONE
- Convert israwhidebroken to WSGI - https://fedorahosted.org/autoqa/ticket/91 - INPROGRESS
Open discussion - <Your topic here>
FUDCon - Oxf13
Jkeating announced plans to host a talk around the future of Fedora development. This talk would include outlining No_Frozen_Rawhide_Proposal, AutoQA, auto-signing, new milestones, and how all these puzzle pieces are supposed to fit together.
Jwb asked if the discussion could be recorded for those who would not be in attendance.
Target audience for DVD.iso - Viking-Ice
In reference to the Fedora target audience discussion, Viking-Ice asked, Who's the dvd img target audience. sysadmins [ or ] end users?
Jlaska pointed to the install guide which states:
If you have plenty of time, a fast Internet connection, and wish a broader choice of software on the install media, download the full DVD version
Wwoods provided a link to the fedora-advisory-board discussion - http://lwn.net/Articles/358865/
Discussion followed around whether DVD/CD optical media was still required. The recommendation was to take any updates or discussion on this topic to the fedora-advisory-board list.
Upcoming QA events
- NA
Action items
- adamw - initiate security policy discussion on fedora-{devel,security}-list
- jlaska to send request for retrospective feedback to fedora-test-list@
IRC transcript
| jlaska | #startmeeting Fedora QA Meeting | 16:00 |
|---|---|---|
| zodbot | Meeting started Mon Nov 23 16:00:42 2009 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| zodbot | Useful Commands: #action #agreed #halp #info #idea #link #topic. | 16:00 |
| adamw | morning | 16:00 |
| jlaska | #topic gathering critical mass | 16:01 |
| jlaska | hmm, I forget which tag gives the meeting a specific title | 16:01 |
| jlaska | #meetingtitle qa | 16:01 |
| * kparal is here | 16:01 | |
| * tk009 is here | 16:02 | |
| * jeff_hann here | 16:02 | |
| jlaska | adamw: kparal tk009 jeff_hann - welcome :) | 16:02 |
| * Viking-Ice pops up.. | 16:02 | |
| * poelcat here | 16:02 | |
| * wwoods aliiiiive | 16:02 | |
| * Oxf13 | 16:02 | |
| Oxf13 | lucky to be alive | 16:03 |
| * jlaska tips hat to Viking-Ice, poelcat, wwoods and Oxf13 | 16:03 | |
| jlaska | okay, let's get started then | 16:04 |
| * jlaska walking through proposed agenda https://www.redhat.com/archives/fedora-test-list/2009-November/msg00989.html | 16:04 | |
| jlaska | #topic Previous meeting follow-up | 16:04 |
| jlaska | * jlaska will propose Common_F12_Bugs after meeting for bug#530541 | 16:04 |
| buggbot | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=530541 medium, low, ---, skvidal, CLOSED ERRATA, Free space check on /boot not thorough enough | 16:04 |
| jlaska | well, this is done ... thanks of course to adamw for his mastery of wiki documentation! | 16:05 |
| jlaska | you can see what came out of this at ... | 16:05 |
| jlaska | Common_F12_bugs#preupgrade-boot | 16:05 |
| jlaska | and some re-organization done to ... | 16:05 |
| jlaska | How_to_use_PreUpgrade | 16:05 |
| adamw | np | 16:05 |
| jlaska | so thanks adamw and wwoods for the guidance there :) | 16:05 |
| jlaska | next up ... somewhat related ... | 16:06 |
| jlaska | * preupgrade test updates | 16:06 |
| jlaska | for those following along with the home game ... rhe is helping by updating the existing preupgrade test cases to ensure we're catching this behavior | 16:06 |
| jlaska | For details, checkout the trac ticket ... | 16:06 |
| jlaska | https://fedorahosted.org/fedora-qa/ticket/30 | 16:06 |
| wwoods | oh, that's "updates to the preupgrade tests" not "updated preupgrade packages in updates-testing" | 16:07 |
| jlaska | wwoods: yeah, you got it | 16:07 |
| jlaska | Hurry has helped cleanup the existing cases ... and with some guidance from kparal, a new case should be coming to target the /boot behavior | 16:07 |
| jlaska | that'll probably finish up in a week, but just wanted to let folks know where it was | 16:08 |
| jlaska | next up ... | 16:08 |
| jlaska | * jlaska to send request for retrospective feedback to fedora-test-list@ | 16:08 |
| jlaska | as you can probably tell, I've not managed to task this last week | 16:08 |
| * jlaska wears the cone of shame | 16:08 | |
| jlaska | I'm hoping to get this out this week of course ... so we can start the F12 retrospective and F13 planning process | 16:09 |
| adamw | bad jlaska | 16:09 |
| jlaska | indeed! | 16:09 |
| jlaska | okay, that's all I had in the minutes from last week | 16:10 |
| jlaska | I know folks have been busy, are there any other items to follow-up on that I missed? | 16:10 |
| * poelcat was wondering about having a release wide retrospective at FUDCon | 16:10 | |
| poelcat | would that be appealing to people or would they rather use our time there on something else? | 16:10 |
| jlaska | poelcat: ooh, not a bad idea | 16:10 |
| poelcat | it's easy to say "let's do ____ at FUDCon" but the time always goes fast! | 16:11 |
| jlaska | definitely | 16:11 |
| jlaska | well, I'm not opposed to it ... I've not figured out a great plan for processing the retrospective feedback ... other than documenting it on the wiki, and asking folks to think about areas they'd like to tackle to address the pain points | 16:12 |
| jlaska | so, I'm open to different approaches | 16:12 |
| jlaska | we can bounce around ideas on that after the meeting if you like | 16:13 |
| poelcat | okay | 16:13 |
| poelcat | carry on :) | 16:13 |
| jlaska | and if no one responds to he mail ... I guess that helps answer it :) | 16:13 |
| jlaska | s/he/the/ | 16:13 |
| jlaska | okay ... swim suits on please ... let's dive in ... | 16:14 |
| jlaska | #topic Security test plan | 16:14 |
| Viking-Ice | This is something that each spin SIG needs to decided and adjust to their target audience and or the purpose of the spin. | 16:14 |
| Viking-Ice | You can not impose the same rules on Desktop vs workstation/server deployment. | 16:14 |
| Viking-Ice | The recent pk-fiasco was blown out of proportion and is a typical example for an incompetent admin who used and deploy an image who's target audience was home desktop end user ( Which I believe all the live *DE spins are as in being the latest *DE technology preview for the home desktop end user ) in a multiuser corporate/enterprise environment. | 16:14 |
| poelcat | jlaska: can you give a little background by what you mean on a security test plan? | 16:15 |
| adamw | Viking-Ice: PackageKit is on every default Fedora installation. | 16:15 |
| Viking-Ice | I have no clue to who releng target audience is with the dvd img but i'm pretty sure that's not workstation/server deployment. if it is it should follow what's documented/recommended on CSI ( https://fedorahosted.org/csi ). | 16:15 |
| jlaska | poelcat: sure | 16:15 |
| adamw | Viking-Ice: and that's not on-topic for us anyway. | 16:15 |
| jlaska | so ... not really interested in churning up the waters on this front | 16:15 |
| wwoods | no, I think it's on-topic to a certain extent; | 16:15 |
| jlaska | it's been done plenty already and it seems the issues is being worked | 16:15 |
| jlaska | what I wanted thoughts on from the group was something spot blogged about | 16:15 |
| wwoods | the proposed security test plan includes a bunch of test cases tailor-made for a corporate workstation/server deployment | 16:15 |
| wwoods | which is inappropriate for the board-defined use cases for the default spin | 16:16 |
| wwoods | and for most of our other desktop spins | 16:16 |
| wwoods | I think we can agree that the plan - as with all test plans - needs to be tailored to the needs of the spin | 16:16 |
| adamw | where is 'the proposed security test plan'? | 16:16 |
| wwoods | I think it also points out the need for a Server/Workstation spin. | 16:16 |
| jlaska | http://spot.livejournal.com/312216.html | 16:16 |
| jlaska | adamw: 2 parts to this ... what spot posted is certainly not the final product | 16:16 |
| jlaska | Viking-Ice: and wwoods correctly note that there may be SIG specific test cases/areas for the tplan | 16:17 |
| adamw | all of that seems perfectly sensible for _any_ multi-user setup. nothing corporate. | 16:17 |
| adamw | if i were running a family PC that's pretty much what I'd want. | 16:17 |
| * spot notes that there are additional revisions to that which need to be made | 16:17 | |
| jlaska | I think we can certainly build into the plan a way to call out SIG specific tests | 16:17 |
| jlaska | spot: yeah, I was reading the comments and going to ask where your "master copy" was | 16:17 |
| poelcat | jlaska: so prior to final, QA would go through the list and verify each of them? | 16:18 |
| jlaska | poelcat: so that's the thinking ... | 16:18 |
| spot | jlaska: i was updating the post as the master copy initially, but i got busy and couldn't keep up | 16:18 |
| jlaska | first ... someone would propose a test plan that touches on the content spot highlights | 16:18 |
| spot | jlaska: i'll update it now | 16:18 |
| * adamw notes that most of those complaining about the PK issue were not corporate users, they were people with _home_ multi-user systems | 16:19 | |
| jlaska | once we have content we are all reasonably comfortable with and is something the team can manage ... I'd look to get this on the schedule for testing somehow | 16:19 |
| wwoods | re-reading the list of stuff spot's got.. I think I agree with adamw, those items - and that definition of "unprivileged" - are very reasonable | 16:19 |
| adamw | well, apart from the ones who were just complaining because they had nothing better to do. | 16:19 |
| wwoods | and there are certainly things in the comments that people who want spins with stronger default policies might like to write test cases for | 16:19 |
| adamw | but yeah, i find spot's list very reasonable and simple and a great place to start. | 16:19 |
| jlaska | anyone interested in taking a stab at some initial content here? | 16:19 |
| adamw | i'm not sure we want to move too fast | 16:20 |
| adamw | logically we should start designing test plans once the parameters are actually set | 16:20 |
| jlaska | adamw: what would you envision as the next steps? | 16:20 |
| wwoods | and much respect to spot for harnessing an angry mob to create something useful | 16:20 |
| adamw | we can't really draw up a test plan to check a security policy until there's a security policy | 16:20 |
| adamw | right now there's a blog post with bullet points | 16:20 |
| adamw | there's rather a gap from one to t'other :) | 16:20 |
| jlaska | adamw: yes, fair point | 16:21 |
| Viking-Ice | which leaves what base sec policy for desktop and another for workstation/server ? | 16:21 |
| adamw | i know everyone's all crazy enthusiastic about this right now (heh)...but there's six months to the next release | 16:21 |
| jlaska | adamw: I'd like to capitalize on spot's work here ... so the end result I'm hoping we can get to is a documented repeatable series of steps anyone can pitch in on | 16:21 |
| wwoods | adamw: uh, yes, but there's 8 weeks to F13 feature freeze | 16:21 |
| poelcat | lol | 16:22 |
| * poelcat was waiting for that | 16:22 | |
| jlaska | :) | 16:22 |
| adamw | wwoods: please put that statistic down and back away slowly ;) | 16:22 |
| wwoods | hey, this dead horse ain't gonna beat itself | 16:22 |
| adamw | there's several squishy areas here that worry me that we're not going to address ourselves | 16:22 |
| jlaska | adamw: cool, let's call those out | 16:23 |
| adamw | basically what qa's going to need to have is a set of test cases to test each item of the security policy which make up a 'security test plan' | 16:23 |
| adamw | but the thing is - what exactly would we be testing? | 16:23 |
| adamw | there's however-many-zillion apps in the repos | 16:23 |
| adamw | and we can't be absolutely sure which of them potentially allow any of these things to happen | 16:23 |
| adamw | well, we probably can, but it requires someone to do some spade work | 16:23 |
| Oxf13 | right | 16:23 |
| jlaska | which is why I raise it here | 16:23 |
| wwoods | I assume the policy would define some stuff - like a list of actions that unprivileged users must not be able to accomplish without an admin password | 16:24 |
| adamw | is anyone on development side planning to do an audit to produce a comprehensive list of apps that use elevated privileges? is there going to be a policy for flagging up apps which do so in future? | 16:24 |
| jlaska | first, wanted to get some scope for this issue ... so this is helping | 16:24 |
| wwoods | the policy needs to outline *specific, testable* items | 16:24 |
| Oxf13 | basically you're going to have to learn what mechanisms are used to elevate privs, such as PolicyKit, and then monitor packages that include policy files | 16:24 |
| jlaska | adamw: I wouldn't be opposed to that ... but I'm not looking for version 1.0 to be the worlds most exhaustive comprehensive plan | 16:24 |
| pjones | Oxf13: learning? but I hate learning! | 16:24 |
| jlaska | I'm looking for _something_ to start with and build on for each future release | 16:24 |
| Viking-Ice | is it not up to Fedora security to come up with the base security policy for desktop and workstation/server which we can then adjust create test plans for to make sure spins that fall under either category follow ? | 16:25 |
| adamw | wwoods: but unless we have some mechanism to produce a reliable list of the apps that can touch items of security policy in any way, we have to test everything in the distro for each security policy provision | 16:25 |
| wwoods | Viking-Ice: yeah, good point, but we can probably give guidance | 16:25 |
| Oxf13 | Viking-Ice: that's a nice way of passing the buck. | 16:25 |
| adamw | or make a list ourselves, which doesn't seem a) like our responsibility and b) like something we'd do very well | 16:25 |
| Oxf13 | there's absolutely room for cooperation | 16:25 |
| wwoods | adamw: ah, but we do - there are only a few ways to elevate privileges | 16:25 |
| Viking-Ice | we can not blindly create test cases based on what ever we think mean that crew is the expert after all.. | 16:25 |
| adamw | no, i think viking is right. our job is to test the policy, not to define it. | 16:25 |
| wwoods | and this is an area we can probably request help on | 16:25 |
| adamw | wwoods: that's exactly what i'm saying :) | 16:26 |
| jlaska | #info part#1 of this effort should involve defining a policy | 16:26 |
| spot | jlaska: updated | 16:26 |
| wwoods | ah, I understand - we can't do it, so we should be *requesting help* outlining that stuff | 16:26 |
| adamw | so i think we need a couple of things before we can sensible do any security policy testing: a security policy, and one that has a provision for treating security-sensitive apps sensitively. | 16:27 |
| jlaska | #info the QA team can support the policy by creating test documentation (plans/cases) and providing test results | 16:27 |
| wwoods | (for values of "can't" equal to "can, but don't necessarily have expertise and will need help and guidance &c") | 16:27 |
| adamw | then we would have a reasonable degree of confidence in what it is we're supposed to be testing, and the set of packages across which we need to test it. | 16:27 |
| jlaska | adamw: seems like a sensible approach | 16:27 |
| jlaska | spot: thank you | 16:28 |
| adamw | (i don't know about you but i don't want to spend the rest of my life checking if supertuxkart can change the system clock :>) | 16:28 |
| jlaska | at this point, I just care about critpath | 16:28 |
| adamw | that doesn't make sense, though | 16:28 |
| jlaska | we can embrace extend as needed ... or ensure that the process supports that | 16:28 |
| adamw | _any_ app that can screw over your security model is 'critpath' | 16:28 |
| Oxf13 | erm. | 16:28 |
| adamw | the critpath concept is only valid for application _brokenness_, not security | 16:29 |
| Oxf13 | if supertux doesn't include a PolicyKit policy file, a link to consolehelper, or a suid binary, we don't care about it | 16:29 |
| Oxf13 | we can easily narrow down the set of packages we do care about | 16:29 |
| adamw | Oxf13: right. which is why i want an Official List of applications which can do privilege escalation, and some kind of policy for what we do with new ones | 16:29 |
| wwoods | yeah, what Oxf13 said - it's *very* easy to detect the things needed to *attempt* elevated privilege | 16:29 |
| spot | or, alternately, the testing can check a package for the prerequisites and if found, test | 16:29 |
| Oxf13 | adamw: that's reasonable, but I'd do s/applications/methods/ | 16:30 |
| jlaska | spot: yeah that's fair too | 16:30 |
| poelcat | who can create an initial list of packages? | 16:30 |
| wwoods | and, yeah, rpmguard should throw hell of red flags for anything with new security policy / suid binaries | 16:30 |
| spot | as it is possible for a package to grow suid/consolehelper/policykit with an update | 16:30 |
| Oxf13 | adamw: since suid is a method, not a package. | 16:30 |
| adamw | true. | 16:30 |
| Oxf13 | spot: right, this absolutely falls under post-build checking | 16:31 |
| adamw | there's a wrinkle there, which is - how do we know what packages call an suid binary from a different package? | 16:31 |
| Oxf13 | and red flag throwing. | 16:31 |
| kparal | in rpmguard the suid check is already. we can add policy files check | 16:31 |
| jlaska | okay ... so ... next steps here? | 16:31 |
| jlaska | (rather ... first steps) | 16:31 |
| adamw | i'd like to know what's going on already | 16:31 |
| Oxf13 | adamw: that's not much of a concern, since the user could call the suid binary | 16:31 |
| adamw | it seems like others may know more than me | 16:31 |
| adamw | Oxf13: good point | 16:31 |
| Viking-Ice | Is it not best to wait for what the security teams comes up with then adjust create/come up with and adjust test cases accordingly dont see much point in discussing the "how" until then.. | 16:31 |
| tibbs | Forgive the interruption, but please note that I've tried for the better part of a year to get some security review of a package with suid binaries I was reviewing. I could never get any response. | 16:31 |
| adamw | is there some kind of official effort to develop a security policy? is spot running it? | 16:32 |
| Oxf13 | jlaska: step 1 should be getting help to define the set of methods which priv escalation can happen | 16:32 |
| jlaska | adamw: what's going on already? can you be more specific? | 16:32 |
| wwoods | tibbs: well that sucks. who've you been asking? | 16:32 |
| adamw | jlaska: see above | 16:32 |
| jlaska | adamw: ah gotcha ... | 16:32 |
| * spot is not running any sort of official effort at this time | 16:32 | |
| Oxf13 | tibbs: yeah, full fledged security audits aren't cheap, and likely won't be done in Fedora land :/ | 16:32 |
| tibbs | fedora-devel and fedora-security-list. | 16:32 |
| Oxf13 | I think all QA can reasonably do is identify the software that requires such an audit, and catch changes. | 16:33 |
| jlaska | possibly | 16:33 |
| wwoods | Oxf13: a semantic nit but that seems like it'd be part of the preamble to security policy - "this policy applies to any package which can elevate privileges. These packages can be found by ..." | 16:33 |
| adamw | i think the first step is simple then - determine if we're actually planning to _have_ a security policy | 16:33 |
| Viking-Ice | and what security bases should QA follow when doing such an audit? | 16:33 |
| jlaska | okay ... so, this is certainly something people have a lot of thoughts on, which is great | 16:34 |
| adamw | perhaps encourage it by pointing out that we can't do any meaningful security testing without one | 16:34 |
| Oxf13 | wwoods: ok, not sure how that contradicts anything I've said | 16:34 |
| wwoods | it doesn't, just trying to, uh, simplify the plan? | 16:34 |
| adamw | if we assume that a security policy is actually going to emerge at some point, the second step is the policy/process for security-sensitive-packages | 16:34 |
| adamw | after that, we can come up with test cases. | 16:34 |
| jlaska | okay ... let's start to wrap-up this topic | 16:35 |
| Oxf13 | Viking-Ice: honestly I think step1 is just identify the software which can elevate privileges. Auditing to come later by those who know how to audit. | 16:35 |
| adamw | (all imo of course) | 16:35 |
| adamw | i'd propose an official-from-the-qa-team mail to -devel-list summarizing this discussion | 16:35 |
| Oxf13 | jlaska: proposal: Work with various teams to identify the methods in which software can elevate privileges. | 16:35 |
| Oxf13 | jlaska: (continued): step 2 would be to work on tests to discover these methods used by packages, in order to identify software that needs auditing. | 16:36 |
| adamw | i.e. pointing out the importance of having a security policy, and the parallel necessity for a list/policy for security-sensitive packages, and go from there | 16:36 |
| Oxf13 | jlaska: so that when the security policy lands, we'll be ready with discoverability | 16:36 |
| Viking-Ice | adamw: both the -devel and security list | 16:37 |
| jlaska | is anyone in the meeting interested in representing QA to bring this discussion to -devel-list and -security-list ? | 16:37 |
| adamw | i would if you like | 16:38 |
| adamw | together with oxf13 representing releng i guess? | 16:38 |
| Oxf13 | I"m sure I'll participate | 16:38 |
| Oxf13 | I'm not signing up to lead anything else right now though (: | 16:38 |
| * adamw is not your guy for writing any actual tools to discover security-critical packages etc | 16:39 | |
| jlaska | now if this turns out to be a 5000 more involved than lets create a set of steps we can document and repeatably/reliably execute ... we can reconsider | 16:39 |
| jlaska | adamw: I don't want any tools at this point | 16:39 |
| adamw | but definitely your guy for over-long hectoring email discussions =) | 16:39 |
| Oxf13 | I think right now we need to focus on discovery | 16:39 |
| wwoods | I'll happily help with code to detect privlege escalation in packages | 16:40 |
| Oxf13 | that will lead to more data about what kind of tools we need | 16:40 |
| jlaska | alrighty, adamw if you'd like to start by putting some feelers out here ... that would be delicious | 16:40 |
| adamw | Oxf13: i agree that's a basic pre-requisite, along with the commitment to develop some kind of sensible policy | 16:40 |
| wwoods | I know kparal will want to put that in rpmguard | 16:40 |
| adamw | Oxf13: if there's not going to be a policy it's kind of wasted effort | 16:40 |
| wwoods | but I dunno if we're at that point yet | 16:40 |
| adamw | but let's leap that hurdle when we get to it. | 16:40 |
| Oxf13 | adamw: yeah, policy is important, but we can get from discovery to tools for discovering sensitive packages, long before we have a policy about what to /do/ with them. | 16:40 |
| jlaska | adamw: you want to tackle this week, or shall I leave it on for next week? | 16:40 |
| adamw | Oxf13: sure, it's just the commitment to there _being_ a policy that i'd like to see first, not the actual policy | 16:41 |
| adamw | jlaska: i can send something out this week for sure | 16:41 |
| * jlaska notes it may be a short week for US folks | 16:41 | |
| adamw | is anyone here subscribed to -security-list already? | 16:41 |
| adamw | i'm not, just want to know if there's been any discussion on this already | 16:41 |
| jlaska | #action adamw to initiate discussion w/ -devel-list and -security-list on creating a security policy that QA can plan around | 16:41 |
| jlaska | adamw: I'm not ... will subscribe now | 16:41 |
| jlaska | so ... let's at least see where this project would take us | 16:42 |
| adamw | i think with a clear policy and a list of sensitive packages it'd be relatively simply | 16:42 |
| adamw | simple* | 16:42 |
| adamw | 'check and make sure nothing from List A does any of the stuff in List B' | 16:42 |
| jlaska | requirements sure make writing tests easier! | 16:42 |
| adamw | which is good. i like simple. | 16:43 |
| jlaska | okay ... let's move on to the next topic | 16:43 |
| jlaska | thanks for the discussion/clarification on the security approach | 16:43 |
| jlaska | #topic Enhancing Release Criteria | 16:43 |
| jlaska | for this topic, I don't really want to discuss the details of the proposed criteria on IRC | 16:43 |
| jlaska | more just to recognize that a proposal is out there ... and perhaps some points that will be good for QA to help further define | 16:44 |
| jlaska | poelcat: were there any points I missed that you'd like feedback on? | 16:44 |
| jlaska | for the logs ... | 16:45 |
| jlaska | #info announcement - https://www.redhat.com/archives/fedora-test-list/2009-November/msg00926.html | 16:45 |
| poelcat | i think its all in the email | 16:45 |
| adamw | this is going to be pretty key to future releases so poelcat would love feedback | 16:46 |
| poelcat | also trying to set a better stage for more info that might come from the target audience discussion | 16:46 |
| poelcat | my hope was to have discussion on the mailing list | 16:47 |
| poelcat | until fudcon | 16:47 |
| poelcat | and then at fudcon hammer out the dents and formalize something we can use for Fedora 13 | 16:47 |
| poelcat | is that realisitc? | 16:47 |
| jlaska | I would think so ... but I guess it depends on the feedback that comes in | 16:48 |
| adamw | sounds good to me | 16:48 |
| Viking-Ice | This proposal sounds sane to me so I got nothing to suggest for improvement or add to the current :| | 16:48 |
| wwoods | For the record, I'd like to say that the Release Criteria were originally created just by writing down whatever unwritten common-sense tests and policies we already had, and maybe a couple "it'd be nice if.." ones | 16:48 |
| jlaska | sounds like the security policy! :) | 16:49 |
| wwoods | none of it was cast in stone and I'm really happy to see that it's finally getting some proper thought behind it | 16:49 |
| jlaska | wwoods: actually, I think what was there is the basis/foundation for what poelcat has created | 16:49 |
| wwoods | so thanks, poelcat | 16:49 |
| poelcat | wwoods: you're welcome | 16:50 |
| poelcat | you gave us a good start ;) | 16:50 |
| poelcat | :) | 16:50 |
| jlaska | wwoods: if there are any specific criteria from the previous page that you felt "I wish I we'd change it to ...", that'd be good feedback to have | 16:50 |
| poelcat | the ";)" was accidental | 16:50 |
| poelcat | that's all i've got | 16:51 |
| wwoods | yeah I don't have any specific suggestions - and I'm happy that the awkward MUST/SHOULD convention was dropped | 16:51 |
| wwoods | heh | 16:51 |
| jlaska | alright cool, so please take a moment to review poelcat's mail | 16:51 |
| adamw | yeah, that confused a lot of people. | 16:51 |
| jlaska | if you hate it ... feel free to reply to the list | 16:51 |
| jlaska | and of course, if you like it ... please do the same :) | 16:51 |
| Viking-Ice | Well if you hate it reply to the list with what you think might be better... | 16:52 |
| jlaska | Viking-Ice: right on! | 16:52 |
| jlaska | Okay, let's change gears to our regularly scheduled AutoQA update ... | 16:52 |
| jlaska | #topic AutoQA Update | 16:52 |
| jlaska | wwoods: kparal: who wants to go first? | 16:53 |
| kparal | wwoods is the one with the big changes | 16:53 |
| wwoods | heh | 16:53 |
| kparal | go on | 16:53 |
| wwoods | okay, so: I merged the autoqa git branch I'd been working on | 16:53 |
| wwoods | this branch brings in the new autoqa python library | 16:54 |
| wwoods | which has shared repoinfo code for the watcher scripts and utility functions/classes for tests | 16:54 |
| wwoods | and the new post-koji-build hook | 16:54 |
| wwoods | which is still fairly experimental, but we have it running a simple 'rpmlint' test on every new build that comes out of koji | 16:55 |
| wwoods | (I'd give a link here, but we don't yet have a public autotest instance, alas) | 16:55 |
| wwoods | AFAICT it's still working, though - it's run 275 tests since I turned on the cron job on.. thursday? | 16:55 |
| jlaska | wwoods: they seem to be still processing, sweet | 16:56 |
| wwoods | (note to anyone who reads the git logs: I keep writing 'rpmdiff' when I mean 'rpmlint', please ignore that) | 16:56 |
| wwoods | so that basically closes out the goals we had for the autotest 0.3 milestone | 16:56 |
| wwoods | errr, sorry: *autoqa* 0.3 | 16:56 |
| * adamw hands wwoods a coffee | 16:57 | |
| jlaska | heh, too many auto's :) | 16:57 |
| kparal | too many similar names :) | 16:57 |
| wwoods | there's a couple things we're planning to work on at FUDCon - primarily a hackfest on a solid depcheck test | 16:57 |
| wwoods | to keep us from ever having broken deps in the repos | 16:58 |
| wwoods | that will require a new post-bodhi-update hook | 16:58 |
| wwoods | so - yes, those things are on the roadmap, but first we're prepping stuff for FUDCon | 16:58 |
| wwoods | I think primarily we want to try to solidify the post-koji-build hook, | 16:58 |
| wwoods | think of some possible ways to make it easy for package maintainers to add post-build tests, | 16:59 |
| wwoods | and get rpmguard up and running | 16:59 |
| * jlaska wonders if kparal can remotely participate in the hackfest | 16:59 | |
| jlaska | the TZ's might not cooperate though | 17:00 |
| wwoods | I'd hope so, but.. yeah | 17:00 |
| kparal | I have to look at it | 17:00 |
| jlaska | perhaps a morning session | 17:00 |
| kparal | how about the local testing feature, wwoods? | 17:01 |
| wwoods | oh! yes! | 17:01 |
| wwoods | yeah - that's required for maintainers to be able to work on post-build tests | 17:01 |
| wwoods | do we have a trac ticket for that? I forget | 17:01 |
| kparal | I believe we have several, and a mailing-list thread :) | 17:02 |
| jlaska | I can't find the specific ticket for that right now, but it might be hiding | 17:02 |
| kparal | maybe this one: https://fedorahosted.org/autoqa/ticket/52 | 17:02 |
| jlaska | aha ... it's not yet bound to a milestone | 17:03 |
| wwoods | ah that's why I keep missing it. | 17:03 |
| jlaska | kparal: but that's the one | 17:03 |
| wwoods | we might think about a FUDCon milestone for stuff we need before that | 17:03 |
| kparal | ok, let's attach it to the milestone then | 17:03 |
| jlaska | either stuff to do before FUDCon ... or maybe things we can get help with @ FUDCon? | 17:04 |
| jlaska | wwoods: lots of updates ... anything else on your radar or at risk? | 17:05 |
| wwoods | jlaska: nothing springs to mind | 17:06 |
| jlaska | kparal: how about with you? | 17:07 |
| kparal | alright, when I was waiting for wwoods' big merge (52 commits ahead), I was trying to improve wiki documentation. So I created a new AutoQA front page, which should work as a guidepost - different kinds of user can choose interesting stuff for them and go to a link for details. | 17:07 |
| kparal | The previous content was moved to "AutoQA architecture" page. there's the post: https://fedorahosted.org/pipermail/autoqa-devel/2009-November/000023.html | 17:07 |
| kparal | but don't look at the front page much in detail, it's going to change soon. after my changes jlaska worked on an improved version: User:Jlaska/Draft so it's possible it will replace the current version soon | 17:08 |
| kparal | this week I plan to work on integration of rpmguard into autoqa, now when finally everything seems to be ready | 17:08 |
| kparal | that would be it I guess | 17:09 |
| jlaska | cool, I'm excited to see rpmguard in action | 17:10 |
| kparal | I hope we are going to see some :) | 17:10 |
| jlaska | wwoods: kparal: thanks for the updates | 17:11 |
| wwoods | we'll need to figure out what to do with the output (mail it to package owners/autoqa-results?) and what to do when there's a change that should block the package | 17:11 |
| wwoods | but that can wait until after the test is working | 17:11 |
| jlaska | okay ... let's move to open discussion | 17:11 |
| jlaska | #topic Open discussion - <your topic here> | 17:12 |
| Oxf13 | FUDCON! | 17:12 |
| jlaska | anything not covered in the meeting today that someone would like to discuss? | 17:12 |
| Viking-Ice | Does any one know what the targeted audience is with the dvd img and is? | 17:12 |
| Oxf13 | I think we need to get qa/releng up on the stage and walk people through the future of Fedora development | 17:12 |
| Viking-Ice | that documented somewhere? | 17:12 |
| jlaska | #topic Open discussion - FUDCon | 17:13 |
| Oxf13 | Outlining no frozen rawhide, autoqa, autosigning, new milestones, how all these puzzle pieces are supposed to fit together | 17:13 |
| Oxf13 | maybe even throw in the future SCM and message bus for flavor | 17:13 |
| wwoods | mmm, futureflavor | 17:13 |
| jlaska | Viking-Ice: I'll jump to your topic next ... | 17:13 |
| adamw | will there be jetpacks? | 17:13 |
| adamw | oh, please let there be jetpacks | 17:13 |
| jwb | Oxf13, is that going to be recorded at all? | 17:14 |
| Oxf13 | jwb: hopefully we can get this one recorded | 17:14 |
| jwb | would be nice. i'd like to review since i won't be there | 17:14 |
| Oxf13 | I'll take the lead on this | 17:14 |
| jlaska | #info Oxf13 proposed a FUDCon discussion on the future of FEdora development process including NFR, AutoQA, autosigning, milestones and jet packs | 17:15 |
| adamw | yaaaay | 17:15 |
| jlaska | #topic Open discussion - dvd img target audience | 17:15 |
| kparal | what exactly is the question? | 17:16 |
| Viking-Ice | Who's the dvd img target audience | 17:16 |
| Viking-Ice | sysadmins end users ? | 17:16 |
| jlaska | according to the install guide ... http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch-new-users.html#sn-which-files | 17:16 |
| jlaska | "If you have plenty of time, a fast Internet connection, and wish a broader choice of software on the install media, download the full DVD version" | 17:16 |
| wwoods | so where's the link to that fedora-advisory-board discussion | 17:17 |
| kparal | well if I have slow internet or no internet, I would burn Fedora DVD at my friends/buy it and I would have much more programs available | 17:17 |
| jlaska | wwoods: the target audience discussion? | 17:18 |
| wwoods | ah: http://lwn.net/Articles/358865/ | 17:18 |
| kparal | they are not mentioning DVD there, just generally | 17:18 |
| Oxf13 | at this point, the DVD has multiple target audiences | 17:18 |
| wwoods | so there's that, but yeah, that doesn't specifically talk about the DVD | 17:18 |
| wwoods | yeah. the DVD is problematic. | 17:19 |
| Oxf13 | gnome desktop users, KDE desktop users, developers, and server admins | 17:19 |
| jlaska | Viking-Ice: where were you thinking of going with this? Or what were you wanting to hilight? | 17:19 |
| adamw | i don't think we have a story for the default dvd install | 17:19 |
| Oxf13 | default DVD install is fairly similiar to the Desktop live image | 17:20 |
| wwoods | the stories for the various spins / Live images is easier, since they're (theoretically) targeted | 17:20 |
| Viking-Ice | More or less to establish if would be the recommended img for workstation/server install and the default pkg install set is targeted that way.. | 17:20 |
| Viking-Ice | but not to the home end user.. | 17:20 |
| * poelcat wonders if we could eliminate the DVD and CD and just have the LiveCD | 17:20 | |
| wwoods | the default pkg install set for the DVD is roughly the same as the Desktop LiveCD | 17:20 |
| poelcat | just brainstorming... no idea what the consequences would be | 17:21 |
| * Viking-Ice wonders if we cant eliminate optical media support altogether... | 17:21 | |
| wwoods | definitely can't eliminate optical media. not yet, anyway. | 17:22 |
| kparal | well I know some people that are really burning linux dvds just because they want to use linux offline | 17:22 |
| Oxf13 | poelcat: probably not until we solve upgrade from Live images | 17:22 |
| jlaska | this is an interesting discussion, but is this in the right venue? | 17:22 |
| Viking-Ice | usb key's ftw. | 17:22 |
| Oxf13 | yeah, I really don't think this is QAs problem | 17:22 |
| poelcat | Oxf13: it could reduce their problems :) | 17:22 |
| jlaska | where is the appropriate place to raise concerns here? | 17:22 |
| jlaska | I think this goes back to what adamw has said ... that we'd fully benefit from added clarity here | 17:23 |
| Oxf13 | well, Fedora Board has been beating the target audience drum, so probably there | 17:23 |
| poelcat | jlaska: post to f-a-b | 17:23 |
| jlaska | poelcat: Oxf13: gotcha | 17:23 |
| jlaska | Viking-Ice: I guess there we have it | 17:24 |
| jlaska | okay ... if no other topics, let's call it a meeting | 17:25 |
| jlaska | #topic Open discussion | 17:25 |
| * jlaska sets the timer @ 60 seconds | 17:25 | |
| jlaska | okay folks ... thanks for your time | 17:26 |
| jlaska | #endmeeting | 17:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!