1

In OpenVPN GUI, I am getting the red message

WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this.

I do not want to always re-type my password again and again. Is there a way to suppress the warning without using the auth-nocache option?

I do not want to get myself used to habitually ignoring a red warning in the log dialog. This bad habit might prevent me from noticing an actual issue in the future. We have @SuppressWarning in Java for exactly the same reason.

I want to emphasize that I am not choosing between security and convenience, but I am asking for higher security! Multiple internet sources I found on this warning (e.g. here, here or here) tell that the risk is minimal. However the risk that I become used to ignore warnings seems much higher to me.

Honza Zidek
  • 190
  • 11
  • Why won't you just *ignore* this warning? – Nikita Kipriyanov Jul 02 '22 at 04:47
  • @NikitaKipriyanov It's called "no warning policy". Getting used to ignoring warnings is a bad habit. Either **solve** or **suppress** a warning (after you understand its meaning and consequences), but **never ignore**. Some companies, e.g. Google, have even set their compilers to report all warnings as errors and break the build, so the developers don't get used to ignoring warnings. – Honza Zidek Jul 02 '22 at 12:58
  • @NikitaKipriyanov OpenVPN GUI shows the log while connecting and warnings are displayed in red. I want to stay able to catch visually something wrong. If I get used to seeing the red color every time I am connecting, I will lose this sense. And I will overlook a real problem. Not letting users or admins to suppress individual warnings is a bad design and it goes against security. – Honza Zidek Jul 02 '22 at 13:22
  • A-ha, I remember, the same stupid policy lead to the introduction of [CVE-2008-0166](https://github.com/g0tmi1k/debian-ssh) in Debian. They broken the PRNG by *resolving or silencing Valgrind warnings* in the OpenSSL source. – Nikita Kipriyanov Jul 02 '22 at 16:30
  • @NikitaKipriyanov Actually the case mentioned here is yet another argument for my statement :) Instead of suppressing the warning (with the comment in the code that the warning here is OK), they removed the code causing the warning. That's **not** what *no-warning policy* means, this is suboptimization instead. They indeed silenced the warning... – Honza Zidek Jul 03 '22 at 20:06
  • 1
    @HonzaZidek I completely agree. I upvoted the question, as I'm having the same concerns as you do. – julien.giband Sep 12 '22 at 12:11

0 Answers0