By applying the button with the text “Update Native Packages (eos-update)” in the EOS Welcome launcher window I today did an upgrade of the following package:
vapoursynth
With the command “pacman -Ss vapoursynth” I then found out that the currently installed version of the vapoursynth package is 72-1.
On the following web project site I found out that the latest release of vapoursynth is 72 (“R72”), but this version is mentioned there as “BROKEN!!!”:
that the currently available version of vapoursynth is R70-2, which is lower than the above-mentioned version (R)72-1, and that this package has been flagged as out-of-date since 2025-04-16.
I cannot remove this package using the “pacman -R” option because of other packages being dependent on vapoursynth.
I am asking myself:
How the heck got the vapoursynth package onto my machine in version (R)72-1 via pacman? Pacman should have prevented me from installing the vapoursynth package in version (R)72-1, shouldn´t it have? What is this new version of vapoursynth, could it maybe be malware?
Because I do not know the answer to this question I am now asking this forum for help.
I just added the following sentence to my first post in this thread, and this is the main question I am thinking of:
What is this new version of vapoursynth, could it maybe be malware?
Or, as I wrote before: Pacman should have prevented the installation of a newer version of a package that officially is marked as out-of-date. So, how could this happen on at least my machine?
No malware, rest assured. Just an unlucky name. I have it too, it’s used by ffmpeg and mpv in my case. I also have v72-1. You can think of it as a Linux pendant for Windows’ AviSynth, it does video processing.
You can always check by doing a pacman -Qi packagename, then look under Required by: and Optional For:.
Can’t hurt to also check Conflicts With: and Replaces:.
When I use the “pacman -R” option, trying to delete a certain package, then I also get informed about packages dependencies if they exist with regard to a certain package.
PS: So why are you so sure that vapoursynth in version 72-1 is no malware?
Well, you can never be 100% sure of course. But here are my reasons:
It’s in the Arch extra repository, This is much more closely watched than the AUR, for instance.
I’ve been using it for a long time, so I trust the author, the website and the documentation quite a bit.
It’s signed and SHA-256-sum’d.
I trust the Arch packager Maxime Gauduin and his email address.
Chances that someone has meddled with the original code are minimal.
You can’t of course exclude a software author suddenly turning malicious, but that could happen everywhere and in all ecosystems. With FOSS, it’s very easy to find (say, compared to a Windows .exe), and all alarms would go off very soon.
You see “the red flag” (outdated), which normal users can set to notify Arch of an issue.
The page looks “old”. You click on View Changes in the little “Package Actions” menu at top right. This leads you to Arch’s gitlab instance and you immediately recognize…
The top entry (14 hours ago) is “upgpkg: 72-1”. You click on that.
You get a diff page showing all changes made to all files since the change before.
The .SRCINFO shows where they get the stuff from (the author’s github page, at a certain commit), the .PKGBUILD is what Pacman uses to actually build the package on your system. One should always check the .PKGBUILD if downloading from third-party repos or the AUR! Malicious packagers could put something in there.
You’re almost satisfied but would still like to check the original source code?
and go there using a browser. On GitHub, you can browse his sources to your heart’s content, call up the revisions Arch used for packaging, see changes, and everything.
HTH, it’s kind of a general “How to find out things” procedure.
The beauty of Open-Source-Software: You can “follow the chain” and check it all out yourself. Or even help to improve it, since you can look at the sources.
Oh, and I must admit when seeing this the first time (I think it was while installing mpv), I got alarmed too. It so much sounds like “vapourware”… unfortunate naming indeed.
Thank you a lot, @Moonbase59 - well, I am not able to apply all the steps you mentioned but at least the first 5 or maybe 6 steps.
By the way, the user “Maxim Gaudin” applied an unverified audit on gitlab.archlinux.org for vapoursynth in version 72-1 - I hope this is no problem with regard to software security and authenticity.
the same package has been signed by verified Arch packagers, and
Maxim has been packaging it using an “unverified” key in the months before, without objections by the others.
So yes, I still trust it.
Might be different if I had never seen that person working on that package before, or finding that he is a new member.
My own GPG keys would also not be “verified”—I don’t use them often, and I’ve never been to a “key signing party” or the like. So that can happen.
Having a key and a checksum can at least assure us that the .PKGBUILD that arrives on our computer hasn’t been tampered with.
It can be a little different with …-git packages from the AUR, these might have an unchanged .PKGBUILD but still download the latest (most current) sources from a GitHub/Gitlab repo. You’d be able to see that in the .PKGBUILD, and that’s one of the reasons why people should check their PKGBUILDs when using 3rd-party repos. And not just install anything because “the name sounded nice”.
That said, I also trust the ffmpeg and mpv developers quite a lot. If they declare vapoursynth a good and valid (maybe optional) dependency, they’d surely have tested and used it.
P.S.: I am an old fart, but Arch has ever been an on-off relationship with me. Also, I’m only human and can make mistakes. So if anyone more knowledgeable than I am finds an error or improvement in what I’ve written, don’t hesitate to correct me.
You should search a little how software management works in a Linux distribution.
Do you think anybody can contribute to maintaining an official package with no authorization ?
To determine if packages are authentic, pacman uses OpenPGP keys in a web of trust model. The current Master Signing Keys are found here. At least three of these Master Signing Keys are used to sign the Developers’ and Package Maintainers’ own keys. They are then used to sign their packages. Each user also has a unique OpenPGP key, which is generated when you configure pacman-key(8). It is this web of trust that links the user’s key to the master keys.
.
Examples of webs of trust:
.* Custom packages: Packages made and signed with a local key.
.* Unofficial packages: Packages made and signed by a developer. Then, a local key was used to sign the developer’s key.
.* Official packages: Packages made and signed by a developer. The developer’s key was signed by the Arch Linux master keys. You used your key to sign the master keys, and you trust them to vouch for developers.
Regarding Maxime Gauduin : Member since September 18, 2020
And you can see he helps maintaining many packages :
I am using Linux since 2003, so do you still think I do not know anything about maintaining official packages in Linux distributions? By the way, I myself have a GnuPG public and private key.
Well observed!