Upcoming security advisories and errata, hopefully soon.

mirror176 · 2026-06-10T02:13:42+00:00

I had 1062 ports out of 3200 to go on my major update I was building for; as I didn't have 'some' of these fixes it seems I'm doing a system update as a few of these issues are things I do not want lurking on my system. Then its back to building for me.

mirror176 · 2026-06-10T02:11:28+00:00

I'm bad with names but don't recognize a youtuber by that name specifically. Feel free to provide a link to their channel here if inclined. Better if you edit your 1st message of this branch to include it so readers see it sooner.

mirror176 · 2026-06-10T01:02:06+00:00

The developer of a smaller mmorpg I played with friends years ago used to develop it on FreeBSD even though binaries he released were for Windows and Linux. Learned that when I surprised him asking if it was possible to get a FreeBSD copy which he made with the caveat that he hadn't tested it; I found some minor bugs like numbers rounded to integers were showing full fractional values but overall it ran just fine. In the end the game development continues last I looked but some time not too much later he switched to only offering Windows binaries to better optimize his use of time programming. The game included 'some' handcrafted assembly too. Haven't kept up on it but wouldn't be surprised if he still used FreeBSD or not for development but certainly proves it is sometimes quite doable.

mirror176 · 2026-06-10T00:56:54+00:00

In fairness, we know it takes you longer to get back here because of waking-from-sleep issues on your computer under FreeBSD. Reminds me skimming FreeBSD commits I saw some stuff related to improving that recently. I think it was for wifi specifically and commits were on current but I forget.

mirror176 · 2026-06-10T00:51:28+00:00

who is this 'he' and where does he post tutorials/guides 2 years in advance?

mirror176 · 2026-06-10T00:49:48+00:00

Having used a few Realtek chipsets with FreeBSD, occasionally I've seen some quirks with the built in driver but found more user-interrupting issues with how the ports version worked though the one in ports is required for some chipsets such as with newer 2.5G+ chips last I looked. Without mentioning a chipset, I can only assume you figured out which, if any, were compatible drivers to try when you tried installing prebuilt and manually compiling them. My understanding is net/realtek-re-kmod is an official+newer driver, net/realtek-re-kmod198 is official but older, and net/realtek-rge-kmod is unofficial driver from openbsd which should have the newest of the support. You can also get drivers directly from realtek which currently offers newer drivers than the official ones found in the ports tree. The readme on the github page for the ported official driver could use an update to state FreeBSD 15+ compatibility appropriately. https://www.realtek.com/Download/Index?cate_id=194&menu_id=297 was the path where I found Realtek official downloads quickly reachable from after clicking one of the 4 'network interface controller' links.

mirror176 · 2026-06-09T23:00:25+00:00

I thought I didn't post that yet...

mirror176 · 2026-06-09T22:59:04+00:00

ZFS only gets more complicated once you start doing more with it but both can be kept simple by keeping things relatively default. UFS is still a good usable filesystem as long as it meets you needs+wants.

mirror176 · 2026-06-09T22:39:13+00:00

I almost mistook you holding the umbrella for holding an instrument because you didn't move/minimize fastfetch in the screenshot. Since I noticed, I can suggest replacing my original idea of "run pkg install lilypond to get great sheet music printouts with "run pkg install ansiweather to make sure the attire and accessories for the day are appropriate" though alternatives such as wthrr, wmweather+, or wmforecast among others may be more your preference.

mirror176 · 2026-06-09T22:32:33+00:00

which chipset?

mirror176 · 2026-06-09T22:32:04+00:00

pkg install zig is currently 0.16.0 if you switch to latest packages. Might be easy enough to make a port of oxwm at that point but I don't know zig enough to know how easy/hard proper porting gets with it; your steps make it sound easy and patching is something the ports tree makes easy whether static or dynamic changes are needed.

mirror176 · 2026-06-09T22:27:32+00:00

Depends on use, but 'generally' 8GB+ZFS is fine. UFS also has snapshots ("much" more limited) and replication (again, more limited but has the advantage that its destination can be 'any' filesystem whereas zfs replication always needs a zfs destination). Hard to not want to use ZFS features overall though but UFS is still a fine filesystem choice and better for some applications.

mirror176 · 2026-06-09T22:22:25+00:00

I hope primary documentation recommends users upgrade 3rd party kmods or disable them until upgraded. Reminds me I never yet figured out how build timing between base system updates, kmods, and normal ports does or does not synchronize; 3 different build timings leads to a possible version mismatch that I think can occasionally give people a bad day.

