Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies > > == Summary == > This new feature of crypto-policies allows system administrators and > third party providers to modify and adjust the existing system-wide > crypto policies to enable or disable algorithms and protocols. > > == Owner == > * Name: [[User:Tmraz | Tomáš Mráz]] > * Email: tmraz@xxxxxxxxxx > > == Detailed Description == > > The crypto-policies package will be enhanced to allow system > administrators to modify the existing system-wide crypto policy levels > by removing or adding enabled algorithms and protocols. For example it > will be possible to easily modify the existing DEFAULT I just wonder what is the strategy here? Does it means that the "DEFAULT" definition will be store permanently somewhere in /usr/ and I'll be able to copy the DEFAULT into /etc and modify it according to my needs? I am just asking, because AFAIK, currently the crypto policies configuration is stored just in /etc and modifying the "DEFAULT" profile would make the updates problematic, requiring someone to file with .rpmnew files etc. That would be unfortunate. Vít > policy to > disable the SHA1 support or enable support for a national crypto > algorithm that is supported by the crypto libraries but is disabled in > the policies. System administrator will be able to add a simple > configuration file that will achieve this after calling the > update-crypto-policies command. > > == Benefit to Fedora == > > This will enable advanced users of Fedora to adjust the > crypto-policies of the system to their particular needs and > requirements. > > It will also enable using Fedora where the national crypto algorithms > are required without need to manually tinker with configurations of > various software components to enable the national crypto algorithms. > > == Scope == > * Proposal owners: > The design of the feature and prototype is already finished upstream. > We still need to convert the existing back-end policy generators to > the new framework and convert the existing policy definitions to the > new format. Then the crypto-policies package will be rebased to the > version with the custom crypto policies support included. > > * Other developers: N/A (not a System Wide Change) > * Release engineering: N/A (not a System Wide Change) > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > > No impact. The crypto policies will continue to work as expected and > worked before if a custom policy is not set. > > == How To Test == > > This will be tested as part of the upstream crypto-policies testsuite. > > == User Experience == > > Unless the user will choose to create and/or apply a custom crypto > policy on the system, there will be no noticeable user experience > change. > > == Dependencies == > > N/A (not a System Wide Change) > > == Contingency Plan == > > * Contingency mechanism: (What to do? Who will do it?) N/A (not a > System Wide Change) > > == Documentation == > > N/A (not a System Wide Change) > > == Release Notes == > > The crypto-policies package was enhanced to allow system > administrators to modify the existing system-wide crypto policy levels > by removing or adding enabled algorithms and protocols. For example it > is now possible to easily modify the existing DEFAULT policy to > disable the SHA1 support or enable support for a national crypto > algorithm that is supported by the crypto libraries but is disabled in > the policies. This can be achieved by adding a simple configuration > file and calling the update-crypto-policies command. > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
