On Wednesday, 23 September 2015 9:05 AM, Fabio Olive Leite wrote:
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.
Thank you so much for the summary & follow-up.
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?
Well, I think we already have a closed security(a)fp.o list and the FST
in place which is good to receive information about the embargo issues.
What we really need is a process/policy to push updates in a timely order.
Fedora package maintainers don't always treat security issues withthe due urgency,
which is why majority of the FST efforts & energy go into
prodding them for updates.
I wonder how other communities folks handle it. Don't they also have
maintainers who are least bothered about fixing security issues in their
@Florian: how does it work in Debian?
The Fedora Security Team must organize the right resources to make
happen as well.
Maybe for Fedora we could go with a few Proven Packagers?
Yep, I think many of us FST folks are proven packagers; But with a
different day jobs, which means lesser time for FST tasks. Maybe a couple
of dedicated FST folks would be good?
Maybe what we need to do is come up with a policy stating how we
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.
True, +1. A published policy document would be helpful.
Would we need some kind of "security-updates" repository
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
I'm not sure about it, a separate repository sounds iffy.
-P J P