logo_kerberos.gif

Release Meeting Minutes/2008-03-31

From K5Wiki
< Release Meeting Minutes
Revision as of 16:38, 10 January 2011 by TomYu (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Minutes of weekly release meeting for 2008-03-31:


Sam: Last meeting for me. Next week Kerberos Consortium. Might be present on the 14th but not running meeting.

Tom: Not sure available to call in next week.

Sam: Board meeting overlaps with this call so no call.

Sam: Ken working on coding practices and auditing. Want to discuss auditing with board. Code review cost prohibitive. Looking at static analysis tools. Looking at Coverity and Solaris Lint.

Sam: Want integrated into processes, periodic runs, fix problems identified. Project management: process for getting to this. Technical: handling false positives. Adopt idioms that reduce false positives. Not a total solution.

Ken: Confused about the difference between while(1) and for(;;). Thinks while(1) can exit through the bottom of the loop.

Sam: Can't make Solaris Lint and gcc happy because they warn about different things. Platform specific issues. How do we want to handle this?

Will: Ken, did you look at the gcc compiler warnings?

Sam: Looked at those too but Solaris Lint, gcc and Coverity all find different problems so more tools does produce increased coverage. More tools also produce more false positives.

Kevin: Pick 2 tools that provide the best coverage?

Ken: Not reviewed all tools. Currently only looked at Coverity and Solaris Lint in depth.

Will: Under the impression that some version of our lint has security analysis options that might help you. Will look into it. Might be internal only though.

Ken: Using the lint that comes with the compiler (Sun Studio 12). Also lint binary in Solaris release but that's the UCB one.

Will: Will look at tools.

Ken: Are you interested in the bugs we've found in lint? (false positives, etc)

Will: If they can be batched up then we would find them useful.

Sam: We will report them through the normal channels and also batch them up for you.

Sam: How do we want to build these tools into our build system.

Ken: Coverity side looks fairly easy to automate. Can track bugs from one run to the next. Can mark false positives to be ignored. Runs as part of the build system.

Ken: Lint is a little more difficult because every compile needs to be modified to include lint options. Pulling all the data from each files is a little tricky. make lint target using the same files list as make depend.

Sam: make rule that runs our normal build but changes the value of cc_link to include lint options.

Ken: Would need to special case object files. Wouldn't be any easier than adding additional targets.

Sam: Makefiles should only have one list of source files for each target. Should fix at the same time.

Sam: What about false positives on lint?

Ken: Has a mechanism using comments. Haven't verified it works. Suppressing warnings in macros harder because comments get stripped before macro expansion.

Tom: Splint annotations were too much work. Need to make sure we make fewer modifications for lint.

Ken: Need to look more at how to do suppressions to be sure we can handle this correctly.

Will: Might have annotations facility. Will investigate.

Sam: How do we get to a proposal?

Tom: Which tools do we use?

Sam: Should commit to using Coverity. Use open source version.

Ken: Issue that people can sniff the analysis over the network if we use the open source version.

Kevin: Can bittorrent Coverity anyway so a hacker can just use a stolen copy and get the analysis themselves.

Ken: Might be helpful to pick a directory and try to make them lint-clean as a demo.

Sam: Get me a proposal by the 14th on how to do that.

Will: Fundamental questions: Which tools and handling output (protected?). Process of how tools are going to be used (on commit, nightly, etc)?

Sam: Want to see all that in Ken's report.

Sam: Do we have any other status updates?

Will: Updated the wiki. Added some documentation.

Will: Saw mention of a common credentials cache. What is meant by that?

Sam: Willis and Paul Armstrong believe we should have a common credential cache. Ball is in their court to elaborate on why and what they wanted. They have a slot to present at the board meeting.

Tom: Had something to do with a cluster environment or something like that. Computing nodes that need to all talk to the same credentials cache.