The interface here is a bit weird - if the verify callback returns 1
for a certificate higher up in the chain, this will propagate to the
next invocation of the callback for the next certificate, even if
openssl on its own would not trust the certificate.
By re-ordering the checks and keeping track of the fact that we
returned 1 despite openssl failing its own validation, the validation
logic should now cover all combinations of certificate count and
self-signed/system trust status.
Note that in PVE we should instantiate the API client with
`pve_new_format` in order to have this client also switch to
the new mechanism, otherwise the old api will be used which
does not support multiple factors or recovery keys.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Oguz Bektas [Fri, 16 Aug 2019 11:51:34 +0000 (13:51 +0200)]
fix #2227: enable totp codes to be passed in cli
this patch enables to pass totp codes during cluster join if tfa has
been enabled for root@pam (or any other user actually, but having it enabled on
root causes problems during cluster join).
u2f support is not yet implemented.
Co-developed-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Co-developed-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Oguz Bektas [Thu, 27 Jun 2019 16:00:48 +0000 (18:00 +0200)]
check for tfa during cluster join, abort if yes
momentarily, we check for tfa in the cluster join and abort if it's
enabled, since the tfa ticket is not being handled correctly atm, which
caused a '401 No ticket' error[0][1].
todo is to ask with a prompt on gui and cli to enable totp and possible
u2f in the future
Thomas Lamprecht [Mon, 22 Jan 2018 09:52:13 +0000 (10:52 +0100)]
avoid harmful '<>' pattern, explicitly read from STDIN
Fixes problems in CLIHandler using the code pattern:
while (my $line = <>) {
...
}
For why this causes only _now_ problems lets first look how <>
behaves:
"The null filehandle <> is special: [...] Input from <> comes either
from standard input, or from each file listed on the command line.
Here's how it works: the first time <> is evaluated, the @ARGV array
is checked, and if it is empty, $ARGV[0] is set to "-" , which when
opened gives you standard input. The @ARGV array is then processed
as a list of filenames." - 'perldoc perlop'
Recent changes in the CLIHandler code changed how we modfiied @ARGV
Earlier we assumed that the first argument must be the command and
thus shifted it out of @ARGV, now we can have multiple levels of
(sub)commands. This change also changed how we handle @ARGV, we do
not unshift anything but go through the arguments until we got to
the final command and copy the rest of @ARGV as we know that this
must be the commandos arguments.
For '<>' this means that ARGV was still fully populated and perl
tried to open element as a file, which naturally failed.
Thus the change in pve-common only exposed this 'dangerous' code
pattern.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Thu, 14 Dec 2017 10:12:06 +0000 (11:12 +0100)]
raise exception if manual fingerprint verification failed
If a fingerprint could not be verified automatically or manually
raise an exception to ensure that we do not continue with handling
the problematic or even evil response.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Thu, 14 Dec 2017 10:12:05 +0000 (11:12 +0100)]
use new Exception.pm class to signal errors to caller
Allows a caller to acces the HTTP response code, which may be useful
to handle application logic. E.g., catching a HTTP_NOT_IMPLEMENTED
and fallback to an older method.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Thu, 14 Dec 2017 10:12:04 +0000 (11:12 +0100)]
add APIClient/Exception.pm class
As we do not want to depend on PVE libraries with this I forked of
the PVE::Exception class, removed all raise_* methods so that only
raise() itself was left over.
Also some minor adaptions to newer style for exporting where used.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>