You read this part, right?
If you can’t upgrade to Rust 1.66.1 yet, we recommend configuring Cargo to use the
gitCLI instead of its built-in git support. That way, all git network operations will be performed by thegitCLI, which is not affected by this vulnerability. You can do so by adding this snippet to your Cargo configuration file:
[net]
git-fetch-with-cli = true
git version 2.39.1-1 contains critical security fixes, see:
So it should be fast-tracked.
It’s already in the testing and unstable branch. Please do not request packages that are already in the repos. This has been mentioned many, many times.
<rant>
Oh, but it’s not in the stable branch, you say. If you’re that concerned about security and bleeding edge updates then you would already be using the testing or unstable branch.
Riddle me this: What’s the point in having three branches if no one uses the other two? People complain there are issues when a stable update hits. If more people used the testing and unstable branches and provided feedback, then there would be less issues in the stable branch. For those who already do, thank you very much. You are appreciated.
Manjaro unstable is on par with Arch stable. The only reason why Manjaro’s unstable branch could possibly be “unstable” at times is the short transition between syncing Arch stable and updating Manjaro custom packages. That period is normally within hours or even minutes. At most it could be up to a day if there’s toolchain rebuilds. Remember, not every team member is in the same time zone. The testing branch will not have that issue at all and is basically a preview of the next stable update.
</rant>
Any questions or comments? They are welcome. Please speak freely just as I have done.
If so the discussion will be converted into a new topic and this post will reference it.
EDIT: A reply to this post has been removed because the author of said post does not know how to discuss a topic constructively.
Certbot needs to be updated and fix due to issues, there is a version mismatch somewhere.
It was flagged out of date yesterday. As was mentioned in your thread, it seems to be a local issue on your end. There are neither Arch bug reports, Arch forum posts nor Manjaro forum posts about it.
I manually updated Discord a little while ago while we’re waiting for Arch to rebuild a corrupt package stopping us from syncing.
The version in the Arch repos is newer than the one in our repos, so I told the OP of the linked thread above that I’d put in the update request. 
yt-dlp has released a new version that copes with the changed YouTube API. The version 2024.03.10 should be provided.
This version is already available on Arch Linux. Since my software depends on it, I’d very much appreciate an update
Update - The request was made because an AUR install will pull the wrong version. From that point of view it is irrelevant if a more recent version is in another repository. Yt-dlp can be downloaded via curl - which I had implemented intrinsically until someone requested the repository dependency …
It’s available in Manjaro unstable repository as well.
see this.
Using the AUR on Manjaro stable branch is officially supported this much - 
yt-dlp version 2024.03.10-1 is available on Unstable and Testing branches
packages.manjaro.org - yt-dlp
I tried to install Persepolis package 3.2.0-8 from main repo but noticed its dependecy youtube-dl which is on AUR only and no longer maintained. I’m on stable branch.
Checking Packages shows that unstable/testing branch got updated persepolis package 4.0.1 which must have happend sometime in early/mid march. Commits · main · Arch Linux / Packaging / Packages / persepolis · GitLab.
Persepolis 4.0.x changed dependency to yt-dlp which is on the main repo.
Is there a way to also get persepolis 4.0.1 on stable?
The easiest is to wait until 4.0.1 filters down to the lower levels. I imagine it won’t be too far away.
Failing that, I notice Persepolis-git 4.0.1 is available with a yt-dlp dependency, if that will suffice in the meantime:
Vulnerability of Flatpak, please provide a newer version than 1.15.6 in Stable
The sandbox system is said to be able to run arbitrary code if the application includes such.
You can perform a simple test to verify whether your system is affected. [Run] any Flatpak application and run it with the
--command=--helpfollowed by the application’s ID. If the system returns an error message stating that the help command is not found, your Flatpak installation is not vulnerable.
However, if it displays an output similar to that of the
bwrap --helpcommand, it means your version is still at risk.
So I did test it and selected one.ablaze.floorp from my apps listed in flatpak list
I have version
flatpak --version
Flatpak 1.15.6
And I concluded Stable is affected because this is the output of (replace “one.ablaze.floorp” with any long name of your installed apps listed under flatpak list)
flatpak run --command=--help one.ablaze.floorp ✔ at 14:02:17
usage: bwrap [OPTIONS...] [--] COMMAND [ARGS...]
--help Print this help
--version Print version
--args FD Parse NUL-separated args from FD
--unshare-all Unshare every namespace we support by default
--share-net Retain the network namespace (can only combine with --unshare-all)
--unshare-user Create new user namespace (may be automatically implied if not setuid)
--unshare-user-try Create new user namespace if possible else continue by skipping it
--unshare-ipc Create new ipc namespace
--unshare-pid Create new pid namespace
--unshare-net Create new network namespace
--unshare-uts Create new uts namespace
--unshare-cgroup Create new cgroup namespace
--unshare-cgroup-try Create new cgroup namespace if possible else continue by skipping it
--userns FD Use this user namespace (cannot combine with --unshare-user)
--userns2 FD After setup switch to this user namespace, only useful with --userns
--disable-userns Disable further use of user namespaces inside sandbox
--assert-userns-disabled Fail unless further use of user namespace inside sandbox is disabled
--pidns FD Use this pid namespace (as parent namespace if using --unshare-pid)
--uid UID Custom uid in the sandbox (requires --unshare-user or --userns)
--gid GID Custom gid in the sandbox (requires --unshare-user or --userns)
--hostname NAME Custom hostname in the sandbox (requires --unshare-uts)
--chdir DIR Change directory to DIR
--clearenv Unset all environment variables
--setenv VAR VALUE Set an environment variable
--unsetenv VAR Unset an environment variable
--lock-file DEST Take a lock on DEST while sandbox is running
--sync-fd FD Keep this fd open while sandbox is running
--bind SRC DEST Bind mount the host path SRC on DEST
--bind-try SRC DEST Equal to --bind but ignores non-existent SRC
--dev-bind SRC DEST Bind mount the host path SRC on DEST, allowing device access
--dev-bind-try SRC DEST Equal to --dev-bind but ignores non-existent SRC
--ro-bind SRC DEST Bind mount the host path SRC readonly on DEST
--ro-bind-try SRC DEST Equal to --ro-bind but ignores non-existent SRC
--remount-ro DEST Remount DEST as readonly; does not recursively remount
--exec-label LABEL Exec label for the sandbox
--file-label LABEL File label for temporary sandbox content
--proc DEST Mount new procfs on DEST
--dev DEST Mount new dev on DEST
--tmpfs DEST Mount new tmpfs on DEST
--mqueue DEST Mount new mqueue on DEST
--dir DEST Create dir at DEST
--file FD DEST Copy from FD to destination DEST
--bind-data FD DEST Copy from FD to file which is bind-mounted on DEST
--ro-bind-data FD DEST Copy from FD to file which is readonly bind-mounted on DEST
--symlink SRC DEST Create symlink at DEST with target SRC
--seccomp FD Load and use seccomp rules from FD (not repeatable)
--add-seccomp-fd FD Load and use seccomp rules from FD (repeatable)
--block-fd FD Block on FD until some data to read is available
--userns-block-fd FD Block on FD until the user namespace is ready
--info-fd FD Write information about the running container to FD
--json-status-fd FD Write container status to FD as multiple JSON documents
--new-session Create a new terminal session
--die-with-parent Kills with SIGKILL child process (COMMAND) when bwrap or bwrap's parent dies.
--as-pid-1 Do not install a reaper process with PID=1
--cap-add CAP Add cap CAP when running as privileged user
--cap-drop CAP Drop cap CAP when running as privileged user
--perms OCTAL Set permissions of next argument (--bind-data, --file, etc.)
--size BYTES Set size of next argument (only for --tmpfs)
--chmod OCTAL PATH Change permissions of PATH (must already exist)
So if possible, please provide a newer version in Stable.
From the above link:
Thankfully, the Flatpak team has promptly responded with patches to this vulnerability. Users are strongly encouraged to update their Flatpak installations to the following versions to ensure they are protected:
** [I think does not count for Manjaro Stable!]> [ For users on the stable branch, Flatpak version 1.14.6 or newer.]**
** For those on older stable branches, version 1.12.9 or 1.10.9 are the safe bets.**
** Developers using the developmental branch should update to version 1.15.8 or above.**
I think Manjaro based on Arch goes by the third option what they call developmental branch!
All the above - quoted/pics is from Flatpak Patch Addresses Major Sandbox Escape Flaw
I guess we will get the fix pretty quickly. The updated version is already in testing branch, and since stable was not updated for over a month i think it will soon be time for an update, resp. that the testing versions hit stable.
Thank you for looking it up. I didn’t know I could update to the 1.15.8 version with manjaro-downgrade command. But maybe do not follow what I just did 
Will not run any flatpak now 
Sorry, not possible to fast-track it at this time. The flatpak package has quite a view other dependencies.
We have a testing and unstable branches for a reason. If users want to help the stable branch actually live up to it’s namesake, the more users using the aforementioned other two branches will help with that. Keep in mind the Manjaro unstable branch is on par with Arch stable. Don’t let the branch name fool you. 