Crypto policies packaging guideline

Miloslav Trmač mitr at redhat.com
Mon Sep 29 15:17:02 UTC 2014


Hello,
(resurrecting an really old thread, sorry about the delay.)
----- Original Message -----
> 1) Will I (as a hobbyist packager) be able to reach the proper
> conclusion, e.g. find the real place where these defaults are set, such
> as [4, 5]?

If you, as the package maintainer, who knows the package, can’t do this, who can?  The security experts can grep for SSL_CTX_set_cipher_list as well as anybody, but following through the call chain and multiple langauges does require package-specific expertise.  A distribution is supposed to be a set of software customized to work well together, and yes, that necessarily means understanding the source code and being able to change it.  We _need_ to be able to do such things with Fedora’s packages; perhaps we haven’t been asking packagers for this much recently, but we need to start, and this is as good a reason to start as any.

> 2) What about dynamic languages, such as Ruby, Python etc. They are not
> covered by the guidelines at all.
Yes, it would be good to expand the guideline to cover the bindings of the major languages.

> 3) Should I really rewrite the upstream defaults and how? What will be
> the impact on other libraries written in Ruby? Not mentioning that there
> was quite lengthy controversial discussion upstream [6] and you ask me
> again to override its results.

By my uninformed estimation, the vast majority of TLS using projects either don’t have an explicit configuration (i.e. there is nothing to be done), or are not carefully maintaining the cipher list, unlike this recent Ruby change; and even projects that have recently updated it are not automatically guaranteed to keep maintaining it in the future.

Libraries written in Ruby _should_ in general inherit the system-wide defaults, though, yes, this may in very rare cases result in additional patching of these libraries if they are connecting to specific services that are less secure and need custom configuration.

(It might be interesting to compare the Ruby defaults list and the current version of the PROFILE=SYSTEM list.)
    Mirek


More information about the devel mailing list