Curl --insecure and wget --no-check-certificate in scripts/download.pl

Is turning off cert validation really necessary? This seems like a security risk to me. I've removed it and it doesn't stop me from downloading the bare minimum + LuCI. What kind of package source needs this to be downloaded, and is there a better way to resolve it instead of disabling cert validation for everything?

Edit: in case I didn't make myself clear, I'm building openwrt from source, so it makes sense to do my best to ensure the sources that I retrieve from the internet are genuine. My question is why isn't this a default behavior, and what's preventing openwrt to remove these insecure options in the perl script?

Edit2: This is also a privacy issue. The fact that anyone looking at your traffic can determine what you've downloaded by size doesn't mean it's okay to give up on transport security. For anyone who have the same concerns, just do sed -i 's/\s--insecure\|\s--no-check-certificate//g' scripts/download.pl. I have not observed any side effects while compiling images with a basic package set.

99% of packages are checksum'd on the way down.
While I get your point, does it matter?

One simply doesn't deliberately weaken their setup for no significant benefits. I'm asking about it because I'd like to know the rationale behind these, perhaps there are some valid reasons that I did not know about.

1 Like

To save flash space, by default the set of "trusted" top level root certificates is not installed (package ca-certificates).

Also at default curl is not present, only a BusyBox version of wget compiled without SSL support (SSL libraries are quite large). The OpenWrt server does accept http connections.

3 Likes

I fully understand why there are no ssl support by default on the target image, but I'm not talking about the target image here, download.pl is called when downloading package sources during the build process, and it's critical that the source files retrieved in this process are in fact genuine.

2 Likes

HTTPS provides no integrity guarantees, we rely on SHA256 checksums to verify the integrity of downloaded artifacts. In the past there's been various download servers which frequently had broken HTTPS setups in the past, so the sanest choice was to disable certificate checking.

1 Like

Does this also apply to the source retrieval during the building process?

Yes, sources are pinned to Git SHA1 sums which guarantee the integrity of the entire hash tree beneath. Additionally we provide mirror SHA256 sums for cached scm clones and implemented reproducible tarball creation.

Tarball downloads are checked for their expected SHA256 checksums.

Subversion or CVS repos might be susceptible to MITM since fetching a specific revision does not guarantee tree integrity, but HTTPS wouldn't solve this either. Besides, to my knowledge no package uses CVS and only a single digit number of external non-defualt packages relies on Subversion SCM clones.

2 Likes

Thank you for the explanation, this is very helpful.

Is there a quick(/built-in) way of listing these? (Or even better, check them against my diffconfig?)

$ grep -r PKG_SOURCE_PROTO | grep -vE 'PKG_SOURCE_PROTO.*git' 
net/vpnc/Makefile:PKG_SOURCE_PROTO:=svn
utils/lcd4linux/Makefile:PKG_SOURCE_PROTO:=svn
1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.