CRAN rejection for tidyverse dependencies not in mainstream repositories

We submitted a package this morning to CRAN, but it was rechecked because of pre-checks on the windows build. The Debian build was perfectly fine, but it looks like the windows build isn't seeing tidyverse packages in any mainstream repo.

One thing that's noteable is that the CRAN submission used R under development for the R version. This seems odd for a CRAN post. Is there a way to make sure that the latest stable version is used? Or is this possibly something temporary while the tidyverse packages are making their way back up? We tested using win-builder prior to submitting. We don't have any strong OS dependencies either, so at first glance this seems like it's not our issue.

The failed URL check also seems off - it worked fine with Debian, and the link is just to our our code coverage tag, which is indeed there.

CRAN feasibility check messages that flagged below.

* using log directory <blanking out>
* using R Under development (unstable) (2020-08-31 r79098)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file '<blanking out>/DESCRIPTION' ... OK
* this is package <blanking out>
* package encoding: UTF-8
* checking CRAN incoming feasibility ... WARNING
Maintainer: <blanking out>

New submission

Strong dependencies not in mainstream repositories:
  rlang, magrittr, dplyr, purrr, stringr, tidyr, tidyselect, tibble,
    lifecycle, forcats
Suggests or Enhances not in mainstream repositories:
  testthat, haven, knitr, rmarkdown, huxtable, tidyverse, readr,
    kableExtra, pharmaRTF

Found the following (possibly) invalid URLs:
  URL: https://codecov.io/gh/ <blanked out>
    From: README.md
    Status: Error
    Message: libcurl error code 35:
        schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed).

It appears that this was an issue with the CRAN check machine and a timing issue. We resubmitted and tests passed as expected. If you encounter a similar issue, and you can confirm that there do not appear to be any issues with your package, I encourage you to do the same and wait then re-submit.