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
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
>
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
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 wa
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
--- 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
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
> ce
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
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
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
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
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
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
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
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
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
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,
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
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:
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'
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
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
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
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
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
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
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
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?
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
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
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
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.
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.
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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:
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
74 matches
Mail list logo
