WARN message is suddenly printed on each mc calls

[xtian-socgen]

This is related to the PR #4989 which was merged 4 months ago.
Related code is: cmd/main.go#L511-L521.

IMHO, this is very bad for the user experience.
At least, please make this option an opt-in, even though I still don't see any reason to keep it.

Expected behavior

Do not print WARN messages not related to mc command.
There is no reason to print a WARN when I mc ls if not related to the ls itself.

Actual behavior

When I use mc ls, I now have a WARN message reporting the certificate will expire soon (in 2 months).
This is not relevant, as there is nothing I can do here.

[0] > mc ls www/mybucket/myfile
[2024-10-16 12:19:45 CEST] ...

== WARN: `xxx.xxx.xxx` certificate will expire in 2025-01-25 10:16:45 +0000 UTC. Renew soon to avoid outage.

Hopefully, this is not yet happening for Amazon S3 or with the -json flag.

Steps to reproduce the behavior

mc --version

[0] > mc --version
mc version RELEASE.2024-10-08T09-37-26Z (commit-id=cf128de2cf42e763e7bd30c6df8b749fa94e0c10)
Runtime: go1.22.8 linux/amd64
Copyright (c) 2015-2024 MinIO, Inc.
License GNU AGPLv3 <https://www.gnu.org/licenses/agpl-3.0.html>

System information

[harshavardhana]

IMHO, this is very bad for the user experience.
At least, please make this option an opt-in, even though I still don't see any reason to keep it.

why? - this is an opinion; provide an explanation technically why this is not the right thing to provide.

[xtian-socgen]

Let's say it differently, I didn't want to be rude :)

This is the same as if curl started to warn me each time I curl an https site that the certificate will expire in 2 months (1 year for a 10 years certificate), even if I'm not in verbose or debug mode. This will definitely degrade the user experience of all users of curl.

As I'm not the s3 administrator, this is not relevant, and because the certificate will only be changed a few days before its expiration, this is giving a bad user experience showing an unnecessary warning for nothing.

Of course I could redirect the stderr to /dev/null to prevent this, however I'll lose error messages because of this, which is not god either, as stderr is not meant to be used as a debug/verbose output unless specifically specified.

And finally, if or when this will happen for Amazon S3, the whole world using mc will see this warning.

I guess the original idea was to be able to identify that the certificate will expire "soon", but mc is not the right tool to check these sort of things.
There are plenty of other ways to do that, including using openssl tool to get expiration in days.

[harshavardhana]

mc and curl are not the same.

mc is used for administrative purposes, and in our experience, we have seen our customers go without noticing expiring certificates, which eventually causes an outage.

That's why comparing mc with curl is just hyperbole, invalid, and lacks understanding of what mc is.

Amazon S3 won't expire in such a manner, and let's hope not, but it would be nice to know if it ever experiences an outage like this.

However, we built mc for MinIO, which serves that purpose well for our customers, so the PR has been sent here to tune this down to 28 days instead.