What follows are notes of the second testing-security meeting held at Oldenburg September 23, 2005 with joeyh, micah, jmm, lamont, aba and christoph in attendance:
. Solidifying DTSA criteria
We had some discussions about solidifying DTSA criteria. Some
questions that we came up with helped us determine some more
solid criteria:
1. Do we want to do DTSAs for packages not in testing because of
missing arch builds?
The current situation is that as soon as you tell it
to start syncing the package as the builds for the
architectures trickle in, they are then made available
in the archive. This means that many architectures
sync into the archives after the DTSA is
published. This could result in announcing a DTSA,
only to find a FTBS on an architecture. So far this hasn't
happened,
as the buildd problems have only been chroot problems.
One solution discussed was asking if RMs could push
into testing even if a particular arch wasn't built. However it
was
determined that if an arch was keeping up, but there wasn't a
build
for a particular package, then there is something wrong and the
RMs
aren't going to want to push it in.
Criteria: we wait for the big three builds (i386, powerpc
and amd64) before doing anything, don't hold up
an advisory because a slow arch (such as m68k) is
held up
2. Automatically pulling things from the debian archive to t-s archive
Automatically pull things from the debian archive to the
testing-security archive. For example, sendmail has a bug
but arm and m68k has not been built, the solution
would be to automatically pull in the missing architectures
from the main archive. This makes it easier to do a DTSA
because you don't need to wait for building to finish, when the
missing architectures get built in the main debian they are
automatically sync'd in.
There are some restrictions to this: it can only be done after
the dinstall happens. After a set number of days (10), the
package would be automatically removed from
testing-security. This would only be a solution for slow arch
builds, not dependency issues. There would have to be
dependency checking happening in this automatic procedure.
Procedure would be to issue a DTSA and make a hint to pull
this in from the debian archive
Question: should we try to build the missing architectures in
secure-testing? No, should be
suppressed so that the normal debian autobuilder network can
build those and get automatically
sync'd over as the hints file will still exist
Criteria:
Aba will work on setting up this automatic sync
procedure, we auto-sync from the debian archive when
it is easy
3. Dependency problems:
Some packages it would take at least 2 more months before the
regular
kdelibs would propogate because it is waiting for so many
things, in
this case it would make sense to define criteria and isolated
security
fixes have been published. Adjust the build-depends if its
possible
with the old tool-chain, then build and test heavily before
uploading.
Criteria: Backport packages by modifying build-depends where
there are obscure dependency toolchain problems
blocking, test heavily
4. If a non-free leaf package is not being built on an arch,
then we need to coordinate with RMs; if it is a non-leaf
package then it should be checked and autobuilt by aba
(non-leaf = if it will remove a lot of other packages)
. Statistics of downloads?
Question: are there any statistics on who has downloaded what arches?
Answer: not really, as some people sync via rsync to other
hosts, so we don't have reliable statistics
. Refining DTSA steps
We discussed some ways to refine some of the DTSA steps, as
there are some issues and some of the steps do not need to be
done manually.
1. Maybe the website generated from our database, rather than
manual/static updates in the steps
2. If you run the DTSA script twice, it will make two entries
in the list, unreleased tag in the DTSA list is that necessary
3. Updating DTSAs needs to be fixed so that the minor version
number isn't increased when wanting to regenerate existing
DTSAs. Need a way to regerate an existing DTSA without
increasing the minor number
. DTSAs for kernel security problems
Because there is a special procedure necessary to apply the
security fixes for kernels (ie. reboot) it may make sense to
do a DTSA for all kernel updates with security fixes. This
would mean that we would only write DTSAs, and not
build/upload any packages.
The idea was floated to make a daily run script that gives a
list of packages which have been installed in the archive and
compare it against a list of known security holes, this would
be for watching things like kernel entering testing
. Long-running processes
If you are dealing with a DTSA for a library that is being
replaced by a newer version, existing applications that have
this library still open need to be restarted; this is true of
all long running processes. There is a script included in
nagios that does some sort of lsof to tell you what
applications are still running and asks you to restart them
(firefox, gdm, etc.)
. Solidifying syntax criteria
why do we put unfixed in the brackets? makes parsing harder, etc.
part of the problem we have two or three different parsers and
we said yesterday that it wold be good to standardize/stabalize
our formats. Moritz will make a proposal of fixes after
studying them. Need to convert in parallel the information
formerly included in NOTE:s into not-affected and possibly
also converting some; severities from low into unimportant
. Collaborative repository of security patches
It was discussed how it would be nice to share a repository
with Ubuntu, and others, that would contain security patches. Because
finding patches takes too much time (digging in Bugzilla for half an
hour is a pain, but needing to get a SuSe src RPM and extract it and
try to find the patches they applied is insanity). If we
created a repository that Debian and Ubuntu uses to share
patches, it would then be made available to others so that
everyone can benefit.
. Sid tracking page
Joey modified the script that makes the tracking page so that
it can be generated for sid as well, it contains all the hurd
holes, yay! http://spohr.debian.org/~joeyh/unstable-security.html
. BTS bug severity
As the testing-security team ends up looking at a significant
number of the bugs tagged with +security, it would be good if we were
versed in the proper severity levels so we can help adjust them and
educate people as to what the proper severity levels for security
issues should be:
* affects a user that installs a package: critical
* affects a user that has executed a binary, allowing
compromising userdata, taking over account, etc.: grave
* affects build-process, or generally annoying: important
. Adding HELP tag
It was discussed to add a HELP tag so that we can generate a
page of issues (such as all x400 embedded source) that we need
help with so other people can look and see what we could use
general help with.
. Filtering bug-dist
Setup a mailing list that is subscribed to bug-dist that
automatically filters out all emails except those which include tag
+security and those that contain bug numbers that are listed in CAN/list
. Publishing the testing-security's severity levels
We discussed the severity levels that we use in our tracking,
and Micah agreed to dig out the discussions from the mailing list and
compile them all together so we can agree on them and make them
documented.
low - not bad XSS issues
medium - things that are local security
high - remote holes/DoS (would rather terminate the service
rather than run a insecure version)
. Dealing with the upcoming CVE naming scheme change
This happens October 19th.
They will probably rename files - which will break our update scripts
our CVE list will probably get all the CANs dumped into it,
because they are renaming it Joeyh will contact [EMAIL PROTECTED]
about what will be happening so we can deal with it in
advance update everything that says CANs with CVE
there will be mappings from old CAN numbers to the new CVEs
there should be a special announcement from us about the change when it
happens
. Florian's tracker
Move florian's stuff to secure-testing website then (need to
find out what the resource issues are with the tracker), need
to keep aba in the loop for moving
. Getting PTS to include a link from existing packages to their
security history from Florian's tracker. Need to contact
[EMAIL PROTECTED] (buxy) about this once the tracker has been
"finalized"
and put somewhere stable
. Need to discuss embedded source copies with martin pitt to see if we
can create a common list of these
. Dealing with removed packages?
aptitude lists removed packages
it lists security updates for stable, but not testing - but
its an ugly hack (should instead use the Release file?)
publish removed packages so that people know
. Testing-security apt pinning issue
aba will look into fixing the pinning issue - you can't pin
against release name, or code-name (etch), but only against
the suite name (testing), aba will look into making the
pinning for etch-seucre mirror the way it works in testing
. Adding fixed in stable in the list?
Need to talk to joey and mpitti about this so we can support
other distributions.
signature.asc
Description: Digital signature
_______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
