Differences between revisions 25 and 26
Revision 25 as of 2011-03-09 12:57:29
Size: 22106
Editor: RhondaDVine
Revision 26 as of 2018-05-24 01:46:16
Size: 22036
Editor: PaulWise
Comment: titanpad link is dead
Deletions are marked like this. Additions are marked like this.
Line 34: Line 34:


Debian Security Meeting: January 2011

14th of January 2011 to 16th of January 2011
Linux Hotel, Essen

Nico, Moritz, Florian, Thijs, Joey, Sebastien, Stefan, Rhonda

Location, Date


  • Work out formal conditions under which five year LTS support can be implemented
  • Better organisation of work: designated rotating weekly security desk acking all issues
  • Better organisation of work: Having everyone commit to a fixed amount of DSAs per month?
  • Better organisation of work: What to do with RT? Finally activate the RT overview :-)

  • Better organisation of work: Everyone needs to use the security tracker
  • Better organisation of work: Build log autosigning
  • Hash out new advisory generation and hack the scripts needed
  • Procedures/scripts for tracking of ia32-libs
  • Introduce maintainer-handled security packages for stuff we we don't provide much benefit (Typo3, Asterisk)
  • Designated spu coordinator for proper no-dsa organisation
  • Check all the stuff we were missing from last year
  • Wine and cheese
  • look into the logrotate issue


DDA has some summary of the meeting


Minutes of the security team meeting in Essen

1. Rotating Security Front Desk (weekly)

  • Have a dedicated person, who is responsible for the incoming "security info stream"
  • Helps the others to not need to read all the mails, CVEs, etc and let people focus on fixing stuff instead of organisational issues
  • responsibilities:
  • opening tickets for new incoming issues by:
  • mail to team@security.debian.org

  • mitre CVE update stream (+ Debian bug, tracker) http://lists.alioth.debian.org/mailman/listinfo/secure-testing-commits

  • oss-sec (+ Debian bug, tracker)
  • vendor-sec
  • Classify tickets according to severities (see below in 2.)
  • Organisation is done in SVN, in the file org/security-frontdesk.2011.txt
  • A mail will be sent out to ask everyone about participation to allocate the rest of the year, individual weeks can be swapped later [jmm]

2. Improve RT efficiency

  • Rhonda created a dashboard, which present an overview of all open RT tickets, this overview can be mailed to team@security.debian.org on a daily basis (done)

  • Ask DSA, whether it's possible to sync debian.org account data to RT. This would make it much easier for people to open a ticket. While opening a ticket is already possible with the mail interface, it makes it difficult to followup to a ticket. [(asking DSA is) done by Thijs]
  • Encourage maintainers to directly open a ticket [-> bits mail]

  • update developers reference [Thijs]
  • update our own instructions on security.debian.org [Thijs]
  • Encrypted mail should still go to team@security.debian.org

  • For now reportbug should not redirect people to opening up tickets for embargoed issues, since they might accidentally use the public Security Queue. report already asks, whether a security issue is public and if so, it adds a note to rather send mail to team@security.debian.org, where it's picked up the security frontdesk person, which can then open a ticket if needed

  • Severities 0: unimportant, 50: normal, 100: important
  • Action item: ask RT admins to change default priority to 50 - done
  • Fine-tune available columns in the dashboard and security queues

3. Build log autosigning

We still want it. The current process is complicated, forces us to do silly, manual work, which only adds delays. It also keeps our inboxes sane (one eglibc uploads results in one GB build logs to each security team member...) If buildd admins still want to do manual signing for unstable etc., they can. Who should we contact? We need to check the current status. We'll try to contact Phil Kern on IRC during this weekend. (G: Thats a thing that will happen after squeeze)

4. Revamped security release process

Information provided manually:

  • Subject line info:
  • Separate subject for regression fixes
  • Separate subject prefix for critical issues [new]
  • DSA id (taken from the filename)
  • List of source packages
  • What's with binNMUs?
  • CVE IDs
  • Debian bug number(s)
  • Free form descriptions of vulnerability (could be taken by dak from the changelog)
  • Known behaviour change flag [new] (later maybe integrate into unattended-upgrades,...)
  • individual signature by the person who released the update [maybe switch to separate advisory signing key, depending on how the tools work]
  • fixed versions for testing, sid and sometimes experimental (e.g. in case of xulrunner) (could try to be fetched from CVE/list)
  • optionally the name of the person preparing the advisory, if different from the person doing the release (the latter would then be put into the From or Sender header).

