Not all manjaro PKGBUILD are published?

Sorry for the yellow title, but this should attract more people into the discussion.

Issue:

$ pacman -Si plasma-angelfish
Repository      : community
Name            : plasma-angelfish
Version         : 1.3.0+14+g0026956-1
Packager        : Philip Müller <philm@manjaro.org>

No groups or projects matched your search Packages · GitLab

OR

https://software.manjaro.org/package/plasma-integration
Build Date: Wednesday June 22 13:55
Packager: Philip Müller , Manjaro
Package Source -> https://gitlab.manjaro.org/packages?filter=plasma-integration

$ pacman -Si plasma-integration
Repository      : extra
Name            : plasma-integration
Version         : 5.24.5-2
Packager        : Philip Müller <philm@manjaro.org>

plasma-integration is manjaro build, not from Arch, but PKGBUILD only for kde-unstable and not for extra/kde

These are not two cases, there are much more of them. These packages are just examples.

Topics for discussion:

  • Is the manjaro PKGBUILD closed source code and not published?
  • For all popular distributions, the source code of the packages/build scripts is open and available for study. Are they wrong and shouldn’t do that? How to rebuild a package with a .patch if PKGBUILD is not available?
  • There is no way to know exactly how the packages was built. Today it is angelfish, tomorrow it is a fbi-manjaro-backdoor under the old name and impossible to check/control it. How to detect when a package has been infected? Isn’t this a huge security hole?

I’m just guessing, but I suppose you just didn’t find them, not that they don’t exist.

Of course it should exist, but it is not in the official repository → “No groups or projects matched your search”. The source code for proprietary software also exists and is unlikely to be found in the public. Is manjaro proprietary?

Similar:

Manjaro consists of packages from multiple sources.
Mainly:

  • Arch Linux
  • Manjaro

Most packages are inherited from Arch Linux, so you would look at the Arch Linux PKGBUILD for it.

Another reason why some of the PKGBUILD’s might not be found, could be that the maintainer/builder, didn’t add the PKGBUILD to gitlab. Could simply have been forgotten, or could have been a very small change to an official Arch Linux PKGBUILD.

A good way to get more knowledge, is to contact the maintainer/builder to get his/her answer on the reason why it can’t be found.

Manjaro itself is not proprietary, even though Manjaro does have some nonfree software in the repository and in some cases installed.

Although Manjaro is Arch-based and Arch compatible, it is not Arch. Manjaro:A Different Kind of Beast - Manjaro

It is safe to update a package from Arch repos? It is safe to update a package from Arch repos?

You’re risking a partial upgrade, which can range from minor issues to ruining your system.

The packages that are provided as examples are built by Manjaro developers not imported from Arch Linux. This is why need PKGBUILD from Manjaro, not from Arch Linux. For inherited packages there is a alt. meta-Packager, for these packages there is none.

This is not the first time, so the forgetfulness is incredible, there are much more such packages than two or three.

It turns out that there are still some changes, but you can’t check/control or read about them? Binary blobs with unknown content that you can only guess about, this is some kind of madness.

For all built by Manjaro developers packages where no PKGBUILD, it’s joke?

Then I don’t understand why not all PKGBUILD’s source codes are opened and published, may contain changes that break some licenses.

I understand your frustration. I keep all my PKGBUILD’s up on gitlab.

You should contact the builder/maintainer to get them to solve this issue.

Making a general assumption, that all Manjaro developers do this on purpose, is simply wrong.

My goal is to explain the problem in as much detail as possible and attract attention to it so that it is fixed as soon as possible. All built by Manjaro developers packages should publish PKGBUILD.

I’m worried about security issues and possible violation of some licenses. As well as the impossibility of check/control by the user side, it refers to security issues. I didn’t mean to fault or abuse anyone, but I’m really shocked that miss source code is the okay in Manjaro.

Maybe I do not understand the problem - it’s likely :wink:
Or maybe search terms where not correct.
For the two examples I looked at manjaro branch compare,

https://packages.manjaro.org

located the packages, looked at the info and was lead to the here linked gitlab pages.
There is a PKGBUILD for each of them.

Packages / kde-unstable / plamo-gear / angelfish · GitLab

Packages / kde-unstable / plasma / plasma-integration · GitLab

These are different packages: plasma-angelfish ≠ angelfish

$ pacman -Si plasma-angelfish
Repository      : community
Name            : plasma-angelfish
Version         : 1.3.0+14+g0026956-1
Packager        : Philip Müller <philm@manjaro.org>

$ pacman -Si angelfish
Repository      : community
Name            : angelfish
Version         : 21.05-1
Packager        : Bernhard Landauer <oberon@manjaro.org>
# and this version "21.05" doesn't exist at all https://gitlab.manjaro.org/packages/kde-unstable/plamo-gear/angelfish/-/commits/master/

Versions do not match:

$ pacman -Si plasma-integration
Repository      : extra
Name            : plasma-integration
Version         : 5.24.5-2
Packager        : Philip Müller <philm@manjaro.org>

https://gitlab.manjaro.org/packages/kde-unstable/plasma/plasma-integration/-/blob/d9ef0e328d6cc72ba6a1d6ad0f5ab6f11ae2f100/PKGBUILD#L32
pkgver=5.24.5.r562.g43922b5
# and pkgrel=1 when should be 2

