Firefox version on trueos-major is 53 but current version of it is 57. What is it?


Hello. My pkg repo is trueos-major. Version of Firefox on it is 53, but fresh version of Firefox is 57. Do I all right? How can I upgrade my Firefox?

Best regards,


Do you mean trueos-master?

I also have trueos-master and the port for Firefox is correct. Are you sure that you’ve pulled and rebased from upstream?


It are my repos:

trueos-base: {
url: “”,
signature_type: “fingerprints”,
fingerprints: “/usr/local/etc/pkg/fingerprints/trueos”,
enabled: true

trueos-major: {
url: “”,
signature_type: “fingerprints”,
fingerprints: “/usr/local/etc/pkg/fingerprints/trueos”,
enabled: true

Is it correct, don’t?


Ah sorry. I misunderstood.

If you are on TrueOS stable. Then you will have the earlier version as that was released in June. Unstable has the latest version, but that will soon become stable in December.

So, if you wait a couple of weeks, you will have Firefox 57. If you can’t wait and are willing to send bug reports, you can try unstable.


you do realize mixing FreeBSD repos and TrueOS repos can get your machine really confused


Do I? What is it mean? Must I drop FreeBSD.conf? I thought this repo didn’t work…


this is for ports, my bad

my /usr/loca/etc/pkg/repos/FreeBSD.conf shows NO

And in June Firefox was 53. This up coming update will have 57


Ok, let me just clear up any confusion here:

  1. Firefox versions
    53 is the latest version on the STABLE repository (6-month release), 57 is the latest version on UNSTABLE (rolling-release). STABLE will be getting updated in the beginning of December and will stick with that for another 6-months.
  2. PKG repos.
    By default, I think there are a few package repos listed in the default pkg.conf, but the FreeBSD ones are disabled and the TrueOS ones are enabled (in the other config files for pkg). It is not recommended to “mix” the FreeBSD/TrueOS package repositories becuase the FreeBSD packages will not work on TrueOS (incompatible system ABI). That is why we build/push our own package repo which keeps in sync with the system.


Could we use the ESR releases for STABLE? They would seem to be better aligned with that release cycle.

(Update: Looks like that’s a separate package… maybe a suggestion to use -esr instead for STABLE?)


Ok, I think I understood all of it, thank you very much. I managed to install FF 57 from ports, everything has worked out.


Could you possibly make clear if there will be any security updates on STABLE?

Currently my daily security email indicates 20+ packages with vulnerabilities (including firefox and chromium). It looks like any package updates for stable stopped about 4 months ago.

I know there will be a stable update soon, but what will happen after that, no security fixes for another 6 months?


essentially - yes.

The whole point of the STABLE branch is to provide a relatively static version of the project (and all available packages) for up to 6 months. The only exception to this is if a major security advisory comes out for FreeBSD itself that impacts the STABLE release - in which case we will patch the OS and any impacted packages associated with that advisory. We will not be watching/updating 3rd-party packages during the 6-month lifecycle of a STABLE release - that breaks the whole purpose of a static/unchanging release branch.

If you need to use the latest versions of applications, then you need to change over to the UNSTABLE branch. That branch is specifically designed for rolling with the updates that are available from upstream vendors/developers.

Remember: the only way to truly avoid security holes is not a “reactive” approach where patches/updates are only pushed after an issue is found, but rather to stay current with upstream versions of utilities because most security issues are not reported publicly, they are quietly fixed in newer releases.


thank you for the clarification


This may be hijacking the original thread, but one thing that I’ve found useful is subscribing to the freebsd security mailing list. The mail is full of good information, mitigation techniques if possible, but always “what does this impact”. Based on that you can decide how critical the update is to you. Say a CVE is issued for sendmail that affects servers: if you are not running a publicly visible mail server (or not running one at all), that CVE while critical, is of lower importance for you to patch than someone using Sendmail for a publicly visible mail server.

Security vulnerabilities are worth actually reading and trying to understand the attack vector. If it requires root access while physically in front of the machine, you can control that. Remote privilege escalation simply by visiting a website with bad html, those I worry about.

I happen to like the STABLE/UNSTABLE that the team came up with. I don’t feel like I’m “always updating” and they’re saving me the trouble of updating a system and associated ports: if you’ve never done a make buildkernel && make buildworld && make installkernel && reboot && make installworld && rebuild all your ports, trust me when I say “let them do the work”.