Data to be dropped from the new advisories:

  • Debian-specific flag
  • bugtraq id/CERT advisory ids... (were rarely used)
  • distinction remote/local vulnerabilites
  • vulnerability type from subject line

Data generated by dak:

  • List of affected binary packages [new]
  • And their versions if they differ from the source package version [new]
  • Information on included binary archs (put in generic instructions, don't release without i386/amd64) include 'architectures available at time of release'
  • fixed versions for oldstable, stable
  • Source package versions including the epoch
  • For computer parsable form: hash+url of .dsc files (not in normal advisory mail)

Data generated by dsa-release-script:

  • Generic instructions
  • Date
  • Person who released the update (unless overriden in the data file, e.g. for security assistants' DSAs)
  • Subject line with package names


  • Commit the DSA source file in SVN with the needed manual information
  • Filename should be data/DSA/advs/DSA-XXXX-Y.sourcepackage1_sourcepackage2
  • A less error-prone file name should be used
  • Pre-commit hook checks name and format
  • What about CVE ids? could be an easy way to detect typos
  • Non-package DSA-Mails (drop of security support, ...) are just mailed manually to the list
  • dsa-release-script is run with the ID of the DSA source file as an argument
  • As a fallback the file could not be fetched from SVN, but instead be given as an argument, e.g. in case of Alioth downtime
  • After asking for confirmation and printing the list of .changes files and missing archs, the files are installed into the archive as currently with security-install
  • Post-process script is run, which generates webwml file and commits it to web repository and triggers a website rebuild (maybe this part can be done on www-master instead and be triggered by the DSA mail, too)
  • DSA mail should then trigger a rebuild of the security section on the www-master and a resync of the pages
  • Post-process script is run, which prepends to data/DSA/list
  • Post-process script is run: The advisory mail is signed with a common advisory signature key and sent out from security-master, not by the individual maintainers. Add preview of final mail before sending it out.
  • Optionally generate XML representation or whatever people want to have to postprocess the information (yaml or 822 format is in use for Debian stuff already, consider that too)
  • During processing the information which gets added by dak (e.g. binary package information) and the updated file commited back into SVN (so that the files contain the full information)
  • Needs to allow specifying a different name for maintainer-supported security updates (and DSAs from security assistants)

Implementation [Florian, Nico, Moritz]: Python, since other code parts are already written in Python Data format: Start with rfc822-style, see if it works out

5. Handling ia32-libs

Package is problematic because it contains 101 other source packages verbatim. For lenny the problem is that the package has lastly been updated long before the release, so there's a rather large delta between the current version in the archive and a possible new upload. This makes adding it to the next point release as the only viable option.

As for squeeze we've been more active to push for updates of ia32-libs during the freeze. If we have another catch-up update in the first point release we should be reasonably set. Due to its size we cannot update it too often. We will only release an ia32-libs update for stable squeeze as a DSA for "critical" issues. Otherwise we'll catch up in a point release.

We don't want to add special support to the tracker for ia32-libs, because it is supposed to be gone in wheezy.

We need to talk to mhy, he had a tool there once doing it. [Thijs will work on this.]

6. Maintainer-handled security packages that are hard to test (typo3,asterisk,..)

  • maintainers can commit the DSA files to svn
  • advisory will be sent in the name of the maintainer (so they get blamed for breaking stuff ;-p)
  • The Sender: header is used to indicate the security team member that blessed the update.

[Wait until 4. is done]

7. Long Term Support [-> send to private/DPL?, include a line in the bits mail]

Basic model:

  • Support for stable and oldstable is done as it is currently handled
  • "LTS person(s)" handle(s) the remaining time up to five years
  • Also use the Debian infrastructure for the LTS support
  • All LTS packages will be freely available

Scope of supported packages: Possibly the whole archive, but with limitations:

  • Limit 5 year support to one browser engine?
  • Limit scope of kernel support (e.g. disregard local denial of service and driver backports for new hardware)?
  • Packages which are end-of-lifed in the lifetime of regular stable would also be end-of-lifed in LTS support time
  • Some packages will not be LTS-supportable


  • The LTS person(s) should rather be hired by a foundation, not provided by a single company
  • Too much of a single point of failure
  • Getting funding is much easier if several companies provide smaller amounts of funding
  • Corporate funding should be in the form of contracts over a longer time, not one-off donations
  • Hiring someone needs some kind of perspective/plannability
  • Benefits for companies contributing:
  • Influence on packages under security support
  • Communicating priority requests to LTS person
  • Access to expertise of LTS person
  • Sponsors can provide test cases, test configurations and reference VMs
  • Setting up the foundation should be driven by the DPL, one of the interested companies or an interested DD.
  • This is not something the Security Team can and wants to do
  • Amount of manpower needed:
  • Depends on the scope of packages
  • While it might be doable with a single person, there're significant reasons to have two:
  • Avoid single point of failure
  • Cover sickness/vacations
  • "Four eyes principle": One builds the update, the other runs QA

8. Interaction with s-p-u and maintainers [->bits mail]

Stress the concept that the maintainer is also responsible for his packages in stable and he should address security issues (or help the security team). Maybe put it into developer's reference (also encourage running and/or adding test suites; discourage e-c-c).

Find a designated coordinator for stable point updates. All issues which are not going to be fixed in a DSA are added to data/spu-candidates.txt. The SPU coordinator needs to approach maintainers, explain them that the issue could be fixed in stable-proposed-updates instead and guides the maintainer through the necessary steps when proposing the update to release managers. We could either approach potential candidates in private or include a call for help in next bits from the... mail. This needs a fancy title, "Debian Security Czar" or some such. The candidate doesn't need to be a DD, he/she only needs to be reliable and able to read mail and write agreeable responses. Also the backlog of older no-dsa tags needs to be checked and validated with maintainers.

9. Hardening support in Wheezy

The state of Squeeze wrt hardening features is disappointing. We need a more fundamental approach than hardeningwrapper, it should be the default in our toolchain, not something maintainers opt-in. (At least for i386 and amd64, special archs could opt-out. Even if we only change it on i386 and amd64, that would be a huge win.) Features, which we definitely need are:

  • stack protector
  • relro/znow (check znow for performance problems)
  • PIE (at least on amd64)

Wheezy will likely/hopefully have a grsecurity kernel flavour.

Schedule a Enabling Hardening Options BoF at Debconf. Invite gcc and ports maintainers. Start with finding a set of options to enable that are agreed upon by attendants. TODO: Collect which distribution has already enabled which feature on which architecture and put into wiki/Hardening. [SF]

10. Beta testing area

Still very desirable, both for our internal testing and for users testing updates. Nothing has been implemented, though and nearly all the work would be needed on the dak side. One of the FTP masters should be lured into implementing it. [Moritz]

11. Policy amendment for testing

It would be useful to have a policy addition that maintainers are encouraged to provide a README.test file, which describes the needed steps to test the package (in case a test suite exists and is not run automatically run during built or even to document the fact that a testsuite is already run during build and which parts of the package are covered by the testsuite), where to get test files or how to run the testsuite.

This would not only be useful for security updates, but also for standard QA NMUs. [Nico]

12. Status of volatile security

Mostly unknown to us nowadays.

13. Status of security for backports.debian.org [-> bits mail]

Some backporters don't track the status of their backports regularly and thus have security fixes outstanding. And mostly only Gerfried is dealing with outstanding issues. It is needed to raise awareness of the status page in the security-tracker for backporters. This should be mentioned in the bits mail. It would be nice to have something like the DTSA-candidates page for backports. Help with backports security support would be welcome.

14. Document extent of security support in testing

Change docs in security FAQ and testing-security.debian.net to point out that there are very few uploads to testing-security und fixes mostly go in by unstable (with possible exceptions before releases due to freeze states). [SF]

Try to integrate the docs into webwml. The secure-testing.debian.net domain cannot be deleted because of debsecan. (It is desirable to migrate this to a debian.org domain, separate from security-tracker.debian.org in case of increased load.) But the html could be replaced with pointers to www.debian.org.

15. Document limited support of packages

There are debtags which are derived from data/package-tags. These debtags should be displayed more prominently in packages.debian.org and the PTS (red box). There should be a web site with the single-line rationale from data/package-tags and packages.debian.org should link to that. The format of data/package-tags should be changed to allow more verbose descriptions, including hyperlinks. [Gerfried, Nico: bug report fuer p.d.o, Raphael?]

It seems the debtags are not updated regularily. Ask enrico about that [Nico has sent that]. Also, we must be sure that it is possible to change them during stable life-time. Optional: display this information in the security-tracker on a per package basis.

The overloaded nature of <no-dsa> and <unimportant> makes it difficult to generate a list of reasons for lack of security updates automatically.

16. Security tracker bugs/wishes/enhancements/proposals/desires/etc (this only lists things for which there is no bug report yet):

  • Improve check-new-issues to only show new advisories that the user has never seen before: People who use c-n-i can modify it to suit their needs. If someone doesn't know enough perl, he can ask SF.
  • Integrate data/embedded-code-copies with the tracker in some way (at least at pointers to CVE-specific pages). Links from the PTS are not necessary because we should simply file bugs.
  • Simplified handling of oldstable and release codenames would be nice, but needs quite some work. They are hardcoded in multiple places, including the sqlite files. Maybe have a detailed config file for the Python stuff (config.json) and a simple two-line shell snippet (stable=xxx, oldstable=yyy) for all other scripts.
  • Remove data/NMU/list (done)


17. Security team member status

We will need to ask people for status anyway, because of rotating front desk schedule. Ask everyone if he is active, ask assistants if they need help. Make it clear that inactive/removed people can come back at short notice. [Moritz]

18. Secure-testing repository

We will remove all people who have not committed since beginning of 2009 (and notify them by mail). [SF]

Maybe rename repository from secure-testing to a separate repo security-tracker because updating secure-testing gives the impression that testing security is more active than it really is. Look how many links would need to be changed, first. Maybe do this shortly after squeeze release. [Later]

19. CVE tags in BTS

Make it easy to search for CVE ids (in the regular bug field, in the short URL). Make them be displayed by default. Ask Don/Blars about how to do it. [SF]

20. Bits from the ... mail / For those who care about security

Compose a mail and add the things mentioned above. Ask for volunteers.

  • we need to define exactly what we are looking for. E.g. people following sec lists, bugtrackers, etc and adding them to the tracker; people triaging issues, fixing them, auditing code, etc, etc
  • Concentrate on finding people working on tracker/stable issues/but filing/... Then approach the promising candidates for doing DSA work. Directly asking for people to do DSA work hasn't given good results in the past, too many people dropped off.


21. Auditing

  • Auditing of new packages (see http://www.nth-dimension.org.uk/blog.php?id=70 - my non-DD thoughts but i'm sure there will be other ideas)

  • there's an inactive debian-audit project which doesn't even work out for packages already in the archive, NEW would be way more work, maybe reactivate that. this role isn't tied to the security team in any way, can be done by anyone.
  • data/packages/new-packages is a list of new packages. The goal was to pick a couple, try to find embedded copies, look for NFUs, etc. Only I, Raphael, worked on it. (Looks to be too much work to us. Maintainers should already do that. Most old NFUs should be fixed in the newes upstream version).
  • ftp-masters could require maintainers to provide the security team with a list of embedded copies of NEW packages along with a justification, prior accepting them from NEW. (probably too much work, too)

[Some motivated volunteer, maybe mail to debian-security]

22. /usr/local permissions

23. Documentation for procedures:

There are many out of date documents spread in multiple places (wiki, svn, security-team host, etc). Default location should be wiki under http://wiki.debian.org/DebianSecurity. People can move stuff there if interested. Create new stuff in wiki.

24. Spam on lists

Alioth lists: Ask alioth admins if something can be done.

team-alias: Ask DSA to set up spam filtering. Now that we have a front-desk, we can ask people to resend if a mail has not been acked after a week or so ("should never happpen").

How to deal with the post-DSA deluge of VAC, OOO emails and bounces (discuss with listmasters wrt. deleteion). Maybe the return-path for bugtraq, full-disclosure, etc. could be set to /dev/null.

[fw will try to work with the appropriate Debian teams on the spam issue]








FRI 15:45 DUS

SUN 18:20 DUS


Times are touchdown and takeoffs of the plane


Sat 10:00

Sun 17:30


ICE and S via OB


Fri afternoon

Sun 15:00

not yet


FRI 16:40 DUS

SUN 16:25 DUS



FRI 15:02

Sun 15:00


times are at Essen Hbf


FRI 14:57

Sun 17:00


times are at Essen Hbf


Fri 19:14

Sun 14:15



Fri ~19:00

Sun 17:00


times are Essen Hbf


With regards to travel cost reimbursements please collect all receipts and tickets you wish to reimburse and send them to use after the meeting. Please attach a filled out form.

Please use the German form if your account is in Germany:

Please use the English/SWIFT form if you are in SWIFT land outside of Germany: