Use dpkg to handle the config files management instead of postinst about raspberrypi-sys-mods HOT 11 CLOSED

We do so in cases where the package actually owns the file. If sys-mods is purged, we can't assume that that means people no longer want to use the repo. They may have installed installed vscode directly from a deb downloads from the MS website. If we were to be strict about trying to do it 'the right way' (controversy of adding a repo aside), we shouldn't have used the same filename as MS uses in their package.

from raspberrypi-sys-mods.

I had started to write a commit to achieve exactly that: Moving the repo + key from postinst to static + conffiles. But actually the repo is only added when the raspberrypi-sys-mods package was already installed before and older than this version, not on a fresh install of the package and not on any future upgrade. So changing it now to a config file adds the chance that it is reinstalled, while currently one can simply remove the two files and will never see them again (unless sources change).

What I totally agree with is that builds should be done from the GitHub repository (or a local repo that 100% matches), at best with some delay to give a chance for review. The way it was done, I got into serious worries that someone hacked my server (because I was unable to identify the origin of the files) or our sources, after I saw I few reports from our users, or Raspberry Pi Foundation servers, after I was pointed by someone to the sys-mods package so that I could check and find the mismatch between this GitHub repo and the download server. I personally don't care about a few pings to a MS server, but I worry about a heart attack 😄.

from raspberrypi-sys-mods.

Yeah, it would certainly raise some concerns for me if I was in your shoes as well. Heads up that the package lists themselves are signed and the source is always available in the apt repo itself.

There will be another update to address some of the issues people raised, but it won't re-add the repo or the key for people who have removed it.

from raspberrypi-sys-mods.

Heads up that the package lists themselves are signed and the source is always available in the apt repo itself.

True, basically I found clarification in forum threads quickly. I just read through the other (blocked) issue, the sensitivity of 3rd party APT repositories within the open-source/Linux community is clear now 😉. Thanks for still being able to receive the constructive ideas among the posts. conffiles is another idea that definitely adds transparency but as well ties the repo more to the package than it is currently. I'm looking forward for your solution. Since we're dealing with 3rd party repositories as well, probably we can learn something from it 🙂.

from raspberrypi-sys-mods.

and the source is always available in the apt repo itself.

That's not that apt-get source raspberrypi-sys-mods Told me while I was trying to dig wtf was happening.

Hence, why : #41 (comment)

If sys-mods is purged, we can't assume that that means people no longer want to use the repo.

well, apt install did assume that user wanted it. I don't see why the same logic would not apply when it's time to apt purge the same package.... And as it been said for the installation, it's only the repository, this does not affect any binaries.

I think this is where lies the différance between apt remove and apt purge. When you purge, expect missing config files.

I think the core of the problem is that the management of this situation happens at the file level. From what we see so far, there is a race condition between people that want to inject the microsoft repository to the file and the ones that try to erase and prevent it. Where in fact, this should actually happen at the package management level since this is a package update, So users could apt-hold, ignore or rollback or what ever more civilized than using chattr +i.

Sadly due to the fact that raspberrypi-sys-mods is a god package, and it reproduces the whole chain of changes since the last update instead of just installing the current state of it's content. This is not possible.

Maybe the first step would be to create a package name add_vscode_repo.deb and separate it from raspberrypi-sys-mods so users and downstream packagers could apt-hold it, flag it as conflicting or revert it.

In lysmarine, I am not set to deal with injection. So I kinda don't have any fair and clean way to address it. I think the more transparent thing I can do is update a random unrelated package of mine to add a new recommended package named revert_and_prevent_vscode_repository_installation.deb where I will remove the repository entry and permanently prevent raspberrypi-sys-mods for writing in this file in case that my update is run before yours.

Or maybe the whole /etc/apt/source.d/ as someone has already expressed the idea of using a different file name to distinguish your adding of the repository from a manual entry.

• im using the term "injection" cuz I have seen enough destroyed wordpress to be suspicious when I see echo "payload " >> target instead of install $SOURCE $DEST

from raspberrypi-sys-mods.

And OFC make a post to explain to users what is going on and what are their options.

from raspberrypi-sys-mods.

As said, it's only added a single time, and won't be added neither any second time, nor on any subsequent upgrade, based on current postinst code. So chattr +i, setting the package on hold, adding a hosts blackhole or any other of those actions I read across the discussions and even articles/blogs around this topic, is non-sense. Simply remove the two files and you never need to bother again. I'm not sure whether it is planned to have the repo pre-installed on any Raspberry Pi OS image, but current pi-gen (according to it's current GitHub repo) doesn't do it and a fresh raspberrypi-sys-mods install won't add it, so there is no action required from your side for lysmarine when it's about new images.

For existing users/systems, on DietPi with the next update we'll check if the repo exists, and in case use a whiptail to inform and let users decide whether to keep or remove it. But this requires an interactive updater script and the repo stays until the admin manually removes it or manually calls the update, of course.

I think the more transparent thing I can do is update a random unrelated package of mine

Or add a debconf or postinst-based interactive read -p / whiptail prompt to leave the choice to your users? But DEB installs can be easily done non-interactively, which makes debconf being skipped (although it's possible to use a default choice) or read -p / whiptail would hang the install 🤔. I see the issue...

from raspberrypi-sys-mods.

Hi Michalng btw :)

The way I read it is if a user have raspberrypi-sys-mods-20200729 installed, read all the panic in the forums. Decide to not do that update, or try to remove the file before installing the package cuz he copy pasted 2 lines form a random chat and now think he is safe. Then raspberrypi-sys-mods-2022 raspberrypi-sys-mods-2023 and raspberrypi-sys-mods-2077 get released and the user finally decide to do the update.

I also think that if a user do apt remove and apt install in 2077. The function will be executed function cuz the installed version will be 0(but I have read the manpage wrong yesterday and got corrected, so I can be wrong agan )

__
The minimal thing that cover all the use case possible is to have an already existing empty file with no repo in it.

This said. im also expecting in the future some regex being applied to the file like we can see here :

And im keeping on eye on the idea of renaming the file.

from raspberrypi-sys-mods.

Or add a debconf or postinst-based

That would result in the same problem created here where the update is pushed as an omnibus bill that force the user to accept my revert attempt if he/she wants to receive updates of this unrelated package.

The same way that if you do not let raspberrypi-sys-mods-20200729 attempt to install M$ repo, I won't receive the repo source update located here.

That's why, I think, This must be done in its own package, so the user can decide to get it, or not, or change its mind without being penalized. or hacking in files that are covered by the package.

But, can't just publish a package on my PPA. it won't be downloaded with apt update

So the most polite way I can do that. is to recommend the installation of it. My problem is that I don't have a god package where it would make sense to attach this. So an unrelated package will be selected to.

from raspberrypi-sys-mods.

This thread's getting too chatty - locking until there's an official update.

from raspberrypi-sys-mods.

Addressed in the first response.

from raspberrypi-sys-mods.