Pling download error

Here the same. Also I cannot access the lists via wget on console. Same message: certificate has expired.
EDIT: And the reason is an outdated ca-certificate… I have found no possibility to update the ca-certificates by console…
@fu-sen: you can access console by pressing ALT-F2 . Login is root/raspberry.

I need to look into this.
Please bear with me and I will try to release a new fixed version as soon as I can.

@fu-sen: you can access console by pressing ALT-F2 . Login is root/raspberry.

Thank you for that information. Now that I’ve got root, I’m looking for a workaround.

I suspect that there’ll be no «workaround» as PINN is a «static» (minimal) system and doesn’t support package updates. I think the only fix will be for @procount to build and release a new version of PINN?

@lurch — yes I think you are right, but I will put a temporary workaround in place for the short term.

The only permanent workaround is to wait for the PINN to update, but if you have a console with root privileges, you should be able to get a root certificate and work temporarily.

That is absolutely correct. I by myself jumped to a «direct-Arch-installation-procedure» without any helpers like PINN. But of course I wait for PINN update because of many newcomers do not have the skills to fix things on console

So how are we able to fix this? I tried mounting the filesystem and searching around to find DST_Root to comment out but the 3 paritions for PINN aren’t familiar to me and don’t match what I expected. I need a little more help here on specifically how to remove or disable DST_Root — keeping in mind the filesystem claims it’s read-only once booted. Was really hoping to get this card set up by tomorrow and will end up doing the process manually if there’s nothing that can be done with PINN except wait for someone to fix it

We have to wait until the package is recompiled. The file has to be removed before compiling.

I have tried updating the ca-certificate package and manually removing the DST-ROOT certificate, but no difference.
I have still to find the new certificate and check it is included in ca-certificate and add it if it does not exist.

Other instructions from Let’s Encrypt suggest that openssl needs upgrading from 1.02 to 1.1.0 or later. I have tried doing this, but the openssl package in buildroot changes significantly between these 2 versions, so it may mean a complete upgrade of buildroot (which is non-trivial).

Initially I thought this only affected the gentoo64 installations from Sakaki, so I was going to move them to my sourceforge repository for a quick fix, but then I realised it affects all of that as well.

The only workaround you can do yourself for the moment is to manually download an OS folder from sourceforge using an alternative browser and store it on a local USB stick in a /os folder for local installation (see https://github.com/procount/pinn/blob/master/README_PINN.md#local-images-on-usb-stick for details).

Have you tried to replace the X3 certificate by this certificate: https://crt.sh/?id=9314791 ? Of course you have to use the .crt format …

On an old browser I had to include Let’s Encrypt R3 intermediate cert, as just adding new ISRG Root X1 and removing DST Root CA X3 wasn’t suffice, not sure why…

A quick-and-dirty-fix would be to ignore certifiate errors by command line parameter… This can be made configurable in settings. As NOOBS and PINN now are they are really unusable at all. So for an intermediate state I think this would be ok.

Thanks for this hint. I had already considered it, and it may be a necessary stop-gap.
Where I use wget this is quite easy to do, but in many cases I use QT’s network classes which require a bit more work. I am investigating this in the background.

Looks like I have a workable solution!
I’ll do a bit more testing and prepare a release so I can push up a new version ASAP (maybe later today or tomorrow)
Thanks to all for your suggestions.

If you want to try it out and provide feedback here, I put a copy in the archive folder.
https://sourceforge.net/projects/pinn/files/archive/pinn-362.zip/download
Please try it on a blank SD card, unless you are aware of the proper upgrade process. 😉

I think the self-upgrade will unfortunately fail (again, due to the certificate error), so I am thinking about an alternative script to automate the upgrade on this occasion.

Congrats and many thanks for your very fast rection. I can confirm it is working again.

When I have finished the upgrade script I will post it here if someone wouldn’t mind testing it.
Then I can push the full release.

Here is the upgrade script
https://sourceforge.net/projects/pinn/files/archive/upgrade362.sh/download
On a PINN v3.6 SD card (that has the certificate error), copy this script to the PINN partition.
Boot into PINN.
Either enter the recovery shell (press ctrl-alt-F2) or connect to the shell over ssh, and login with root/raspberry.
Then type the following commands:

The v3.6.2 version will be downloaded, installed and then PINN will be rebooted.

@procount I tried your instructions for the upgrade script and when I enter
./upgrade362.sh
I get the following
sh: ./upgrade362.sh: not found

Looks like the file has control characters at the end of all the lines. I’ve seen this when it’s saved on a Windows machine. vim will show them as ^M. Once I removed those I was able to run the script successfully.

I thought I would raise this to your attention.

@TheAjItator Thanks for testing. I have re-copied the script, hopefully with Linux line endings.
Could you please see if this version is better (it may take a few minutes for it to mirror)?

@procount I see that your script uses rm /tmp/pinn-362.zip — I don’t have access to a busybox shell right now, but on a regular desktop bash shell that would fail if /tmp/pinn-362.zip doesn’t exist. rm -f /tmp/pinn-362.zip would work regardless of whether the file exists or not.
(But of course the busybox rm command may well work differently!)

It errors out, but it doesn’t abort the script, fortunately.
I chose to delete it because if it already exists, the wget will create pinn-362.zip.1 etc, and I’d forgotten how to prevent it.
But thanks for checking my script. It’s lacking a bit of robust error handling, but it should be good enough.

This comment was increasing at midnight in Japan.
I forgot this report: Initially I just got the Japanese version of the Raspberry Pi 400 and was preparing the environment with PINN.
I installed PINN and scripts on the SD card with RPi400 and tried it.

It’s working! My RPi400 and PINN got the expected behavior.

Thanks for testing. I think Raspberry Pi OS would install anyway, but I guess the rest of the errors you previously reported have gone anyway now.

Hopefully we won’t get evil hax0rs trying to spoof the JSON files used by PINN 🤣

Yes, this is just a temporary workaround to get PINN working again.
The openssl/certificate issue still needs resolving properly.
All contributions are gratefully received

Исследователи безопасности сообщили о неисправленной критической уязвимости в магазинах приложений FOSS (Free and Open-Source Software – свободное программное обеспечение с открытым исходным кодом) на базе Pling для Linux. Уязвимость позволяет злоумышленникам удаленно выполнить код и потенциально может использоваться для атак на цепочку поставок.

«Магазины приложений для Linux на базе платформы Pling уязвимы к червеобразному межсайтовому скриптингу и потенциально могут использоваться в атаках на цепочку поставок. Родное приложение PlingStore уязвимо к удаленному выполнению кода, которое можно осуществить с любого сайта, пока приложение запущено», — пояснил
соучредитель ИБ-компании Positive Security Фабиан Браунляйн (Fabian Bräunlein).

Уязвимость затрагивает следующие магазины приложений:

• appimagehub.com;

• store.kde.org;

• gnome-look.org;

• xfce-look.org;

• pling.com.

PlingStore позволяет пользователям находить и устанавливать ПО, темы, иконки и расширения для Linux, которые нельзя загрузить через центр ПО дистрибутива.

Уязвимость связана с тем, как страница со списком товаров магазина анализирует поля HTML или встроенного мультимедиа, что потенциально позволяет злоумышленнику внедрить вредоносный код JavaScript, который может привести к выполнению произвольного кода.