Any idea what I missed and what I need to do from here? I need to get on an airplane and leave soon and can’t afford the possible downtime from collateral damage an “update” to 12.3 might cause. I have to admit, I’m considering risking a broken upgrade to 12.3 anyway. This server is running a lot of different packages and processes, and at the moment, they’re all working except for this Heartbleed issue. It was this issue which helped me discover 12.2 is no longer supported.
And yes, on 12.3 and 13.1 you should get the fixed packages by running “zypper up” as well. If you don’t, you either don’t have the update repo in your repo list, or you have not installed libopenssl-1_0_0 from the standard repo in the first place. (keyword “vendor stickiness”)
Yes, the packages in there are built for Factory, i.e. the testing branch of the next openSUSE version.
Also it is in fact the development repo for Factory, so the packages in there might break at any time.
And finally, the latest openssl packages might not be fully compatible to the ones shipped with 12.2 which would break all your software that uses them.
There is a reason why new versions of software are normally not released as official updates, only backported fixes.
Why don’t you just want to use the 12.2 packages that I pointed to?
Again, those are the same as the 12.3 update, but built for 12.2.
On 2014-04-11 10:56, wolfi323 wrote:
> I would not recommend to install a Factory package on 12.2, and even
> less to add that repo.
I read in passing a reference to the 12.2 package being built on a
factory repo by someone. It might be this package. If it is, the package
“might” be installed, but the repo should not be added. And I don’t
understand why it is there.
This info is not verified.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I hate to have to answer my own question, but I was finally able to get this patch installedin my 12.2 server, and it does work. Here’s what I had to do:
Thank you for this patch! Now I can go catch a plane and upgrade to 12.3 when I have more time to manage collateral upgrade damage. I know if I want to do this right I now need to upgrade certificate and change passwords on my site. Or run the risk that I’m tiny enough, nobody will care.
IMO this thread shows the severe problem with backporting a patch into an existing package version…
Unless you test, you cannot be assured easily whether you have a version without certain patches or not. So, for instance I assumed for a long time that “zypper up” was sufficient and only looked further when I wasn’t seeing the patched version installed on my machines. And, of course @craigarno ran tests to prove whether the patch was installed.
If the patch is serious enough… and I think everyone can agree that heartbleed is in this category… then it’s a bad idea to backport and so should require a new revision number, even if minor. The openssl project seems to understand this because the mainline release will have a new revision number (1.0.2, succeeding all 1.0.1 versions).
Perhaps the same policy should be integrated into openSUSE versioning, even if to add a custom minor revision number of our own. Of course whatever policy is adopted needs to be consistent with mainline versioning so as to automatically perform updates when mainline versions arrive(In a different open source project I subscribe to, they’re experiencing severe pains because their previous versioning caused update errors, so “live and learn”).
I do not understand you at al. When I look with YaST > Software > Software Management, I find these versions for libopenssl: http://hcvv.home.xs4all.nl/openSSL-versionsUpdate.jpeg
They are all on the Update repo and put there after the first one (the lowest in the list) was introduced on the release of openSUSE 13.1 in the OSS repo. As you can see, they all have different minor numbers. They are all the result of different backports over time. They can all easily be identified.
As I said earlier, you can get the latest by YaST Online Update, or by zypper patch. You can also do zypper up because that will include zypper patch (and it will also install newer versions of packages you have on other repos than the standard OSS, non-OSS and Update repos).
Can you please xplain what sort of revision number you mean.
On 2014-04-11 20:26, tsu2 wrote:
>
> IMO this thread shows the severe problem with backporting a patch into
> an existing package version…
> Unless you test, you cannot be assured easily whether you have a version
> without certain patches or not.
A “test” that simply looks at the version, is broken. It can give you a
false positive.
And also gives you false negatives…
You have to actually test for the vulnerability.
> Perhaps the same policy should be integrated into openSUSE versioning,
> even if to add a custom minor revision number of our own.
Yes, this is being considered.
Notice that updating to the latest upstream package is out of the question.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
As an engineer with 30 plus years of experience in design and documentation, I understand both your points. This is a sticky (and difficult) documentation issue.
As “hcvv” points out openssl-1.0.1e-1.44.1.x86_64.rpm already does contain the revision number “tsu2” would like to see. It’s the “1.44.1” part against openssl-1.0.1e. So this issue is covered, and has the added bonus of self documenting which “other vendor” software these changes are applied. i.e. it’s a branch in the OpenSUSE revision control system. I like this approach, but it may not be self evident to some who are staring at a big identification string and wondering why the darn thing is so complex?
If simplified too far, such as only incrementing only the primary number, then confusion is added which will require further documentation to sort out each version number, what was patched, and how it leapfrogged “newer” versions from an outside vendor. 1.0.1e is OpenSSL’s number. 1.44.1 is OpenSUSE’s number covering all the changes which had to be applied to make 1.0.1e work with everything else in the OpenSUSE system. Development is further complicated by OpenSUSE having to maintain different branches for different releases; 12.2, 12.3, 13.1, 13.2, multiplied by x86, x64, etc.
As was said elsewhere in this thread, earlier systems probably don’t want OpenSSL’s 1.0.1g as it is likely to have interface (API) changes which will break existing software in existing systems using OpenSSL’s 1.0.1e. And there is a -lot- of software which uses OpenSSL in a system; IMAPS, HTTPS, POPS, Asterisk, … and on and on.
The existing documentation system from my point of view works and covers existing need. Anything else is usually education about how things work.
I would like to add that I think the real issue tsu2 has is with zypper. “zypper up” wasn’t able to “do the right thing” auto-magically with the new repo’s. This is why I had to go look at the new 12.2 repository, get the actual names, then tell zypper to forcibly install the correct versions based on what I observed in the repository, and not supersede this choice with what zypper chose as a “newer” version which doesn’t address this issue. Testing proved this.
What we’re looking at is a “corner condition” in zypper’s design, just now newly identified. If you’d like to see zypper operate differently, as in get more design attention for this kind of corner condition, I suggest leaving a politely worded “Bug” for the team. This bug should be your best effort to explain the problem (this special case) in graphic detail with as many of your own assumptions explained as you can identify before saving. This is hard to do, but worth the time it takes. Otherwise the developer may be scratching their head wondering exactly what you meant and close your clever suggestion as “non-repro” because it was too vague to be actionable in development.
Remember, you’re communicating with someone who likes OpenSUSE as much as you do, who really does want to help you. Give them all the information and encouragement you can so we can all have a better product. And remember, “Stuff Happens”. What matters is how you pick yourself up and keep going. Hopefully with as much grace and style as you can manage. And don’t forget to smile.
>
> IMO this thread shows the severe problem with backporting a patch into
> an existing package version…
> Unless you test, you cannot be assured easily whether you have a version
> without certain patches or not. So, for instance I assumed for a long
> time that “zypper up” was sufficient and only looked further when I
> wasn’t seeing the patched version installed on my machines. And, of
> course @craigarno ran tests to prove whether the patch was installed.
>
> If the patch is serious enough… and I think everyone can agree that
> heartbleed is in this category… then it’s a bad idea to backport and
> so should require a new revision number, even if minor. The openssl
> project seems to understand this because the mainline release will have
> a new revision number (1.0.2, succeeding all 1.0.1 versions).
>
> Perhaps the same policy should be integrated into openSUSE versioning,
> even if to add a custom minor revision number of our own. Of course
> whatever policy is adopted needs to be consistent with mainline
> versioning so as to automatically perform updates when mainline versions
> arrive(In a different open source project I subscribe to, they’re
> experiencing severe pains because their previous versioning caused
> update errors, so “live and learn”).
>
I agree with you in principle but I’ve been through enough of these goat-
ropes to acquire a slightly different perspective. If you do a distribution
update update you face a substantial testing/verification delay whereas the
individual patch route allows for an almost instant response. Given that
this case was simple enough to make just about everyone comfortable with the
expected result, I see nothing wrong with end-running the established update
protocol as oS did. Different story if the potential for side effects are
larger but sometimes you just have to make a judgment call: response speed
vs. code protocol .
On 2014-04-11 22:16, hcvv wrote:
>
> Miuku;2636439 Wrote:
>> And this is why openSUSE should switch to a rolling distribution format.
>>
>> runs for the hills wearing a flame proof suit
> One of the important reasons I use openSUSE is that it is not using a
> rolling release system.
Same here.
By the way, I have just read that there is a new update been prepared of
openSSL to version 1.0.1g, to cover this “version” issue precisely. It
is not yet available.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I am using opensuse 13.1. In looking through the Yast Control Center, I find three instances of openssl 1.0.1e-11.32.1. How can I tell if any of these is a patch for heartbleed?
On Sat 12 Apr 2014 09:16:02 PM CDT, MoeNeigh wrote:
I am using opensuse 13.1. In looking through the Yast Control Center, I
find three instances of openssl 1.0.1e-11.32.1. How can I tell if any of
these is a patch for heartbleed?
Hi
Look at the changelog for the one that is installed…
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.1 Kernel 3.11.10-7-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
