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
>
_______________________________________________
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