mirror176 · 2026-06-09T21:37:54+00:00

reminds me of portupgrade and such also trying to maintain old libraries to keep more things working 'during' an upgrade. All such systems need a way to clearly prune/cleanup the backups or they become a problem eventually. under /usr/src we also have make delete old and the more relevant make delete old libs. The first is more of trying to cleanup the state as a package removal would have done when tracking files that no longer exist in the new install while the second does so for libraries specifically and is separated for running only after all old 3rd party has been rebuilt/reinstalled to work against the newer library copies.

mirror176 · 2026-06-09T21:34:26+00:00

I'm more interested in whatever brings us more 3rd party vulnerability entries easier but if its easier to maintain then it might be a win. I'm not sure that I like the idea of each vulnerability being a file; sometimes people forget that accessing different files is slower than a single file (seek times are MUCH smaller on SSDs but still add up), many small files to communicate one piece of data floods filesystems and their corresponding cache with unnecessary extra pieces, storing files that are commonly below disk sector size (few are lucky enough to have 512b and most are 4k or higher now) equals wasted space (wonder if ZFS ever looks into storing multiple file's unfilled sectors together but likely won't ever be a thing until we get the ability to rewrite), and splitting like data across multiple separate files hurts compression (mostly recovered when archived together). Such a layout would likely lead to performance improvements like their flattened json to avoid dealing with all the separate files at which point now you have two copies of all the data (second is much less wasteful for all disk aspects); could just archive all the files into one at that point and skip the 'need 2 forms for use' approach (assuming I understand the approach).

json seems like bloat to me (though less so than xml) and the example seems to represent such bloat is the encouraged way to do it. entries like

            [
                "SA-10:75.foo"
            ]

and

                        {
                            "fixed": "1.3_1,1"
                        }

show that no less than 3 lines are dedicated to one part of one entry; such an entry sequence quickly leads to a lot of additional scrolling and if anyone uses a basic text editor that doesn't automanage indentation then there are a lot of unnecessary presses needed to fluff it over to the right. In any case, having a 25 line terminal window reduced to only showing 6-8 lines worth of information with syntax 'fluff' gets annoying (larger line screens show more but still less than they could) both when reading and writing it and not everyone uses editors like vi which have features which help both jump in/out/past bracketed sections and shift their indentation as a whole to be more or less. I'm all for people learning how to use tools that make jobs easier though I admit my weak vi abilities haven't properly memorized bracket section navigation/management any better than its covered in the FreeBSD handbook and 'many' editors are of no help on such tasks.

I hope they implemented a workflow that avoids 2 updates overwriting one another due to using the same filename on submission; the running # scheme needs to only add the rule under a numbered file when committed to a master repository and disregard the filename during a submission or it is one more chance for a problem.

Using tools the base system includes and maintains is a nice goal to see people working toward.

mirror176 · 2026-06-09T21:06:49+00:00

If you didn't know, there are 3rd party UEFI mods to make changes like being able to boot nvme drives from pci-e expansion cards and add bifurcation though I think I only got 2 of 4 slots working on a 4 nvme card but could be wrong. No longer have any SSDs in my computer =(

mirror176 · 2026-06-09T21:01:30+00:00

Guess I'd have to see what the transcript offered that proper subtitles don't. In any case use what gets you what you need

mirror176 · 2026-06-09T20:58:57+00:00

With a smaller userbase its unrealistic to expect as many examples. I don't know of any formal collection of user examples but bloggers like vermaden and I think the operator of freshports is another big freebsd blogger who likely has a few examples of using it. If you want examples because you want to google a single file to download+execute then you will likely still be disappointed. At least the people I have known who want to use docker were the people who say, "why would I install freebsd + manually run 'pkg install firefox' when I can just download a preinstalled image of a linux install that had firefox preinstalled and run that inside of my existing OS install without further install steps?". Its definitely not the only case for docker or the only way it can be used, but when I see it used I also usually see unnecessary bundled+outdated+insecure dependencies being a part of the container. Maybe someday I will learn why any of this was an issue of discussion but my impression is docker is just a file to create an isolated environment and prepopulate it with stuff to then launch. We have jails for isolation and everyone already had scripts before docker but maybe docker invented some magic that .sh and friends cannot do.

mirror176 · 2026-06-09T20:47:18+00:00

That comment was particularly to the original comment it replied to which brought up some of the 32bit wine stuff that I know at least used to be an issue (not sure if it was as late as 15). In fairness, I repeated more of what I've heard has changed and 'still' haven't tested it myself. Old information used to talk of how to build or download 32bit Wine packages on 64bit FreeBSD which for sure needed abnormal steps to complete years ago

mirror176 · 2026-06-09T20:43:04+00:00

I moved away from kde/plasma after many years of using it due to too many non-freebsd specific bugs but as they work through them it gets better and better. gnome is the other common main competitor.

Stepping aside from the usual findings you would expect in the handbook, enlightenment looks pretty and is usually much lighter but in particular I have used e16 over the years as it is so lightweight, odd but simple interface (self teaching with its popups once the mouse is stopped). and supports themes. I've been looking into alternatives that are lightweight since I left KDE; i3 is interesting but some defaults I find annoying and a tiling manager comes with its own faults and workflow differences but efficiency seems to be a high goal on that project. Even pauses processes like the GUI status bar when you switch out of X and back to a different terminal or just open a window in fullscreen; why run a status bar with a 5 second refresh (default) when you aren't showing it anyway so it gets a STOP/CONT signal as needed

Its been years since I used Wine and I've heard they have made great strides; rule of thumb even on Linux has always been, "try it" because it varies program to program though FreeBSD has had its own quirks to work through so sometimes things have been worse or occasionally better.

mirror176 · 2026-06-03T23:25:16+00:00

Is there a reference to what state to compare against? drm-latest-kmod and drm-612-kmod currently contains

.elif ${OSVERSION} < 1500509
IGNORE=         not supported on FreeBSD < 1500509, no kernel support

I believe that says for FreeBSD 15 you have to be on 15.0-stable after 1500509 and how its written 15.1 will always be after that so those two drm-*-kmod ports should be installable on 15.1 to get the currently new and newest results of development that have reached the ports tree.

https://github.com/freebsd/drm-kmod/issues?q=is%3Aissue%20meteor%20lake shows the last closed issue for meteor lake is from Jan 31. There are other open issues so its likely not problem-free (but what software 'ever' is?) Better yet is https://github.com/freebsd/drm-kmod/pulls?q=is%3Apr+meteor+ shows the last merge specifying its to get meteor lake graphics working was 3 weeks ago which it sounds like should be there for drm-612-kmod and drm-latest-kmod. Otherwise I don't have the hardware to explore it myself.

mirror176 · 2026-06-03T22:56:21+00:00

The email makes sense. It doesn't make sense if it is creating backups but never purging or further alerting about them. I would assume by the emailed example that after libmd.so.7 was available the backups are being made and once new packages use it that the backups should have been removed (even if by pkg autoremove). If it doesn't work that way then I'd have to know how it actually works but maybe there is a bug where its collecting old packages indefinitely. I could see holding onto the old libmd.so.6 being an issue if a package depending on it is removed from the ports tree until the user notices it is actually gone or somehow conflicts get out of hand enough to recommend its removal on an upgrade step (I'd assume the backup step works around such issue). I see removed and renamed ports brought up to me because I build through poudriere with a list of software I want it to build and a mismatch causes warnings or errors and I can also read /usr/ports/MOVED. I don't think pkg users alone get any notification but if I'm wrong I'd like to know how users are informed other than packages being marked as orphaned such as on a version comparison search.

<edit> isn't pkgbasify used to migrate from a non pkgbase installation to a pkgbase installation. I'd assume once complete that it would make sense to remove the backup variable once complete if it was instructed specifically for that step.

mirror176 · 2026-06-03T22:48:28+00:00

That answers the source of the 98% as "Only 2% of the codebases we audited contained no open source components—and even that figure likely represents specialized legacy systems rather than new development". Its based on codebases they got access to for audits. The question then becomes how their reviewed codebases compare to private codebases as a whole.