then

https://packages.manjaro.org

links to the wrong things when looking for those names and then pulling up the linked PKGBUILD
… which I can’t assess but don’t think is so

:man_shrugging:

Another reason you may not be able to find it - is due to split packages - a package name is not necessarily identical to the PKGBUILD creating the package.

Topic unlisted because what you are implying is not true.

Because not all packages are built using a buildserver but is built and tested locally - I cannot count the number of times I forgot to update the pkgrel or forgot to create a PKGBUILD for package I pushed to a branch.

The Manjaro team are only human and what you are implying is irrational and I can only see this as an attempt to add items to the FUD machine.

Here are some plasma overlays: Packages / temp / kde-stable · GitLab

If this is not true, then it is very strange that instead of explaining why this is not true, the topic was hidden from prying eyes. I hope you are not trying to hide the issue in this way.

Unfortunately, this only confirms the security issues, and the lack of build scripts only increases it, since it is impossible to control or verify this. It is enough to push the infected binary blob and say that you forgot to create a PKGBUILD. This does not mean that this is already happening, but the lack of build scripts contributes to this, just as you should not rule out the usual inattention and you confirm that “I cannot count the number of times I forgot”.

I can’t call the ability to see build scripts an irrational desire. From your words, it turns out that big projects that are working on the Reproducible builds are fools. In Arch Linux, I can check this, for example by looking at the meta information “pkgbuild_sha256sum” or comparing the contents of the packages.

Thanks, searching for that didn’t really show up, there’s still no plasma-angelfis, angelfish there anyway. The packages above were given to indicate that there is a general issue.

There is no problem with the desire to know the PKGBUILD but You keep implying malicious intent - almost insisting that malicios intent exist - and that is why the topic is unlisted.

I don’t question the relevance of keeping the pkgbuilds update and matching the packages in the repo.

I am questioning your motive on this matter as you are not appearing like you are trying to elevate the quality more like seeking a confrontation - pointing out what you consider malicios intent - to my knowledge - there is no member of the Manjaro team which has malicious intents - as I am burning for the opensource concepts - so are the rest of the team - but we are only humans - working on this in spare time - there is no huge corporation behind - there is no huge quality assurance department - so please keep you accucations down - okay?


Edit

A package is essentially a compressed package containing the files which are needed for the functionality provided and may contain one or more dependency references.

If You are curios or even suspicious You can unpack such package or navigate it using e.g. Midnight Commander - and you will be able to see exactly what files are provided with the package and if necessary you can unpack it and examine the files up close.

You should also bear in mind that all packages are gpg signed and all those signatures are kept beside the package and is included within the repo database file - and tampering with the signatures is next to impossible - as this would require the signing key to be stolen - and should such thing happen - the signature would be revoked and all packages force rebuilt to eliminate abuse at repo level.

I can’t edit your official commentary, everyone can read it before the discussion.

It would be strange to get a different reaction when, instead of constructive answers, the topic is hidden and now, instead of constructive discussion, there is a clarification of how I wrote about it, using apparently prohibited words or something else. Anyway, sorry if I mislead someone, you are free to edit my messages so that they better show the essence of the issue “Not all manjaro PKGBUILD are published?”. English is not my native language(asian), perhaps I did incorrectly described the essence of the issue in some messages. I have never claimed that “malicious intent exist”, the first line of my message said “Sorry for the yellow title, but this should attract more people into the discussion.” and “This does not mean that this is already happening, but the lack of build scripts contributes to this”, you can place a BIG RED WARNING in the first message that at the time “malicious intent NOT exist, this is only a very small impossible theory”.

Me too. But opensource does not means blind faith and this does not mean that you are not trusted. It is precisely for these cases that there are tools that can check trust using mathematics, technology and so on. And opensource concepts requires an “open code not free, but open”, in my opinion it should be decided on your “Manjaro Team” side, or not?

I think the lack of build scripts is various security issues, this can violate licenses, this creates issues to the users. After a message about the issue, I expected to see a discussion of whether it is a issue or not. Search for a solution if this is a issue. And as a result, fix or closing the topic as canceled. Isn’t that working like that?


NEW (I was busy. Thanks, this is more like a discussion now.)

With the PKGBUILD present, I can rebuild the package and compare the files at the binary level, additionally I can verify that the PKGBUILD hash matches pkgbuild_sha256sum. Your proposal does not provide such cases.

The signature in this case solves another issues, for examples, when the network in not trust or verify the identity of the packager.

It would be nice to add these rules to the registration page, now there “By registering, you agree to the privacy policy and terms of service.” and FAQ from tos.

If I understood your short answer correctly, then I won’t take up your time anymore. But could you answer specific questions. This is important to me as I use Manjaro and want to know what it contains.

  • Has the issue of missing PKGBUILD’s files been accepted by Manjaro Team or rejected? - accepted|rejected
  • If the issue is accepted, will all PKGBUILD’s files be published and published in the future? - yes|no|maybe
  • If the issue is accepted, where can I follow the “status” of the issue? - url

Thanks in advance for your replies and Manjaro Team work, I’m sorry the discussion ended with this.