[Secure-testing-team] Notes from Debconf 9 security BoF: July 29, 2009

[Micah Anderson]

During Debconf 9 there was an informal security BOF organized on the
29th. There were a number of people in attendance that have, currently
are, or are interested in working on security issues in Debian. 

This discussion was not recorded, however what follows is my attempt
to take notes during this discussion. Please be aware that these notes
are not a verbatim account, but rather have various holes, gaps and
other missing things. The noise level fluctuated during the
discussion, resulting in periods where I could not hear very well,
other periods I was not quick enough to type, or I was talking, or
whatever. So please keep this in mind when reviewing these. Ask for
clarifications on the list, and I am sure any of the attendees will be
able to recall more specifics when necessary. Please also clarify
anything that is incorrect below if I have accidentally misrepresented
what you said. 

At some points I tried to note who was speaking, but that was not
uniformly applied.

The agenda that was generated on the list ahead of time was:

 * Getting more members for testing-security
 * Integrating security tracker information into the PTS
 * Security workflow
 * Reminding developers to support their (old)stable packages
 * Integrating security information into the DEHS
 * How to support the transition, if we are skipping a release
 * Debian as a CNA
 * Miscellaneous

The TODO items that came out of this were:

 * nico will contact those who volunteered for security work to see if they would start with t-s
 * generating an email to d-d-a should be done
 * nico will make sure that fw is connected with raphael and stefano for PTS integration
 * luciano will work on improving the existing documentation, clarifying workflow
 * raphael, jmm and lucus will rebuild the archive with hardening options enabled
 * all developers need to support their packages through old-stable
 * once the tracker is integrated with the PTS, raphael can integrate into DEHS
 * luk will work on finding resources to handle proper security support for upcoming transition

Getting more members for testing-security
-----------------------------------------

Getting more members for testing-security, how do we get new people
in? We have becoming pretty good in maintaing the tracker recently but
we really lack of people who also fix bugs and write patches We need
more volunteers, because t-s is currently stalled, need fresh ideas
for how to get new people in.

In response for last call for stable sec. there were more volunteers
than were actually taken, maybe these could be contacted for t-s?

This was the initial intention that these people would start working
on t-s, but most did not. But they maybe were not told this, it was
not clear to these people.

needed: preparing testing security updates, rebuilding updates from
unstable, and releasing. also needing to look at testing migration,
asking the release team to hint stuff, nmu'ing in unstable so things
get fixed faster. we need dd's for this because need to have upload
rights.

TODO: write another note to d-d-a asking for more people, nico will
find a list of those people who volunteered.

determining what needs to migrate, because it is not clear what things
need to migrate. if a security upgrade affects a library transition,
then a hint can't be done. sometimes a buildd maintainer needs to be
pushed to get that fixed. could this be semi-automatically? maybe
could be better support in the tracker for why things have not
migrated yet. need to go to several web pages to figure out why things
have not migrated, should be incorporated into the tracker somehow?

if we are freezing in december, then we need to have t-s support
working again before then.

Integrating security tracker information in the PTS, DEHS
----------------------------------------------------------