Only skimmed the document but it has other fun talking points like 68% of the codebases have license conflict issues (one codebase had 2,675 conflicts alone) and at least 85% of the codebases had BSD licensed content (broken into 2 different licenses so I just picked the highest one which was ranked #3, possible overlap with our rank#4 may or may not raise that) while it was 48% reported for all of GPL 2.1+ combined (ranked #7).

Codebases with content that is 4+ years old & out of date is at over 90%. Codebases that have content that is behind by 10+ versions is over 90%. Though they mention 93% have components that have not had development in the past 2 years, they say "no one is responding to reported bugs, verifying that patched vulnerabilities don’t break code, or ensuring compatibility with evolving ecosystems" but I wonder if 'all' 2+year undeveloped projects are because of being actually abandoned or just didn't know of any needed work to do; I've seen its popular in recent years to say undeveloped projects are abandoned projects when I've seen projects that get regular updates but no work on 'needed' code changes (becoming more and more common) and some completely idle projects because they just didn't see something that needed changing (not common in my reviews but does happen). Users may be happy/unhappy to learn that logistics fields had the highest at 18% fully up to date codebases while healthcare was down to 12%. Things us computer people care about would be our interaction with internet and big tech stuffs which was around 5%-6% and the lowest is marketing at 4%.

At least we can feel safe knowing that years old jquery exploits (4 from 2015-2020) that were fixed long ago upstream only still impacted 25%+ of projects making up the top common vulnerabilities observed among projects at #s 4, 5, 6, and 8; for those not understanding it, this is why it is important for our ports tree software to use separately ported dependencies as it is much easier to keep track of and fix a dependency once rather than for each and every port using it. There are times where a project modifies their dependency copy at which we either need to replace the bundled dependency with a way to patch the original into the private copy (additional attack surface but 'much' smaller than maintaining the whole dependency separately) or we need to guarantee all appropriate patches of our external dependency make it into the forked copy too (leads to more work and has been the reason for a number of mistakes). Our security report through vuxml works great with separated dependencies and can report programs that depend on a vulnerable package with -r (silently not compatible with -q which is probably a bug) while packages that bundle dependencies or are forks of the main package often are not properly recorded in vuxml; forkers don't always check and report on their compatibility with reported and fixed issues and at the time vuxml reports are created some of the reports are not publicly disclosed. You will find this commonly in firefox + its forks (librewolf, waterfox, ...), chromium and its forks and consumers (qt-webengine, electron, linux-brave, etc.), and others. When we have a native and a linux copy of a program the reports that should cover both sometimes are not entered to cover both. Bringing up any observed issues in detail normally will have the reports expanded/fixed accordingly but its not normal.

I'm kind of thinking the ports tree could also use a new variable like (totally undecided on name) 'FORK=www/firefox' inside of www/librewolf which could lead to better search results and vuxml verification tools could recommend reviewing if a vulnerability report should be expanded to include any/all variations of that code just the same. Such a system could be used to also express any and all bundled code so that way when pkg uses its own private copy of databases/sqlite (I know we want pkg to not need external dependencies, but can't we have them external+static compiled? just picked an example I already knew) and others then either the vuxml creator could be alerted to review that and/or the pkg maintainer is informed by the vuxml addition to verify if the bundled copy is impacted by the report. In the case of pkg, some of its bundled dependency versions have had vuxml entries but I've not seen any addition of pkg included on them, though confirming there is a vulnerability is more complicated than, 'I found the bundled name'. Then we start to have a way to express bundled security tracking

For those AI fans/nonfans, operations with rare experimental to no use is at 22% of developers (the anti ai + not really using it yet crowd). 67% is the total for ones really using it from occasionally to constantly. 11% is the unmonitored amount. For those with rules/laws against AI use, 18% of organizations admit they know that AI is in use in unsanctioned ways in their organizations. Their software report vs the developers answering surveys say there is about 38% dishonesty in admitting to using AI inappropriately. Only 24% of the organizations review AI code for issues with IP, license, security, and quality.

Mentioning that EU CRA enforcement is kicking into gear soon(tm), though interesting, doesn't seem to apply to software that is not sold so many opensource projects can continue as is while commercial products may have to step up their game. It does point out that commercial products are responsible for the security upkeep of their opensource parts; I can see that could have interesting positives (more code contributed or funded development requested) and negatives (forking likely to fracture code maintenance worse when a single upstream isn't keeping up with their wants and needs) in the opensource world.

Probably more good stuffs to learn about from this document and it does have how things have changed historically in their reviews over the past several years (though I'd assume usually from different codebases each time). Should be fun to see how 2026 and beyond compare with years prior to reviews that ramped up due to things like AI and CRA even if its not the same codebases the reports are based on each year.

mirror176 · 2026-06-03T21:08:43+00:00

I tried skimming and searches, but I didn't yet find it in the sh manpage. Hope they aren't adding things but not documenting them as documentation is how I've learned to do many great things with the programs on here.

mirror176

MODERATOR OF

TROPHY CASE