What makes this different from crypto-policies used in Fedora and openSUSE?
1 Like
Note that I’ll soon open up specification and should also add some documentation.
The first thing with crypto-policies is that it cannot be used on Debian/Ubuntu as such. It necessarily integrates deeply with the system. This means that there would be a pretty large amount of work to adapt it.
A lot of what’s in crypto-policies is also very much a distribution choice which doesn’t transfer well across distributions (SHA1 in RH-based distro has a different recent history, TLS 1.0 and 1.1 have been disabled in Ubuntu for ~4 years, …).
Finally, in this context, cross-distribution compatibility seems like it could be an ongoing cost.
This means that reusing is likely not going to be a saving a lot of effort and is actually likely to cost. Therefore, starting something separate can make sense: it all depends on how much it’s going to cost in terms of development and support.
I’ve designed crypto-config to be pretty light and small. One of the biggest differences with crypto-policies was to eschew the parsers and generators that are in crypto-policies in favor of files written by package maintainers. There is fairly little code overall (there was a lot of design to get to something that simple though ;p ).
This was decided after looking at crypto-policies’ changes history which convinced me that the flexibility of a generator was not needed. I should mention that I would likely have created a generator too if I had started without prior art to study.
I should mention that I would probably have
PS: I think it’s light enough that any distribution (with support for dpkg triggers or similar) will be able to integrate the framework with their own profiles 
1 Like