Vulnerability on these ports!

When I try to update these vulnerable ports I end up in error.
# pkg audit -F
Code:
Fetching vuln.xml.bz2: 100%  748 KiB 766.3kB/s    00:01    
openjpeg-2.3.0_2 is vulnerable:
OpenJPEG -- multiple vulnerabilities
CVE: CVE-2018-6616
CVE: CVE-2018-5785
CVE: CVE-2018-5727
CVE: CVE-2017-17480
CVE: CVE-2017-17479
WWW: https://vuxml.FreeBSD.org/freebsd/11dc3890-0e64-11e8-99b0-d017c2987f9a.html

pango-1.42.0 is vulnerable:
pango -- remote DoS vulnerability
CVE: CVE-2018-15120
WWW: https://vuxml.FreeBSD.org/freebsd/5a757a31-f98e-4bd4-8a85-f1c0f3409769.html

2 problem(s) in the installed packages found.
#


# portmaster -o graphics/openjpeg graphics/openjpeg

Code:
===>>> Currently installed version: openjpeg-2.3.0_2
===>>> Port directory: /usr/ports/graphics/openjpeg

===>>> Gathering distinfo list for installed ports

===>>> Launching 'make checksum' for graphics/openjpeg in background
===>>> Gathering dependency list for graphics/openjpeg from ports
===>>> Initial dependency check complete for graphics/openjpeg


===>>> Starting build for graphics/openjpeg <<<===

===>>> All dependencies are up to date

===>  Cleaning for openjpeg-2.3.0_1
===>  openjpeg-2.3.0_1 has known vulnerabilities:
openjpeg-2.3.0_1 is vulnerable:
OpenJPEG -- multiple vulnerabilities
CVE: CVE-2018-6616
CVE: CVE-2018-5785
CVE: CVE-2018-5727
CVE: CVE-2017-17480
CVE: CVE-2017-17479
WWW: https://vuxml.FreeBSD.org/freebsd/11dc3890-0e64-11e8-99b0-d017c2987f9a.html

1 problem(s) in the installed packages found.
=> Please update your ports tree and try again.
=> Note: Vulnerable ports are marked as such even if there is no update available.
=> If you wish to ignore this vulnerability rebuild with 'make DISABLE_VULNERABILITIES=yes'
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/openjpeg

===>>> make build failed for graphics/openjpeg
===>>> Aborting update


===>>> You can restart from the point of failure with this command line:
       portmaster <flags> graphics/openjpeg 

This command has been saved to /tmp/portmasterfail.txt

#


# portmaster -o x11-toolkits/pango x11-toolkits/pango
Code:
===>>> Currently installed version: pango-1.42.0
===>>> Port directory: /usr/ports/x11-toolkits/pango

===>>> Gathering distinfo list for installed ports

===>>> Launching 'make checksum' for x11-toolkits/pango in background
===>>> Gathering dependency list for x11-toolkits/pango from ports
===>>> Initial dependency check complete for x11-toolkits/pango


===>>> Starting build for x11-toolkits/pango <<<===

===>>> All dependencies are up to date

===>  Cleaning for pango-1.42.0
===>  pango-1.42.0 has known vulnerabilities:
pango-1.42.0 is vulnerable:
pango -- remote DoS vulnerability
CVE: CVE-2018-15120
WWW: https://vuxml.FreeBSD.org/freebsd/5a757a31-f98e-4bd4-8a85-f1c0f3409769.html

1 problem(s) in the installed packages found.
=> Please update your ports tree and try again.
=> Note: Vulnerable ports are marked as such even if there is no update available.
=> If you wish to ignore this vulnerability rebuild with 'make DISABLE_VULNERABILITIES=yes'
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/x11-toolkits/pango
*** Error code 1

Stop.
make: stopped in /usr/ports/x11-toolkits/pango

===>>> make build failed for x11-toolkits/pango
===>>> Aborting update


===>>> You can restart from the point of failure with this command line:
       portmaster <flags> x11-toolkits/pango 

This command has been saved to /tmp/portmasterfail.txt

#
 
Note that by doing so you are installing ports with known security issues on them. Ignoring that is typically a bad idea. So think twice before applying DISABLE_VULNERABILITIES.
 
Note that by doing so you are installing ports with known security issues on them.

Not installing, upgrading ports with known security issues. I doubt that was the intention behind that vulnerabilities check feature, preventing upgrades seems too dumb.
 
