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
--
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
