Bug 14421

FEATURE_WGET_HTTPS is, lets say, somewhat controversial. it has its very own CVE... :) here are a couple of suggestions to improve it.

1) require '--no-check-certificate' when accessing HTTPS resources (or else a failure message describing this requirement would be printed). this option exists in native wget and would end all discussions. the intention is clear: only be insecure if the user explicitly allows it. the principle "what you don't know won't hurt you" is a very important one to keep. (current printed warning should be kept anyway.)

2) if 1) is implemented, consider changing FEATURE_WGET_HTTPS to the new behavior. a new build flag would be included to enable previous behavior, but this would force builders to explicitly request the controversial, transparently insecure behavior. alternatively, two new build flags could be introduced, and FEATURE_WGET_HTTPS retired causing a build failure if defined. this forces an informed choice, and is in line with "what you don't know won't hurt you".

3) if the current issues with data signature are solved, then HTTPS could be made secure in a specific context. either one of '--no-check-certificate' or '--pinnedpubkey=FILE/HASHES' would be required. the user would have the option of providing a server cert o cert hash to allow for secure downloads without the complete public key infrastructure. this would be great: people everywhere would finally be able to bootstrap securely in small systems. if implementing wget's '--pinnedpubkey=' is too cumbersome, you could define your own simplified flag for this function. or a specific format for the existing flag could be required to ease implementation.