Joey Hess wrote:
> Ok, since nobody from the security team replied to my earlier question,
I've not spoken with Martin Schultze in private mail. He indicated he
(and thus presumably, the rest of the security team) wasn't aware of these
security fixes. That, of course, is a pretty good reason why the
security team hasn't announced them.
What I'm wondering is if there is some prodedure we can put in place to
facilitate the security team in making announcements of security fixes.
As I understand things from my (very) brief stint on the security team,
its jobs are:
1. To dig up security holes (from bugtraq, private security lists not
open to the public, find them themselves, etc), and make maintainers
aware of them.
2. If a maintainer does not/cannot respond quickly enough, to fix the
security holes.
3. To ensure that security fixes are available for all platforms,
including those the maintainer does not have easy access to.
4. To backport the fixes into stable as necessary.
4. To post security announcements in a standard, consistent format, that
explains the hole, points to fixed files, and is PGP signed so
outsiders can trust the annoucement.
It seems to me that the list of fixes I posted shows that in this
particular case, 1 and 2 were not a problem. Lots of debian folks read
bugtraq, and the maintainers found out about the holes (although perhaps the
security team, in some cases, did not!). The maintainers fixed the holes.
I don't know about 3. 4 seemed to be at least partly dealt with by the
maintainers of the changelog entires I posted, and wasn't even necessary
for all of them.
The main problem appears to be in 5. I wonder then, if we can do something
to ease the security team's job in step 5. For example, if there was a
published template a maintainer could fill in the blanks in about a
security hole they have just fixed in their package, and then send it on
to the security team to let them take care of step 3, do final touchups,
sign it, and announce it, I think this might lessen the burden on the
security team. I have attached a rought draft of such a template to this
message, based on the format of existing debian security advisories.
If these proto-announcements were filed in a public place[1] we could also
more easily keep up with the progress of the security team, and tell if
they were getting swamped and needed more help.
--
see shy jo
[1] As most of them can be; once a maintainer has fixed a security hole,
noting it in the changelog, and generating a diff, and uploads and
(auto-)announces the package, the fact of the security hole is already
pretty public.
# Enter the name of your package here:
Package:
# Enter the type of vulnerability here, breifly. Common types include:
# [local exploit, remote exploit, denial of service, symlink attack]
Vulnerability type:
# Does it effect only Debian? [yes no]
Debian-specific:
# Has the exploit been accomplished in real-world testing; does a
# program to exploit it exist? [yes no]
Known exploits:
# Now use one paragraph to explian the vulnerability. Be sure to mention
# what version of the package is vulnerable, and which version(s) of Debian
# it was distributed in.
The version of **** as distributed in Debian GNU/Linux 2.x (aka ****)
# frobnigated the baz incorrectly; mass havoc may result.
This has been fixed in version ****, and we recommend that you
upgrade immediatly.
