On Thu, Feb 27, 2014 at 11:52:01AM -0500, Bill Nottingham wrote: > Jaroslav Reznik (jreznik@xxxxxxxxxx) said: > > = Proposed System Wide Change: System-wide crypto policy = > > https://fedoraproject.org/wiki/Changes/CryptoPolicy > > > > Change owner(s): Nikos Mavrogiannopoulos <nmav@xxxxxxxxxx> > > > > Unify the crypto policies used by different applications and libraries. That is > > allow setting a consistent security level for crypto on all applications in a > > Fedora system. > > > > == Detailed Description == > > The idea is to have some predefined security levels such as LEVEL-80, > > LEVEL-128, LEVEL-256, > > or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the > > security levels > > that the administrator of the system will be able to configure by modifying > > /usr/lib/crypto-profiles/config > > /etc/crypto-profiles/config > > > > and being applied after executing update-crypto-profiles. > > (Note: it would be better to have a daemon that watches those files and > > runs update-crypto-profiles automatically) > > How is an admin supposed to know what levels such as the above are, and why > they might choose a particular one? Supplemental question: Why wouldn't you always want to choose the most secure one? I believe the proposal is trying to answer this question here: "It may be that setting a high security level could prevent applications that connected to servers below that level to connect" but it's rather unclear, and could do with at least more explanation and ideally some examples of things that wouldn't work. In any case, I can't imagine I'd ever want a Fedora machine that wasn't "most secure" (discounting external connections). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
