[Security_sig] 4/28 Conf. call minutes
chrisw at osdl.org
Thu Apr 28 09:52:48 PDT 2005
Matt Anderson (HP)
Chris Wright (OSDL)
Joseph Cihula (Intel)
Mary Edie Meredith (OSDL)
Ed Reed (Novell)
- CGL security spec ('live edit' stage)
- DCL security spec
- any other business
Chris: ping DTL
Ed: followup call w/ Mary, continue to fill out details on DCL doc
Joe/Matt: CGL, live edit
Chris: Live edit stage of CGL security, Matt can be there a bit late,
Joe will be there.
Joe: Just putting finishing touches. Formatting issues were fixed.
Chris: DCL work...
Ed: Not had lot of time on it, but begun morping CGL doc to DCL doc.
Need some context details. CGL it's a section, is DCL same or a
Mary: Hasn't been decided. Security section that is it's own document.
Ed: Can massage the intro work either way. The DCL requirements...
Mary: It's not DCL language. We use capabilities. We try not to
dictate the solution.
Joe: The CGL requirements are written as requirements, but the
registration process only requires that you show which requirements you
provide for and those which you don't. Same kind of voluntary option.
Mary: We don't
Ed: OK, so wherever I'd say requirement, replace with capability.
Mary: We try to produce a maturity level for each capability.
Ed: Any more thoughts on the overview/table of contents?
Mary: Hadn't looked at it since you first posted it. Looked good.
Ed: Would like to figure out where I've been too detailed.
Mary: When we get down to a capability. The more detail we have to
describe it the better.
Ed: Password storage, secret stores. Gnome and KDE provide wallets,
server side needs similar to provide access to encrypted store.
Joe: Are you maintaining a mapping between capabilities to usage model?
If so, I think all detail is relevant.
Mary: Use cases often become our final goal. It's the best way to help
developers see the need for a feature.
Ed: Broad class of problem is key storage for SSL server.
Mary: That sounds like a capability. And more detail helps understand
gaps and assign maturity levels.
Chris: Top down with broad brush strokes for starters is fine. Can
always farm off subsections or fill in details as we go.
Mary: As much detail as you have is useful, and it doesn't matter if
it's lopsided per section.
Ed: OK, that's helpful. We need to be able to appeal to each niche's
perspective to give validity to the document.
Mary: It's really helpful for developers to have detailed use cases to
help development efforts.
Mary: Goal is to have public draft by S.F. LWE. Goals, milestones...?
I'd like to give status to Paris f2f.
Ed: Best way to manage me is to setup followup call on Monday/Tuesday
and work out some milestones for this.
Mary: DTL doing this?
Chris: Haven't heard from DTL in a while, I'll ping them.
Mary: I know the documentation stage (from the NFSv4 experience) is
really lacking for security (or functional) auditing and testing. Is
that an area the SIG will go in the future.
Chris: Documentation is lacking across the board in open source
projects. I don't think we'll change that readily. We can make better
impact simply working on projects.
Mary: You think there's plenty of work in that area?
Chris: Yes, there's no shortage.
Ed: Put it this way, the bar keeps raising for customer expectations.
And enterprise features will become commoditised as open source
implementations develop and mature. E.g. where's the patch management
tools that give you information re: what's installed vs. which CVE
problems it solves (or leaves you vulnerable to).
Mary: NFSv4 testing, one more call left to discuss details and finalize
the testing plan. Calls have been abnormally quiet which has Bryce and
I a bit worried. But we have at least one person here interested in
doing some of the pen testing and he's working with Chris on that.
Chris: Plan to share that testing plan with us?
Mary: Yes I'll publish the spreadsheet with items and priorties of areas
that need security testing.
More information about the security_sig