10:35 p.m.
Hello everyone,
On the last FST meeting I took the action item of summarizing to the
list the discussion about how we can handle embargoes and private
information about vulnerabilities being a 100% open project and only
having public build infrastructure. This is not simply an extract from
the logs, as it has some commentary, opinions, suggestions, and likely
also some mistakes, as it took me a few days to be able to come back to
this action item.
The Fedora Project, as an independent entity, has a Security Team of
its own, but the reality is that the majority of the work is reactive,
getting maintainers to update packages after vulnerabilities become
public, or handled by Red Hat Product Security engineers when packages
span both Fedora and RHEL. There is nothing wrong with Red Hat
engineers maintaining Fedora packages, but there should not be a
dependence on Red Hat people to perform the work.
The main question brought up in the meeting was: how can Fedora deal
with embargoed vulnerabilities and prepare updates in a timely fashion
if all of its infrastructure is public and open? How can Fedora have a
private team of trusted individuals to receive embargoed notifications
and prepare an update to be available after unembargo?
Clearly it must be possible to do so, since other community projects
such as Debian, Gentoo and the BSDs have also earned the trust of
companies and organizations and do get embargoed notifications of
vulnerabilities. The Fedora Security Team must organize the right
resources to make this happen as well.
Florian Weimer noted that it wasn't magical for Debian, they just set
up with the team, the processes and policies, hoping for the best. In
Debian the folks in the Security team are all Debian Developers, so
there is some level of trust. Maybe for Fedora we could go with a few
Proven Packagers?
Maybe what we need to do is come up with a policy stating how we deal
with embargoed information, form a team with 3-4 trusted individuals
that can receive embargoed information and subscribe them to the
security-private mailing list, and then try to win the trust of other
distros and vendors that we will do the right thing.
There was also the discussion of how much can Fedora benefit from
embargoed notifications. The answer seems to be "not much", but one
possibility is that, upon receiving the notification to the private
list, one of the members of the list gets in touch with the affected
package maintainer and helps them prepare a patched package that would
be submitted to the build system immediately after the embargo is
lifted. This would at least buy us several hours, and we may be able
to have updates out on the same day as the vulnerabilities go public.
On a later conversation with Sparks, we were also considering how
quickly we can push a security update through our mirrors system. It
wouldn't be much use to rush a security fix out to the master
repositories and have it take days to reach all the mirrors.
Would we need some kind of "security-updates" repository that would
only carry security fixes while they are fresh and not mirrored
everywhere else? Maybe a small centralized repository would not need
to handle too much load, if it only contains security fixes for a small
period of time while they are still being copied to the other mirrors.
Let's discuss this on the list and see what are the next actions on
this effort.
Cheers!
--
Fábio Olivé --- Seja hoje melhor do que você foi ontem.
PGP: F1C1 1876 3922 1906 6631 0C31 92A5 9276 250D 8380