Control: tag -1 moreinfo Control: severity -1 wishlist On Wed, Apr 07, 2021 at 11:40:34AM +0200, Andreas Beckmann wrote: > Package: ca-certificates > Version: 20210119 > Severity: serious > > Hi, > > as I had commented on > https://salsa.debian.org/debian/ca-certificates/-/merge_requests/6 > > After seeing the new version scheme for debian-security-support (sid now > has 1:11+2021.01.23), I was thinking whether something similar would be > sensible for ca-certificates, too. Am I correct to assume that the sole > source of certificates included is the "mozilla bundle"? > Currently yes. Historically it has included other CAs, and that could conceivably happen again.
> What about changing the versioning scheme to > <epoch>:<release>+<mozilla-bundle>+<number> ? > With <epoch>=1, <release>=11 for bullseye, <mozilla-bundle>=2.46, > <number>=1, s.t. we would have 1:11+2.46+1 for now. A new mozilla bundle > packaged could use 1:11+2.47+1 for bullseye and 1:10+2.47+1 for buster > while excluding some of my patches that are not compatible with > ca-certificates-java in buster (or would require an update of -java too, > but that needs to be done very carefully). (ca-certificates-java in > bullseye needs to depend on ca-certificates (>= 1:11) in that case). > Such versioning would be more clear than 20200401 for bullseye > backported with reduced functionality as 20200401~deb10u1 to buster. > That hypothetical buster version would still satisfy the new versioned > constraint in ca-certificates-java in spite of not having the expected > functionality. > That doesn't really make sense to me, I'm afraid. I'm not familiar with the issue you're trying to fix with this, though... Cheers, Julien
