On Wed, Jan 17, 2018 at 11:33 AM, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > On Wed, Jan 17, 2018 at 10:36 AM, Casey Bodley <cbodley@xxxxxxxxxx> wrote: >> I'm trying to pick up Adam's crypto rework branch >> (https://github.com/ceph/ceph/pull/14498), and found that our cryptopp >> implementation was broken with the switch to c++17. Cryptopp adds a 'typedef >> unsigned char byte' to the global namespace that conflicts with std::byte >> whenever 'using namespace std' is present (which is almost everywhere in >> ceph). >> >> I've been able to fix some parts of the codebase by shuffling around the >> #include order for ceph_crypto.h to get it above any other ceph headers. For >> radosgw, though, it's included by rgw_common.h and pulled into every source >> file. I worry that if I go through and fix everything so it builds, it will >> just break again without regular testing. >> >> Do we know of anyone that still relies on this cryptopp implementation? It >> doesn't look like we use it in any of our packaging. > > Searching through my mail we discussed removing cryptopp in summer > 2016 (subject "remove cryptopp support?"), and it looks like we only > kept it in because it was easy and Matt and Marcus didn't like going > all-in on NSS. > > But I think the only reason we ever had cryptopp was because it was an > easier library to program against, and once we had the NSS > implementation we shifted to it thanks to the certifications involved. Kinda, it was definitely easier to use, and didn't have the license issues that we had with openssl iirc. We weren't even aware of nss when we started using it, and it was definitely easier to use. The need for nss came because of certification issues. > And I'm not seeing any real references to it in the last several years Yeah, if no one objects. Yehuda > in our archives. So I think you should just zap it away. :) > -Greg > >> >> >> Example compilation failure: >> >> In file included from /usr/include/cryptopp/iterhash.h:4:0, >> from /usr/include/cryptopp/md5.h:4, >> from /home/cbodley/ceph/src/common/ceph_crypto.h:15, >> from /home/cbodley/ceph/src/common/ceph_context.cc:27: >> /usr/include/cryptopp/cryptlib.h:523:28: error: reference to ‘byte’ is >> ambiguous >> virtual void SetKey(const byte *key, size_t length, const NameValuePairs >> ¶ms = g_nullNameValuePairs); >> ^~~~ >> In file included from /usr/include/cryptopp/cryptlib.h:86:0, >> from /usr/include/cryptopp/iterhash.h:4, >> from /usr/include/cryptopp/md5.h:4, >> from /home/cbodley/ceph/src/common/ceph_crypto.h:15, >> from /home/cbodley/ceph/src/common/ceph_context.cc:27: >> /usr/include/cryptopp/config.h:172:23: note: candidates are: typedef >> unsigned char byte >> typedef unsigned char byte; // put in global namespace to avoid ambiguity >> with other byte typedefs >> ^~~~ >> In file included from >> /home/cbodley/ceph/build/boost/include/boost/config/compiler/gcc.hpp:165:0, >> from >> /home/cbodley/ceph/build/boost/include/boost/config.hpp:39, >> from >> /home/cbodley/ceph/build/boost/include/boost/algorithm/string/std_containers_traits.hpp:18, >> from >> /home/cbodley/ceph/build/boost/include/boost/algorithm/string.hpp:18, >> from /home/cbodley/ceph/src/common/ceph_context.cc:21: >> /usr/include/c++/7/cstddef:64:14: note: enum class std::byte >> enum class byte : unsigned char {}; >> >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
