ubuntu community update policy (in particulat drupal7)

[Alias for Public Use]

> Date: Mon, 4 Aug 2014 10:58:53 +0100
> From: robie.basak at ubuntu.com
> To: alias4pu at outlook.com
> CC: ubuntu-motu at lists.ubuntu.com
> Subject: Re: ubuntu community update policy (in particulat drupal7)
>
> On Sun, Aug 03, 2014 at 09:38:51PM +0200, Alias for Public Use wrote:
>> I wonder about the update policies for universe packages.
>>
>> In particular I have noticed the drupal 7 package in the community
>> repository is at verion 7.26, wheras the current version is 7.30.
>
> The version in Trusty is 7.26-1. The version in the current development
> release (Utopic) is 7.30-1.
>
> The version in an existing release is not updated except for security or
> high impact bug fixes. https://wiki.ubuntu.com/StableReleaseUpdates has
> rationale and criteria.

The reason for my inquiry was the fact drupal7 is still at 7.26 in trusty, considering the fact several security issues had been addressed in version 7.27-30. The information in said webpages actually only increases my surprise.
>
> [...]
>
>> Is there some kind of mechanism to issue resyncs/create an updated
>> package?
>
> Yes. If someone prepares a debdiff, or if a fix is just a straight sync
> from Debian, the Ubuntu Security Team will be happy to review and
> sponsor it.
> https://wiki.ubuntu.com/SecurityTeam/SponsorsQueue#Notes%20for%20Contributors
> has the procedure.
I suppose I should create a bug report (and possibly package fix) then.

>> Escpecially for packages which have potentially large security issues
>> and which have their own update mechanisms and which can be installed
>> into a working ubuntu server with minimal invasiveness...
>
> Using upstreams' own update mechanisms has in general never been
> acceptable for distributions. It worries me when I see that, for
> example, the "normal" way to upgrade Wordpress is from its own web UI.
> Surely the ability to be able to modify itself remotely through itself
> (in terms of a remote sysadmin, as opposed to a remote upstream that is
> verified cryptographically) is a security issue in itself?
That is true, the permission for self-modification should preferably be enabled on demand through another schannel (administrative shell access to for example)

>
>> ...I believe there should be an update schedule or the package should
>> not be available at all.
>
> What do you mean by "an update schedule"? Are you asking that that
> somebody apply, test and upload regular security updates? If so, then
> who are you suggesting should do this? Or are you just asking what the
> mechanism is to provide security updates?
I just wondered if anyone in particular is watching packages. I suppose not, so as stated earlier its everyone's/my responsibility to report issues and (help) have them fixed.

The thing is if apparently no-one is watching the package and doing this, it might be safer not to offer the package in the first place. That way people unaware of the possibility of security issues not  being addressed for extended periods of time cannot install the package. If necessary they would have to install the software themselves, probably more aware of the need to watch updates closely.