It doesn't look like it's upgrading, it looks like it's downgrading actually.

Code:
===>>> Currently installed version: openjpeg-2.3.0_2
That looks good, but a little further down:
Code:
===>>> Starting build for graphics/openjpeg <<<===

===>>> All dependencies are up to date

===>  Cleaning for openjpeg-2.3.0_1
===>  openjpeg-2.3.0_1 has known vulnerabilities:
....
===>>> make build failed for graphics/openjpeg
So it's trying to build and install 2.3.0_1 instead of 2.3.0_2. And by enabling DISABLE_VULNERABILITIES it's actually being forced to install a vulnerable version.
 
Just spotted OP actually tries to downgrade openjpeg-2.3.0_2 to openjpeg-2.3.0_1. Meh, there is absolutely no utility in reading audit log, freaking out and frantically trying to upgrade your programs. For normal desktop/notebook users regularly checking the package repository for upgrades would be enough.
 
It shouldn't. It never did on any of my systems. Unless the VuXML info is wrongly interpreted, that's something that happened in the past. The version check was handled incorrectly in certain situations. But that doesn't appear to be the case here.

I can remember only one or two occasions when I really needed DISABLE_VULNERABILITY, but this was because there was no updated version available yet.
I have never needed it to update a vulnerable package to a fixed version.

That's why I said to think twice about enabling it. It's rarely needed. It certainly is never needed to update a vulnerable port/package to a fixed one.

But note that 2.3.0_2 is also vulnerable. At least according to VuXML. It says all versions, up to and including, 2.3.0_2 are vulnerable.
http://www.vuxml.org/freebsd/11dc3890-0e64-11e8-99b0-d017c2987f9a.html
 
If you run portmaster graphics/openjpeg x11-toolkits/pango, it is not supposed to install the most current?

Why the downgrade?

Unless the installation is launched by a dependency
 
Why the downgrade?
I suspect his INDEX-* file is not in sync with the actual ports tree he has. The INDEX may have 2.3.0_2 but the port itself might still be 2.3.0_1. An out of sync INDEX can cause all sorts of weird build issues.

If you use SVN keep an eye out for merge conflicts or other reasons why (parts of) the ports tree isn't updating correctly. If you use portsnap(8) it might be a good idea to wipe /usr/ports/ and do a fresh extract.

I've encountered things like this myself. Usually because I screwed around with various ports and settings. Wipe, rinse and repeat ;)
 
If you use SVN keep an eye out for merge conflicts or other reasons why (parts of) the ports tree isn't updating correctly. If you use portsnap(8) it might be a good idea to wipe /usr/ports/ and do a fresh extract.


The port tree and source code this built through SVN, the flavor of the system is RELEASE 11.2, and for binary packages the latest.
 
When the vulnerable program is a dependency of another program, I have used DISABLE_VULNERABILIES=yes on occasion and then deinstalled the vulnerable program with no il effects to the parent program after the build. graphics/OpenEXR being a vulnerable dependency for graphics/gimp was one. Only because I use GIMP daily and would be be lost without it. It probably won't work in the majority of cases and likely to break something.

I've had a vulnerability on graphics/OpenJPEG for weeks now. I haven't looked into it or tried it with that port. I've been waiting like everybody else. Patiently. I only frequent a handful of sites I trust on a regular basis and calculate the odds of them having set up an exploit as being low. I do what's within my power browser side to foil their evil plot and live with the risks.

I've been waiting for a new version of www/seamonkey and using www/firefox, now it's vulnerable and I'm on www/palemoon till I start to work on it. So it helps to have a program you can use to fall back on.

FreeBSD does and always has "just worked" for me as a desktop OS. This type of thing just happens from time to time and you deal with it.
 
....and using www/firefox, now it's vulnerable and I'm on www/palemoon till I start to work on it. So it helps to have a program you can use to fall back on.

FreeBSD does and always has "just worked" for me as a desktop OS. This type of thing just happens from time to time and you deal with it.

But palemoon doesn't have extensions like Ghostery or Privacy Badger to mitigate network insecurity like trackers or unbearable advertising.
 
So it's trying to build and install 2.3.0_1 instead of 2.3.0_2. And by enabling DISABLE_VULNERABILITIES it's actually being forced to install a vulnerable version.

