Update Arch Linux installation

[francoism90]

The package for Arch Linux has been updated and seems to work fine. The git version is in AUR and indeed seems to be missing some essential stuff.

[romkatv]

This package had been broken for longer than it has been working. The owner of the package twice knowingly released new versions that didn't work and were regressions. I'm not comfortable recommending this package at this point. This may change in the future.

[romkatv]

For the reference, the community package has once again been broken. See https://bugs.archlinux.org/task/67212. A new package version has been pushed without testing and it had two bugs. One bug has been pointed out to the package owner a long time ago but he'd ignored it. Another bug was caused by disregarding by the owner of his own instructions for updating the package.

[francoism90]

@romkatv Sorry, I don't know enough of the package details to have an opinion about that one. I'm a bit confused why gitstatus has been included in the source, but like said before, this didn't work in the -git package either.

[romkatv]

@romkatv Sorry, I don't know enough of the package details to have an opinion about that one.

It's quite simple. I took ownership of zsh-theme-powerlevel10k-git and maintain it in good working state. The official powerlevel10k documentation lists it as a supported installation method.

zsh-theme-powerlevel10k is not owned by me and I have no control over it. This package has a history of being broken often. The owner of the package doesn't use powerlevel10k himself and pushes new versions with no testing whatsoever.

I'm a bit confused why gitstatus has been included in the source

gitstatus is a part of powerlevel10k that I have also made available as a separate project.

[francoism90]

@romkatv Great stuff! I didn't know you took ownership of zsh-theme-powerlevel10k-git. :)

I'll replace it with your pkg and let you know if I'm running into any troubles.

[romkatv]

I just found out that the community package is being compiled with optimizations turned off. Optimizations have been turned off on May 26 in this commit. It's unclear whether this was intended. A bug has been filed on Sep 1 (with a patch) but it hasn't received a response.

My recommendation to avoid the community package still holds. Use zsh-theme-powerlevel10k-git instead.

[shibumi]

@francoism90 Just for the record, because there are a few wrong accusations in this issue:

• We have tremendously improved the situation in the last 6 months via pushing zsh-theme-powerlevel10k to the test repository first
• The zsh-theme-powerlevel10k maintainer has been invited to participate and test the zsh-theme-powerlevel10k package via our test repositories. The same applies to all users.
• We had no issues in the last 6-8 months
• The AUR version does not satisfy our security guidelines nor packaging standards. There are various issues with the AUR version. To just call out a few:

1. The zsh-theme-powerlevel10k-git package is not reproducible and thus vulnerable to supply chain attacks.
2. The zsh-theme-powerlevel10k-git package does not satisfy our hardened binary guidelines. The gitstatusd binary is not fortified, not built with PIE nor with a stack canary.
3. The zsh-theme-powerlevel10k-git package installs lot's of trash in the /usr/share/ folder like build assets, source code and other artifacts that are necessary for building/installing.

I haven't had a look on the zsh-theme-powerlevel10k-git-bin package, but some points apply there as well. In general I would not recommend using the AUR package.
There are a few other issues that actually needs to change as well. For example the /usr/share/zsh-theme-powerlevel10k/gitstatusd/usrbin directory is far away from good practice. There should be no binaries in the /usr/share directory.

This is by the way not meant as attack. I invite the maintainer again to participate in the packaging progress. Patches are welcome, but they must follow our security standards and packaging expectations.

[romkatv]

there are a few wrong accusations in this issue:

What are the wrong accusations?

• We have tremendously improved the situation in the last 6 months via pushing zsh-theme-powerlevel10k to the test repository first

Cool!

• The zsh-theme-powerlevel10k maintainer has been invited to participate and test the zsh-theme-powerlevel10k package via our test repositories. The same applies to all users.

You are the maintainer of zsh-theme-powerlevel10k, right? I'm curious who issued the invitation to test your own package. Have you accepted the invitation?

• We had no issues in the last 6-8 months

Great! I'm really glad about that.

1. The zsh-theme-powerlevel10k-git package is not reproducible and thus vulnerable to supply chain attacks.

Can you clarify the nature of the attack?

2. The zsh-theme-powerlevel10k-git package does not satisfy our hardened binary guidelines. The gitstatusd binary is not fortified, not built with PIE nor with a stack canary.

Thanks for letting me know. This has no bearing on security though, right? gitstatusd runs as the same user with the same privileges as the login shell that controls it. The only thing that can exploit gitstatusd is the login shell itself, which is pointless.

3. The zsh-theme-powerlevel10k-git package installs lot's of trash in the /usr/share/ folder like build assets, source code and other artifacts that are necessary for building/installing.

Ouch. It's the first time someone called the source code of my project trash.

There are a few other issues that actually needs to change as well. For example the /usr/share/zsh-theme-powerlevel10k/gitstatusd/usrbin directory is far away from good practice. There should be no binaries in the /usr/share directory.

This is an internal binary that's used only by scripts in /usr/share/zsh-theme-powerlevel10k. What's wrong with storing it under the same directory? And what's the right place?

This is by the way not meant as attack.

I'm glad.

I invite the maintainer again to participate in the packaging progress. Patches are welcome, but they must follow our security standards and packaging expectations.

I also welcome patches. You are invited to send them!

[FFY00]

I just found out that the community package is being compiled with optimizations turned off. Optimizations have been turned off on May 26 in this commit. It's unclear whether this was intended. A bug has been filed on Sep 1 (with a patch) but it hasn't received a response.

That is because you decided to change the default handling of the CMAKE_BUILD_TYPE config, which I do not understand why. To me, it seems to be due to a lack of understanding of its meaning in CMake, leaving it empty is a perfectly valid option with its own behavior, you should not be manually falling back to Debug if it is not set.

https://cmake.org/cmake/help/v3.21/variable/CMAKE_BUILD_TYPE.html

https://github.com/romkatv/libgit2/blob/5860a42d19bcd226cb6eff2dcbfcbf155d570c73/CMakeLists.txt#L255-L257

Please refer to the CMake packaging guidelines to understand why setting CMAKE_BUILD_TYPE to Release is undesirable.

Can you clarify the nature of the attack?

If any of the Arch Linux packagers gets compromised, users will not be able to reproduce the package to detect if it was tampered with.

See https://reproducible-builds.org.

Ouch. It's the first time someone called the source code of my project trash.

Nobody is calling the source code of your project trash, that is a weird and IMO kind of bad-faith takeaway to take. What was pointed out was that it is not at all relevant for a binary package.

This is an internal binary that's used only by scripts in /usr/share/zsh-theme-powerlevel10k. What's wrong with storing it under the same directory? And what's the right place?

Please refer to the FHS, particularly the section about /usr/share. The correct place would be libexec, which on Arch Linux is set to /usr/lib.

---

I appreciate you putting the time to look at these issues and being willing to discuss, though it seems that you are lacking some background on Arch Linux packaging, and Linux packaging is general. Given this, I would like to ask you to consider coordinating with the package maintainer(s) instead of making recommendations directly to users without fully understanding the implications. We all are just trying to do what's best for the user here. You obviously dominate this project, and the Arch Linux maintainers dominate packaging, so please let's try to collaborate instead of fighting each other.

[romkatv]

I just found out that the community package is being compiled with optimizations turned off. Optimizations have been turned off on May 26 in this commit. It's unclear whether this was intended. A bug has been filed on Sep 1 (with a patch) but it hasn't received a response.

That is because you decided to change the default handling of the CMAKE_BUILD_TYPE config, which I do not understand why.

That's an extremely interesting remark.

zsh-theme-powerlevel10k is not owned by me. It's been compiling libgit2 -- also not owned by me -- with optimizations turned off (which incidentally also disables hardening) since May last year. A bug report with a patch has been up and ignored since September last year.

