On Fri, Dec 30, 2022 at 12:41:59PM +1100, Damien Miller wrote: > On Fri, 30 Dec 2022, Theo Buehler wrote: > > > On Fri, Dec 30, 2022 at 10:09:16AM +1100, Damien Miller wrote: > > > This updates libcbor to upstream version v.0.10.0. This version includes > > > clang15 header fixes and fixes a few memory leaks. Full release notes > > > are at https://github.com/PJK/libcbor/releases/tag/v0.10.0 > > > > I understand that it is a libcbor major bump. Why is the libfido2 bump > > needed? > > Caution - some of the libcbor changes were listed as "breaking" in the > release notes. I took this to mean an ABI bump. libfido2 depends on > libcbor, so I figured that bumping it would avoid any possibility of > inconsistency between them at link time. Too much?
There are numerous ABI breaks in libcbor that do require a major bump: size_t -> uint64_t in public API, enum values added and removed, ... It's thus perfectly reasonable to bump libfido2. I was just wondering whether there was a more specific reason since I couldn't immediately spot anything. This bump is cheap, by all means keep it. > > The CBOR_CUSTOM_ALLOC deprecation and the fact that cbor_set_allocs() is > > now exposed is a bit disappointing. > > > > https://github.com/PJK/libcbor/pull/237 > > > > Other than that the diff looks good to me, build tested on sparc64, so > > gcc-archs should be fine, too. > > That's reasonable. I can chop those out: Yes, I think that makes sense and isn't super intrusive. I'd prefer this version. (It's a bit strange to write "Will keep this PR open for a few weeks to give people a chance to object." and then turn around, merge it and cut a release containing it.)
