Hi, Pardon for the late reply, I didn't want to respond until I study your update process and it got sidetracked somehow.
On Tue, 2008-02-26 at 16:59 -0500, Michael Stone wrote: > Lubomir, > > First, thanks very much for contacting us. > > > I am wondering how Fedora security response team can be helpful to the > > OLPC project software: We currently monitor various sources for security > > issues that affect software shipped in Fedora distribution, notify the > > developers about relevant flaws that affect us via bugzilla and track > > progress on fixing. > > We can certainly use any help that you can offer. :) > > > As Fedora project developers and infrastructure are involved in > > development and packaging of OLPC software, we can add OLPC to list of > > software we track security issues for. > > This would be wonderful - please do so. Public notifications could be > directed to [EMAIL PROTECTED] or to [email protected] > depending on how broadly you want to publish the information within the > OLPC community. Private notifications can be sent to > [EMAIL PROTECTED], which will be our > controlled-distribution mail queue for security notifications. > > > I'm specifically interested in how are security issues treated currently > > -- how do you deploy updates and when. > > To date, all security updates have been provided as a part of our > regularly scheduled releases. However, necessity has forced us to > develop an 'unscheduled software release process' in order to control > the risks incurred by changing our software to support deployments (in > Uruguay, Mongolia, and now, Peru) or to fix crucial late-breaking bugs: > > http://wiki.laptop.org/go/Unscheduled_software_release_process > > > Do you fix only issues of some specific severity or all of them? > > As the 'Proposal Criteria' section suggests, we're most interested in > security issues that threaten theft-deterrence or child safety; or that > threaten the educational utility of large numbers of laptops. Actually we can hardly deal with physical safety. We deal with software packages and flaws with them. While monitoring many sources for information about flaws, triage them and get developers fix those. For example in Fedora we try to fix all vulnerabilities, even ones with very low impact. We keep status of flaws in packages [1] and inform the respective maintainers via Bug tracking system when their action to roll packages and do an update is needed. [1] For fedora 8 it looks like this: http://cvs.fedora.redhat.com/viewcvs/fedora-security/audit/f8?root=fedora&view=markup > > What kind of input from SRT would be interesting to you? > > I'm not terribly familiar with what kind of output the SRT usually > produces. Could you direct me to some examples of your work so I can > give you a better answer? See above statement. In order for me to understand how do you do the updates; The OLPC software distribution contains a gecko based web browser which fairly often contains flaws exploitable by visiting a malicious web page and is considered critical by Red Hat. Do you do unscheduled updates for those? Or do you hold them until next scheduled update period? When you do a scheduled software update, do you care about known security flaws to be fixed? If yes, what can SRT do is maintain a file similar to [1] for packages that are distributed on laptops and file bugs for respective maintainers so it would be easy to see which outstanding security flaws of various impact are present at any time, so that it can be easily checked if something important is not forgotten for the release. It would take little extra work for SRT, as our tools and processes already do extensively take advantage of various pieces of Fedora infrastructure, which is also used by OLPC (koji buildsystem, CVS, etc.) > Michael -- Lubomir Kundrak (Red Hat Security Response Team) _______________________________________________ Security mailing list [email protected] http://lists.laptop.org/listinfo/security
