[Secure-testing-team] Oldenburg 2nd meeting summary

[Micah Anderson]

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 steve at mitre
	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
	hertzog at debian (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.  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050924/5cf8ed48/attachment.pgp