Isn't it likely that 2.3.0_1 also has the vulnerability? I always assumed the vulnerability problem prevented you from get slightly-better-but-still-bad software, but I suppose like most people, I just wait around until the port gets fixed and then upgrade later and don't think too much about it.
 
But palemoon doesn't have extensions like Ghostery or Privacy Badger to mitigate network insecurity like trackers or unbearable advertising.

I've got Change Referer Button, DownloadThemAll!, NoScript, uBlock Origin and Eclipsed Moon installed as extensions in www/palemoon right now. That pretty well takes care of most things.

Eclipsed Moon changes your UserAgent but I need to disable it after doing so, it still shows what you changed it to. Otherwise it was logging me out every time I switched to a different forum page here.

And you cannot get DownloadThemAll! on www/firefox anymore.
 
I've got Change Referer Button, DownloadThemAll!, NoScript, uBlock Origin and Eclipsed Moon installed as extensions in www/palemoon right now. That pretty well takes care of most things.



Eclipsed Moon changes your UserAgent but I need to disable it after doing so, it still shows what you changed it to. Otherwise it was logging me out every time I switched to a different forum page here.

And you cannot get DownloadThemAll! on www/firefox anymore.

Hello Trihexagonal, what is Change Referer Button and DownloadThemAll! used for?
 
Hello Trihexagonal, what is Change Referer Button and DownloadThemAll! used for?

The Change Referer Button (yes, that's the way it's spelled) "add-on allows the user to quickly toggle "network.http.sendRefererHeader" without going to the "about:config" window."
https://addons.mozilla.org/en-US/firefox/addon/change-referer-button/

The page you land on can't tell which page you came from. I can't validate one of my site pages by clicking the Validator button with it enabled because it can't tell which page I was referred from. A click of the button is all that's needed to enable or disable it.

DownThemAll! (which was called DownloadThemAll!! before the Mandela Effect kicked in) is a mass downloader that speeds up the process of downloading one or more large files... like .iso files. :) It's the best.
 
DownThemAll! (which was called DownloadThemAll!! before the Mandela Effect kicked in) is a mass downloader that speeds up the process of downloading one or more large files... like .iso files. :) It's the best.

I can't find the DownThemAll extension in any of the browsers like firefox or palemoon.
 
Sorry for offtopic, but now that you mentioned palemoon, this is NOT how you promote your project: https://github.com/jasperla/openbsd-wip/issues/86
Sorry for a ditto offtopic response but I get the impression that the Palemoon developers don't even understand the ramification of license they used. The Mozilla Public License is pretty clear on applying extra limitations to your work.

Alas, that conversation turned ugly really quick and the result should be obvious. I think most of us would steer clear from Palemoon after reading that ordeal. I know I am.
 
It looks like they've cut the page that had incomparable add-ons, but here is the home page to download and install it.

https://www.downthemall.org/main/install-it/downthemall-3-0-3/

It is not installed because it is not compatible for firefox 63 or palemoon 27.9

By the way, has anyone been able to fix that openjpeg security vulnerability? The system continues to detect this eternal vulnerability.

# pkg audit -F
Code:
vulnxml file up-to-date
openjpeg-2.3.0_2 is vulnerable:
OpenJPEG -- multiple vulnerabilities
CVE: CVE-2018-6616
CVE: CVE-2018-5785
CVE: CVE-2018-5727
CVE: CVE-2017-17480
CVE: CVE-2017-17479
WWW: https://vuxml.FreeBSD.org/freebsd/11dc3890-0e64-11e8-99b0-d017c2987f9a.html

1 problem(s) in the installed packages found.
#
 
It is not installed because it is not compatible for firefox 63 or palemoon 27.9

I'm using www/palemoon 27.9.4 and DownThemAll! 2.0.18.1-signed.1-let-fixed.

massdownload.png

I had to rebuild www/firefox yesterday for the vulnerability, which hosed my www/palemoon installation, so I just rebuilt it, too.


Alas, that conversation turned ugly really quick and the result should be obvious. I think most of us would steer clear from Palemoon after reading that ordeal. I know I am.

I use it out of practicality. I only use Mozilla products and it gives me another option if www/firefox or www/seamonkey develop a vulnerability. Monkey has had a vulnerability for some time now.

I got wind of it just before the CoC and that took precedence, but was not the least bit happy about how we were treated as a community and have a card to play in that game up my sleeve.
 
Back
Top