To me, it seems to be due to a lack of understanding of its meaning in CMake, leaving it empty is a perfectly valid option with its own behavior, you should not be manually falling back to Debug if it is not set.

You might want to educate someone who's actually involved in this issue, which is between the package owner and libgit2.

Can you clarify the nature of the attack?

If any of the Arch Linux packagers gets compromised, users will not be able to reproduce the package to detect if it was tampered with.

See https://reproducible-builds.org.

I read shibumi's remark that "zsh-theme-powerlevel10k-git is vulnerable to supply chain attacks" as implying that my package is vulnerable to supply chain attacks more than other packages. If that's indeed what shibumi meant, I'd be grateful for more info.

That said, your point about the value of reproducible builds as an aid in uncovering a compromise is duly noted. I took a look at why gitstatusd isn't byte-for-byte identical across builds and fixed the issue. The absolute path to the current directory is no longer embedded in the binary.

Ouch. It's the first time someone called the source code of my project trash.

Nobody is calling the source code of your project trash, that is a weird and IMO kind of bad-faith takeaway to take. What was pointed out was that it is not at all relevant for a binary package.

You won't convince me that I cannot read a simple statement. Calling the source code of my project trash wasn't the core of the sentence but it was nevertheless a part of it. Your bad-faith accusation as a follow up to an insult is out of line.

This is an internal binary that's used only by scripts in /usr/share/zsh-theme-powerlevel10k. What's wrong with storing it under the same directory? And what's the right place?

Please refer to the FHS, particularly the section about /usr/share. The correct place would be libexec, which on Arch Linux is set to /usr/lib.

Thanks for the links. For my education, does Archlinux support multiple architectures on the same OS with a centrally mounted /usr/share?

Note that both zsh-theme-powerlevel10k-git (my package) and zsh-theme-powerlevel10k (not mine) store gitstatusd at the same location, so this discussion has no implications on which package is preferable for the users to install.

Given this, I would like to ask you to consider coordinating with the package maintainer(s) instead of making recommendations directly to users without fully understanding the implications.

My reasons for recommending against zsh-theme-powerlevel10k are given in this thread. They still hold. I welcome improvements to this package and will change my recommendation when its quality becomes satisfactory.

[shibumi]

You won't convince me that I cannot read a simple statement. Calling the source code of my project trash wasn't the core of the sentence but it was nevertheless a part of it. Your bad-faith accusation as a follow up to an insult is out of line.

It was not my intention to call your source code 'trash' and I am sorry for that misunderstanding. What I referred to as 'trash' is everything unrelated to provide the package's intended functionality. Assets blow up space. Just imagine every software maintainer would include their git repository with all build assets.. users would be annoyed by manually cleaning everything after each package update/installation.
Furthermore, it is another violation of FHS. If you want to ship documentation do it in a dedicated directory that is clearly marked as documentation. Nobody needs files like .gitattributes or object styles or C source code in their /usr/share directory tree.

I read shibumi's remark that "zsh-theme-powerlevel10k-git is vulnerable to supply chain attacks" as implying that my package is vulnerable to supply chain attacks more than other packages. If that's indeed what shibumi meant, I'd be grateful for more info.

This is correct. Reproducible-builds and binary transparency can cover supply-chain attacks. @FFY00 has provided already a good link for reproducible-builds: https://reproducible-builds.org/. Another good example is this picture here (source: https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html):

Every red mark is a possible attack vector in a supply chain. This is one of the security issues. The other one has been your build flags in the AUR package. If you compare the gitstatusd binary to the one from the official arch linux repositories you can see that we compile our binaries with PIE and other security features.

