A previous change made it not possible to remove the admin
user. This also included disabling the admin user. The user can
be disabled, just not deleted because it is required.
Move the test test_ipa_cacert_manage_prune to the end of the
class because it changes time which can break replication.
Fixes: https://pagure.io/freeipa/issue/9489
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The current filter in principal_has_privilege is only working for normal
IPA users where krbprincipalname is matching the principal. An idoverride
user (for example from AD) is not found with this filter.
A new filter for the principal as an ipaOriginalUid has been added as a
second try if a match with krbprincipalname was not found.
principal_has_privilege is used in the replica connection check. The
additional check enables to deploy replicas using an AD user/administrator
that has been added to the "admins" group.
Fixes: https://pagure.io/freeipa/issue/9542
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The ipa tool has nearly since epoch returned 2 for the case of
entry not found.
The certificate processing raises a separate error,
CertificateOperationsError, when something goes wrong.
This returns 1.
With the introduction of the JSON API most requests will get
a proper HTTP return code representing what went wrong. In this
case we can use 404 to determine if the request resulted in
a NotFound therefore can eventually return a 2 and be
consistent in return values.
Related: https://pagure.io/freeipa/issue/9562
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
SIDGEN plugin only uses local ID ranges and thus a restart is really
needed only when a local range is added, modified or removed.
Also fix the SSSD warning because removal of any range requires restart
everywhere, not just on a specific server.
Fixes: https://pagure.io/freeipa/issue/9558
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
After the addition of a new idrange, the sidgen plugin is not
immediately aware of the new idrange and a restart of 389ds is
required. Otherwise the creation of new user/group with a uid/gid
inside the new range fails to grant a SID to the user/group.
Fixes: https://pagure.io/freeipa/issue/9558
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
When authentication indicators were introduced in 2016, ipa-pwd-extop
plugin gained ability to reject LDAP BIND when an LDAP client insists
the authentication must use an OTP token. This is used by ipa-otpd to
ensure Kerberos authentication using OTP method is done with at least
two factors (the token and the password).
This enfrocement is only possible when an LDAP client sends the LDAP
control. There are cases when LDAP clients cannot be configured to send
a custom LDAP control during BIND operation. For these clients an LDAP
BIND against an account that only has password and no valid token would
succeed even if admins intend it to fail.
Ability to do LDAP BIND without a token was added to allow users to add
their own OTP tokens securely. If administrators require full
enforcement over LDAP BIND, it is cannot be achieved with LDAP without
sending the LDAP control to do so.
Add IPA configuration string, EnforceLDAPOTP, to allow administrators to
prevent LDAP BIND with a password only if user is required to have OTP
tokens. With this configuration enabled, it will be not possible for
users to add OTP token if one is missing, thus ensuring no user can
authenticate without OTP and admins will have to add initial OTP tokens
to users explicitly.
Fixes: https://pagure.io/freeipa/issue/5169
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
If a vault operation fails, the error message just says "InternalError". This commit
improves error handling of key archival and retrieval calls by catching the PKIException
error and raising it as an IPA error.
Related: https://pagure.io/freeipa/issue/9191
Signed-off-by: Francisco Trivino <ftrivino@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Cryptography 42.0.0 introduced two new abstract properties
`not_valid_before_utc` and `not_valid_after_utc`, which are non-naive UTC
variants of the `not_valid_before` and `not_valid_after` properties.
The old properties are deprecated. The changeset also modifies code and
tests to use the new `_utc` variants.
Fixes: https://pagure.io/freeipa/issue/9518
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Since commit 5c0e7a5fb4, a new extended
operation to get a keytab is supposed to be used. This keytab
setting/retrieval extended operation checks access rights of the bound
DN to write to a virtual attribute 'ipaProtectedOperation;write_keys'.
If the write isn't allowed, the operation is rejected and ipa-getkeytab
tool falls back to an older code that generates the keytab on the client
and forcibly sets to the LDAP entry. For the latter, a check is done to
make sure the bound DN is allowed to write to 'krbPrincipalKey' attribute.
This fallback should never happen for newer deployments. When enrollemnt
operation is delegated to non-administrative user with the help of 'Host
Enrollment' role, a host can be pre-created or created at enrollment
time, if this non-administrative user has 'Host Administrators' role. In
the latter case a system permission 'System: Manage Host Keytab' grants
write access to 'krbPrincipalKey' attribute but lacks any access to the
virtual attributes expected by the new extended operation.
There is a second virtual attribute, 'ipaProtectedOperation;read_keys',
that allows to retrieve existing keys for a host. However, during
initial enrollment we do not allow to retrieve and reuse existing
Kerberos key: while 'ipa-getkeytab -r' would give ability to retrieve
the existing key, 'ipa-join' has no way to trigger that operation.
Hence, permission 'System: Manage Host Keytab' will not grant the right
to read the Kerberos key via extended operation used by 'ipa-getkeytab
-r'. Such operation can be done later by utilizing 'ipa
service/host-allow-retrieve-keytab' commands.
Fix 'System: Manage Host Keytab' permission and extend a permission test
to see that we do not fallback to the old extended operation.
Fixes: https://pagure.io/freeipa/issue/9496
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Fix the following errors:
I0021(useless-suppression)
R1710(inconsistent-return-statements)
E1101(no-member)
Ignore the following errors:
E0601(used-before-assignment)
The variable is imported when the code is run in_server.
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
hbactest does a number of internal searches, one of which
can exceed the configured sizelimit: hbacrule-find
Collect any messages returned from thsi call and display them
to the user on the cli.
Fixes: https://pagure.io/freeipa/issue/9486
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
PKI 11.4.0 changed the reason keyword in the REST API from lower-case
to camel-case in https://github.com/dogtagpki/pki/commit/926eb221ce6
Use Reason instead of reason as the keyword for revocations
for PKI 11.4.0+
Related: https://pagure.io/freeipa/issue/9345
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
This is a side-effect of adding the libpwquality options. It
imposes its own hardcoded minimum password length so some care
was needed to ensure that it isn't set too low.
So if there are no libpwquality options used then it's fine to
have no minlength in the policy.
Fixes: https://pagure.io/freeipa/issue/9297
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
The ipaidpuser objectclass is required for the attribute ipaidpsub.
When a user is created or modified with --idp-user-id, the operation
must ensure that the objectclass is added if missing.
Add a test for user creation and user modification with --idp-user-id.
Fixes: https://pagure.io/freeipa/issue/9433
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The XML API is already deprecated and will be removed in some
future release.
All but the updateCRL API has an equivalent in REST. The upstream
dogtag project documents most of the API at
https://github.com/dogtagpki/pki/wiki/REST-API . I say most
because not every API includes sample input/output. The
pki ca-cert command is a good substitute for seeing how the API
is used by their own tooling.
This changes no pre-existing conventions. All serial numbers are
converted to decimal prior to transmission and are treated as
strings to avoid previous limitations with sizing (which would
have been exacerbated by random serial numbers).
Fixes: https://pagure.io/freeipa/issue/9345
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
An attempt to do this was already coded but the wrong
argument was used. It was passing in the location name and
not the map name so the map wouldn't be completely removed.
Include a test to verify that the map is gone after removing
it by calling automountlocation-tofiles which will fail if the
map wasn't properly removed.
Fixes: https://pagure.io/freeipa/issue/9397
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
admin is required for trust operations
Note that testing for removing the last member is now
irrelevant because admin must always exist so the test
for it was removed, but the code check remains. It is done
after the protected member check.
Fixes: https://pagure.io/freeipa/issue/8878
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Use of 'ipa idp-add --provider' was supposed to allow override scope and
other IdP options. The defaults are provided by the IdP template and
were actually not overridden. Fix this.
Fixes: https://pagure.io/freeipa/issue/9421
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The user and stageuser commands return the following error
when the user is created/updated with a non existing idp:
$ ipa user-add testuser --first test --last user --idp dummy
ipa: ERROR: no such entry
The error is not descriptive enough and has been modified to
display instead:
$ ipa user-add testuser --first test --last user --idp dummy
ipa: ERROR: External IdP configuration dummy not found
Fixes: https://pagure.io/freeipa/issue/9416
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
A host uses Location (nshostlocation) as an optional hint where
a host may phsyically be located (e.g. Lab 2). This will result in
an attribute in the host entry like:
nshostlocation: Lab 2
A server uses location (ipalocation) to identify which DNS location
the server is part of (e.g. prague). This will result in an attribute
in the server entry like:
ipalocation: idnsname=prague,cn=locations,cn=etc,dc=example,dc=test
They are completely different animals.
https://pagure.io/freeipa/issue/9317
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
There are 2 possible methods to rename users and groups:
- either use ipa user|group-mod oldname --rename newname
- or use settattr:
ipa user-mod oldname --setattr uid=newname
ipa group-mod oldname --setattr cn=newname
The first method validates the new name but the second method
doesn't. Add a validation to make both methods consistent
Fixes: https://pagure.io/freeipa/issue/9396
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
cert-find is a rather complex beast because it not only
looks for certificates in the optional CA but within the
IPA LDAP database as well. It has a process to deduplicate
the certificates since any PKI issued certificates will
also be associated with an IPA record.
In order to obtain the data to deduplicate the certificates
the cert from LDAP must be parser for issuer and serial number.
ipaldap has automation to determine the datatype of an
attribute and will use the ipalib.x509 IPACertificate class to
decode a certificate automatically if you access
entry['usercertificate'].
The downside is that this is comparatively slow. Here is the
parse time in microseconds:
cryptography 0.0081
OpenSSL.crypto 0.2271
ipalib.x509 2.6814
Since only issuer and subject are required there is no need to
make the expensive IPACertificate call.
The IPACertificate parsing time is fine if you're parsing one
certificate but if the LDAP search returns a lot of certificates,
say in the thousands, then those microseconds add up quickly.
In testing it took ~17 seconds to parse 5k certificates (excluding
transmission overhead, etc).
cert-find when there are a lot of certificates has been
historically slow. It isn't related to the CA which returns
large sets (well, 5k anyway) in a second or two. It was the
LDAP comparision adding tens of seconds to the runtime.
When searching with the default sizelimit of 100 the time is
~10s without this patch. With it the time is 1.5s.
CLI times from before and after searching for all certs:
original:
-------------------------------
Number of entries returned 5038
-------------------------------
real 0m15.507s
user 0m0.828s
sys 0m0.241s
using cryptography:
real 0m4.037s
user 0m0.816s
sys 0m0.193s
Fixes: https://pagure.io/freeipa/issue/9331
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This reverts commit 1f30cc6527.
The problem isn't with python-cryptography, it is with the
IPACertificate class which does way more work on a certificate
than is necessary in cert-find.
Related: https://pagure.io/freeipa/issue/9331
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This reverts commit 191880bc9f.
The problem isn't with python-cryptography, it is with the
IPACertificate class which does way more work on a certificate
than is necessary in cert-find.
Related: https://pagure.io/freeipa/issue/9331
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Add a "Passkey configuration" subtab in the "Policy" tab,
showing the settings for passkeyconfig.
Related: https://pagure.io/freeipa/issue/9261
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The passkey is a long string and not user-friendly.
Instead of showing the whole passkey in the webui, only show
the id part and a string for discoverable or server-side passkey.
Related: https://pagure.io/freeipa/issue/9261
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Display the passkey value for user or stageuser
in the user details page
Allow addition/removal of a passkey
Related: https://pagure.io/freeipa/issue/9261
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Apart from server-side credentials passkey should also register
discoverable credentials.
ipa user-add-passkey --register now supports an additional option,
--cred-type server-side|discoverable
that is propagated to passkey_child command.
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Currently supports a single parameter:
--require-user-verification [ 'on', 'off', 'default']
Related: https://pagure.io/freeipa/issue/9261
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This condition was checked in group-add but not in group-mod.
This evaluation is done later in the pre_callback so that all
the other machinations about posix are already done to make
it easier to tell whether this condition is true or not.
Fixes: https://pagure.io/freeipa/issue/8990
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The commands ipa user-add or ipa group-add validate the
format of the user/group name and display the following
message when it does not conform to the expectations:
invalid 'login': may only include letters, numbers, _, -, . and $
The format is more complex, for instance '1234567' is an invalid
user name but the failure is inconsistent with the error message.
Modify the error message to point to ipa help user/group and add
more details in the help message.
Same change for idoverrideuser and idoverridegroup:
The user/group name must follow these rules:
- cannot contain only numbers
- must start with a letter, a number, _ or .
- may contain letters, numbers, _, ., or -
- may end with a letter, a number, _, ., - or $
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2150217
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
If a cert-find fails on the CA side we get a Message tag
containing a string describing the failure plus the java stack
trace. Pull out the first part of the message as defined by the
first colon and include that in the error message returned to
the user.
The new message will appear as:
$ ipa cert-find
ipa: ERROR: Certificate operation cannot be completed: Unable to search for certificates (500)
vs the old generic message:
ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (500)
This can be reproduced by setting nssizelimit to 100 on the
pkidbuser. The internal PKI search returns err=4 but the CA
tries to convert all values into certificates and it fails. The
value needs to be high enough that the CA can start but low
enough that you don't have to create hundreds of certificates
to demonstrate the issue.
https://pagure.io/freeipa/issue/9369
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The command ipa idview-show NAME has a post callback
method that replaces the ID override anchor with the corresponding
user name.
For instance the anchor
ipaanchoruuid=:SID:S-1-5-21-3951964782-819614989-3867706637-1114
is replaced with the name of the ad user aduser@ad.test.
The method loops on all the anchors and for each one performs the
resolution, which can be a costly operation if the anchor is for
a trusted user. Instead of doing a search for each anchor, it is
possible to read the 'ipaOriginalUid' value from the ID override
entry.
Fixes: https://pagure.io/freeipa/issue/9372
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
When ipa cert-find --all is called, the function prints the
certificate public bytes. The code recently switched to OpenSSL.crypto
and the objects OpenSSL.crypto.X509 do not have the method
public_bytes(). Use to_cryptography() to transform into a
cryptography.x509.Certificate before calling public_bytes().
Related: https://pagure.io/freeipa/issue/9331
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
cert-find is a rather complex beast because it not only
looks for certificates in the optional CA but within the
IPA LDAP database as well. It has a process to deduplicate
the certificates since any PKI issued certificates will
also be associated with an IPA record.
In order to obtain the data to deduplicate the certificates
the cert from LDAP must be parser for issuer and serial number.
ipaldap has automation to determine the datatype of an
attribute and will use the python-cryptography engine to
decode a certificate automatically if you access
entry['usercertificate'].
The downside is that this is comparatively slow. Here is the
parse time in microseconds:
OpenSSL.crypto 175
pyasn1 1010
python-cryptography 3136
The python-cryptography time is fine if you're parsing one
certificate but if the LDAP search returns a lot of certificates,
say in the thousands, then those microseconds add up quickly.
In testing it took ~17 seconds to parse 5k certificates.
It's hard to overstate just how much better the cryptography
Python interface is. In the case of OpenSSL really the only
certificate fields easily available are serial number, subject
and issuer. And the subject/issuer are in the OpenSSL reverse
format which doesn't compare nicely to the cryptography format.
The DN module can correct this.
Fortunately for cert-find we only need serial number and issuer,
so the OpenSSL module fine. It takes ~2 seconds.
pyasn1 is also relatively faster but switch to it would require
subtantially more effort for less payback.
cert-find when there are a lot of certificates has been
historically slow. It isn't related to the CA which returns
large sets (well, 5k anyway) in a second or two. It was the
LDAP comparision adding tens of seconds to the runtime.
CLI times from before and after:
original:
-------------------------------
Number of entries returned 5011
-------------------------------
real 0m21.155s
user 0m0.835s
sys 0m0.159s
using OpenSSL:
real 0m5.747s
user 0m0.864s
sys 0m0.148s
OpenSSL is forcibly lazy-loaded so it doesn't conflict with
python-requests. See ipaserver/wsgi.py for the gory details.
Fixes: https://pagure.io/freeipa/issue/9331
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Antonio Torres <antorres@redhat.com>
The sizelimit option was not being passed into the dogtag
ra_find() command so it always returned all available certificates.
A value of 0 will retain old behavior and return all certificates.
The default value is the LDAP searchsizelimit.
Related: https://pagure.io/freeipa/issue/9331
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Antonio Torres <antorres@redhat.com>
IPA API commands to manage RBCD access controls.
Fixes: https://pagure.io/freeipa/issue/9354
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
We need to deepcopy the list of default objectlasses from IPA config
before assigning it to an entry, in order to avoid further modifications of the
entry affect the cached IPA config.
Fixes: https://pagure.io/freeipa/issue/9349
Signed-off-by: Antonio Torres <antorres@redhat.com>
Reviewed-By: Francisco Trivino <ftrivino@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
When you run "ipa idp-show <idp reference>" the IdP reference is shown
as "Identity Provider server name". This is confusing as we are pointing
to the earlier created IdP reference rather than a server. Other files
are updated as well to reflect this change.
Additionally some typos are fixed with this patch too.
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The doc string located in the 'Authentication
indicators' ('Services' settings page) was
missing the usage explanation for the 'ipd'
checkbox option.
Fixes: https://pagure.io/freeipa/issue/9338
Signed-off-by: Carla Martinez <carlmart@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
The automember-rebuild task may require high CPU usage
if many users/hosts/groups are processed.
Add a note in the ipa automember-rebuild CLI output
and in the WebUI confirmation message.
Fixes: https://pagure.io/freeipa/issue/9320
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Francisco Trivino <ftrivino@redhat.com>
When ipa trust-add is executed with --range-type ad-trust-posix,
the server tries to find the max uidnumber and max gidnumber
from AD domain controller.
The values are extracted from the entry
CN=<domain>,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,<AD suffix>
in the msSFU30MaxUidNumber and msSFU30MaxGidNumber attributes.
msSFU30MaxUidNumber is required but not msSFU30MaxGidNumber.
In case msSFU30MaxGidNumber is missing, the code is currently assigning
a "None" value and later on evaluates the max between this value and
msSFU30MaxUidNumber. The max function cannot compare None and a list
of string and triggers an exception.
To avoid the exception, assign [b'0'] to max gid if msSFU30MaxGidNumber
is missing. This way, the comparison succeeds and max returns the
value from msSFU30MaxUidNumber.
Fixes: https://pagure.io/freeipa/issue/9310
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
https://pylint.pycqa.org/en/latest/user_guide/messages/convention/unnecessary-lambda-assignment.html:
> Used when a lambda expression is assigned to variable rather than
defining a standard function with the "def" keyword.
https://peps.python.org/pep-0008/#programming-recommendations:
> Always use a def statement instead of an assignment statement that
binds a lambda expression directly to an identifier:
def f(x): return 2*x
f = lambda x: 2*x
The first form means that the name of the resulting function object is
specifically ‘f’ instead of the generic ‘<lambda>’. This is more useful
for tracebacks and string representations in general. The use of the
assignment statement eliminates the sole benefit a lambda expression can
offer over an explicit def statement (i.e. that it can be embedded
inside a larger expression)
Fixes: https://pagure.io/freeipa/issue/9278
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Stanislav Levin <slev@altlinux.org>
