Update requests for packages imported from Arch Linux

All Rust versions containing Cargo before 1.66.1 are vulnerable.

rust 1:1.66.1-1 is currently in the unstable branch.

I do not think keeping such a critical security issue at testing is a good idea.

You read this part, right?

If you can’t upgrade to Rust 1.66.1 yet, we recommend configuring Cargo to use the git CLI instead of its built-in git support. That way, all git network operations will be performed by the git CLI, which is not affected by this vulnerability. You can do so by adding this snippet to your Cargo configuration file:

git-fetch-with-cli = true
1 Like

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.


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.


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.

1 Like

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. :man_shrugging:

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 - :zero:

yt-dlp version 2024.03.10-1 is available on Unstable and Testing branches
packages.manjaro.org - yt-dlp

1 Like

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?

1 Like

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:

1 Like

A post was split to a new topic: Glibc is a bit flaky when using chrootbuild

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=--help followed 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 --help command, 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

1 Like

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.

1 Like