Re: [389-users] Re: NOTICE - Rust will be mandatory starting in 389-ds-base-2.2
by Mark Reynolds
On 8/23/22 9:58 AM, Trevor Vaughan wrote:
> How are you going to handle the FIPS build issues surrounding Rust
> right now?
>
> Are all crypto libraries going to build against the underlying OpenSSL
> (or something else certified)?
Correct all the Rust password storage scheme plugins use OpenSSL (not
NSS), so we don't have these issues anymore.
FYI we were able to get the NSS PBKDF2 version working in FIPS (in very
recent versions), but the Rust version is much better and more secure.
Thanks,
Mark
> Thanks,
>
> Trevor
>
>
> On Tue, Aug 23, 2022 at 9:53 AM Mark Reynolds <mareynol(a)redhat.com> wrote:
>
> Hello,
>
> For many years now we have been offering Rust plugins, and for those
> that build the server themselves it was possible to disable Rust
> if it
> was not wanted. This is no longer going to be an option starting
> in the
> next release of 389-ds-base-2.2 (On Fedora 37). We are upgrading the
> default password storage schema to the Rust password storage scheme
> PBKDF2_SHA256 for its improved security and performance over the
> C/NSS
> version (PBKDF2-SHA256). We are also going to be incorporating
> Rust into
> core parts of the server. So leaving Rust optional is no longer
> going
> to be an option.
>
> Sorry for the inconvenience this will impose on people not wanting to
> build with Rust, but this is the direction we are moving in with
> the 389
> project.
>
> Feel free to ask any questions or voice concerns over this change,
> and
> we will do our best to address them.
>
> Sincerely,
>
> --
> Directory Server Development Team
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to
> 389-users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point
> (410) 541-6699 x788
>
> -- This account not approved for unencrypted proprietary information --
>
> _______________________________________________
> 389-users mailing list --389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fe...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
--
Directory Server Development Team
1 year, 3 months
NOTICE - Rust will be mandatory starting in 389-ds-base-2.2
by Mark Reynolds
Hello,
For many years now we have been offering Rust plugins, and for those
that build the server themselves it was possible to disable Rust if it
was not wanted. This is no longer going to be an option starting in the
next release of 389-ds-base-2.2 (On Fedora 37). We are upgrading the
default password storage schema to the Rust password storage scheme
PBKDF2_SHA256 for its improved security and performance over the C/NSS
version (PBKDF2-SHA256). We are also going to be incorporating Rust into
core parts of the server. So leaving Rust optional is no longer going
to be an option.
Sorry for the inconvenience this will impose on people not wanting to
build with Rust, but this is the direction we are moving in with the 389
project.
Feel free to ask any questions or voice concerns over this change, and
we will do our best to address them.
Sincerely,
--
Directory Server Development Team
1 year, 3 months
Lockless work queue - work in progress
by James Chapman
https://github.com/389ds/389-ds-base/issues/5338
Hi,
This is a draft implementation of a lockless work queue to address the
contention observed when the server is processing connections. However, the
design of the lockless queue means it is unsafe to free a node after it is
dequeued as another thread could be using it. I have noticed this behaviour
intermittently, where a thread tries to access a node that has been freed,
breaking the linked list.
Possible solutions to this problem:
Use a double word compare and swap, but this is not available on commonly
used hardware.
Use node pointer modification counters to only free a node when no thread
is using it.
I am currently working on this problem, any advice would be appreciated.
1 year, 3 months
