The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #10102 ([experimental] Multiprocess bitcoin by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Concept ACK

Concept ACK

Operating systems and Boost availability:

Debian

• Jessie - 1.55.x
• Stretch - 1.62.x
• Buster - 1.67.x

macOS

• brew - 1.70.x
• macports - 1.66.x

Fedora

• 28 ?
• 29 - 1.66.x
• 30 - 1.69.x

FreeBSD

• 11 - 1.70.x
• 12 - 1.70.x

OpenBSD

• Had >=1.53.x since 2013

NetBSD

• 7, 8 - 1.69.x

Ubuntu

• Trusty - 1.54.x
• Xenial - 1.58.x
• Bionic - 1.65.x
• Disco - 1.67.x

I don't see the point of bumping the minimum version if there's no strong reason to require the new version, IMO.

We are trying to, in time, get rid of the boost requirement completely at some point, and reduce usage of it as much as possible (e.g. boost::chrono will go completely and be replaced by std::chrono). It's unlikely we'll really require some newer version, and it's fine to require these work-arounds until then IMO.

I think it is reasonable to drop the workarounds, since they are no longer tested by anyone. For the same reason we dropped windows xp support.

True, but almost all of them are about time/sleep things, and we'd get rid of those anyway when switching to std::chrono.

There have been a few abandoned attempts in the past, so I wouldn't be too optimistic that this is happening any time soon:

• util: Replace boost:: with std:: in utiltime util: Replace boost sleep with std sleep #16117
• refactor: Drop boost::thread and boost::chrono refactor: Drop boost::thread and boost::chrono #14489
• threading: use std::chrono for timestamps threading: use std::chrono for timestamps #9566

Sure, but is there any hurry, at all?

To be honest I prefer the policy to touch the boost parts as little as possible until the dependency can be dropped whole-sale, and not unnecessarily require a newer boost.

I do agree it's unlikely for people to still have a boost <1.53.0, so I'm not against this specific change, but I think otherwise it'd be a waste of time forcing people to upgrade a dependency that we don't really want to use in the first place, and without a pressing need such as a CVE.

there was a CVE for boost 1.48 till 1.52: https://www.cvedetails.com/cve/CVE-2013-0252/ but I'm sure it was patched in distros and upgrading to >= 1.53 isn't absolutely necessary?

From the network we only accept sanitized strings (a subset of ascii), so this CVE shouldn't be a problem

Rebased.

Agree with @laanwj

Let's wait for a real reason to require a bump.

Ok, closing this for now then.

It looks like 1.47 won't build, since we use wait_until in src/rpc/mining.cpp and src/net.cpp with no fallbacks. Maybe we should bump this just because it's broken and untestable.

It looks like 1.47 won't build, since we use wait_until in src/rpc/mining.cpp and src/net.cpp with no fallbacks. Maybe we should bump this just because it's broken and untestable.

It seems only src/scheduler.cpp has fallback.

I'm wrong. Those other wait_until are std, not boost.

But I don't know it does work either. Maybe we should just go ahead with the bump...

🐙 This pull request conflicts with the target branch and needs rebase.

Going to re-close.

Maybe for 0.22, we could consider boost 1.58 as minimum. Though, I'd rather not boost by then.