https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/05/report-389-ds-base-1.4.2.7-1.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code
> On 5 Feb 2020, at 03:10, Ludwig Krispenz wrote:
>
> I think I can agree with 1-8, 9 is one solution to fix the problem you
> reported, but not yet validate that there are no other side effects, there
> are potential postop plugins which should NOT be called for tombstone delete,
> eg
I think I can agree with 1-8, 9 is one solution to fix the problem you
reported, but not yet validate that there are no other side effects,
there are potential postop plugins which should NOT be called for
tombstone delete, eg retro cl, we need to investigate side effects of
the patch and
Hi,
I agree with you that calls to pre and post should be balance, but not
sure if your approach is the correct one. There is a condition for post
"!delete_tombstone_entries" which prevented the call for postop plugins
in case of the deletion of a tombstone entry. Your patch now ensures
that
Ok, let's take this from the top:
1: Defects that cause a server to become unresponsive are bad and must
be repaired as soon as possible.
2: Some #1 class defects are exploitable and require a CVE. As far as
I can tell, this one does not, but you should keep an eye out for the
possibility.
3:
