Re: request for freeze exception for samba 3.2.1
Steve Langasek wrote:
Dear release team,
This is a request for a freeze exception for the new upstream version of
samba 3.2.1. Samba 3.2.1 is a stable point release of the recent Samba 3.2
branch; while this is not guaranteed to be a bugfix only branch, the changes
here are not extraneous. diffstat of the source/ directory (i.e., excluding
the documentation) gives:
56 files changed, 774 insertions(+), 517 deletions(-)
Almost all of these changes are straightforward bugfixes, some of which are
certainly severity: important despite being unfiled. Highlighting those
changes that are not straightforward, for consideration:
* Improve processing of registry shares.
* Canonicalize servername in the printer functions to remove leading
* Fix option processing in smbcacls - add POPT_COMMON_CONNECTION.
* Re-activate 'acl group control' parameter and make it only apply
to owning group.
* Make ntimes function more like POSIX and allow NULL arg.
* Fix error message if trying to join with a non-privileged user.
* Cleanup some duplicate code by passing the password to the wbinfo_auth*
* Allow SID with 0 in subauthority to be converted properly.
* Add broadcasting of the debug message to all winbindd children.
* Allow authentication and memory credential refresh after password
change from gdm/xdm.
* Allow %u parameters for print job username.
The first of these is a rather sizeable change (117 insertions(+), 32
deletions(-)), but it's also a change regarding a new feature, so there's
minimal risk of regression.
And I believe this next change corresponds to Debian bug #493752:
* Fix trusted domain handling in Winbindd.
The full WHATSNEW.txt (== release notes) for this release is attached.
Is this acceptable? Note that over the course of a stable release, samba
will typically have a large number of security uploads due to the size and
complexity of the code base, so on balance this diff, though large, is not
necessarily larger than the delta that would eventually be allowed through
via SRU anyway; and it's impossible to predict whether accepting these
changes now will make a difference for security fixes later. I think that
this early in the freeze, we're better off taking the new upstream version
If that's not ok, then we maintainers will need to cherry-pick a number of
these changes anyway; more work for us, with an IMHO minimal decrease in the
risk of regression.
I also have one Debian-specific change on my radar currently, to try to get
the size of these packages down size they've bloated significantly with the
newest upstream branch.