Dne 27.8.2014 22:42, James Antill napsal(a):

#topic #452 Crypto policies packaging guideline .fpc 452 https://fedorahosted.org/fpc/ticket/452

Looking into this topic and the proposed guidelines [1], I am not sure how to apply them for Ruby.

On the first look, looking for SSL_CTX_set_cipher_list, it is called at [2]. It looks like some helper method, which in Ruby translates into #ciphers= method, which does not appear to be used anywhere.

Nevertheless, if you look better, you can discover, that it is actually called at [4] and fed by some defaults [5]. This is not directly obvious.

This raises several questions:

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]? 2) What about dynamic languages, such as Ruby, Python etc. They are not covered by the guidelines at all. 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.

Don't take me wrong, I support this effort. It just looks to have lot of blind spots.

Vít

[1] https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies [2] https://github.com/ruby/ruby/blob/trunk/ext/openssl/ossl_ssl.c#L904 [3] https://github.com/ruby/ruby/blob/trunk/ext/openssl/ossl_ssl.c#L2113 [4] https://github.com/ruby/ruby/blob/trunk/ext/openssl/lib/openssl/ssl.rb#L86 [5] https://github.com/ruby/ruby/blob/trunk/ext/openssl/lib/openssl/ssl.rb#L26 [6] https://github.com/ruby/ruby/commit/699b209cf8cf11809620e12985ad33ae33b119ee

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