Re: F29 System Wide Change: Strong crypto settings: phase 2
On 06/11/18 15:14, Tomas Mraz wrote: >> Okay, so IIUC now, this is an all-or-nothing kind of change. If I >> elect/need to use LEGACY to administer some old hardware that I >> cannot >> otherwise connect to using the defaults, then I'm compromising that >> host's security for anything/everything its used for until it's taken >> back off LEGACY and returned to whatever the non-LEGACY is called. >> Do I >> have it right now? > > Yes, except one thing. Just by switching to LEGACY it does not mean > you're compromising the host's security. The protocol negotiation and > ciphersuite ordering still applies and it will use the best available > protocol and ciphersuite and not some random insecure protocol version > and ciphersuite. The insecure protocols and ciphersuites will be used > only in the case the other end does not know anything better. Could switching to LEGACY allow some man-in-the-middle downgrade attacks, in which an attacker manipulates the initial phases of handshakes, and tricks the parties to use a weaker protocol? Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NL36VBZ7FSCXDGABTZXIJHIJEA5FJQB2/
Re: CA certificate directory for a VPN client
On 06/01/18 08:39, Mikhail Zabaluev wrote: > A question arose about a good choice of the default directory for > trusted CA certificates over these proposed rpm PRs: > > https://src.fedoraproject.org/rpms/strongswan/pull-request/6 > https://src.fedoraproject.org/rpms/strongswan/pull-request/7 > > An IKEv2 client from strongSwan package, charon-nm, needs to be > configured with a directory name to load trusted X.509 CAs from. The > CA certificates are used to authenticate VPN servers. > > There are following considerations for the directory choice: > > 1. It should be in /etc so that it can be configured on ostree machines. > 2. There is a concern with using a subdirectory of > /etc/pki/ca-trust/extracted : charon-nm has no regard for key usage > flags, and there are indeed no standardized flags to authorize > specifically the VPN usage. Trusting by default any CA that is used to > validate TLS websites may be considered too permissive; small VPN > operators typically use self-signed or private CA certificates. If a single CA list for both TLS and VPNs was used, and a user added a VPN's private CA to that shared list, it would technically enable the VPN operator to issue false certificates, and TLS clients like Firefox would then trust such false certificates. This side effect of installing a VPN's private CA should be avoided. Therefore I agree with you, the directory for VPN CAs should be configured separately. Are there any VPNs that use server certificates issued by web CAs? All VPNs that I have seen personally used their own CA certificates. > 3. It would be useful to have a shared CA certificate directory > configured out of the box for various VPN clients, similarly to how > /etc/pki/tls/certs can be shared by any applications using TLS. If a user wants to connect to a specific VPN A, the user might also like to avoid to connect to a service operated by an attacker that pretends to be A. If most VPN CAs are private CAs, and haven't been audited in similar ways as the Mozilla CA Certificate program is doing it, that might be an argument for shipping an empty directory by default, and requiring the user to manually install the CA certificate for only the services they intend to connect to. > I came up with /etc/pki/vpn, that is not currently populated in > Fedora. Would there be a more appropriate choice, governed by PKI > policies that I'm not aware of? If the directory format expected by charon-nm might be different from the input expect by other vpn clients, then it might make sense to define a directory specifically for charon-nm. If you think it's reusable, it might make sense to define the file format expected in that directory. For TLS, because different tools require the list of CAs in different format, we have chosen the approach that is documented in the update-ca-trust(8) manual apge. Does charon-nm want individual files? Does it expect specific filenames, like the hashed filenames that openssl may use? Does it expect files in PEM or DER format? Does it support files in which multiple certificates are concatenated, or does it accept only one CA per file? These are example attributes, that might cause the contents of the directory to work only for the charon-nm tool, but not for others. Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/W64BLLOEGMI34AWO6ODUBDDBKEJOXJI5/
Building software based on Firefox 58 ? Please read
Hello, for everyone maintaining packages that are derivatives of the Mozilla Firefox source code: If you're updating to Firefox 58, I'd like to suggest that you include a local patch. Background: We are changing the default NSS database file format, and Firefox needed to be changed to be compatible with that change, too. Upstream Firefox 58 includes a change, which enforces that new format. The upstream Firefox 58 binaries will therefore already use the new file format. For Fedora, we've decided that we want to keep using the old file format in the already released Fedora versions 26 and 27. The change of default has been applied to the NSS library in Fedora 28 (currently Rawhide). The Firefox 58 builds for Fedora will include a local patch that will change it to use the NSS default, and not use the Firefox preference. For details see: https://bugzilla.redhat.com/show_bug.cgi?id=1537287 If you'd like to avoid that other software derived from Firefox 58 performs an automatic file migration in Fedora 26/27, then you could apply the patch to those packages, too. If you decide not to apply this change to a package derived from Firefox 58, the software should function correctly, and will automatically perform a migration of the NSS databases. However, the reason for this recommendation is to avoid potential surprises on the stable channels Fedora 26 and 27, especially because it isn't possible to revert the application storage back to the previous state, after a migration was performed automatically. Additional background information can also be found here: https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: NSS Default File Format SQL in Fedora 28
On 25.10.2017 17:16, Kai Engert wrote: > https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql#Current_status > - https://bugzilla.redhat.com/show_bug.cgi?id=1474771 > - https://pagure.io/releng/issue/6883 FYI, this had been re-approved on Nov 6 in bug 1474771. The change was applied to Rawhide on Nov 7. https://bugzilla.redhat.com/show_bug.cgi?id=1496560 So far I haven't seen any feedback, neither negative nor positive. Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: NSS Default File Format SQL in Fedora 28
On 25.10.2017 15:22, James Hogarth wrote: > There's always process if something is high enough level to be > considered a "Change" > > Please follow the appropriate process to have this included as a > system level change for F28. Ok. The change was previously accepted for Fedora 27. I've edited and updated the previous trackers: - https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql#Current_status - https://bugzilla.redhat.com/show_bug.cgi?id=1474771 - https://pagure.io/releng/issue/6883 Will this be sufficient to restart the change acceptance process for Fedora 28? Thanks, Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
NSS Default File Format SQL in Fedora 28
TL;DR: The change originally planned for Fedora 27 will now be done for Rawhide Fedora 28, probably tomorrow. We had previously announced to change the NSS crypto library to use the new sql file format by default. Please see the attached message for the technical details. Because of blocker bugs, it wasn't done for Fedora 27. During the past months the known bugs in NSS were fixed, and the Firefox/Mozilla code was improved. I think now we're ready to make the change for Rawhide. If I understand correctly, at the current time of the development phase of Rawhide Fedora 28, it isn't necessary to go through a formal process to make this change. The new tracking bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1496560 The following is noteworthy, when using NSS with the sql file format: - Performance is slightly reduced. The old dbm storage didn't use any locking mechanism, and therefore it was easy to get corrupted storage when accessing the files in parallel by more than one application. The new sqlite storage can safely be used by multiple applications in parallel, but this has a performance cost. - NSS databases (old and new) can be protected with a password. Previously, some modification operations could be performed without unlocking the database. When using the new sql storage, NSS more strictly requires the user to log in to (unlock) the database prior to performing modifications. For example, when modifying the trust settings of a CA certificate with certutil, it will be necessary to provide the database password. - With sql databases, NSS is more strict with half-initialized databases. In the early years of the Netscape/Mozilla era, in order to support some application/browser level functionality, it had been necessary to distinguish between "half initialized state: no password ever set on the database, not even an empty password" and "fully initialized state: password set on the database, even if it's just the empty string". We believe this state is no longer required, certutil and modutil no longer create half-initialized databases. Until recently, NSS databases created by Firefox/Thunderbird etc. were still in this half-initialized state. There might be other applications that did this. When using a database in the half-initialized state, some database operations could fail, with similar symptons as not having logged in to the database, even after databases are (automatically) migrated to the sql format (the half-initialized state is kept). When experiencing such issues, it will be necessary to explicitly set a password on the database, even if it's just the empty string. In order to adjust for these properties, Firefox has been changed to always initialize NSS databases with an empty password. In addition, Firefox has been changed to prompt the user for the NSS database password (Firefox calls it the master password) if necessary, prior to e.g. trust database modificiations. These recent changes will be contained in NSS 3.34, Firefox 58 and Thunderbird 59, which aren't released yet. In order to allow us testing the new sql database file format with Fedora Rawhide as soon as possible, the changes have been backported to the versions currently used in Rawhide: NSS 3.33, Firefox 57 beta, Thunderbird 52.4. The packages were built yesterday. If other applications based on Mozilla Gecko, e.g. like Iceowl or Icecat, would like to avoid that users run into these potential failures, they could pick up the same backported patches. Please look at the commits for Firefox and Thunderbird to find them, or see the dependency list of bug 1496560. Please let us know if you experience problems. (Ideally, please file a bug against the "nss" component and CC kengert@rh, hkario@rh, rrelyea@rh, dueno@rh.) Thanks Kai --- Begin Message --- = System Wide Change: NSS Default File Format SQL = https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql Change owner(s): * Kai Engert <k...@redhat.com> Change the NSS library default to use the sqlite based data storage, when applications don't specify their preferred storage file format. == Detailed Description == Applications that use the NSS library often use a database for storage of keys, certificates and trust. NSS supports two different file formats, one called DBM (based on berkeley DB files) and another one called SQL (based on sqlite DB files). Today's default file format used by NSS, used when applications omit the type parameter, is the older DBM file format, which forbids parallel access to the storage. The suggestion is to change the default file format to SQL, which allows parallel access to the storage. Applications, or users using the NSS command line utilities, often provide the database storage location using a simple directory path parameter. Some might not be aware, or forget, that the parameter can be prefixed with a
Re: Removal of code signing trust bits from ca-certificates
There hasn't been any negative feedback, neither in Rawhide, nor from updates testing. I've just pushed the update to stable F25 and F26. Kai On Tue, 2017-07-18 at 22:11 +0200, Kai Engert wrote: > Until recently, Mozilla maintained three individual trust bits for each root > CA > certificate: > - trust for TLS servers > - trust for email security > - trust for code signing > > The next CA update from Mozilla will switch the code signing trust bit > OFF for all CAs. > > Mozilla will no longer maintain this trust bit. > > See > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/004uvRRnVy > Y > for background. > > I'm not aware of anyone using this trust bit. The removal might have no > effect. > > This update of the CA list is supposed to get published with Firefox 56 on > September 26. > > In order to allow the Fedora community to test potential effects of this > change, > I intend to publish an update to the ca-certificates packages early, and keep > it > in updates-testing for a few weeks. > > Tracking bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1472468 > > Thanks > Kai > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Removal of code signing trust bits from ca-certificates
Until recently, Mozilla maintained three individual trust bits for each root CA certificate: - trust for TLS servers - trust for email security - trust for code signing The next CA update from Mozilla will switch the code signing trust bit OFF for all CAs. Mozilla will no longer maintain this trust bit. See https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/004uvRRnVyY for background. I'm not aware of anyone using this trust bit. The removal might have no effect. This update of the CA list is supposed to get published with Firefox 56 on September 26. In order to allow the Fedora community to test potential effects of this change, I intend to publish an update to the ca-certificates packages early, and keep it in updates-testing for a few weeks. Tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=1472468 Thanks Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Question on koji error: SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)
On Sun, 2017-04-23 at 01:05 +, Globe Trotter wrote: > Hi, > I am trying to build a package on koji using: > koji build --scratch f25 thaali-0.4.2-1.fc25.src.rpm > > and I get: > SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed > (_ssl.c:661) > > What does this mean? I have both kerberos ticketing and ssh set up. > Valid starting Expires Service principal > 04/22/2017 20:00:42 04/23/2017 20:00:16 host/koji.fedoraproject.org@FEDORAPR > OJECT.ORG > renew until 04/29/2017 20:00:16 > 04/22/2017 20:00:38 04/23/2017 20:00:16 krbtgt/FEDORAPROJECT.ORG@FEDORAPROJE > CT.ORG > renew until 04/29/2017 20:00:16 I don't get an error when I try to submit a scratch build. I'm not sure what hosts the koji tool will connect to, is that limited to https://koji.fedoraproject.org/ ? Do these command give you cert validation errors? openssl s_client -showcerts -connect koji.fedoraproject.org:443 /usr/lib64/nss/unsupported-tools/tstclnt -CCC -D -b -h koji.fedoraproject.org -p 443 (Feel free to mail the output from these commands to me.) Maybe you're behind a man-in-the-middle proxy? Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage
On Mon, 2017-04-10 at 15:31 +0200, Kamil Dudka wrote: > Anyway, I guess we should move this discussion to some curl- or nss-related > channel... The question remains, if it makes sense to switch back to openssl, if the consequence is a loss in completeness of certificate trust checking. In my opinion, a little bit of space saving shouldn't be a sufficient argument for removing existing security functionality. In the future, we should work on improving the certificate validation in a way that can benefit all of our crypto libraries. This will certainly require additional code, too. There were some thoughts to potentially reuse the functionality that Firefox has implemented at the application level, because currently there don't seem other implementations in sight. That code is based on top of NSS code. If that gets done, and if you want SSL/TLS connectivity inside the base image to be as secure as in the rest of Fedora, you might have to eventually add NSS back to it. Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage
You convinced me, that it would be good to have test cases to demonstrate how nss/openssl/gnutls are behaving related to the distrust rules. I setup the following page, wich provides multiple test cases, and intructions how to test: https://kuix.de/misc/test-distrust/ Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage
On Fri, 2017-04-07 at 11:54 +0200, Kamil Dudka wrote: > On Friday, April 07, 2017 11:01:35 Kai Engert wrote: > > On Fri, 2017-04-07 at 10:38 +0200, Kamil Dudka wrote: > > > Although we build libcurl against NSS now, it loads the same CA bundle as > > > if we built it against OpenSSL: > > > > > > /etc/pki/tls/certs/ca-bundle.crt > > > > > > So I doubt it could actually take advantage of those extra flags. > > > > This file doesn't contain the distrust flags. > > > > The correct file would be /etc/pki/tls/certs/ca-bundle.trust.crt > > Yes, but it does not make sense to load such a file by nss-pem because it > does > not support those flags anyway. The correct fix for NSS-linked libcurl would > probably be to just disable loading the CA roots from file by default. Why do you mentioned a need to fix curl-nss? The regular approach for NSS applications is to load the NSS libnssckbi.so (now the drop-in replacement p11-kit-trust.so), which provides all trust and distrust information in a format that NSS can handle. How does curl-nss load the CA trust list? If curl-nss doesn't load libnssckbi.so/p11-kit-trust.so but rather loads a simple PEM file, then today's curl-nss doesn't use distrust information. Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage
On Fri, 2017-04-07 at 10:38 +0200, Kamil Dudka wrote: > > Although we build libcurl against NSS now, it loads the same CA bundle as > if we built it against OpenSSL: > > /etc/pki/tls/certs/ca-bundle.crt > > So I doubt it could actually take advantage of those extra flags. This file doesn't contain the distrust flags. The correct file would be /etc/pki/tls/certs/ca-bundle.trust.crt > If you > have a reproducer at hand, you can give it a try. I currently don't know of a public test site that uses a blacklisted certificate. As long as libcurl/openssl doesn't load the right file, we don't need to test. When you're able to switch openssl to use the correct one, I can help to create a test for that. > > Even if you switch that to the distrust list, you still don't get the > > partial distrust, which may be implemented at the NSS code level (such as > > date based distrust for StartCom/WoSign roots, and the domain constraints > > for some CA). > > You say "may be implemented at the NSS code level". The intention was to say, that additional distrust rules might get implemented at the NSS code level in the future. > Do I understand it > correctly that NSS currently does not implement the date based distrust > and the domain constraints? NSS does implement them, see the places where the wiki page mentions NSS: https://wiki.mozilla.org/CA:Root_Store_Trust_Mods Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage
On Thu, 2017-04-06 at 09:29 -0700, Adam Williamson wrote: > On Thu, 2017-04-06 at 18:22 +0200, Kai Engert wrote: > > I would like to make you aware that the certificate validation of openssl > > isn't > > as complete as in NSS. > > > > For example, NSS is able to handle the blacklisted/distrusted CAs, which > > have > > been published by Mozilla, and are being made available as part of the ca- > > certificates package, while I believe openssl isn't. > > > > In addition, a few CA distrust mechanisms have been implemented at the NSS > > code > > level, and no equivalent mechanisms are currently being implemented at the > > openssl level [1]. > > I don't believe this is accurate. There is an extended certificate > format which OpenSSL will accept which allows you to indicate specific > trust or *dis*trust of a given certificate for specific purposes. You > could, I think, use this format to produce a certificate file which > basically says "I distrust this CA certificate for all purposes". > > I wrote a bit about this at > https://www.happyassassin.net/2015/01/16/openssl-trust-and-purpose/ . > > Corrections welcome, of course... The ca-certificates package indeed produces two versions of the PEM format files, one as a simple list of CAs, and another version that uses the BEGIN TRUSTED CERTIFICATE file format, which includes the distrust flags. A couple of year ago, I had filed a bug to request that the openssl library default is switched to make use of this advanced format: https://bugzilla.redhat.com/show_bug.cgi?id=873373 However, that bug is still in NEW state, so I guess it depends on the individual applications, if they use the list that includes distrust information. Which one is libcurl using? Even if you switch that to the distrust list, you still don't get the partial distrust, which may be implemented at the NSS code level (such as date based distrust for StartCom/WoSign roots, and the domain constraints for some CA). Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage
I would like to make you aware that the certificate validation of openssl isn't as complete as in NSS. For example, NSS is able to handle the blacklisted/distrusted CAs, which have been published by Mozilla, and are being made available as part of the ca- certificates package, while I believe openssl isn't. In addition, a few CA distrust mechanisms have been implemented at the NSS code level, and no equivalent mechanisms are currently being implemented at the openssl level [1]. As a consequence of the switch to openssl, software that currently uses libcurl would lose these additional trust checks when doing certificate validation for SSL/TLS connections. Kai [1] https://wiki.mozilla.org/CA:Root_Store_Trust_Mods ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Enabling support for TLS 1.3 in NSS (not yet by default)
TL;DR: If you are packaging software that uses NSS, please test if it works correctly, if TLS 1.3 support is enabled. COPR packages are available. Although still in draft status, the development of the new TLS 1.3 protocol version is making progress. The upstream Mozilla NSS library already supports it, and has enabled support for it with version 3.29. We should work towards enabling the TLS 1.3 protocol in the systemwide version of NSS used by Fedora, too. (tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1432889 ) (Note that "enable support" means, that the code is enabled at build time. The protocol is still disabled by default, if an application chooses to use the default versions enabled by the NSS library. Enabling version TLS 1.3 as an NSS library default will be a separate, future step.) In theory, the pure presence of TLS 1.3 support in the NSS library shouldn't cause any issues. But unfortunately, it's not as simple as that. There are applications, which will query (at runtime) the library to obtain the range of supported SSL/TLS versions, and which will try to enable all of them. We have already identified at least one package that is failing because of that behavior: (openldap: https://bugzilla.redhat.com/show_bug.cgi?id=1415140 ) If an application controls the set of ciphersuites that are enabled, then enabling TLS 1.3 will not work, unless the application also enables the new TLS 1.3 specific ciphersuites. That means, enabling support for TLS 1.3 in NSS has the potential to break some applications. The last time we tried to enable it in updates-testing, we found the above openldap issue, and then we revoked that update. It isn't clear if we have already identified all packages which need to be adjusted for TLS 1.3 code presence (probably not). Could you please help to test if enabling TLS 1.3 support causes any issues with the applications you are using? There are experimental COPR packages available below, which are based on the most recent Fedora NSS packages, and which enable TLS 1.3 as the only change: https://copr.fedorainfracloud.org/coprs/kengert/nss-with-tls-1.3/ Please give feedback, if you experience problems. When you do, please remember to mention that you are using an TLS-1.3-enabled package. Note that upstream Firefox 52 has already enabled support for TLS 1.3 by default. At this time, because we don't build that code in our system NSS package, Firefox 52 in Fedora cannot use TLS 1.3 yet. Thanks in advance for your help Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On Sat, 2017-01-21 at 15:47 +0100, Christian Dersch wrote: > On 01/21/2017 03:44 PM, Christian Dersch wrote: > > > > Autokarma just means the package will not be pushed automatically, but > > karma mechanism is still active. So once your update reached the > > stable karma level you defined, you can hit the push to stable button. > > If level is not reached you have to wait 7 days (but thats the case > > with autokarma too), but as the update contains prominent applications > > I don't expect it takes so long ;) > > Just forgot: Until monday is a *short* time, we have weekend and the > update did not reach testing yet. I suggest more time. I've disabled autokarma. The current Firefox 50.x will go unsupported on Tuesday, replaced by Firefox 51. Usually new important security fixes are contained in the new Firefox update. Unless we want to delay Firefox 51, this update must go out earlier, or at the same as Firefox 51. I suggest that we make a broad call for getting this update tested widely by Monday. Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On Sat, 2017-01-21 at 13:20 +0100, Christian Dersch wrote: > > > The combined updates have been submitted to testing: > > > F24: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18 > > > F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e42b513012 > > > > > > If you can, please help testing, thank in advance! > > > > Please edit the default karma and put it higher than the default 3 so > > we don't get 3 people that test the one thing pushing it stable > > Maybe disable autokarma? Then you can decide to push when you think it > is well tested. With autokarma disabled, is there a minimum test duration, before it can get pushed to stable? Because we probably want to have it pushed to stable on Monday. Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On Fri, 2017-01-20 at 10:22 -0600, Michael Catanzaro wrote: > > Please just make sure they all get released in the same Bodhi update to > avoid breakage. The combined updates have been submitted to testing: F24: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18 F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e42b513012 If you can, please help testing, thank in advance! (Note that the NSS update for rawhide, which enforces the conflicts, hasn't been built yet, because we're waiting for a successful icecat rebuild on rawhide.) Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On Fri, 2017-01-20 at 13:12 -0600, Michael Cronenworth wrote: > On 01/20/2017 12:15 PM, Kai Engert wrote: > > In order to create the combined update, I need commit access for all > > involved > > packages. The remaining piece are the commit privileges for Icecat. I've > > requested them, but haven't received them yet. > > If we're under a time constraint I'm sure a provenpackager would be willing > to > create the update for you. I've been granted the required permissions. (Note that provenpackagers don't have access to firefox, I've been told, so their powers wouldn't have been sufficient.) Thanks! Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On Fri, 2017-01-20 at 10:22 -0600, Michael Catanzaro wrote: > On Fri, 2017-01-20 at 16:17 +0100, Martin Stransky wrote: > > All builds are ready except TB on arm. I'm sure we make that in time. > > > > Martin > > Please just make sure they all get released in the same Bodhi update to > avoid breakage. Yes, that's our intention. I see that the Icecat maintainer has already built updated packages for F24 and F25 that include the required patch. In order to create the combined update, I need commit access for all involved packages. The remaining piece are the commit privileges for Icecat. I've requested them, but haven't received them yet. Thanks Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On Fri, 2017-01-20 at 18:40 +0200, Alexander Bokovoy wrote: > > FreeIPA is broken when trying to install with nss 3.28.1. We reliably > reproduce this issue with > https://bodhi.fedoraproject.org/updates/FEDORA-2017-e42b513012 > > It seems that new nss also breaks 389-ds LDAP server's selection of > available ciphers. As result, ldapsearch does not work against the > 389-ds LDAP server configured as part of FreeIPA deployment. > > > However, if ANY of the above build cannot be completed soon, or, if ANY of > > the > > updates cannot move to the stable Fedora updates, it can block users from > > upgrading to the Firefox 51 update on Jan 24. > > > > Is that acceptable? > > I think failing server applications is unacceptable. Alexander, the test of NSS 3.28.1 in Fedora has uncovered multiple issues, and the issue with FreeIPA is a different issue than the one I had explained in this thread. We'll prevent the FreeIPA issue, by disabling the experimental TLS 1.3 support at compile time in the Fedora NSS build, until the FreeIPA team is able to adjust their code to be compatible with TLS 1.3 support being enabled in NSS. Thanks Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
Hello, we are currently dealing with a tricky situation, that the NSS and Mozilla package maintainers have been discussing, and I'd like to publish our plan. The most recent NSS update, version 3.28.1, is required to ship to the Firefox 51 update planned for January 24. Unfortunately, NSS 3.28.1 is incompatible with Mozilla applications version 50 and older. If Mozilla 50 or older is used together with NSS 3.28 or newer, and the application attempts to use HTTP v2, the connections to some servers may fail (including connections to Google servers). The fix is simple, it's possible to apply a small patch to the older Mozilla applications, to make it compatible with NSS 3.28.1 The difficulty here is the timing, and it's a conflict between "don't break applications in Fedora" and "ship new Firefox security update as soon as possible". If we start by shipping NSS 3.28.1 first, without yet having fixed the Mozilla applications, then we allow Firefox 51 to be shipped, but we risk that the other applications aren't fixed in time, and that users might see regressions, caused by the upgrade to NSS 3.28.1 Alternatively, if we wait until all affected Mozilla packages have been updated to fixed versions, it might delay the January 24 Firefox 51 update. After discussing this, we have a preference to avoid the breakage in Fedora, and try to ship all required updates as soon as possible. In order to avoid the breakage, we want to add "Conflicts:" statements to the NSS 3.28.1 package, that makes it conflict with all known Mozilla packages that don't contain the required fix yet. The packages we have identified are: - firefox - thunderbird - seamonkey - xulrunner - icecat I see that for all the above packages, build attempts that include the fix are already ongoing in koji, so there's hope that we might be able to resolve the situation in time. However, if ANY of the above build cannot be completed soon, or, if ANY of the updates cannot move to the stable Fedora updates, it can block users from upgrading to the Firefox 51 update on Jan 24. Is that acceptable? Do you agree that we make NSS conflict with any known incompatible packages mentioned above, and thereby may inhibit a subset of Fedora users from upgrading to Firefox 51 immediately? If we can get all the above builds done quickly, and all of them pushed to Fedora stable updates quickly, we're good. Note that we have the remaining risk that we haven't identified all Mozilla packages that might be affected. The relevant code isn't in NSS, but in Mozilla's network code. That means, if the above list of packages isn't the complete set of affected Mozilla based applications, other packages might still experience the connectivity regression. But as soon as another package is identified, it can rebuild to pick up the mentioned fix. Thanks Kai PS: Tracking bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1381400 (Don't get confused with the separate, unrelated discussion on TLS 1.3) An example of the regression is here: https://bugzilla.redhat.com/show_bug.cgi?id=1414929 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mock error on armv7hl koji
FYI, the issue was gone after Kevin had updated all builders to newer kernel/libraries and had rebooted them. Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mock error on armv7hl koji
On Wed, 2017-01-11 at 12:16 +0100, Pavel Raiskup wrote: > > The relevant task is: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=17230493 > > > > Thank you, > > Could the build go OOM? mock_output.log doesn't report anything after rpmbuild is started, it seems the task gets interrupted. build.log shows the build completes, and the test suite execution has started, which takes a rather long time, with many individual tests, which includes starting and termination of background processes. That log also stops reporting progress somewhere in the middle of the expected tests. Exhausted resources (like OOM) seems like a plausible explanation for the unexpected interruption of the task. Could someone with administrator access on the arm builder machine please check if that theory is correct? Are there known limitations? Thanks Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable
On Mon, 2016-08-22 at 07:40 -0400, Stephen Gallagher wrote: > FESCo discussed this briefly on Friday. There was no formal vote, but the > general sense was that you should just go ahead and do this as described above > (immediately, so it lands in updates-testing ASAP and will be available by the > time the Alpha ships). Thanks! commited http://pkgs.fedoraproject.org/cgit/rpms/ca-certificates.git/commit/?h=f25=9c4ba05bc7552c5d4163760cc997b6021ac5a606 built http://koji.fedoraproject.org/koji/taskinfo?taskID=15337856 and update submitted https://bodhi.fedoraproject.org/updates/ca-certificates-2016.2.9-1.1.fc25 Kai -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 24: Call for testing: ca-legacy disable
Hello, I'm the maintainer of the ca-certificates package. Could you please help to confirm that the following system configuration change doesn't cause any regressions for your use of the Internet? ca-legacy disable # (needs to be executed with root permission) If you see any issues with SSL/TLS connections after this change, please try to go back to the default configuration, by executing ca-legacy default then restart the software you were using, and try your connection again. If "ca-legacy default" makes it work again, then please let me how I can reproduce the connection that fails for you in "ca-legacy disabled" mode. (... either by sending an email, or by commenting in the following tracker bug: https://bugzilla.redhat.com/show_bug.cgi?id=1368522 ) Background: I'd like to disable the legacy CAs by default in Fedora 25, which I believe is safe. Your testing will help to confirm that. In the past, the special configuration was introduced because of limitations in older software versions. In the meantime, all known limitations have already been fixed in the software we ship with Fedora 24. The change will increase security, because it will allow us to remove trust for older root CA certificates with weaker key sizes. If you'd like to know more what the ca-legacy tool does: - man ca-legacy - https://fedoraproject.org/wiki/CA-Certificates Thanks for your help! Kai signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable
On Fri, 2016-08-19 at 09:18 -0500, Michael Catanzaro wrote: > On Fri, 2016-08-19 at 15:20 +0200, Kai Engert wrote: > > > > It won't break software that uses NSS / OpenSSl / GnuTLS / glib- > > networking. > > I have only one concern: what about Qt stuff? Do you know? I've just used f24 qupzilla to access a site with a relevant configuration. I'm using the suggested configuration on my system, and the site loads fine. So apparently QT uses one of the fixed underlying libraries. > Anyway, I agree that you should prepare an F25 update for this. Just do > not request a freeze exception, then it will be pushed to testing > immediately after the alpha release. > > I'm not sure I agree with pushing it to F23/F24 due to the risk of > unexpected breakage -- you were CCed in [1] which was our chance to do > that for F24 -- but it will probably work out fine > > [1] https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.or > g/thread/FTYLBKE5MU5E2OGD43G5HA7AXAZIKM7Q/#FTYLBKE5MU5E2OGD43G5HA7AXAZIKM7Q I'm very sorry, but I had missed that thread. I blame bad folter filtering and the large amount of emails. I've improved my filtering, to make sure I'll see all emails I'm cc'ed on. Kai -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable
On Fri, 2016-08-19 at 09:05 -0400, Stephen Gallagher wrote: > Applying this to older releases would be a violation of the Stable Updates > Policy[1] (though arguably it could be considered to fall under "The update > fixes a security issue that would affect a large number of users.". Although I currently assume the change is safe for stable Fedoras, getting it into future stable releases such as Fedora 25 has a higher priority. Instead of a fixed schedule for updating to F23/F24, here's a more conservative suggestion: We start a new thread on this devel list, and ask all developers who use F23/F24 in a stable environment, to perform the configuration that is equivalent to the suggested package change (which is, to run the "ca-legacy disable" command), and ask them to report any regressions they notice. We could adjust our plans based on the feedback (or lack thereof) we'll get. If everything seems to work fine, in a second step, we could broaden our call for testing, by sending an equivalent message to a fedora users mailing list. > That said, I'm not saying "don't allow this in F25", personally. I'm saying > "don't try to land it in the middle of an already-slipped Freeze". That's a > different situation. I don't want this to potentially cause us to slip another > week. Understood, thanks. Kai -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable
On Fri, 2016-08-19 at 09:45 -0400, Stephen Gallagher wrote: > However, pre-release Fedora is different from released Fedoras in that the > updates-testing repo is enabled by default on them. This means that if you > push > the ca-certificates package to updates-testing before next week's Go/No-Go > meeting, it is guaranteed that it will already be available to anyone doing a > dnf update from the moment they install the Alpha media. This makes it exactly > one update from inclusion on Alpha systems. It does not need to wait for a > stable push to get there. Thank you for this detail. In other words: - exclude this change from alpha to avoid all risks - create the alpha release, and after it's done: - build this change into f25 updates-testing - all F25 alpha users doing updates will get this change immediately and will participate in testing it. That sounds good to me. Thanks Kai -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable
On Fri, 2016-08-19 at 15:20 +0200, Kai Engert wrote: > It's not as simple as that. The suggested change doesn't mean that our > software > will block any CAs with 1024 bit. This sentence wasn't sufficiently precise. Although for some server certificates, it's possible to find a chain of trust to one of the old 1024 bit roots, that doesn't mean that these server certificates will be blocked. Instead, our software has already been fixed to find the alternative chain of trust to the replacement root CAs. That means, despite no longer trusting these 1024 bit root CAs, all issued certificates that are still intended to be valid, will be treated as valid by our software, because it can find the path to the alternative, stronger root CAs. server intermediate / old 1024-bit root CA certificate -> CA certificate -> points to either - \ new stronger root CA Kai -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable
On Fri, 2016-08-19 at 09:01 -0400, Stephen Gallagher wrote: > > I'm having a hard time following the argument of scale and risk here > > when it pertains to schedule slip. The package itself is fairly > > self-contained and isn't likely to cause issues against the actual > > Alpha test criteria. Can you elaborate why you think doing this as an > > FE would cause a slip? > > > > Essentially, it means that anything in Fedora using 1024 RSA root CAs would > suddenly fail. It's not as simple as that. The suggested change doesn't mean that our software will block any CAs with 1024 bit. I've explained the technical background in detail in the link to the openssl ticket that can be found in my initial message of this thread. The issue here is that whenever a server certificate needs to be verified, there may be more than one potential chain of certificates to find a trusted root CA. The CA organizations had planned to phase out their roots, and had implemented mitigations already, when this project started two years ago. In order to still work, software must be able to find alternative chains of trust, to the newer replacement root CAs, which we already ship in our CA list. Two years ago, OpenSSL and GnuTLS and glib-networking weren't able to find these alternative trust chains, which was the only reason why we had decided to keep trusting the old root CAs. Meanwhile our software has been fixed, and those library now can find the required alternative trust chains, and things work. > I don't have a clear picture of what exact tests are run, but I'd > not be surprised to discover some of the Workstation browser tests to suddenly > start failing as a result of this. That's not even including anyone who just > starts poking around with it and filing bugs because their favorite website is > no longer available. Based on the work we've done, I don't think this will happen. Our group has scanned a very large number of the most popular sites (Alexa). We identified that there are still a very small number of sites that still use the legacy configuration that was problematic with the older software versions, but couldn't find issues with the SSL/TLS libraries I mentioned. We have been preparing this, and have waited for quite a bit of time, before this is now being suggested as a reasonable thing to do. > Put another way: with my Blocker/FE reviewer hat on, I'd be inclined to vote > this as too risky to grant an FE to, simply because we have no real way of > knowing what it would break. I'd rather not jeopardize the already-slipped > alpha for a late change with an unknown risk level. It won't break software that uses NSS / OpenSSl / GnuTLS / glib-networking. Sites that are trusted in a fresh Firefox profile will work with these other software libraries, too. Only sites that aren't trusted by Firefox might fail to be verified, but that's exactly what we want to achieve, for security reasons, following the trust decisions that have been made by the Mozilla CA maintainers, and which we want to follow. > With my FESCo hat on, I'd be in favor of landing this in updates-testing > immediately. Then folks who install the Alpha will get it in their first > update > and we'd have ample time to work out the issues prior to Beta. If we agree to try to include it with Fedora 25, then both before Alpha and after Alpha are fine with me. Thanks Kai -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable
On Fri, 2016-08-19 at 14:54 +0200, Florian Weimer wrote: > The plan is to apply this change to past releases, too. > > I find this discrepancy—okay for past releases, but not okay for > alpha—somewhat puzzling. I don't know which direction this should go, > but let's be consistent, please. Given that this: - doesn't have the risk of breaking the operating system, - but only the small risk that some unidentified software we ship might no longer be able to connect to a very small amount of servers, the alpha release seems like a good opportunity to me to allow for feedback from users in testing environments. If we'll get any feedback of nonworking connections, I assume it will be limited to more exotic software that does SSL/TLS connections (because OpenSSL + GnuTLS + NSS + glib-networking are known to have been fixed). If we get any such feedback prior to shipping stable updates for Fedora 23 + 24, it will give us the chance to work on changes to potentially affected software (which we currently don't know if any such software exists). I agree with Florian, if nobody is concerned with the idea to make the change for stable F23/F24 updates, then we should include it as part of the final F25, too, and earlier testing is better. If it cannot become part of F25, then this cleanup would have to be postponed until after the release of F25, for consistency. Kai -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable
On Fri, 2016-08-19 at 08:46 -0400, Josh Boyer wrote: > On Fri, Aug 19, 2016 at 8:38 AM, Stephen Gallagher <sgall...@redhat.com> > wrote: > > > > On 08/19/2016 08:29 AM, Kai Engert wrote: > > > > > > On Thu, 2016-08-18 at 22:29 -0400, Yaakov Selkowitz wrote: > > > > > > > > Beta sounds a bit late to be introducing such a change unilaterally. > > > > Should this not be going through FESCo at this point? > > > > > > Then I suggest that we make the change immediately for Fedora 25, to allow > > > it to > > > be included in the delayed alpha release. > > > > > > > It will absolutely not be accepted as a Freeze Exception. Changes of this > > scale > > are far too high-risk and will almost certainly result in another schedule > > slip. > > I'm having a hard time following the argument of scale and risk here > when it pertains to schedule slip. The package itself is fairly > self-contained and isn't likely to cause issues against the actual > Alpha test criteria. Can you elaborate why you think doing this as an > FE would cause a slip? I've filed a FESCo ticket, asking for approval for this change in Fedora: https://fedorahosted.org/fesco/ticket/1616 The suggested change is limited to modify static lists. It will change two existing configuration choices to have identical effect. The only risk is that potentially, we find software that can no longer connect to a very small amount of Internet sites (because the site's certificates requires one of the legacy CAs to be trusted). That risk is very small, and doesn't affect the stability of the Fedora OS. Kai -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable
On Thu, 2016-08-18 at 22:29 -0400, Yaakov Selkowitz wrote: > Beta sounds a bit late to be introducing such a change unilaterally. > Should this not be going through FESCo at this point? Then I suggest that we make the change immediately for Fedora 25, to allow it to be included in the delayed alpha release. Kai -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable
On Mon, 2016-08-15 at 22:19 +0200, Kai Engert wrote: > Unless we find good reasons not to do it, I suggest to push the legacy > removals > to stable around 2016-09-21. I just noticed that the Fedora 25 beta freeze is scheduled for 2016-09-20. I think it would be good to have the change included in Fedora 25 by default, so I'd like to push it to a f25 stable update one week earlier, around 2016-09-14. Kai -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable
You may remember Mozilla's initiative from 2014 to remove those root CAs from the CA trust store that use RSA keys of a weaker 1024-bit size. The topic has been previously discussed on this list [1]. Because of past limitations with both OpenSSL [2] and GnuTLS, and to ensure their compatibility with most security SSL/TLS sites until their limitations could be removed, we had decided to delay the removal of the root CA trust from Fedora. We called that legacy trust, the legacy trust was set to enabled as the default configuration, and we had introduced the ca-legacy utility [3] to allow an administrator to configure their preference between a "default" setting (higher compatibility) and "disable" (less compatibility, strictly following Mozilla's decisions), and we documented our changes over time to Mozilla's list [4]. Mozilla upstream has completed the removal of SSL/TLS trust for all such root CAs, the last removal had happened in late 2015. (... although some of the root CAs are still trusted for email security certificates, this is why the legacy tool doesn't simply add or remove CAs, but it switches between two different sets of trust flags.) As a result, operators of web sites had time to learn about broken sites, and it's likely that most sites have been fixed. Therefore it's time to follow up. In the meantime, both GnuTLS and OpenSSL have been fixed, and the versions we ship in stable Fedora can handle the problematic scenarios correctly. I'm not aware of SSL/TLS sites that are trusted in a fresh Firefox profile, but which aren't trusted by openssl s_client or gnutls-cli when the system is configured with ca-legacy disable. (Thanks a lot to Hubert Kario for performing web scans of a large set of major web sites, that provided helpful data.) Therefore I suggest that we attempt to remove all legacy trust flags in an update to the ca-certificates.rpm package very soon. (More specifically, I suggest that the legacy list is changed to be empty, with the result that both legacy configurations "default" and "disable" will have the identical state.) An update to the ca-certificates set version 2016.2.9 (as of NSS 3.26) is currently pending (which adds trust for the ISRG / Let's Encrypt root CA). I'd like to push that one to stable updates first. Immediately afterwards, I'd like to submit a follow-up release, that removes the legacy trust flags, and push that to testing on all currently maintained Fedora branches. I'd like to disable auto-karma for the legacy CA removal, and allow a few weeks to wait for feedback. Unless we find good reasons not to do it, I suggest to push the legacy removals to stable around 2016-09-21. Please let me know if you any questions or concerns. Kai [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OCQ5LTMJFT4A366TBSPXWWROV7WCJV5J/ [2] https://rt.openssl.org/Ticket/Display.html?id=3621#txn-4 [3] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4NZLWGVXCGUROHT535R7PTRQJKHILSWW/ [4] https://fedoraproject.org/wiki/CA-Certificates [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1156844 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Heads up: nss-3.18 released: coming to fedora
On Thu, 2015-03-19 at 16:54 -0500, Yaakov Selkowitz wrote: On Thu, 2015-03-19 at 17:41 -0400, Elio Maldonado wrote: nss-3.18 was released. Please see the upstream release notes at https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.18_release_notes Rawhide is now updated and it should start showing up on updates-testing for F-22 and stable branches next week. According to that, shouldn't there also be a ca-certificates release to match? Yes, of course, I'll work on it asap. Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: update on ca-certificates, introducing the ca-legacy utility
On Fri, 2014-11-21 at 17:17 +0100, Kai Engert wrote: https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc19 https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc20 I'd appreciate more testing feedback. I'd like to push these packages into the stable updates channel, soon. Thanks in advance, Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
update on ca-certificates, introducing the ca-legacy utility
On Fri, 2014-10-31 at 14:05 +0100, Kai Engert wrote: All legacy root CA certificates, which seem to be required for full compatibility with either OpenSSL or GnuTLS, will continue to be included and enabled in the ca-certificates package. For users who are willing to accept the breakage and prefer using the latest trust, only, we provide a mechanism to disable the legacy trust. I've described the proposed approach in more detail at https://bugzilla.redhat.com/show_bug.cgi?id=1158197 I've pushed experimental packages with this implementation to Rawhide and updates-testing for Fedora 21. I have disabled the karma automatism, because I'll be offline for the next 2 weeks, and don't want things to go live while I'm away. I think it will be helpful to collect test feedback during that time, and see if it's suitable, and make a ship/no-ship decision of this approach later. In the meantime, while I was on vacation, the above has been (accidentally) pushed as a stable update for Fedora 21 already: ca-certificates-2014.2.1-1.5.fc21.noarch It seems it will be included in the final release of Fedora 21. Given that we keep legacy trust enabled, and given that I haven't seen any problem reports, it's probably OK. Using the new ca-legacy utility, users/administrators who are willing to accept the compatibility issues and who prefer to closely follow the Mozilla CA trust decisions, can disable trust for the legacy root CA certificates as a systemwide configuration, by executing this command as root: ca-legacy disable The configuration will be remembered in /etc/pki/ca-trust/ca-legacy.conf and will be used on future package upgrades, when additional certificates are moved to the legacy state. If required, it's possible to undo the configuration and restore to the current default, using: ca-legacy enable The current configuration can be shown using: ca-legacy check Regarding Fedora 19 and Fedora 20: On F19/F20, GnuTLS is also affected by the breakage, when disabling trust for the legacy CAs, because GnuTLS has been enhanced in Fedora 21 and later, only. Updated packages for F19 and F20, that provide the update to version 2.1 of the ca-certificates list, and which also include the new ca-legacy utility and configuration mechanism, have been pushed to updates-testing: https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc19 https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc20 Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: update on ca-certificates, introducing the ca-legacy utility
FYI, I'm documenting the changes that we make on top of the Mozilla CA list at: https://fedoraproject.org/wiki/CA-Certificates Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
update on ca-certificates, introducing the ca-legacy utility
Resending this as a new thread, for increased visibility. As explained in the older thread, the Mozilla project has started to remove CA certificates that contain weak keys. Those removals cause issues with software based on OpenSSL, and software based on older versions of GnuTLS. (A short description of the issue can be found in tracker bug https://bugzilla.redhat.com/show_bug.cgi?id=1166614 - I intend to file a ticket against OpenSSL shortly.) For Fedora, we have decided to keep the legacy CA certificates included and trusted by default, in order to avoid compatibility issues, until we get functional updates to OpenSSL. I'm documenting the changes on top of the Mozilla CA list at: https://fedoraproject.org/wiki/CA-Certificates However, we want to provide users/administrators with the ability to change the default, by configuring the ca-certificates to strictly follow the trust decisions made by Mozilla, thereby accepting the compatibility issues (e.g. untrusted TLS connections, if certificates of affected server configurations cannot be validated). The above has been implemented for Fedora 21, it looks like it will be included as part of the Fedora 21 release: ca-certificates-2014.2.1-1.5.fc21.noarch Using the new ca-legacy utility, it is possible to disable trust for the legacy CA certificates as a systemwide configuration, by executing this command as root: ca-legacy disable The configuration will be remembered in /etc/pki/ca-trust/ca-legacy.conf and will be used on future package upgrades, when additional certificates are moved to the legacy state. If required, it's possible to undo the configuration and revert to the current default, using: ca-legacy enable The current configuration can be shown using: ca-legacy check Regarding Fedora 19 and Fedora 20: On F19/F20, GnuTLS is also affected by the breakage, when disabling trust for the legacy CAs, because GnuTLS has been enhanced in Fedora 21 and later, only. Updated packages for F19 and F20, that provide the update to version 2.1 of the ca-certificates list, and which also include the new ca-legacy utility and configuration mechanism, have been pushed to updates-testing: https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc19 https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc20 Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: update on ca-certificates, introducing the ca-legacy utility
On Fri, 2014-11-21 at 10:45 -0500, Stephen Gallagher wrote: Kai, this is very important information buried at the bottom of a long email thread; would you mind re-sending this summary in a new thread (also to devel-announce) so that people are sure to see it? done -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Wed, 2014-10-15 at 12:28 +0200, Vít Ondruch wrote: Nevertheless, I am still unsure how to proceed with RubyGems. Should I ship the bundled certificates again? Or should I wait until somebody notices? Sorry for my late reply, because I didn't have a good suggestion earlier. We should work with the upstream OpenSSL and the GnuTLS projects, and motivate them to implement more advanced path building. This would be a long term project. For the short term, I'd like to suggest the following strategy: All legacy root CA certificates, which seem to be required for full compatibility with either OpenSSL or GnuTLS, will continue to be included and enabled in the ca-certificates package. For users who are willing to accept the breakage and prefer using the latest trust, only, we provide a mechanism to disable the legacy trust. I've described the proposed approach in more detail at https://bugzilla.redhat.com/show_bug.cgi?id=1158197 I've pushed experimental packages with this implementation to Rawhide and updates-testing for Fedora 21. I have disabled the karma automatism, because I'll be offline for the next 2 weeks, and don't want things to go live while I'm away. I think it will be helpful to collect test feedback during that time, and see if it's suitable, and make a ship/no-ship decision of this approach later. So, to answer Vít's original question: I'd prefer if RubyGems didn't ship its own copy. I think our recent achievement that all software packages on a system use the same (default) set of trusted CA certificates is a good improvement, and I think we should keep it. Thanks Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Fri, 2014-10-31 at 15:00 +0100, Nikos Mavrogiannopoulos wrote: Sorry for my late reply, because I didn't have a good suggestion earlier. We should work with the upstream OpenSSL and the GnuTLS projects, and motivate them to implement more advanced path building. This would be a long term project. Is there some issue with gnutls in F21? As far as I understand it should work as expected with the certificates removed. I confirm that using GnuTLS 3.3.9-2.fc21 on Fedora 21 testing, with ca-certificates-2014.2.1-1.3.fc21, and ca-legacy set to disabled, the command gnutls-cli -p443 www.amazon.com reports a trusted certificate. That's great, thanks Nikos for fixing it in the newer GnuTLS on Fedora 21! (Just for the record, using gnutls 3.1.27 on Fedora 20, and a scratch build of the new ca-certificates package, and set to disabled, the certificate is still rejected, which I understand is because of the older GnuTLS version.) If anyone can still see problems with GnuTLS and the above configuration (disable) on Fedora 21, please let us know which site has the issue. This means, the remaining package that needs fixing is OpenSSL. Thanks Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Mon, 2014-09-08 at 12:53 +0200, Vít Ondruch wrote: I believe that we must contact Amazon and Symantec about this issue. Amazon should remove the second intermediate, ending the path with the G5 intermediate. This will allow openssl to find the trusted root CA. Also, Symantec should reach out to all of their customers and tell them you update their configuration. I will contact them. Great! Thanks. Should I open ticket against ca-certificates to keep track about this issue? There was a short discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c4 In this particular case, because it works with NSS/Firefox, the admins don't think it's necessary to reconfigure? I think it doesn't help to track the issue with this particular web site. I've been told this is a default configuration, which had been recommended by the CA to the customers for a long time, in order to achieve maximum compatibility with clients. So it's unlikely to get all sites changed, for two reasons, worry of site admins to break compatibility, and the fact that it's unrealistic to reach and convince all site admins. This means, we'll either have to find a software solution (such as getting gnutls/openssl enhanced to construct alternative chains), or wait with weak 1024-bit removals by default, until all involved server certificates have expired, which would be very unfortunate (and which might take several years, because of the transitioning trick, that causes recently issued certificates to appear to have been issued by both the weak legacy and stronger replacement root ca cert). Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote: On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote: Unfortunately only NSS works. Both openssl and gnutls fail to connect to popular sites because of that change. It should not be assumed that the users of ca-certificates are only programs using nss. [1] is an interesting read. I get the impression that certificates are being removed as long as there is a compatible replacement that NSS can validate, based on NSS's custom strategies for certificate validation. Is this claim accurate? Yes. Getting phased out old, weak 1024-bit root CA certificates is difficult work, because there are so many issued certificates that still chain up to them. If we wanted to wait for all of them to expire, it would take many additional years, until users were safe from attackers trying to generate certificates that appear to have valid signatures from CA certificates that use a weak signing key. Bridge CA certificates are a common way to enable transitioning from old CA to newer CA certificates, while keeping compatibility. Shipping intermediate CA certificates to help find software find alternative trust chain is a good solution, in my opinion, and indeed is used by upstream to clean up the Mozilla CA list, while keeping compatibility. In my opinion, if other software cannot find the alternative trust chains, that's a bug. I think it's good that we have started experimenting with these removals in the testing areas of Fedora, because it raises awareness of these issues, and hopefully can bring higher priority to getting OpenSSL and GnuTLS enhanced. But given the heavy complaints, maybe it's necessary that we delay shipping the upstream removals into stable Fedora a little longer, until we have a better solution (either by having OpenSSL/GnuTLS enhanced, or maybe by implementing a way that enables users/admins to re-enable legacy CA certificates). Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Tue, 2014-08-26 at 12:36 +0200, Vít Ondruch wrote: $ gem fetch power_assert ERROR: Could not find a valid gem 'power_assert' (= 0), here is why: Unable to download data from https://rubygems.org/ - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://s3.amazonaws.com/production.s3.rubygems.org/latest_specs.4.8.gz) The gem tool appears to use openssl. $ openssl s_client -showcerts -connect rubygems.org:443 21 \ |grep Verify return code Verify return code: 0 (ok) $ openssl s_client -showcerts -connect s3.amazonaws.com:443 21 \ |grep Verify return code Verify return code: 20 (unable to get local issuer certificate) The failure is with the s3.amazonaws.com host. Looking at the certificates the server sends: $ openssl s_client -showcerts -connect s3.amazonaws.com:443 21 \ |egrep s:| i: 0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=s3.amazonaws.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3 i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority This means, the server sends three certificates during the handshake. One server cert, and two intermediates. The intermediate at level 2 was issued by root CA: C=US O=VeriSign, Inc. OU=Class 3 Public Primary Certification Authority This root CA is very old, it had been issued in 1996: With the recent upstream update 2.1 this certificate was disabled for the SSL/TLS use, see: https://bugzilla.mozilla.org/show_bug.cgi?id=986005 (Symantac/Verisign was aware, cc'ed on the bug, and didn't object.) When connecting to this server using an NSS client, such as Firefox, it works. I believe this is because an alternative trust chain can be found. The intermediate certificate sent by the server at level 1 was issued by: C=US O=VeriSign, Inc. OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only CN=VeriSign Class 3 Public Primary Certification Authority - G5 A root CA with this subject is included in our trust list. So, NSS can find this root CA cert, and succeeded the verification, and ignores the unnecessary, additional intermediate CA cert sent by the server. I guess that openssl strictly wants to make use of all intermediates sent by the server, and doesn't search for alternative chains. And the only certificate satisfying this chain has been marked as untrusted for SSL/TLS in our update. I believe that we must contact Amazon and Symantec about this issue. Amazon should remove the second intermediate, ending the path with the G5 intermediate. This will allow openssl to find the trusted root CA. Also, Symantec should reach out to all of their customers and tell them you update their configuration. I will contact them. If we want things to just work, without requiring server administration, then openssl should be enhanced to try additional chains, (or the Ruby software could be changed to use NSS). Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Mon, 2014-09-01 at 18:03 -0500, Michael Catanzaro wrote: This update has caused a lot of pain for Epiphany. Could you take a look at [1] when you get a chance and help us figure out what's gone wrong? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1134602#c3 Sorry for the delay. I've commented in the bug, let's continue there. Thanks Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Tue, 2014-08-19 at 10:07 -0400, Miloslav Trmač wrote: - Original Message - If you experience such situations, the right approach is to contact the owner of the certificate (or the server), and ask them to get a replacement certificate, or to install a replacement certificate on their SSL/TLS server. That’s the right thing to do of course, but leaves the users with an unusable system in the mean time. Could the update description at least generally point to how to work around this if the certificate owner is not (sufficiently quickly) responsive? Mirek Most software has options to override certificate errors. I don't want to encourage how to do that, and covering all potential applications would result in a big list. I'd assume that people who are desparate will find the options on how to override certificate errors and connect anyway. Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Tue, 2014-08-19 at 10:07 -0400, Miloslav Trmač wrote: That’s the right thing to do of course, but leaves the users with an unusable system in the mean time. Could the update description at least generally point to how to work around this if the certificate owner is not (sufficiently quickly) responsive? I'd expect that users would be blocked from using just one application, or from connecting to just a few servers - but should be able to connect to the majority of the Internet just fine. Can you think of scenarios, where a system is mostly unusable? A general workaround is to downgrade to the previous package version, do you think we need to state that explicitly in the update description? Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
Hello, this is a heads-up for an update to the ca-certificates package that I've just submitted for updates-testing for Fedora 19 and 20. The upstream Mozilla CA list maintainers have decided to start removing CA certificates that use a weak 1024-bit key. Although those certificates are still valid, Mozilla has worked with the CAs, and they did agree that it's OK to remove them. However, there are end-entity and intermediate-CA certificates which have been issued by the removed CAs, which are still valid, and they might still be used by some - despite the CAs having attempted to reach out to all their customers and getting them to reconfigure their systems. This means, when installing the updated ca-certificates package version 2014.2.1, some SSL/TLS connections might suddenly fail, because the related CA certificate is no longer trusted. If you experience such situations, the right approach is to contact the owner of the certificate (or the server), and ask them to get a replacement certificate, or to install a replacement certificate on their SSL/TLS server. Additional details can be found in the update description, which I'll paste at the end of this message. (I have disabled karma-automation for this update, in case there's a need for a longer testing period. Note that this updated set of CA certificates is currently planned to be part of Firefox 32, which will get released around SEP 02.) Regards Kai Update description: === This is an update to the latest released set of CA certificates according to the Mozilla CA Policy. It's the same set that has been released in NSS versions 3.16.4 and 3.17. It's noteworthy that several CA certificates with a weak key size of 1024-bits have been removed, prior to their expiration. (It is expected that additional CA certificates with weak 1024-bit keys will be removed in future releases.) The removed CA certificates have been used to issue end-entity and intermediate-CA certificates which are still valid. Those certificates are likely to be rejected when using this upated ca-certificates package. The owners of affected certificates should contact their CA and ask for replacement certificates. In some scenarios it might be sufficient to install an alternative intermediate CA certificate (e.g. on a TLS server), allowing an alternative trust chain to another root CA certificate to be found. More information about the affected CA certificates and other recent modifications can be found in the NSS release notes for version 3.16.3 at https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.16.3_release_notes with amendments to the changes as explained in the NSS release notes for version 3.16.4 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.16.4_release_notes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
advertisement in packaged software
Do the Fedora guidelines allow packaging of software that will show advertisement to the user? Are there any existing packages that already do that? Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: advertisement in packaged software (e.g. Firefox)
On Mi, 2014-02-12 at 10:46 +0100, Kai Engert wrote: Do the Fedora guidelines allow packaging of software that will show advertisement to the user? Are there any existing packages that already do that? There are multiple open questions that need answers. I wanted to get the first question answered first, but since the discussion has already started to discuss consequences, let's get the questions and potential consequence spelled out and discussed separately. This discussion is trigged by http://lwn.net/Articles/585577/ Question (1) Are we allowed to ship software in Fedora that dynamically loads advertisements from the web and shows them to users? I'm partly guessing here. I suspect that showing advertisements doesn't mean showing things that were decided at build time, but rather content that is dynamically decided to be delivered by Mozilla. I think this question should be answered first, and independently of other questions. Question (2) Is the Fedora community willing to accept Mozilla's desire to show advertisements in Firefox? This might depend on the amount and kind of advertisement that will be shown. The information we've received so far in the public blog doesn't clarify this yet: https://blog.mozilla.org/advancingcontent/2014/02/11/publisher-transformation-with-users-at-the-center/ Only if the answer to at least one of the questions (1) or (2) is no, then we must discuss the other questions: Question (3) Does removing the advertisement feature of Firefox violate the trademark? We don't know the answer yet, and this will probably require a statement from Mozilla. Only if answer for question (3) were yes, we'd need to look into removing the trademarks, and how exactly to do it (whether we'd do it on your own, or if we'd work with another project that already does that). Personally, my initial reaction is disappointment that the free software project I've been contributing to since 2001 considers to use it as a mechanism to deliver advertisement, but I'd like to wait with my final judgement until we hear more details. Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: advertisement in packaged software (e.g. Firefox)
On Mi, 2014-02-12 at 09:39 -0500, Matthew Miller wrote: On Wed, Feb 12, 2014 at 03:36:00PM +0100, Kai Engert wrote: Question (1) Are we allowed to ship software in Fedora that dynamically loads advertisements from the web and shows them to users? I think this might need to be broken down or clarified. Otherwise, any web browser is out. Clarification: Load and show advertisement without the user having navigated to a site that triggers loading of the advertisement. Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Shared System Certificates followup: Packaging Guidelines?
On Mi, 2013-12-11 at 09:59 -0800, Toshio Kuratomi wrote: Last night someone asked me about a package that they were working on that had a pem file in it. Looking closer, it seems that the pem file is a cacert bundle. Looking around, there's not currently documentation on what to do with these. I did find some information on the wiki, though: https://fedoraproject.org/wiki/PackagingDrafts/Certificates https://fedoraproject.org/wiki/Features/SharedSystemCertificates https://fedoraproject.org/wiki/Talk:Features/SharedSystemCertificates I'm by no means an expert in this area but my impression is that the PackagingDraft is made obsolete by the Shared System Certificates Feature. As Killerix and Misc note on the talk page we should probably have some packaging guidelines added that tell us what the expectations are. The Guideline should answer the following questions: * Should packages that ship their own cacerts be patched to use Shared System Certificates instead? [I think the answer to this is yes] Packages, that would like to use a default list of CA certificates, should be changed to use (consume) the new consolidated data that we provide as part of SharedSystemCertificates. Fedora packages that need to trust additional, application specific CA(s) should install them into a different, applicaton specific location, and implement loading of those additional trust anchors in their application code. Fedora packages other than the ca-certificates.rpm shouldn't install into the global trusted locations (unless the Fedora decision makes decide otherwise). The reason is, installating additional CAs has the side effect that all other applications on the system will trust that CA, too. (For example, if a game application requires a CA to connect to a game network, that CA shouldn't be trusted for certifying the identities of web sites when surfing using Firefox etc. For that, we want only CAs that have been vetted according to the rules of the Mozilla CA Certificate Policy). Besides Fedora packages, there might be deployment specific packages. If a closed user group, for example the members of an organization, would like to trust a CA operated by that organization, and make it easy to add that CA for the members, the organization could create a package that places an additional CA certificate (or bundle file) into our global locations. Such an RPM package shouldn't qualify for inclusion in Fedora's standard repositories, but it should be made available for download from a separate location. Another category might be community operated CAs, like the one operated by http://cacert.org which hasn't been able yet to fulfil the requirements for inclusion in the Mozilla CA list (but which has some popularity in the free software and free information world). Someone could make an RPM package that installs their root certificate into Fedora's global trust location. I personally would argue, such packages shouldn't be included in Fedora's repositories either, as another package could easily pull it in with an dependency, and users might install it without noticing the impact of installing it. * If the package contains a cacert that is not in our bundle, should those be added? We shouldn't do that. If any CA would like to get included as a globally trusted third party, it should follow the rules outlined at http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ and we'd eventually include them as part of the regular updates to that list maintained by Mozilla. * How does a package add a cacert to our existing bundle? If it's a global Fedora package, it shouldn't. If it's a non-Fedora package, outside of Fedora's repositories, targetted for a closed user group, where people deliberately choose to trust those CAs, the package can install additional files into the /etc/pki/ca-trust/ or /usr/share/pki/ca-trust-source/ as explained in the manual page that you get with $ man update-ca-trust Regards Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Shared System Certificates followup: Packaging Guidelines?
On Mi, 2014-01-08 at 12:32 -0500, Stephen Gallagher wrote: but what about package-specific CAs? For example, I have a pattern I was thinking about adding to the tog-pegasus that causes it to do the following: 1. Create an x509v3 certificate and key with the CA extension 2. Create a new service certificate for tog-pegasus locally 3. Sign it with the CA certificate. 4. Store the public CA certificate in the system's trust store. 5. Destroy the private key so that it cannot be used to sign other certificates. (The effect here being that a user on the local system can connect to an SSL socket on localhost without being challenged or having to ignore the verification) You are listing yet another scenario that I hadn't considered in my previous message. As I understand it, in your scenario, you intend to dynamically create a new CA at installation time. That CA wouldn't be controlled by someone else, because the packager wouldn't have access to the key that gets generated at install time. You're argueing it shouldn't be a problem to make that locally generated CA trusted for all applications on the system, as nobody else controls it. One could think of tricks to abuse that ability. For example, someone could make a package that implements a dynamic MITM capability, by installing a local proxy that uses the locally trusted CA, which can dynamically generate appropriate server certificates for any site a user wants to visit, and by installing a (localhost) proxy configuration into browser's network configuration, thereby enabling the package to incercept all outgoing connection TLS connections without getting noticed. True, when granting permission to install a package on a system, you're granting that package full control over your computer anyway. However, maybe such a MITM functionality might be difficult to detect, and allowing global CA installation would make such tricks possible. Of course, I'm constructing a hypothetical worst case scenario for brainstorming purposes. I don't know if it's realistic that a clever MITM tool, which only activates itself based on certain condition, that hides inside a game package, would be noticed during package review. In order to find a compromise between the extreme positions find a solution and be careful, maybe it should be a requirement that locally generated CA certificates must contain a domain name constraint extension, that limits for which sites it is valid. Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Shared System Certificates followup: Packaging Guidelines?
On Mi, 2014-01-08 at 09:16 -0800, Adam Williamson wrote: Packages, that would like to use a default list of CA certificates, should be changed to use (consume) the new consolidated data that we provide as part of SharedSystemCertificates. This could do with some specifics: [adamw@adam libtorrent (master)]$ rpm -ql ca-certificates | grep -c -e 'pem' -e 'crt' 11 [adamw@adam libtorrent (master)]$ which one of those 11 files, exactly, should we have packages use when? When I came up against this situation recently I threw a dart and picked /etc/pki/tls/certs/ca-bundle.crt , but I'm hardly certain. The manual page explains which files are intended for which purpose, and also mentions the availability of a smarter pkcs#11 module for applications that are able to use it. $ rpm -ql ca-certificates |grep -w man /usr/share/man/man8/update-ca-trust.8.gz $ man update-ca-trust Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Shared System Certificates followup: Packaging Guidelines?
On Mi, 2014-01-08 at 13:38 -0500, Stephen Gallagher wrote: I don't really see this being more likely than an existing application just bundling a wrapper script for certificate generation and 'update-ca-extract' and quietly running that as part of %post. Just as easy to miss and equally effective (with much less trouble). true I don't think that we can really write policy that eliminates the risk of a determined abuse of the available technology. Probably. What do you think about adding a section to package reviewing guidelines, which says that packages that add files to the global CA directories should provide reasoning, and have someone check that reasoning. It might at least make people aware this is something to be careful with. Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Shared System Certificates followup: Packaging Guidelines?
On Mi, 2014-01-08 at 10:03 -0800, Adam Williamson wrote: which one of those 11 files, exactly, should we have packages use when? When I came up against this situation recently I threw a dart and picked /etc/pki/tls/certs/ca-bundle.crt , but I'm hardly certain. The manual page explains which files are intended for which purpose, and also mentions the availability of a smarter pkcs#11 module for applications that are able to use it. $ rpm -ql ca-certificates |grep -w man /usr/share/man/man8/update-ca-trust.8.gz $ man update-ca-trust Thanks. It would probably be useful to have a guidelines section about this, as it wasn't at all obvious. Are you suggesting a guidelines section in the manual page, or somewhere else? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Manual page for Shared-System-Certificates feature
A manual page is now available that describes the new Shared-System-Certificates feature. It's contained in this new build for F19: https://admin.fedoraproject.org/updates/ca-certificates-2012.87-10.4.fc19 (and in rahide, too). man update-ca-trust Please let us know if you have feedback. Thanks a lot in advance! Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora release name problem
On Mon, 2013-03-18 at 23:56 +, Sérgio Basto wrote: Could we consider change release name from Schrödinger's Cat to Schrodingers Cat or other name that not have this additional problem ? In my opinion, it makes sense to distinguish between code and content. When compared with 10-15 years ago, it's my perception that most applications that nowadays process user visible content are able to deal with international characters. This is a great advancement. However, code is usually limited to ASCII. We cannot use Umlauts in variable names in most programming languages. It's no surprise to me that many programmer tools have similar limitation. The Fedora release name is part of the code, and also used by programmer or administrative tools to process it. What we are facing here is the question: Are we ready to introduce non-ASCII characters into the code and tool level?. It seems like the answer is not yet. While I agree it cannot hurt to be able to support umlauts and special characters everywhere, supporting it at the code and tool level seems like a challenge, as we are learning. I don't agree to that argument that it must be fixed immediately, because it's not required to correctly process user visible content. And if you are looking for a more formal justification: Consistently support international and special characters in Fedora release tools sounds like a Fedora Feature to me. But we are already past the Feature Freeze date. So, if you would like to see this as a priority, then propose to make it a future Fedora Feature and offer to work on it. But for this round, it seems too late. I'd like to propose a compromise for the release name. From http://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat I'm learning that Schrödinger was Austrian. Austria uses German language. The german equivalent of Schrödinger's Cat is Schrödingers Katze. No apostrophe is being used here. http://de.wikipedia.org/wiki/Schr%C3%B6dingers_Katze And it's quite common to replace the ö umlaut with oe, for example in email addresses. Because of the above, I propose that we use the following string for the Fedora 19 release name: Schroedingers Katze Regards Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
let's just use Schroedingers Katze as the fedora 19 release name
For those who didn't scroll to the end of my previous message, I propose to use the name: Schroedingers Katze Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Shared System Certificates
On Wed, 2013-01-23 at 16:31 -0500, Bill Nottingham wrote: Essentially, how will we know whether apps work transparently with the library changes, and/or if there are apps that are hardcoding old locations/methods somewhere? Bill, we're not yet ready to shake hands, we're starting and giving you the little finger. Today we have a world that seems unorganized, where multiple crypto toolkits each do their own separate thing. Because some toolkits haven't offered a complete solution, some applications have used their own solutions on top of them. We cannot solve all of that at once. We must start with a first step. This first step is to create a common infrastructure. Once that common infrastructure is ready, then applications can start to use it. After that initial step has been completed, we can advertise it and recommend that new applications use it. And we can start investigating existing applications and work with maintainers to get them changed to the use new shared infrastructure. The goal for this initial round is to have the shared infrastructure ready, and to offer a default functionality that applications are able to use. Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Shared System Certificates
On Thu, 2013-01-24 at 08:27 -0800, Samuel Sieb wrote: On 01/23/2013 07:05 AM, Jaroslav Reznik wrote: = Features/SharedSystemCertificates = https://fedoraproject.org/wiki/Features/SharedSystemCertificates Feature owner(s): Kai Engert k...@redhat.com, Stef Walter st...@redhat.com Make NSS, GnuTLS, OpenSSL and Java share a default source for retrieving system certificate anchors and black list information. This is an initial but useful step in the direction of a comprehensive solution. Will this finally allow deploying an extra CA system-wide that Mozilla products will accept? Yes, if we achieve the goal to get NSS into using the new pkcs#11 library, instead of the default libnssckbi.so, without requiring application changes. We'll have to figure out how to do it. Possibly by changing /usr/lib64/libnssckbi.so to be a symbolic link to /etc/alternatives - which can then either point to a classic NSS lib - or, if our new infrastructure is active - point to the new pkcs#11 replacement. I'm not yet sure whether we would continue to ship both alternatives and use the above system of symbolic links - or whether the new dynamical-contents library would become a mandatory install right away - together with a change to stop shipping the classic static-contents library. Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
pdfedit
In September, Ryan expressed interest to resurrect the pdfedit package, but I couldn't find follow-up messages nor koji builds. I made a patch to fix the build, see https://bugzilla.redhat.com/show_bug.cgi?id=772534 I'll try to take ownership and get builds done. Kai smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pdfedit
On Sun, 2012-12-09 at 16:49 +0100, Kai Engert wrote: In September, Ryan expressed interest to resurrect the pdfedit package, but I couldn't find follow-up messages nor koji builds. I made a patch to fix the build, see https://bugzilla.redhat.com/show_bug.cgi?id=772534 I'll try to take ownership and get builds done. Now I notice that Ryan had already requested ownership, but he is still waiting for his right to commit? What is necessary to make progress and get builds done? Thanks Kai https://admin.fedoraproject.org/pkgdb/acls/name/pdfedit http://lists.fedoraproject.org/pipermail/devel/2012-September/171293.html smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
updating gscan2pdf
Hello, I'd like to ask for assistance getting package gscan2pdf updated. I reported a bug two months ago (835685) but it didn't get attention. One month ago gscan2pdf upstream was updated to 1.0.6, but fedora still uses the four months old version 1.0.4. I've built the newer 1.0.6 locally, no changes were required to the spec, and it fixes said bug for me. I'm (kengert@fedoraproject) willing to help getting the package updated, if you give me permissions. Thanks in advanced for your help. Kai -- Sending me encrypted e-mail: - get my S/MIME cert from https://kuix.de/smime-keyserver/ - get my GPG/PGP key from http://pgp.uni-mainz.de/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seamonkey status
On 24.08.2011 12:04, Rahul Sundaram wrote: On 08/22/2011 03:01 AM, Kai Engert wrote: On 20.08.2011 13:59, Rahul Sundaram wrote: On 08/20/2011 03:57 PM, Matěj Cepl wrote: Putting Firefox maintainers on CC to have a definite word on this, but I suspect that Seamonkey is generally completely in the arms of community. I guess if anybody wants to take it over formally in pkgdb he would be welcome. Chris and Kai, am I right? I dont know what community means in this context. Everything is in the hands of the community in Fedora but the question is who is maintaining it? Apparently, noone is keeping it updated. If so, orphan it properly I worked on it during the weekend. Thanks. Can you fix the spec to follow the packaging guidelines? Add comments when there is a necessity to deviate I would appreciate contributions, reviews, specific proposals. Thanks Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seamonkey status
On 21.08.2011 23:53, Heiko Adams wrote: Am 21.08.2011 23:35, schrieb Kai Engert: On 20.08.2011 13:59, Rahul Sundaram wrote: On 08/20/2011 03:57 PM, Matěj Cepl wrote: Putting Firefox maintainers on CC to have a definite word on this, but I suspect that Seamonkey is generally completely in the arms of community. I guess if anybody wants to take it over formally in pkgdb he would be welcome. Chris and Kai, am I right? I dont know what community means in this context. Everything is in the hands of the community in Fedora but the question is who is maintaining it? Apparently, noone is keeping it updated. If so, orphan it properly I worked on it during the weekend. http://koji.fedoraproject.org/koji/taskinfo?taskID=3290353 I don't know if it's an upstream bug or not but I can't set mozilla sync to override local data. But except of this thing it seems to work fine. Would you be able to test an official build from http://releases.mozilla.org/pub/mozilla.org/seamonkey/releases/2.3/ and test if it's an upstream bug? I'm currently not actively using SeaMonkey, and haven't ever used Sync with SM, so I would appreciate your testing! Also, could you please give karma to https://admin.fedoraproject.org/updates/seamonkey-2.3-1.fc15 if it works for you? Given this is a major upgrade, and given I had to apply some hacks to make it package correctly, I would appreciate more testing before pushing it to stable. Thanks a lot Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seamonkey status
On 20.08.2011 13:59, Rahul Sundaram wrote: On 08/20/2011 03:57 PM, Matěj Cepl wrote: Putting Firefox maintainers on CC to have a definite word on this, but I suspect that Seamonkey is generally completely in the arms of community. I guess if anybody wants to take it over formally in pkgdb he would be welcome. Chris and Kai, am I right? I dont know what community means in this context. Everything is in the hands of the community in Fedora but the question is who is maintaining it? Apparently, noone is keeping it updated. If so, orphan it properly I worked on it during the weekend. http://koji.fedoraproject.org/koji/taskinfo?taskID=3290353 Does this work for you? Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for f14?
On 24.03.2011 19:23, Kevin Kofler wrote: Adam Williamson wrote: In the particular case of Firefox, this isn't a problem, as it just gives you one giant static executable...so it's very easy to 'uninstall'. :) Did they really manage to stuff even the resources into the binary? Wow, very un-unixy! ;-) It's not a single binary, but it's a single self-contained directory. Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 repo
On 18.07.2010 16:06, Mike Chambers wrote: Anyone doing any builds of this during development and supplying a repo to download and install that way instead of source builds? Or is it too buggy to do at the moment? Remi does: http://rpms.famillecollet.com/fedora/13/remi/i386/repoview/firefox4.html http://blog.famillecollet.com/pages/Config-en Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
The work done by Remi, providing a parallel install Firefox 4 for Fedora 13, could be reused to provide the same parallel install in Fedora 14. http://rpms.famillecollet.com/fedora/13/remi/i386/repoview/firefox4.html http://blog.famillecollet.com/pages/Config-en kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
