How are package updates which resolve CVE’s handled?

Support Software & Applications
1

How are package updates which resolve CVE’s handled?

For example, Palemoon-bin has a version bump to v28.13.0, which fixes several CVE’s. That version is in testing and unstable, but not in stable.

Addition after split off from the manjaro build package version bump topic:
Nowadays it’s not a big issue for myself, since I install it via the AUR.

However there is some annoyances after each system update, since the version of the community-repository gets aligned with the AUR one, thinking pacman that I’ve installed it via the community repository instead of via the AUR. Also pacman lacks the ability to prioritize sources per package, thus I keep getting annoyed with “warning: palemoon-bin: local (version-blah-blah) is newer than community (version-blah-blah)”

2

@Aragorn moderator posted in another topic:

Serious security updates are always pushed out immediately. Non-serious security updates are commonly handled via the normal update cycle, in which Manjaro Unstable follows Arch Stable. From there, things percolate down via Manjaro Testing into Manjaro Stable.

I can’t post hyperlinks, so here is the link in text (copy & paste):
https://forum.manjaro.org/t/manjaro-stable-not-safe/21697/3

1 Like
3

And how would that be possible when there are 3 main branches (unstable, testing, stable) plus there is the stable-staging branch and each mirror server provides a database for each of them?

Switch to unstable then. There will be no more blah-blah. :wink:

4

@bogdancovaciu, Your reaction is mostly meta-talk, but I’ll bite:

Are you asking me how pacman devs need to implement this feature?

Well, I give you an idea:
As I said, an optional per package configuration rule. For example the config in a JSON file:

So it comes down to this:

{
	"custom-sources": {
		"pale-moon-bin": {
			"1": "AUR",
			"2": "stable"
		},
 		"example-package": {
			"1": "testing",
		},
	}
}

No, for my daily driver, I prefer to use stable instead. Except for packages which fix security bugs and CVE’s.

5

As far as I know: pacman is an Arch Linux “product”. Having “three” branches is a Manjaro thing. I see little chance of such feature being every included in pacman since it has no notion of “branches”. This would rather be a pamac feature, if anything.

Unfortunately there are also irreconcilable problems:

  1. testing has: A/2.0, B/2.0, C/2.0
  2. stable has: A/1.0, B/1.0, C/1.0
  3. A/2.0 needs B/2.0
  4. C/1.0 needs B/1.0
  5. B/2.0 breaks C/1.0
  6. user wants A from testing, others from stable

What should happen in this case? And there are possibly many more edge cases. In my opinion this is a high effort, relatively low gain investment, that’s one of the reasons why it has not been implemented.

6

Do you want archlinux to rewrite pacman just to avoid a warning? while archlinux ignores the branches and aur not exists for pacman

Moreover mixing branches is only a source of errors so there will never be an easy way to mix and break our system.

7

Why are you guys replying on an example of the matter I want to point out, instead of the matter itself?

I crossed the less relevant information out with the hope the topic doesn’t get more derailed.

8

Practically your topic reduces now to: When will Palemoon-bin v28.13.0 be on stable branch?
With Packages

image
image755×304 16.5 KB

Answer: Soon! :slight_smile: