Re: minssf and TLS cipher ordering

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



How odd, maybe it's the version in EPEL.

On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden <rcritten@xxxxxxxxxx> wrote:
Trevor Vaughan wrote:
> Going full circle on this, I confirmed using s_client that what I was
> seeing was indeed happening but not for the reason that I thought it was.
>
> Given that the min_ssf is 256, the connection requires a 256-bit cipher
> and hash to communicate with the server.
>
> Strangely, the internal strength logic on the 389-DS side appears to
> pick ECDHE-RSA-AES128-GCM-SHA256 *before* ECDHE-RSA-AES256-GCM-SHA384.
> Likewise, if I add any of the AES128 ciphers to the list after the
> AES256 ciphers, one of the 128-bit ciphers will be chosen first. This
> seems incorrect given that the server should be using the strongest
> cipher suite available if possible.
>
> The client cipher order preference is completely ignored (which is fine).
>
> As pointed out in the last response, I did indeed need to explicitly
> enable only the 256-bit+ hash/cipher combinations in the
> confusingly-named nsSSL3Ciphers attribute.
>
> After figuring this out and dumping the internal supported cipher list,
> I can confirm that the ciphers in the nsSSL3Ciphers list are the only
> ones that are presented to the client.
>
> While not ideal, this does provide a solution to the issue where I don't
> have to tell all system users that they need to nail up the cipher lists
> on the client side in order for things to function properly.
>
> But that leaves me with two questions:
>
> 1) Why, when the nsslapd-minssf option is set in the global
> configuration, does 389-DS not automatically prune any options that will
> result in an unsuccessful connection.
>
> 2) Why is the internal cipher sorting order choosing weaker cipher
> suites before stronger ones?

I'm pretty sure that 389-ds still uses NSS for server-side crypto and
unless something has changed NSS doesn't do cipher sorting. It picks the
"best" for you. AFAIR the server has no say in the matter.

But, as a goof I used a pure NSS server tool to see what happens and it
picked the expected cipher.

Enable your two ciphers (in hex form):

$ /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d
/etc/dirsrv/slapd-EXAMPLE-TEST/ -p 8389 -f
/etc/dirsrv/slapd-EXAMPLE-TEST/pwdfile.txt -c :C02F -c :C030 -v -V
tls1.2:tls1.2

run s_client:

New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID:
2AF9EFDDB3EA99C101C4E4F99A47CD479D294C15309D7E994ADA21C083D8E096
    Session-ID-ctx:
    Master-Key:
85646A59B24D5A88080227BD59E328C688910FB0B2E2BAD77D7B1A96F6A9A3ACBF74EEC6C844A7D59527152928580743
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1619562457
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes

So even more confusing unless I've goofed something up, sorry. I didn't
mess with minssf, maybe that does make a difference.

The ciphers are:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   0xC02F
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384   0xC030

Don't mean to stir up the mud but this may be a question for the NSS team.

rob

