Bump some deps

[0xPoe]

1. Bump the openssl v0.10.52 -> v0.10.55 to address the security alert. https://github.com/rust-lang/rustup/security/dependabot
2. Bump proc-macro2 v1.0.51 -> v1.0.63 to make rustup complile. See Delete use of proc_macro::Span::before/after dtolnay/proc-macro2#391.

[weihanglo]

Should we update here as well?

rustup/Cargo.toml

Lines 99 to 104 in 137a99b

	[dependencies.openssl]
	# Used by `curl` or `reqwest` backend although it isn't imported by our rustup :
	# this allows controlling the vendoring status without exposing the presence of
	# the download crate.
	optional = true
	version = "0.10"

[0xPoe]

Should we update here as well?

I updated it with cargo update -p openssl, so I guess we don't need to change it to 0.10.55 explicitly.
I tested it locally:

➜  rustup git:(master) cargo tree -i -p openssl --target all               
openssl v0.10.55
└── native-tls v0.2.11
    ├── hyper-tls v0.5.0
    │   └── reqwest v0.11.17
    │       └── download v1.26.0 (/Volumes/t7/code/rustup/download)
    │           └── rustup v1.26.0 (/Volumes/t7/code/rustup)
    ├── reqwest v0.11.17 (*)
    └── tokio-native-tls v0.3.1
        ├── hyper-tls v0.5.0 (*)
        └── reqwest v0.11.17 (*)

We only have one version openssl in its dependencies.

Thanks for your review! 💚 💙 💜 💛 ❤️

[weihanglo]

Yep but it depends on whether or not we allow openssl older 0.10.55 to be built with rustup. Some pros:

• Cargo's resolver may sometimes converge to downgrade something, this may help us avoid accidental oversight of a PR that downgrades a version in lockfile.
• People that build their own rustup would get a guarantee of having the new version with the security update.

The counterargument is obviously we then force everyone use 0.10.55 or newer.

[weihanglo]

I'd say it must be pretty rare that people build rustup on their own, but still there AFAIK.

[0xPoe]

• Cargo's resolver may sometimes converge to downgrade something, this may help us avoid accidental oversight of a PR that downgrades a version in lockfile.

For this case, the CI may help us to avoid this kind of situation.

• People that build their own rustup would get a guarantee of having the new version with the security update.

We already checked the lock file in our repo. Do you mean users will use it as a package?

[weihanglo]

Yes. As a dependency. Cargo usually tries to make them in sync for the manifest and the lockfile. It's not really a big deal. So go ahead!

[0xPoe]

Yes. As a dependency.

The use of rustup as a dependency should be rare. Thank you for your review.