Investigate moving OS specific Socket and Thread to the Patch Page

[noloader]

Denis Bider offered some arguments to remove some code from the library at issue 23: Recent Windows 8 and Windows 10 support broke Windows 7/VS 2012. If I am parsing the comment correctly, DB suggests removing Socket, Pipe and Thread from the library. Its not clear if it includes the related Sources and Sinks.

I'd like to use this bug report to capture feedback, discover if anyone is using the classes, and track which files and classes are potential targets.

I know some of the classes are being used in the test program.

---

The Crypto++ wiki has a Patch Page. Its for components that may be useful to others, but don't quite fit into the library proper. If anything gets removed, then they surely would be placed there.

[zabulus]

Fully agree. It makes much questions about what pipes, threads and so on are doing in crypto library.

[zabulus]

Also cutting these parts will simplify further porting of stuff

[DevJPM]

TL;DR: I'm pro-removal.

A quick search showed that it was added in 4.0 and there's also a mention of sinks and sources in 5.0 related to sockets, so it's obviously only in the library so you can stream from a socket or a pipe into Crypto++'s filter system (decrypt, verify, decompress, decode it) and then have it at hand. So the original intent was to not limit people to files but also allow them to use advanced IPC and network communication methods with this fancy mechanism of filters, sources and sinks.

So far for the history lesson. Nowadays we don't need this any longer at network level. We have Boost.ASIO (or your favorite networking library) and we have libraries like OpenSSL, LibreSSL, BoringSSL, GnuTLS, s2n, cryptlib,... which can all handle TLS (a really good protocol for most use-cases) so I don't think we should encourage people here to "roll their own". And if people really need more lightweight encryption, there's our patch-page and of course cryptlib ;)

[noloader]

Also see Remove Thread and Socket classes on the mailing list. We are testing the change now on a Testing fork.

The only sore spot was in fips140.cpp and the self-test code:

#if CRYPTOPP_ENABLE_COMPLIANCE_WITH_FIPS_140_2
ThreadLocalStorage & AccessPowerUpSelfTestInProgress()
{
	static ThreadLocalStorage selfTestInProgress;
	return selfTestInProgress;
}
#endif
bool PowerUpSelfTestInProgressOnThisThread()
{
#if CRYPTOPP_ENABLE_COMPLIANCE_WITH_FIPS_140_2
	return AccessPowerUpSelfTestInProgress().GetValue() != NULLPTR;
#else
	CRYPTOPP_ASSERT(false);	// should not be called
	return false;
#endif
}
void SetPowerUpSelfTestInProgressOnThisThread(bool inProgress)
{
	CRYPTOPP_UNUSED(inProgress);
#if CRYPTOPP_ENABLE_COMPLIANCE_WITH_FIPS_140_2
	AccessPowerUpSelfTestInProgress().SetValue((void *)inProgress);
#endif
}

It was changed to:

// One variable for all threads for compatibility. Previously this
// was a ThreadLocalStorage variable, which is per-thread. Also see
// https://github.com/weidai11/cryptopp/issues/208
static bool s_inProgress = false;

bool PowerUpSelfTestInProgressOnThisThread()
{
	return s_inProgress;
}

void SetPowerUpSelfTestInProgressOnThisThread(bool inProgress)
{
	s_inProgress = inProgress;
}

[noloader]

Sockets and Threads were removed at Commit f2171cbe2f49.