OK, but even a later release of the same compiler is actually a different compiler, because the default flags or new flags will cause a different final package.
Do we know which applications are vulnerable now to these proposed possible attacks? Not that I've read, perhaps the set of packages vulnerable is much smaller than is being worried about. As a project manager for both IT and building projects I often heard that if we didn't fix the whole program schedule that everything would fail, when in reality all that was needed was retiming or upmanning the delivery of one or two deliverables kept the project on schedule and often in budget. I'm just pointing out that there is worry and proclamations about an unknown potential.
Again, we are in complete agreement on these points.
Maybe this should have read, "re-compilation" rather than "compilation", but my point is still the same. Even nobino and his project are finding very few problems with re-compilation, and even those that are problems he hasn't identified if they are critical or extension of one of the WM or DE's.

That's what I meant by "everything," and again, it's not true.

Everything on the Slackware DVD gets compiled while it is in -current, but not necessarily during the release cycle for that Slackware version, and certainly not right at release. There is no guarantee that everything on the Slackware DVD will compile with the sources provided, even right at release. Most of it will, but some of it may not.

I've said this about 5 times now, so I think I will just leave it at that.

on a realease, a package source should compile, I do not mean the binary, but the concept, once again a fact you ignore kindly.

custom stock packages != take the delivered source package and recompile it as it is


thanks for the demonstration that you still did not understand anything. you start to become embarrassing.
It was a nice weekend, but this starts to become boring.

Now that all interested agree to disagree, maybe let's this thread have some rest?

Attached Thumbnails

 

7 members found this post helpful.

You continue to ignore that Slackware is not a source distribution. It provides binaries, and those work as expected. What you *want* is that packages can be recompiled, but Slackware is under no obligation to provide it, and not doing so doesn't break the existing binary package.

What other reason could you have to need it to be able to compile? There is no reason if you're not diverging from the stock package because the stock package works fine.

I don't think I'm the one who should be embarrassed in this thread... You continue to ignore that Slackware is not source based and demand that a binary distribution cater to your desire to compile said distribution.

4 members found this post helpful.

This hair splitting over the difference of broken packages and broken build scripts is not only inane, its tedious.

2 members found this post helpful.

those interested on what can be done: two alternatives according to that discussion on lkml.org: https://lkml.org/lkml/2018/1/21/163

"We do need the IBPB feature to complete the protection that retpoline
gives us — it's that or rebuild all of userspace with retpoline."

"IBPB: It's kind of expensive (order of magnitude ~4000 cycles)"

read the following answer of L.Torvald in the same thread (he's talking about INTEL people):

"So somebody isn't telling the truth here. Somebody is pushing complete
garbage for unclear reasons. Sorry for having to point that out."

Is there new vulnerabilities to be announced sooner or later?

That thread is rather cool, compared to the thread on lkml.org!

2 members found this post helpful.

GCC 7.3 is out. Full retpoline ahead. The rat race begins


Cheers

4 members found this post helpful.

already reported

Er, are there actually a lot of packages that have build scripts that need to be updated?

I find that kinda unlikely, considering that: a) I've never had trouble rebuilding packages from -current, and b) all the packages in the x86 branch were rebuilt just a year or two ago (I pointed this out earlier).

Keep in mind that "need to set up a build environment to build the package" is not the same thing as "can't build the package".

It saddens me to see not many see the trees of the woods here?

Slackware maybe has come to a mayor crossroad here.

How come no one mentioned Slackware has legendary binary backwards compatibility?

Would the ABI change, this simply would not more be the case.

This is not a road bump - this is the end of road for those proprietary binary blobs or whatever, that where still working on Slackware every since.

And I have yet to find such a blob outside of the professional (as for money) use or computers.

Where Intel (and AMD) and the Kernel devs able to solve this the proper way, the ABI could stay and only the packages exposed to the actual threat vector could be hardened (browsers & co) ?

Slackware doesn't aim for backwards compatibility. If an ABI changes (which frequently occurs, as many who run -current know), then it's possible that programs compiled against it will be broken. This is no different for Slackware compared to Debian, Arch, or Gentoo.

This is why it isn't recommended to take packages from -current and install them on 14.2 (or packages from 14.1 and install them on 14.2) since you can run into incompatibilities.

If recompiling gcc using a different standard makes all previously compiled binaries incompatible, it's not any different (other than the scope) than when some library has a new, incompatible ABI and Pat needs to recompile those. You can't expect to run binaries compiled on a version of Slackware different than your own.

This is a limitation of using proprietary blobs. If the programs they rely on change, they may stop functioning. This is why you can't install AMD's legacy catalyst drivers onto 14.2. They only support up to Xorg 1.17, and 14.2 went up to 1.18. Early versions of the proprietary amdgpu-pro driver didn't support Xorg 1.19, so it could only be installed on 14.2. Newer versions only support 1.19, so you can't install them on 14.2.

If the people creating those blobs take it into account, they can support multiple versions of software. Just look at Nvidia's binary driver, VirtualBox or Steam. All work across a variety of versions on a variety of distros. If you're running the bleeding edge of some software (the kernel is a common one), they may be a bit behind with support, but they're usually updated within a few weeks.

1 members found this post helpful.

It's crossed my mind, but I decided to see how much it actually impacts me before worrying too much about it. Also, being a late adopter (only two 14.2 systems, the rest still on 14.1) grants me some luxury to observe consequences of changes before they arrive on my doorstep.

Relatedly, the retpoline and other "fixes" only address the currently known exploits to hardware problems that will doubtless be the source of new vulnerabilities for months, if not years. We're leaving one era of unprecedented security upheaval and entering another, even more dramatic one.

It's got me rethinking my approach to security. The old game of whack-a-mole was already getting too frenzied, and it's about to get unsustainable.

2 members found this post helpful.

Hm, it just proved my approach to security right. Big brother is always watching. No need to freak out, you can't do much about it. Just keep your door locked, helps most of the time.

Cheers

1 members found this post helpful.

Er, what?

I'm pretty sure its binary backwards compatibility is on par with that of any other binary-based distro. You just don't have a dependency-tracking package manager getting in your way.