Dominique Dumont via Pan-users posted on Sat, 27 Dec 2025 10:17:35 +0100 as excerpted:
> On Thursday, 25 December 2025 19:38:17 Central European Standard Time > [email protected] wrote: >> Hi, all for using something that hasn't (yet) been hijacked by big tech >> but Gitlab seems unnecessarily intolerant (using Brave in impermanent >> cookie mode (Guest)). > > For what it's worth, gitlab's download page works fine with firefox, > even if I'm not logged to gitlab. > > You may also download pan source from Debian package page: > https://packages.debian.org/sid/pan > > The link to the source is on the right side of this page. > >> Currently using Pan 0.139. Which is the highest binary release that >> works on (EOL) Ubuntu 16.04 LTS? > > I don't think there's any binary package other than the one provided by > Ubuntu 16. > > You may try to compile a more recent version of Pan on Ubuntu 16. I do > not know if it's possible. You may have issue with dependencies. Note > that you're on your own. I won't spent time to help compile Pan on > obsolete environments. Replying to the OP in the context of DD's post... So... IDR which Ubuntu or pan it was tho I /think/ it was well before 2016 (year of Ubuntu 16(??)) which means it shouldn't be a direct worry, but at one point long ago pan had a saved-file-permissions issue that depending on the strictness of your viewpoint could (and was) considered a security issue.[1] Note that it was discussed on the mailing list, so anyone motivated enough to dredge the list archives could pin down the issue that way... or by checking filed bugs as below). Of course it was patched upstream and IIRC a new release with the patch made ASAP. The apropos bit here is that while we (then pan devs or users) filed security-bugs with the various distribution we knew to carry pan at the time, and /most/ either bumped their pan version or backported the appropriate patches to the version they already shipped... Unfortunately Ubuntu effectively ignored the bug and it sat apparently unfixed until it was /hopefully/ fixed at their next release, which (one would hope) shipped the new upstream version (presumably the one their Debian upstream had fixed and shipped in a more timely manner). Unless Ubuntu has changed since then, they probably shipped what they shipped with Ubuntu 16 and that's what you'll get unless you procure it from another source, no updates or fixes, period, even if there are security issues, presumably because pan isn't a core enough package for them to consider it worth the trouble even if it's leaving any actual users of the package exposed. It should be obvious I was /less/ than impressed, and Ubuntu is definitely on my "don't touch, there be dragons!", list. But someone running a 10- year-old EOL LTS version obviously has considerations much higher than security on their priority list, so... YMMV I guess. (shrug) Meanwhile, building from source but assuming you want to avoid as many dependency updates as possible, back in 2016, IIRC, pan still defaulted to gtk2, and while gtk3 might have been a build option, it was very buggy and NOT recommended, if so. I'd have to go back and look to be sure when that changed, but for sure, before Dominique Dumont took over upstream pan (from Debian pan package maintainer previously and AFAIK current), the gtk2 version was getting buggier as it bitrotted, while the gtk3 version still had serious bugs that DD made quick work of! So presuming you want to avoid building other later dependencies as well, if you're trying to build pan on a now decade-old distro, you'll want to stick to versions from the gtk2 era. The switch to gtk3 and other updated libs will be in the release announcement, so you'd presumably want to look for that and target the immediately previous release, working backward from that if it wants newer versions of stuff than you have on Ubuntu 16. Another alternative to avoid building from source in at least /some/ cases... if the deb-package world has anything like rpmfind.net (which I used to search for updated rpms from other distros back on Mandrake back before I switched to Gentoo in 2004, and which I still refer to occasionally for dependency info on stuff I don't have installed here on Gentoo tho it's /not/ rpm-based), perhaps an updated deb package from some other distro or newer Ubuntu can be found, with the same package source then used to update any library dependencies as necessary as well. Finally, @ DD wearing his Debian pan maintainer hat... Are any old gtk2- pan Debian packages still supported or at least reasonably easily available, perhaps in Debian old-stable? I've never run a deb-based distro, but if there's no rpmfind-alike resource for debs, I suppose Debian-old-stable is the likely closest-match deb-based binary-package available. If it's still gtk2-based... --- [1] More detail on the security bug: At the time pan was saving files with the execute bit set in at least some cases, so someone wishing to target pan users could post an executable (say a script with a recursive delete... explicit command deliberately omitted...) with some innocent- looking name, say README.TXT, and depending on how the user and their desktop had configured things on the convenience vs. security scale, a user clicking on the file with the assumption that it would say load in their text editor, might instead find it executing!! The pre-update workaround was to ensure the umask was set to exclude the execute bit in the enviroment used when starting pan, and for years I had a umask setting in my pan-launcher wrapper script (I'd have to check if I still do...). Of course that triggered problems if pan had to create any new directories since the execute bit does something different (enter...) for them, but it worked reasonably well as a short-term workaround on an existing installation that already had pan's normal subdirectory working tree setup, and if one remembered setting the umask when any weird errors came up, it was easy enough to manually set the execute bit on any created directories and retry whatever triggered the error, as well. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/pan-users