> On Mon, Apr 26, 2021 at 11:50 PM William Brown <wbrown@xxxxxxx
> <mailto:wbrown@xxxxxxx>> wrote:
>
>     Then youll need to disable everything except aes256 then I suspect
>     ... :(
>
>     > On 25 Apr 2021, at 11:39, Trevor Vaughan <tvaughan@xxxxxxxxxxxxx
>     <mailto:tvaughan@xxxxxxxxxxxxx>> wrote:
>     >
>     > Well, in this case, I've got to be able to work with regulatory
>     requirements so not much I can do there.
>     >
>     > Trevor
>     >
>     > On Sat, Apr 24, 2021, 9:03 PM William Brown <wbrown@xxxxxxx
>     <mailto:wbrown@xxxxxxx>> wrote:
>     >
>     >
>     > > On 24 Apr 2021, at 22:30, Trevor Vaughan <tvaughan@xxxxxxxxxxxxx
>     <mailto:tvaughan@xxxxxxxxxxxxx>> wrote:
>     > >
>     > > Hi Marc,
>     > >
>     > > I was under the impression that it would pick the highest
>     supported, but that doesn't seem to be what is happening based on my
>     previous example.
>     > >
>     > > Instead, it seems to just be picking the first compatible,
>     regardless of strength.
>     >
>     > It choose aes128 over 256 because of processing speed, and "strong
>     enough".
>     >
>     > >
>     > > Trevor
>     > >
>     > > On Fri, Apr 23, 2021, 10:03 PM Marc Sauton <msauton@xxxxxxxxxx
>     <mailto:msauton@xxxxxxxxxx>> wrote:
>     > > about ciphers order and TLS cipher suite discovery, NSS will
>     pick the one with highest strength from the available ciphers, and
>     compatible with the TLS client ( handshake)
>     > >
>     > > you can check the configuration with for example (replace the
>     string m1 with an instance name):
>     > > dsconf m1 security get
>     > > dsconf m1 security ciphers list
>     > > dsconf m1 security ciphers list --supported | less
>     > > dsconf m1 security ciphers list --enabled
>     > > ldapsearch -o ldif-wrap=no -LLLxD "cn=Directory Manager" -W  -b
>     cn=encryption,cn=config | less
>     > >
>     > > and to set ciphers (can be "delicate"):
>     > > /usr/lib64/nss/unsupported-tools/listsuites | grep -B1
>     --no-group-separator "Enabled" | less
>     > > dsconf m1 security ciphers set xxxxx
>     > >
>     > > doc ref:
>     > >
>     https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/enabling_tls#setting_encryption_ciphers
>     > >
>     > > and NSS source:
>     > > ./lib/ssl/ssl3con.c
>     > > ./lib/ssl/sslenum.c
>     > >
>     > >
>     > > On Fri, Apr 23, 2021 at 4:57 PM Trevor Vaughan
>     <tvaughan@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>> wrote:
>     > > William,
>     > >
>     > > I do apologize! I'll keep that in mind in the future.
>     > >
>     > > Thanks again for your help,
>     > >
>     > > Trevor
>     > >
>     > > On Fri, Apr 23, 2021, 7:50 PM William Brown <wbrown@xxxxxxx
>     <mailto:wbrown@xxxxxxx>> wrote:
>     > > Sorry to call this out, but my name is "William" not "Bill". I
>     have personal reasons to dislike being called that name.
>     > >
>     > > Regardless, happy to help out :)
>     > >
>     > > > On 23 Apr 2021, at 22:11, Trevor Vaughan
>     <tvaughan@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>> wrote:
>     > > >
>     > > > Bill and Pierre,
>     > > >
>     > > > Thanks for the responses!
>     > > >
>     > > > It sounds like I have to figure out how to configure the NSS
>     library for 389-DS specifically.
>     > > >
>     > > > In EL8+ I know that I can configure the global crypto policy
>     but I'm hoping that I can do it for the specific application. I
>     haven't found anything in the documentation so far but at least this
>     gets me pointed in the right direction.
>     > > >
>     > > > Thanks,
>     > > >
>     > > > Trevor
>     > > >
>     > > > On Fri, Apr 23, 2021 at 4:42 AM Pierre Rogier
>     <progier@xxxxxxxxxx <mailto:progier@xxxxxxxxxx>> wrote:
>     > > > Hi Trevor,
>     > > >
>     > > > I do not think it is possible to specify the cypher order
>     negotiation:
>     > > >      I am not sure whether TLS protocol allow to specify an
>     order when negotiating the cypher,
>     > > >      but at 389 level there is no way to specify an order:
>     > > > The NSS security layer provides the list of supported cypher
>     and 389 use
>     > > > nsSSL3Ciphers config parameter to enable/disable theses
>     cyphers in the list (without changing the order)
>     > > >
>     > > >     So my feeling is that if there is an order it is up to the
>     different
>     > > >      security layer implementations and may differs between
>     the applications,
>     > > >
>     > > > Regards,
>     > > >    Pierre
>     > > >
>     > > > On Thu, Apr 22, 2021 at 7:28 PM Trevor Vaughan
>     <tvaughan@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>> wrote:
>     > > > Hi William,
>     > > >
>     > > > In terms of the STARTTLS bits (in theory) properly configuring
>     your client software mitigates the password leak risk. But this also
>     happens with pure (non-RFC) LDAPS connections.
>     > > >
>     > > > The docs note that minssf applies to the crypto required bits
>     as well as the SASL layer.
>     > > >
>     > > > Ignoring most of that, my issue is that I don't understand why
>     I have to nail my client software to ciphers explicitly known by
>     389-DS instead of the two negotiating the strongest things possible
>     out of the gate.
>     > > >
>     > > > For instance, if I use AES256 with a minssf=256, everything
>     works just fine.
>     > > >
>     > > > But, if I use AES128:AES256:@STRENGTH (which should sort
>     strongest to weakest) then access is denied.
>     > > >
>     > > > How do I get 389-DS to negotiate the strongest ciphers first
>     (regardless of the method)?
>     > > >
>     > > > Thanks,
>     > > >
>     > > > Trevor
>     > > >
>     > > > On Wed, Apr 21, 2021 at 7:34 PM William Brown <wbrown@xxxxxxx
>     <mailto:wbrown@xxxxxxx>> wrote:
>     > > > Hi there,
>     > > >
>     > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan
>     <tvaughan@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>> wrote:
>     > > > >
>     > > > > Hi All,
>     > > > >
>     > > > > OS Version: CentOS 8
>     > > > > 389-DS Version: 1.4.3.22 from EPEL
>     > > > >
>     > > > > I have a server set up with minssf=256 and have been
>     surprised that either 389-DS, or openssl, does not appear to be
>     doing what I would consider a logical TLS negotiation.
>     > > > >
>     > > > > I had thought that the system would start with the strongest
>     cipher and then negotiate down to something that was acceptable.
>     > > > >
>     > > > > Instead, I'm finding that I have to nail up the ciphers to
>     something that the 389-DS server both recognizes and is within the
>     expected SSF.
>     > > > >
>     > > > > Is this expected behavior or do I have something configured
>     incorrectly?
>     > > >
>     > > > That's not what minssf does.
>     > > >
>     > > > minssf says "during a bind operation, reject if the encryption
>     strength used is less than 256 bits or equivalent".
>     > > >
>     > > > The "bit strength" is arbitrary though, because it's a concept
>     from sasl, and generally is very broken.
>     > > >
>     > > > Remember, minssf does NOT do what you think though! Because
>     bind is the *first* message on the wire, the series of operations is
>     > > >
>     > > >
>     > > >    client                   server
>     > > > open plain text conn  ->   
>     > > >                       <-   accept connection
>     > > > send bind on conn     ->   
>     > > >                       <-   reject due to minsff too weak.
>     > > >
>     > > >
>     > > > So you have already leaked the password!
>     > > >
>     > > >
>     > > > The only way to ensure this does not occur is to set
>     "nsslapd-port: 0" which disables plaintext. Then you *only* use
>     ldaps on port 636, which is guarantee encrypted from the start.
>     > > >
>     > > > It is worth noting that the use of starttls over ldap, does
>     *NOT* mitigate this issue, for a similar reason.
>     > > >
>     > > >
>     > > > Caveat: If you are using kerberos/gssapi you can NOT disable
>     plaintext ldap due to these protocols attempting to install their
>     own encryption layers.
>     > > >
>     > > >
>     > > > Hope that helps,
>     > > >
>     > > >
>     > > > >
>     > > > > Thanks,
>     > > > >
>     > > > > Trevor
>     > > > >
>     > > > > --
>     > > > > Trevor Vaughan
>     > > > > Vice President, Onyx Point, Inc
>     > > > > (410) 541-6699 x788
>     > > > >
>     > > > > -- This account not approved for unencrypted proprietary
>     information --
>     > > > > _______________________________________________
>     > > > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > > > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > > > > Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>     > > >
>     > > > —
>     > > > Sincerely,
>     > > >
>     > > > William Brown
>     > > >
>     > > > Senior Software Engineer, 389 Directory Server
>     > > > SUSE Labs, Australia
>     > > > _______________________________________________
>     > > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > > > Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>     > > >
>     > > >
>     > > > --
>     > > > Trevor Vaughan
>     > > > Vice President, Onyx Point, Inc
>     > > > (410) 541-6699 x788
>     > > >
>     > > > -- This account not approved for unencrypted proprietary
>     information --
>     > > > _______________________________________________
>     > > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > > > Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>     > > >
>     > > >
>     > > > --
>     > > > --
>     > > >
>     > > > 389 Directory Server Development Team
>     > > > _______________________________________________
>     > > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > > > Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>     > > >
>     > > >
>     > > > --
>     > > > Trevor Vaughan
>     > > > Vice President, Onyx Point, Inc
>     > > > (410) 541-6699 x788
>     > > >
>     > > > -- This account not approved for unencrypted proprietary
>     information --
>     > > > _______________________________________________
>     > > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > > > Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>     > >
>     > > —
>     > > Sincerely,
>     > >
>     > > William Brown
>     > >
>     > > Senior Software Engineer, 389 Directory Server
>     > > SUSE Labs, Australia
>     > > _______________________________________________
>     > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > > Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>     > > _______________________________________________
>     > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > > Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>     > > _______________________________________________
>     > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > > Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>     > > _______________________________________________
>     > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > > Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>     >
>     > —
>     > Sincerely,
>     >
>     > William Brown
>     >
>     > Senior Software Engineer, 389 Directory Server
>     > SUSE Labs, Australia
>     > _______________________________________________
>     > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>     > _______________________________________________
>     > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>
>     —
>     Sincerely,
>
>     William Brown
>
>     Senior Software Engineer, 389 Directory Server
>     SUSE Labs, Australia
>     _______________________________________________
>     389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     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@xxxxxxxxxxxxxxxxxxxxxxx
>     Do not reply to spam on the list, report it:
>     https://pagure.io/fedora-infrastructure
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699 x788
>
> -- This account not approved for unencrypted proprietary information --
>
> _______________________________________________
> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux