Re: Proposed SRU policy amendment for package removals
Hello again, Martin Pitt [2014-11-11 14:54 +0100]: Hello TB, as discussed in the last meeting, I wanted to put up a proposal for amending https://wiki.ubuntu.com/StableReleaseUpdates for package removals like the recent owncloud. Please check that this graps what we discussed; I'd also appreciate language cleanups. Apparently that got voted on in the previous meeting without telling me (or sending minutes to u-d-a@). I now integrated the proposal into the above page. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposed SRU policy amendment for package removals
Hey Kees, Kees Cook [2014-11-11 9:13 -0800]: FTR, this proposal now lives on https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves for easier editing (already did a typo and a grammar update suggested by Robbie, thanks!) I like it, thanks! Is it worth maintaining the explicit list of removals (more than just Examples:)? Yes, I think it is, there won't be too many of those. I adjusted the wiki page accordingly. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposed SRU policy amendment for package removals
Hello Chuck, Chuck Peters [2014-11-12 3:25 +]: Both tor and owncloud are recurring examples! tor was reintroduced explicitly two years after the removal (https://launchpad.net/bugs/413657). If that is out of date again and unmaintained, we should remove it again and blacklist it this time so that it doesn't come back automatically. If that's the case, then I suggest filing a new removal/SRU bug for this. owncloud isn't a recurring example; it was removed now and blacklisted. If we just make an empty package that gives the user some direction on installing upstream, why don't we just do it for them This is *exclusively* a crutch for stable releases to override an undeletable package in a stable release. In the devel series (and hence in all future stable disto releases) the package should be removed completely. We don't want installer packages for free software in the archive by policy. Furthermore amending the SRU process as proposed doesn't really address the fundamental issue of universe packages are often not maintained and with something like tor the consequences can be very dangerous. Right, that's why we are drafting this policy now so that we don't start from scratch every time :-) But in reality most unmaintained universe packages are by far not as dangerous as tor. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposed SRU policy amendment for package removals
Martin, On 2014-11-12 05:43 AM, Martin Pitt wrote: Hello Chuck, Chuck Peters [2014-11-12 3:25 +]: Both tor and owncloud are recurring examples! tor was reintroduced explicitly two years after the removal (https://launchpad.net/bugs/413657). If that is out of date again and unmaintained, we should remove it again and blacklist it this time so that it doesn't come back automatically. If that's the case, then I suggest filing a new removal/SRU bug for this. Perhaps blacklisting for new releases by default should be added to the procedure? We can always remove a package from the blacklist if someone steps up and volunteers to support it. Marc. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposed SRU policy amendment for package removals
On Wed, Nov 12, 2014 at 07:53:13AM -0500, Marc Deslauriers wrote: On 2014-11-12 05:43 AM, Martin Pitt wrote: Chuck Peters [2014-11-12 3:25 +]: Both tor and owncloud are recurring examples! tor was reintroduced explicitly two years after the removal (https://launchpad.net/bugs/413657). If that is out of date again and unmaintained, we should remove it again and blacklist it this time so that it doesn't come back automatically. If that's the case, then I suggest filing a new removal/SRU bug for this. Perhaps blacklisting for new releases by default should be added to the procedure? We can always remove a package from the blacklist if someone steps up and volunteers to support it. If a package has previously been in Ubuntu and has been removed, then it won't be auto-synced (although it will show up in the output of auto-sync for manual resolution; currently only I see that). It normally isn't necessary these days to preemptively blacklist things when you remove them. If a package actually reappears, it might still be worthwhile to blacklist it then in order to quieten auto-sync, but you don't need to do that preemptively. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposed SRU policy amendment for package removals
Martin Pitt said: Examples: [[https://lists.ubuntu.com/archives/ubuntu-devel/2007-September/024453.html|tor]], [[https://launchpad.net/bugs/1384355|ownclod]] Both tor and owncloud are recurring examples! http://packages.ubuntu.com/search?keywords=tor shows: precise (12.04LTS): 0.2.2.35-1: [universe] trusty (14.04LTS): 0.2.4.20-1: [universe] utopic: 0.2.4.23-1: [universe] The up to date version from torproject for 14.04 is currently 0.2.5.10-1~trusty+1. https://www.torproject.org/docs/debian.html.en shows the recommended way of installing it. Maybe I am missing something, why are we still shipping outdated versions of tor for every supported distribution? If we just make an empty package that gives the user some direction on installing upstream, why don't we just do it for them. Can the SRU policy be amended to include installing a good upstream repository like torproject? I am not suggesting we do this for owncloud, but I think we should for tor. Somebody can wordsmith the SRU policy better than I, but I'll take a shot: In cases where upstream software is designed for security reasons and has a history of rapid development, installing an upstream sources.list and repository key will be considered. Furthermore amending the SRU process as proposed doesn't really address the fundamental issue of universe packages are often not maintained and with something like tor the consequences can be very dangerous. I have been looking for a session to cover the universe security issue at UOS, but I haven't seen any. I have considered proposing a session titled Security of the Universe, but I haven't made as much progress as I hoped... One idea that will hopefully alert people about issues is: Now that the debian-security-support package has landed in utopic, we should create a ubuntu-security-support package for each of the supported distributions and update it as the various security teams suggest. The package simply checks a couple files and what is installed on the machine. /usr/share/debian-security-support/security-support-ended /usr/share/debian-security-support/security-support-limited For example this is part of what was shown on a recent Debian wheezy install after I installed the package. * Source:pidgin Details: Support in oldstable is limited to IRC, Jabber/XMPP, Sametime and SIMPLE Affected binary packages: - libpurple-bin (installed version: 2.10.10-1~deb7u1) - libpurple0 (installed version: 2.10.10-1~deb7u1) - pidgin-data (installed version: 2.10.10-1~deb7u1) We should base the new Ubuntu package on the newer debian-security-support 2014.11.07 package in Debian because some hook features were added. I have some other ideas, but those will require much more work and resources. Chuck PS. Security of the Universe The working draft for a mission statement is: First the universe archive, then NEO's, Black-holes and other astronomical phenomena. I know some people won't find it funny, but I like it. It is sort of a natural joke when the pun is influenced from my father who was on the Jet Propulsion Lab navigation team for Voyager 1 and other unmanned space missions. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
