Lovely. Is this something that the 389 team is willing to take up to NSS or shall I go it alone?
Given that most things will work (if accidentally) anyone setting minssf is likely to be quite surprised. Thanks, Trevor On Wed, Apr 28, 2021 at 9:24 AM Rob Crittenden <[email protected]> wrote: > Trevor Vaughan wrote: > > Interestingly, if I remove the cipher specification, I get the result of > > ECDHE-RSA-AES128-GCM-SHA256. > > > > Can you see if this also happens with your version of nss? > > Same as you're seeing, ECDHE-RSA-AES128-GCM-SHA256 is picked. > > rob > > > > > Thanks, > > > > Trevor > > > > On Wed, Apr 28, 2021 at 8:27 AM Trevor Vaughan <[email protected] > > <mailto:[email protected]>> wrote: > > > > So, I just ran this test with selfserv as you have above and > > everything worked as expected with s_client. > > > > It seems to be something in 389 itself. > > > > On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > Then youll need to disable everything except aes256 then I > > suspect > > > ... :( > > > > > > > On 25 Apr 2021, at 11:39, Trevor Vaughan > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>> 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 > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > > > > > > > > On 24 Apr 2021, at 22:30, Trevor Vaughan > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>> 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 > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> > > 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 > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > 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 > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> 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 > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > 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 > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> 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 > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > 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 > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > Hi there, > > > > > > > > > > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > 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 -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > > 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/[email protected] > > > > > > > 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 -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > 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/[email protected] > > > > > > 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 -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > 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/[email protected] > > > > > > Do not reply to spam on the list, report it: > > > https://pagure.io/fedora-infrastructure > > > > > > > > > > > > > > > > > > -- > > > > > > -- > > > > > > > > > > > > 389 Directory Server Development Team > > > > > > _______________________________________________ > > > > > > 389-users mailing list -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > 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/[email protected] > > > > > > 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 -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > 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/[email protected] > > > > > > 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 -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > 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/[email protected] > > > > > Do not reply to spam on the list, report it: > > > https://pagure.io/fedora-infrastructure > > > > > _______________________________________________ > > > > > 389-users mailing list -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > 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/[email protected] > > > > > Do not reply to spam on the list, report it: > > > https://pagure.io/fedora-infrastructure > > > > > _______________________________________________ > > > > > 389-users mailing list -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > 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/[email protected] > > > > > Do not reply to spam on the list, report it: > > > https://pagure.io/fedora-infrastructure > > > > > _______________________________________________ > > > > > 389-users mailing list -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > 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/[email protected] > > > > > 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 -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > 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/[email protected] > > > > Do not reply to spam on the list, report it: > > > https://pagure.io/fedora-infrastructure > > > > _______________________________________________ > > > > 389-users mailing list -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > 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/[email protected] > > > > 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 -- > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > To unsubscribe send an email to > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > 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/[email protected] > > > 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 -- [email protected] > > <mailto:[email protected]> > > > To unsubscribe send an email to > > [email protected] > > <mailto:[email protected]> > > > 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/[email protected] > > > 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 > -- > > > > > > > > -- > > Trevor Vaughan > > Vice President, Onyx Point, Inc > > (410) 541-6699 x788 > > > > -- This account not approved for unencrypted proprietary information -- > > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
_______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
