Ubuntu Wiki

Dev Week -- SRU/Security Updates -- Luca Falavigna, William Grant -- Wed, Feb 20

(02:58:45 PM) DktrKranz: Hello everybody, you brave souls interested in post-release madness!
(02:58:53 PM) DktrKranz: I am Luca Falavigna, a volunteer MOTU and SRU enthusiast.
(02:59:20 PM) DktrKranz: as seb128 just said, now we speak about SRU and Security Updates
(02:59:28 PM) DktrKranz: Now I'll introduce briefly what SRUs are and leave room for some questions before talking about the process behind Ubuntu updates.
(02:59:48 PM) DktrKranz: After that, William Grant (aka Fujitsu) will talk about security updates.
(02:59:52 PM) ***Fujitsu waves.
(03:00:06 PM) DktrKranz: SRU is the acronym for Stable Release Updates.
(03:00:25 PM) DktrKranz: These updates are meant to fix non security-related bugs affecting supported Ubuntu releases (currently they are Dapper, Edgy, Feisty and Gutsy).
(03:00:49 PM) DktrKranz: Common examples include packages which fail to build from source, have unmet dependencies or crasher bugs, but has no direct security impact (such as
(03:00:49 PM) DktrKranz: privilege escalation or buffer overflows).
(03:01:26 PM) DktrKranz: Since stable releases are used by a much wider audience than development ones, additional care should be involved in the process, but it is quite simple anyway :)
(03:02:01 PM) DktrKranz: Starting point is https://wiki.ubuntu.com/StableReleaseUpdates, where you will find every informations related to SRUs.
(03:02:20 PM) DktrKranz: Please everybody have a look at it :)
(03:03:03 PM) DktrKranz: Not every bit is useful for common users/developers, basically just the first half is ("Why", "When" and "How" up to point No. 2).
(03:04:32 PM) DktrKranz: If you haven't questions, let's move to the playground, then
(03:04:48 PM) R1CHARD_jam1ng is now known as R1CHARD
(03:04:48 PM) seb128 left the room ("Ex-Chat").
(03:05:10 PM) DktrKranz: When a bug is SRU-worthy? It is described in "When" section in https://wiki.ubuntu.com/StableReleaseUpdates.
(03:05:40 PM) DktrKranz: If your favourite app crashes or it is uninstallable, a SRU will be granted :)
(03:06:13 PM) DktrKranz: There are many other cases, and they are listed in the above page. Have a good look at it.
(03:07:23 PM) DktrKranz: ~motu-sru team is responsible to approve a SRU candidates for Universe packages, ~ubuntu-sru does the same for main packages.
(03:08:09 PM) DktrKranz: If you want a bug to be reviewed, just subscribe the right team and provide the informations required in "How", "Propose" section.
(03:08:46 PM) DktrKranz: The most important ones you need to provide are:
(03:09:14 PM) DktrKranz: 1) A good TEST CASE, placed into the bug description field, stating how to reproduce the bug (step by step) and the expected behaviour.
(03:09:55 PM) DktrKranz: 2) Explain if (and how) the problem has been fixed into the development version (Hardy, at the moment), this way we avoid regressions.
(03:10:41 PM) DktrKranz: Usually, we don't upload SRU candidates if development version has not been fixed
(03:11:25 PM) DktrKranz: 3) Attach a candidate debdiff for review. It must contain code to fix the given bug *only*, no additional (or cosmetic) changes are allowed unless approved in another SRU request.
(03:12:39 PM) DktrKranz: When preparing debdiffs, the most difficult part of the process is writing the changelog entry. I've seen several SRU candidates rejected due to inaccuracies in changelog, so additional care is a must here :)
(03:13:12 PM) DktrKranz: A good changelog entry must have these requisites:
(03:13:36 PM) DktrKranz: 1) Point to the corresponding Launchpad bug (LP: #xxxxxx). *Always* remember to double-check it to be correct.
(03:14:18 PM) DktrKranz: 2) Target must always be "$release-proposed". "$release" or "$release-updates" are not allowed. For instance, if you want to prepare a SRU for Gutsy, target must be gutsy-proposed. You can use "dch -D $release-proposed" command to set it automatically.
(03:15:08 PM) DktrKranz: 3) Version must be set in order to avoid conflicts with past, current or future versions of the package.
(03:15:51 PM) DktrKranz: Versioning scheme is a bit different from the one you usually see in development releases, it is not complex but has several variants to avoid conflicts (as mentioned above).
(03:16:16 PM) DktrKranz: A couple of examples now:
(03:16:50 PM) DktrKranz: foo_0.1-1ubuntu1 would become foo_0.1-1ubuntu1.1 (we add ".1" to the existing version)
(03:17:30 PM) DktrKranz: bar_0.2-1 would become bar_0.2-1ubuntu0.1 (ubuntu0.1 is used to avoid conflicts with a hypotetical bar_0.2-1ubuntu1 in a newer release).
(03:18:09 PM) DktrKranz: If you have doubts about which version to use, you can ask ~motu-sru or ~ubuntu-sru team members for an advice, they will be happy to answer :)
(03:18:53 PM) DktrKranz: Ok, let's stop here, feel free to ask if you have questions.
(03:21:42 PM) DktrKranz: It seems not, so let's move on.
(03:22:17 PM) DktrKranz: If you are not developers, you can help to check if a SRU candidate is good.
(03:22:46 PM) DktrKranz: http://people.ubuntu.com/~ubuntu-archive/pending-sru.html is a wonderful place to start. It lists SRU candidates still lying in -proposed and which require verification from ~sru-verification team.
(03:22:57 PM) DktrKranz: Again, please everybody have a look at it.
(03:23:30 PM) DktrKranz: As users, you can pick up one of the package listed there and try to test if it works for you.
(03:24:06 PM) DktrKranz: Just follow instruction given in TEST CASE (that's why a good TEST CASE is required: it speeds up verification phase) and attach your results in the corresponding bug report.
(03:24:46 PM) DktrKranz: Your reports will improve overall quality of the SRU process, so a huge thank you for your precious comments :)
(03:25:45 PM) DktrKranz: If you have questions, please fire them.
(03:26:12 PM) DktrKranz: After that, Fujitsu will discuss about security updates.
(03:27:33 PM) emgent: :)
(03:27:52 PM) DktrKranz: <InsClusoe> DktrKranz: Looking at feisty on that page. All updates appear to be language packs. How do we test them? The launchpad page doesn't list the bugs fixed in those updates or details of changes made.
(03:28:15 PM) DktrKranz: You are right, langpacks have been recently uploaded
(03:28:51 PM) DktrKranz: I think they do not receive special verification, since it is a procedure put in place by our archive-admins
(03:29:17 PM) DktrKranz: They are regularly scheduled for translation updates
(03:30:29 PM) DktrKranz: <InsClusoe> QUESTION: What are the changes we should look for if we try these translation updates on our machines? Where are these listed?
(03:31:16 PM) DktrKranz: Changes should be related to translation itself
(03:31:49 PM) DktrKranz: Typos, untraslated strings, and so on. Log is kept in Rosetta.
(03:33:18 PM) InsClusoe: ok.. I was looking for the word 'Rosetta' then.. :-)
(03:33:42 PM) DktrKranz: Rosetta is Launchpad translation platform
(03:34:04 PM) DktrKranz: https://translations.launchpad.net/
(03:35:51 PM) DktrKranz: I'm not comfortable with Rosetta enough to detail how it works, it could be material for an interesting #ubuntu-classroom session :)
(03:37:11 PM) InsClusoe: DktrKranz: Thanks...
(03:37:28 PM) DktrKranz: Fujitsu, audience is yours!
(03:37:32 PM) ***Fujitsu appears.
(03:37:59 PM) Fujitsu: Well...
(03:38:29 PM) Fujitsu: Security updates are pushed out to fix important security issues in supported Ubuntu releases.
(03:38:51 PM) Fujitsu: The preparation is very similar to SRUs, in that the changes must be absolutely minimal, and very well tested.
(03:39:51 PM) Fujitsu: Unfortunately, the nature of security issues often means we need the update pushed out ASAP, so testing often can't be done as much as we'd like.
(03:40:17 PM) Fujitsu: It's a messy job, but someone needs to do it, and we need as many hands on it as we can get.
(03:41:09 PM) Fujitsu: The wiki page describing the procedure is at https://wiki.ubuntu.com/SecurityUpdateProcedures.
(03:42:21 PM) Fujitsu: There are a couple of differences from SRUs, the main one being that there is no waiting period in -proposed (the packages don't go into -proposed at all), so no verification team.
(03:42:40 PM) Fujitsu: A member of the Canonical security team reviews the patch, and publishes it immediately if it's deemed suitable.
(03:43:10 PM) Fujitsu: This is another difference from the SRU procedure. Only the Canonical security team can upload to -security, so updates often block on them.
(03:44:21 PM) Fujitsu: Of course, before we can fix issues, we need to identify and prioritise them.
(03:45:03 PM) Fujitsu: We have the ubuntu-cve tracker for this, which reads the published list of CVEs, and allows us to mark which packages and Ubuntu releases are affected by each issue, if any.
(03:45:20 PM) Fujitsu: It's quite a task to keep it up to date, unfortunately.
(03:45:27 PM) Fujitsu: (it can be found at https://launchpad.net/ubuntu-cve)
(03:46:08 PM) InsClusoe: Fujitsu: Broken link^?
(03:46:29 PM) Fujitsu: Argh, true. ubuntu-cve-tracker, sorry.
(03:46:52 PM) InsClusoe: np.. :-)
(03:48:35 PM) Fujitsu: Versioning in security updates can be very hard to get right, as we normally use an identical scheme to that used in SRUs.
(03:48:59 PM) Fujitsu: This means that unless very careful checking is done, SRUs can be accidentally reverted in security updates, or vice-versa.
(03:50:50 PM) Fujitsu: Any questions?
(03:52:03 PM) Fujitsu: < daishujin> QUESTION: Why use the same versioning scheme?
(03:53:14 PM) Fujitsu: We need to maintain compatibility between the two versioning schemes so we can have SRUs upgrading over security updates (once the security update is integrated), and potentially vice-versa.
(03:53:44 PM) Fujitsu: If we chose a radically different scheme, this would be much harder, and you'd end up with horrible hybrids in many packages by the end of a release's support cycle.
(03:54:09 PM) Fujitsu: < daishujin> QUESTION: How often is this a problem?
(03:54:39 PM) Fujitsu: Not very frequently, I don't believe, but I haven't got any numbers.
(03:55:28 PM) Fujitsu: It's normally fairly easily resolvable, though it may require coordination with SRU teams to get an updated SRU out quickly.
(03:57:50 PM) DktrKranz: pending-sru has "Superseded by -security" section which notes that.
(03:58:03 PM) Fujitsu: Ah yes, forgot about that.
(03:59:37 PM) Fujitsu: Well, that'd be the end, I guess... Any last-30-seconds questions?