This is feature is workaround for #2628 (JumpCloud) and some other services
that allow LDAP search only under BindDN user account, but not allow any LDAP
search query in logged user DN context.
Such approach is an alternative to minimal permissions security pattern for
BindDN user.
According to RFC 4511 4.2.1. Processing of the Bind Request "Clients may send
multiple Bind requests to change the authentication and/or security
associations or to complete a multi-stage Bind process. Authentication from
earlier binds is subsequently ignored."
Therefore we should not use 2 connections, but single one just sending two bind
requests.
- s6 is in main in 3.3, so we no longer need to mangle the repos file
- official image is periodically updated, so it's not preferred to do
upgrades downstream (usually harmless, but inelegant)
- apk-tools in 3.3 supports --no-cache to avoid leaving the APKINDEX
files in the image
When <code> is nested inside <pre>, the next end tag token would not able to be the same
as outer-most start tag. So we only check outer-most start and end tag token to be the same.
Remove the possibility of using email as user name when user actually push
through combination of email and password with HTTP.
Also refactor update action function to replcae tons of arguments with
single PushUpdateOptions struct.
And define the user who pushes code as pusher, therefore variable names shouldn't
be confusing any more.
The old API was using []byte, but was changed to string without running
the tests again.
It also sets the variables from the configuration to make them work.
Maybe there is a better way to do this.
This commit adds the possibibility to use either the native golang
libraries or ssh-keygen to check public keys. The check is adjusted
depending on the settings, so that only supported keys are let through.
This commit also brings back the blacklist feature, which was removed in
7ef9a05588. This allows to blacklist
algorythms or keys based on the key length. This works with the native
and the ssh-keygen way.
Because of #2179 it also includes a way to adjust the path to
ssh-keygen and the working directory for ssh-keygen. With this,
sysadmins should be able to adjust the settings in a way, that SELinux
is okay with it. In the worst case, they can switch to the native
implementation and only loose support for ed25519 keys at the moment.
There are some other places which need adjustment to utilize the
parameters and the native implementation, but this sets the ground work.
