From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH manager] ui: storage: esxi: check 'skip certificate verification' by default
Date: Fri, 22 Mar 2024 09:46:25 +0100 [thread overview]
Message-ID: <236a178a-ca71-41ee-b443-ea594d6f447d@proxmox.com> (raw)
In-Reply-To: <f2a330f1-db73-4037-abe4-1fdab4631a79@proxmox.com>
On 22/03/2024 08:29, Dominik Csapak wrote:
> On 3/21/24 18:07, Thomas Lamprecht wrote:
>> On 20/03/2024 16:39, Dominik Csapak wrote:
>>> needing one less step when adding the storage, assuming most esxi
>>> certificates are self-signed.
>>
>> Well this makes it insecure by default though? Which is not something
>> I'd just not mention in such a commit message...
>
> imho it is very obvious what it does from the commit subject?
>
> 'skipping the certificate verification'
>
> ?
> but ok, i can add a sentence more in the description..
as always, the reasoning and why's count a bit more in such
cases – making the default insecure is something where a giving
a reason for why this is OK is rather a must...
>> As that was the original reason I ticked it in the first place
>> when pondering between security and convenience...
>>
>
> the thought here was that users that make the effort of giving
> their esxi instances valid certificates, can simply uncheck the checkbox?
So can the others?! And that would be pretty obvious if the error
message gets passed through like I requested already off list over
a week ago..
As again... this is making the connection completely insecure, and
users with valid certs won't be notified of that fact "so simply check"
it is really not something a user can be aware of if it "works" without
enabling basic security..
> and i guess many of the users won't bother doing that for the
> esxi instances? (e.g. vcenter does not make that distinction, all
> it does is ask for hostname/ip + password, and cert management seems
> to be non-trivial)
again, not an argument for why we should make it less secure.
>> If we do this I'd rather rename it to "Check Certificate" and have
>> that unticked.
>
> ok makes sense, i'd name it 'verify certificate' though to be in line
> with our realm/metric server wording
>
> also should this be only in the frontend, or do we want to reverse
> the api/config option as well?
No, I'd keep it off there, so having the user pass the --skip- option
makes it more clear.
But tbh. I probably won't apply this in any way, as mentioned there
are other ways to actually improve on this, the error message would
be a relatively easy first one.
next prev parent reply other threads:[~2024-03-22 8:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-20 15:39 Dominik Csapak
2024-03-21 17:07 ` Thomas Lamprecht
2024-03-22 7:29 ` Dominik Csapak
2024-03-22 8:46 ` Thomas Lamprecht [this message]
2024-03-22 9:07 ` Dominik Csapak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=236a178a-ca71-41ee-b443-ea594d6f447d@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.