Bug 1284095

Created attachment 1097302 [details]
Log from executing curl https://getfedora.org/

Tried and couldn't reproduce it. This is from an up to date system with:
nss-3.21.0-1.0.fc23.x86_64
nss-softokn-3.21.0-1.0.fc23.x86_64
nss-util-3.21.0-1.0.fc23.x86_64
curl-7.43.0-4.fc23.x86_64

Thanks for looking so quickly!

(In reply to Elio Maldonado Batiz from comment #1)
> nss-softokn-3.21.0-1.0.fc23.x86_64

Ah, I did not have this.  I had gotten the nss update indirectly while installing other packages, but nss-softokn was left at 3.20.  Having now updated this too, things are working again.

Perhaps there should be some hard rpm conflicts in here?  i.e. nss-softokn already requires "nss >= $V", but apparently here it's not good for nss to get ahead of nss-softokn.  So maybe add nss conflicts "nss-softokn < $V"?

It's pretty nasty for less experienced users that updating nss without nss-softokn would leave dnf completely broken.  RPM dependencies ought to be able to prevent this from happening, I think.

(In reply to Josh Stone from comment #2)
> Thanks for looking so quickly!
> 
> (In reply to Elio Maldonado Batiz from comment #1)
> > nss-softokn-3.21.0-1.0.fc23.x86_64
> 
> Ah, I did not have this.  I had gotten the nss update indirectly while
> installing other packages, but nss-softokn was left at 3.20.  Having now
> updated this too, things are working again.
> 
> Perhaps there should be some hard rpm conflicts in here?  i.e. nss-softokn
> already requires "nss >= $V", but apparently here it's not good for nss to
> get ahead of nss-softokn.  So maybe add nss conflicts "nss-softokn < $V"?

Aha, Looking at the spec file I see
%global nss_softokn_version 3.20.1
Requires:         nss-softokn%{_isa} >= %{nss_softokn_version}
BuildRequires:    nss-softokn-devel >= %{nss_softokn_version}
....

My mistake as I forgot to update the required nss_softokn_version to 3.21.0. 

> 
> It's pretty nasty for less experienced users that updating nss without
> nss-softokn would leave dnf completely broken.  RPM dependencies ought to be
> able to prevent this from happening, I think.

I use to recommend in the Bodhi update notes to update all packages in the bundle, i.e. dnf update nss nss-softokn nss-util nspr in this case. I should do that again. That in addition to updating the minimum {Build}Requires: versions in spec of course.

(In reply to Elio Maldonado Batiz from comment #3)
> Aha, Looking at the spec file I see
> %global nss_softokn_version 3.20.1
> Requires:         nss-softokn%{_isa} >= %{nss_softokn_version}
> BuildRequires:    nss-softokn-devel >= %{nss_softokn_version}
> ....
> 
> My mistake as I forgot to update the required nss_softokn_version to 3.21.0. 

Is it always in lockstep?  Maybe just set it to %{version} so you can't forget.

(Presumably the same goes for nss_util_version, but I did get nss-util anyway.)

> > It's pretty nasty for less experienced users that updating nss without
> > nss-softokn would leave dnf completely broken.  RPM dependencies ought to be
> > able to prevent this from happening, I think.
> 
> I use to recommend in the Bodhi update notes to update all packages in the
> bundle, i.e. dnf update nss nss-softokn nss-util nspr in this case. I should
> do that again. That in addition to updating the minimum {Build}Requires:
> versions in spec of course.

A note in bodhi sounds appropriate, but that's just advisory, and I wouldn't have seen it in this case.  The rpm Requires have real control.

(In reply to Josh Stone from comment #4)
  
> Is it always in lockstep?  Maybe just set it to %{version} so you can't
> forget.
> 
They are in fedora but I must keep generic with nss_softokn-version and nss-util_version as the spec file(s) will be imported into RHEL for the next major update and there softoken is older being the last version that gets (or is about to get) FIPS-140 validation.

> A note in bodhi sounds appropriate, but that's just advisory, and I wouldn't
> have seen it in this case.  The rpm Requires have real control.

I agree. I'll fix the versions soon. The Bodhi update may come a bit later in case another issue comes to light.

what i still don't understand is why we have always 3 different builds

* nss
* nss-softokn
* nss-util

they have typically the same version and arrive at different times in koji

*** Bug 1284100 has been marked as a duplicate of this bug. ***

I've just had this happen to me, so I raised 1284100 on dnf. I've now marked that as a duplicate of this one.

nss-3.21.0-1.1.fc23 nss-softokn-3.21.0-1.1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-aa9e359ff2

nss-3.21.0-1.1.fc23, nss-softokn-3.21.0-1.1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update nss-softokn nss'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-aa9e359ff2

Created attachment 1097536 [details]
SSL error in chromium

I have problem with SSL connection in chromium browser from Russian Fedora repository. There is ERR_SSL_PROTOCOL_ERROR error on site https://chrome.google.com/webstore/category/apps
No such error after downgrading nss* packages to 3.20.1-1.0.fc23.

Last -3.21.0-1.1.fc23 update not fixed SSL error.

See https://bugzilla.redhat.com/show_bug.cgi?id=1284100#c3 and I can access https://chrome.google.com/webstore/category/apps just fine with either the -1.0.fc23 of the -1.1.fc23 releases. Am I missing something here?

The problem seemed to be that nss was at 3.21 but nss-softokn was still at 3.20. The RPMs permitted this, but once you got in that state you couldn't use dnf to get out of it.

https://bodhi.fedoraproject.org/updates/FEDORA-2015-aa9e359ff2 should take care of this and I requested push to stable on it. 

Filed Bug 1284569 so I can properly update the f22 and f21 Bodhi bundles.

(In reply to Elio Maldonado Batiz from comment #15)
> https://bodhi.fedoraproject.org/updates/FEDORA-2015-aa9e359ff2 should take
> care of this and I requested push to stable on it. 

Even if you submit all ns* packages in a single update, it will not prevent users from updating only a subset of them.  The old/new ns* packages should either work together, or you need to use RPM dependencies to restrict the set of installable combinations of packages to a subset that is actually known to work.

Does anybody know why the updated nss packages do not work with old nss-softokn?  Was this incompatibility expected?

no, it will not prevent, but it would make it much more unlikely and for testers like me downloading from koji way easier instead seek around when the 2 other builds are finished

I confirmed the new packages have the right RPM dependencies -- thanks!

nss-3.21.0-1.1.fc23, nss-softokn-3.21.0-1.1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

(In reply to Kamil Dudka from comment #16)
> 
> Does anybody know why the updated nss packages do not work with old
> nss-softokn?  Was this incompatibility expected?

I don't know why but it doesn't surprise too much given the nature this update, though technically a minor release, it's a very rich hefty one. see 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.21_release_notes 
Lots bugs fixes and changes with new functions, types, and macros which span across various layers. I see 43 bug fixes at https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&classification=Components&query_format=advanced&product=NSS&target_milestone=3.21&list_id=12700184