samba - Aug 2020 - core dump from samba-tool when chnging user password

On Mon, August 24, 2020 22:19, Andrew Bartlett wrote:
>
> A bit of an aside, but it would be incredibly awesome if the FreeBSD
> port could adopt the same policy as, eg, Debian and not ship any
> patches that are not upstream.
>
> We do consider such patches, with justification, when submitted by or
> on behalf of their authors.  See for example this recent MR submitted
> by Debian: https://gitlab.com/samba-team/samba/-/merge_requests/1420
>
> It makes assessing issues like this much easier.
>
> Thanks,
>
> Andrew Bartlett
>
I believe that Timur has indeed submitted patches of this nature. I recall
reading that they were deemed unacceptable because of some security related
difficulty in namespacing attributable to ZFS or the kernel in FreeBSd.

This sort of stuff is out of my realm and I am going on memory from a comment
that I read in a FreeBSD samba bug report some time ago.  I am sure that a
direct communication with Timur will obtain the precise details.

-- 
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
   Unencrypted messages have no legal claim to privacy
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

On Tue, Aug 25, 2020 at 1:17 PM James B. Byrne via samba <
samba at lists.samba.org> wrote:
>
>
> On Mon, August 24, 2020 22:19, Andrew Bartlett wrote:
>
> >
> > A bit of an aside, but it would be incredibly awesome if the FreeBSD
> > port could adopt the same policy as, eg, Debian and not ship any
> > patches that are not upstream.
> >
> > We do consider such patches, with justification, when submitted by or
> > on behalf of their authors.  See for example this recent MR submitted
> > by Debian: https://gitlab.com/samba-team/samba/-/merge_requests/1420
> >
> > It makes assessing issues like this much easier.
> >
> > Thanks,
> >
> > Andrew Bartlett
> >
>
> I believe that Timur has indeed submitted patches of this nature. I recall
> reading that they were deemed unacceptable because of some security related
> difficulty in namespacing attributable to ZFS or the kernel in FreeBSd.
>
That was a separate issue regarding acl_xattr. FreeBSD only has
"system"
and "user" xattr namespaces.

Timur did attempt to upstream the talloc patch here:
https://lists.samba.org/archive/samba-technical/2018-February/125592.html

On Tue, 2020-08-25 at 14:12 -0400, Andrew Walker via samba
wrote:
> On Tue, Aug 25, 2020 at 1:17 PM James B. Byrne via samba <
> samba at lists.samba.org> wrote:
> 
> > 
> > 
> > On Mon, August 24, 2020 22:19, Andrew Bartlett wrote:
> > 
> > > 
> > > A bit of an aside, but it would be incredibly awesome if the
> > > FreeBSD
> > > port could adopt the same policy as, eg, Debian and not ship any
> > > patches that are not upstream.
> > > 
> > I believe that Timur has indeed submitted patches of this nature. 
> > 
> 
> Timur did attempt to upstream the talloc patch here:
> https://lists.samba.org/archive/samba-technical/2018-February/125592.html
I've looked this over, and this is exactly the right example, as it
happens.  There was a great discussion about the patch, and ultimately
it was rejected.

This is good feedback, and should not have been ignored in my view. 
Note that I said 'are not upstream', not 'have not been submitted
upstream'.

The gap between those two things ends up being the issue here, which is
when patches we (as the Samba Team) don't agree with are still applied
by distributors and porters, all the QA, experience etc applied to
Samba.org releases is just discarded.

It also just makes bug triage much harder, and we have seen here that
triage of FreeBSD issues is hard enough right now.

Now of course there are always matters of degree in this, but is is an
important principle to start with.

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT - Expert Open Source
Solutions
https://catalyst.net.nz/services/samba