Hi,
Pardon for the late reply, I didn't want to respond until I study your
update process and it got sidetracked somehow.
Post by Michael StoneLubomir,
First, thanks very much for contacting us.
Post by Lubomir KundrakI 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. :)
Post by Lubomir KundrakAs 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 devel at lists.laptop.org or to security at lists.laptop.org
depending on how broadly you want to publish the information within the
OLPC community. Private notifications can be sent to
security-notifications at rt.laptop.org, which will be our
controlled-distribution mail queue for security notifications.
Post by Lubomir KundrakI'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
http://wiki.laptop.org/go/Unscheduled_software_release_process
Post by Lubomir KundrakDo 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
Post by Michael StonePost by Lubomir KundrakWhat 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.)
--
Lubomir Kundrak (Red Hat Security Response Team)