Debian Security Meeting: January 2011

Date
14th of January 2011 to 16th of January 2011
Location
Linux Hotel, Essen
Attendants

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

Location, Date

Agenda

Summary

DDA has some summary of the meeting

Notes

Source

Minutes of the security team meeting in Essen

1. Rotating Security Front Desk (weekly)

2. Improve RT efficiency

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:

Data to be dropped from the new advisories:

Data generated by dak:

Data generated by dsa-release-script:

Workflow:

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,..)

[Wait until 4. is done]

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

Basic model:

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

Organisation:

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:

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):

[fw]

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.

[Thijs]

21. Auditing

[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]

Itineraries

Name

Arrival

Departure

Booked?

Comments

GerfriedFuchs

FRI 15:45 DUS

SUN 18:20 DUS

yes

Times are touchdown and takeoffs of the plane

ThijsKinkhorst

Sat 10:00

Sun 17:30

yes

ICE and S via OB

Moritz

Fri afternoon

Sun 15:00

not yet

Seb

FRI 16:40 DUS

SUN 16:25 DUS

yes

Stefan

FRI 15:02

Sun 15:00

yes

times are at Essen Hbf

Florian

FRI 14:57

Sun 17:00

no

times are at Essen Hbf

Joey

Fri 19:14

Sun 14:15

yes

Nico

Fri ~19:00

Sun 17:00

yes

times are Essen Hbf

Reimbursements

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:


CategorySprint