I honestly, don't get your argument that "gitstatusd runs in the users terminal". Gitstatusd still interacts with foreign data (git repositories). I don't understand how gitstatusd works exactly, but just imagine gitstatusd has a vulnerability that would allow the attacker to execute arbitrary code via a maliciously modified git remote or filename or whatever. Security features like PIE would make this by far more challenging to exploit and use against the user. It makes a huge difference if a program just crashes or if it can be used to execute code or gain intel about the victims machine.

Note that both zsh-theme-powerlevel10k-git (my package) and zsh-theme-powerlevel10k (not mine) store gitstatusd at the same location, so this discussion has no implications on which package is preferable for the users to install.

This is correct and mostly my fault, because I had no time yet to provide necessary patches for moving the gitstatusd binary to a different location. I don't maintain just one project.

zsh-theme-powerlevel10k is not owned by me. It's been compiling libgit2 -- also not owned by me -- with optimizations turned off (which incidentally also disables hardening) since May last year. A bug report with a patch has been up and ignored since September last year.

We won't sacrifice security hardenings for optimizations. Sorry. But security is on the top of our bullet list. And it is on top of your bullet list, too (at least I hope that you care about your user's security. If not that would be sad).

What are the wrong accusations?

That the package is unstable. I see that the package was unstable, but it is not anymore. We have introduced tests and other measures to provide a good experience and people are using it.

@francoism90 said that the package is missing essential stuff. I don't know what he meant by that, but the difference for me is pretty clear right now:

zsh-theme-powerlevel10k provides:

• better endpoint security via hardened binaries
• A smaller installation size due to less build assets and other unnecessary files
• Reproducible builds

The zsh-theme-powerlevel10k-git version provides on the other hand:

• a direct maintained-by-developer-experience. (This is fine. Some people want this)
• a better performance due to optimizations (while sacrificing security features)

In the end it is up to the user which one to pick. I just say it is not fair to publicly shame the package on your README.md, whileb being not unstable and even providing more security features, that your release does not. We do not do this kind of advertisement on our side. Your package is still up in the AUR and it is not modified with a big 'security risk!'-badge, right?

[FFY00]

That's an extremely interesting remark.

zsh-theme-powerlevel10k is not owned by me. It's been compiling libgit2 -- also not owned by me -- with optimizations turned off (which incidentally also disables hardening) since May last year. A bug report with a patch has been up and ignored since September last year.

You maintain your own fork of libgit2. I did not check the git blame to see if you were the one that introduced this overriding, my bad.