The information needs to be exposed more... all the maintainers know
about the security issues when they are actively contacted by
somebody, it should be more proactive from the maintainers. Some
possible ways to make sure the maintainers are a bit more aware of the
issues could be integration with the PTS, generating a per maintainer
report (like the DEHS: http://dehs.alioth.debian.org/)

raphael: it would be easier to export that information from the t-s
from the sqllite database that is generated from the raw CVE text.

jmm: pts is good to get an overview of a package... check the status
of a package, you need to take into account the things in the past of
a package... past security issues are useful to include.

sf: number of open issues in stable, testing, unstable, and a link
into the tracker with the todo issues.

rap: we can talk to stefano, linking to only issues that need to be
done

stefano: portal for the package maint. you go there and see if your package is
in shape or not, problems that need to be fixed, need to see security issues
that you need to work on that need to be fixed, i would like to see there.

rhonda: especially since there is a bug count there already

jmm: might be already fixed in unstable, but the fix in stable is
pending. we have different views in the tracker, like the lenny view
to see all the open lenny issues, or unstable/etch different states
recorded for different issues.

stefano: the PTS is typically a single view from the most recent
version of a package, but that is not a problem. if all the
information is there... only if there is an outstanding issue that
needs to be done

jmm: done or open tags, or not affected... resolutions are there

stefano: sqllite is fine as long as there is no lock, or else i can
copy it from some machine and use a local verison

raph. should be possible to extract the information from the sqllite
db, to find any security issues pending.

jmm: dont know specific impl. details, because this is done by florian
(fw). python library does all the parsing to get all the different
states. this would need to be done by fw

stefano: would prefer a dump in a textual format or whatever... its
more like an interface so if some schema is changed in sql lite, an
index per package or whatever.

micah: in addition to any open issues that must be addressed, it would
be good to have always a link back to the package in the tracker that
lists the history for that particular package

stefano: one possible link is a todo item, you go there and you know
you have to do something. another type of link is on the right less
visible, but only if it has an external source of information. this
would be a link to go to the tracker page.

TODO: nico will make sure fw will see this.

Security workflow
-----------------

luciano: The idea is to make a workflow from the CVE data file, all
the way up to the DSA. to understand each phase of a bug all the way
up to the end... would be nice to discuss it together on the
list. most of the basic information is on the advisory wiki, but it is
too spread out. for example, not sure if everyone understands how a
ticket in RT is graded.

jmm: the currently published process is written for the security team,
an internal notes taking thing, rather than meant for a general
user. it would make sense to make this a more accessible document.

l: that way we can shine some light on some of the workflows, which
may bring in some more volunteers

nico: the split between the stable and testing security documentation
is split, and should be all on one site.

jmm: commit to svn somewhere?

l: what format should it be done?

jmm: verbose document for the security tracker is written in plain
text, it should probably best be put into WML for the security
site. need to put this information on the website (not the wiki). add
an additional document that can be linked to the dev. reference.

TODO: luciano will start in the wiki, and ask questions to the list
about updating the documentation to be more current.

Enabling hardening options in squeeze
-------------------------------------

How to push for enabling more hardening compile options in squeeze?

sf: kees said that ubuntu enabled these options in the compiler. i
talked with doko earlier this week, and was talkng about enabling it
in dpkg-buildpackage, so the environment variables have to be sorted
out. there is the problem that if it is just enabled, architecture
maintainers will cry that some performance tests weren't done

jmm: the current system that was enabled shortly after the lenny
release, you can set dpkg-buildpackage flags unless you specifically
override them, i dont think that they can be set on per-arch basis. if
there are less fully developed tool chains such as arm, we could just
not support/enable it on these architectures.

sf: arm and mips already ignore these options because they aren't
implemented. doko said that PIE brings quite a perf. loss so it
shouldn't be enabled.

jmm: the fstack protector flag which has been used by all distros
except debian and fortified source, which only affect at compile time,
and have a negligable affect, and are quite good at catching
things... compared to PIE and others that are much harder on
resources, and are only catching less likely things. I dont think that
PIE, some additional page table attributes... these things dont make
so much sense for a general application.

jmm: someone needs to run benchmarks on both x86 and amd64, with a
real-time workload, playing a game, music, not artificial
benchmarks. its easy to recompile stuff, there is a package in the
archive, when installed symlinks the tool chain in the compiler to set
these options by default, so it is not that difficult to rebuild the
applications and the libs that are linked against them and test
them. something an arbitrary user could do. this would be feasible for
upcoming release (fstack protection and fortified source). need to get
a rough consensus about the potential slowdowns.

raph; there were some concerns about build failures. we could ask
lucas to rebuild the whole archive with the wrapper to enable.

jmm: only really obscure things will be found, because other distros
have enabled this a long time ago, so only things that are left are
odd things that are probably broken anyways, but dont think that there
would be more than 20-30 FTBS by my gut feeling.

sf; would be easier to push for this by the time we make a mail to
d-d-a that this has already been tried, if raph. would talk to lucas.

jmm: someone needs to run the benchmarks, would probably be a day of
work to get it done if we dont have concrete numbers, many people
would object to it.

sf: if I have tme I would, but I cannot commit to it

jmm: this is something that could easily be done by a regular user.

micah: could build the packages, and then announce to d-d-a to ask
people to point their sources.list to it and install the packages to 
do the testing

raph: the build is on a non-internet accessible host, but we can push
the build packages to a debian host so packages could be pulled and
installed 

general agreement that this should be a release goal, once we have some
testing and benchmarks. 

jmm: there is a package that does all the wrapping, can explain it to
him. will talk to lucas.

raph: it would be better to start the rebuild today. because we need
to rebuild the archive once to check for failures, and then rebuild it
with the current wrapper. it takes some time to rebuild it so...

raphael checked with lucas about rebuilding the archive and he is ok
with the rebuild so that is not a problem. but we need to provide him
with a setup/instructions to follow before the end of tomorrow evening
because then he is going to leave on vacation for over a month.

(note: maintainers can always override this)

TODO: raphael and jmm will work with lucas to begin the process of
rebuilding the entire archive with these flags set, and then once we
have packages available, we can ask for benchmarking info from
developers. 

Reminding developers to support their (old)stable packages
----------------------------------------------------------

We had a discussion on how to make it clear again that (old)stable
needs to be supported by developers. backporting is hard or there are
other issues with the code, but every developer should be able to help
testing their packages on (old)stable. It happens too often that we
have to test some random services we've never used and then we might
miss a crucial testing scenario. Maybe something should be added to
the devref and prepare a mail to d-d-a@

we can remind people to act appropriately, but we cannot force them.

jmm: filing RC bugs against packages that aren't maintained
appropriately according to these rules, such as xpdf... then when some
fresh NM that applied to make that package we made it clear to him
that he needed to support it all the way through. the problem isn't
the new maintainers, its the older people who cause the problems.

luciano: when you close a bug in unstable, the bug is 'closed', so the
problem is related to the view in the BTS.

Integrating security information into the DEHS
----------------------------------------------

jmm: there are some nag mails about RC bugs, it might be worth sending
a weekly mail if you have an open security bug, everyone has an open
issue gets a mail, please get in touch with us, to get it fixed.

nico: this was discussed in essen, but something was missing (*looks*)

raph: wanted to mention that... once we start exporting the info for
the PTS we can use the same info in the DPPO by mail. 

How to provide security support during the transition, if we are
skipping a release
----------------------------------------------------------------

The one before needs to overlap

luk: the lenny release will be probably followed soon by the sqeeze
release, it is probably best to skip the lenny release to directly go
to squeeze, but to avoid confusion from users.

jmm: there was some miscommunication to the people who wrote the press
release I think because ... (lost due to noise)

luk: we should make sure that both things are possible. but for
security support the most important is to skip lenny

jmm: If there is a need for extended security support, this needs to be run
by an external entity, either a DD who is employed by a company who is
donating work, or collecting resources for it. otherwise it would not
be feasible to do this with the current state of volunteers, the
amount of work increases a lot, backports get too complicated, testing
gets more complicated, especially with more complicated packages, like
the kernel you will be in a pile of trouble 

skipping doesn't need to be achieved, to have a direct upgrade
that involves anything with etch with whatever is etch+1, its fine to
have to have a release schedule... there is no need to have that kind
of skip when there isn't a direct upgrade path. what we need to
achieve: that there is an overlapping time frame, if we are providing
an extended time frame then the etch security support needs to be
prolonged by a year. if it takes 3-4 months after the freeze, that
means that the etch release is out of maint. for 2 months, if you add
another year to it then the institutions have a chance to upgrade,
otherwise it is not feasible with the current volunteers. 

sf: if we want to have support from lenny to squeeze+1, then lenny
support would have to be longer, maybe an additional 2 years for this
support which makes this much more difficult from a security stand
point, its much easier to have a big overlap instead.

luk: i will see if i can find resources to do proper security
support. i will try to keep in touch about that, and about the status
of finding an entity to help with sec. support.

jmm: not a fan of shpping out a big release schedule to accommodate
the needs of canonical, because they are profiting from this, and
debian is ending up doing the bulk of the work (and does not profit)
Because Canonical will have an immense benefit from this, but we are
being asked to do quite a lot of work, which we cannot do on our own,
so if they want to do that, then we need a special exemption so
provide us with some resources (they have one DD who is doing security
work, kees... if he could be allocated to work on this that would
help).

luk: colin watson was already suggesting something like this

jmm: it would be too difficult to find someone new to do this work
especially because of the training to get up to speed etc. the
practical approach is that because canonical is profiting from the
whole thing, then they should provide the resources for it.

luk: if it doesn't work for us, then we wont do it, so if they dont
make sure that it works for us, we wont do it.

jmm: did canonical come to debian to align the release dates?

luk: shuttleworth did

Debian as a CNA
---------------

Debian as a CNA, while we can assign CVE ids the current workflow is
far from perfect, we have large delays sometimes getting CVE ids and I
think binding this to one person is a rather bad idea.

Joey is going to block of CVE ids, on klecker so that they can be
allocated. He was until now handing out the issues, but it will now be
a text file in klecker that can be used.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090730/e590a4c2/attachment.pgp>