I have opened an issue with the libgit2 upstream (libgit2/libgit2#5934).

You won't convince me that I cannot read a simple statement. Calling the source code of my project trash wasn't the core of the sentence but it was nevertheless a part of it. Your bad-faith accusation as a follow up to an insult is out of line.

The issue is not reading the statement, but rather interpreting it. When I say I am dying to get lunch, I am not... actually dying. The metaphor here was that the AUR package installed a bunch of stuff that was completely irrelevant and could be disposed of. Nobody was saying that your source code was literally trash, nobody other than you even mentioned the source code.
You can spin this however you want, I don't really care. The point is, nobody was trying to insult you or your work. I may have not pointed this out in the best way, reading it back I understand it might come up as aggressive, but that was not my intent, so I am sorry for that.

Thanks for the links. For my education, does Archlinux support multiple architectures on the same OS with a centrally mounted /usr/share?

It is not either explicitly supported or unsupported, but I'd say it is essentially unsupported as pacman is not prepared for that.

Note that both zsh-theme-powerlevel10k-git (my package) and zsh-theme-powerlevel10k (not mine) store gitstatusd at the same location, so this discussion has no implications on which package is preferable for the users to install.

Yeah, and that should definitely be corrected.

[theconnstruct]

@romkatv I realize that I'm reading this a good three weeks after the fact, but your behavior in this entire conversation has been very "screw the community", "everyone but me is wrong", and "everything is a personal attack."

I love powerlevel10k, but if this is how you're going to act, I'll find a replacement.

[romkatv]

@jcoffm Please refrain from commenting on my (or anyone else's) behavior on this issue.

Everyone: This issue is still on my TODO list. I didn't have the time to reply to your latest comments yet but I haven't forgotten about it.

[carlocab]

Since this is on your to-do list, do you mind reopening this to signal that there are plans to address at least some of the things that have been discussed here?

I understand that it might be better to open a new issue to represent more accurately what is on your to-do list, but I imagine actually writing that down takes time too...

[romkatv]

@carlocab It cannot be reopened because the original repository no longer exists.

[carlocab]

Ah, I see. Fair enough. Thanks anyway!

[romkatv]

It was not my intention to call your source code 'trash' and I am sorry for that misunderstanding.

Apology accepted. No harm done.

imagine gitstatusd has a vulnerability that would allow the attacker to execute arbitrary code via a maliciously modified git remote or filename or whatever. Security features like PIE would make this by far more challenging to exploit and use against the user.

This is a good point.

Note that both zsh-theme-powerlevel10k-git (my package) and zsh-theme-powerlevel10k (not mine) store gitstatusd at the same location, so this discussion has no implications on which package is preferable for the users to install.

This is correct and mostly my fault, because I had no time yet to provide necessary patches for moving the gitstatusd binary to a different location. I don't maintain just one project.

I'll keep an eye on your package. When you move gitstatusd to a different location, I'll incorporate the same changes in my package.

zsh-theme-powerlevel10k is not owned by me. It's been compiling libgit2 -- also not owned by me -- with optimizations turned off (which incidentally also disables hardening) since May last year. A bug report with a patch has been up and ignored since September last year.

We won't sacrifice security hardenings for optimizations. Sorry. But security is on the top of our bullet list. And it is on top of your bullet list, too (at least I hope that you care about your user's security. If not that would be sad).

It's the other way around. When you disabled optimizations in zsh-theme-powerlevel10k, you also disabled hardening. So currently gitstatusd in your package is slower than it could be and it's also not fortified.

What are the wrong accusations?

That the package is unstable. I see that the package was unstable, but it is not anymore.

I believe all statements I've made on this issue w.r.t. zsh-theme-powerlevel10k were true at the time I made them. I haven't made any statements concerning to the future state of the package. It's the difference between "the package is unstable" vs "the package will always be unstable". I haven't made any wrong accusations as far as I can see.

We have introduced tests and other measures to provide a good experience and people are using it.

This is great.

zsh-theme-powerlevel10k provides:

• better endpoint security via hardened binaries
• A smaller installation size due to less build assets and other unnecessary files
• Reproducible builds

The zsh-theme-powerlevel10k-git version provides on the other hand:

• a direct maintained-by-developer-experience. (This is fine. Some people want this)
• a better performance due to optimizations (while sacrificing security features)

I've updated my package to use the same security features as zsh-theme-powerlevel10k (PIE, fortify, stack canary, etc.). It now also respects CFLAGS, LDFLAGS, etc., so that any security flags that Arch Linux might enable in the future will be automatically propagated.

Once you enable optimization and hardening in your package, there should be no difference between the two w.r.t. performance and security.

it is not fair to publicly shame the package on your README.md

For the sake of context, here's what README.md currently says: "There is also zsh-theme-powerlevel10k community package. Historically, it has been breaking often and for extended periods of time. Do not use it."

The package is currently being compiled with optimizations turned off. Whether this constitutes being broken or not is a matter of opinion but it's a significant issue given that the raison d'etre of gitstatusd is performance.

I can replace the sentence that starts with "Historically" if you like but I wouldn't change the final recommendation at this time. Once https://bugs.archlinux.org/task/67790 is fixed and the package is stable for a while, I'll be happy to update the recommendation.

@shibumi and @FFY00, thank you for pointing out issues with zsh-theme-powerlevel10k-git and providing additional information to help me understand them. I believe I've fixed all of them. If you notice anything else, please do reach out. The best way would be by filing an issue but any other channel of communication is also fine.