Raspberry Pi | Microsoft Visual Studio Code APT repository automatically added

[ghost]

ADMIN EDIT

If you don't require the Microsoft Visual Studio Code repository, or don't even know what it is about, simply remove it:

rm -f /etc/apt/sources.list.d/vscode.list /etc/apt/trusted.gpg.d/microsoft.gpg

---

Does this privacy vulnerability also impact dietpi? And are there any plans to add this repo to dietpi aswell, I hope not.

[MichaIng]

This repository is part of the raspberrypi-sys-mods package: https://www.raspberrypi.org/forums/viewtopic.php?t=301011
Sadly, despite the negative feedback, they'll leave it inside and locked the discussion topic around it. The problem is that this package is otherwise quite important, especially a lot of udev rules to allow easy hardware permission handling are applied, which would be a nightmare to maintain ourselves to get rid of the package.

I'll do a suggestion to them to make that repository file a regular static file of the package, since then we can easily block it from being installed. Currently it's installed and even repaired as part of a postinst script, which is very difficult (impossible without deeper hacks) to block.

[ghost]

Ew, okay ill boycot Raspberry Pi temporarily then and I hope others follow me in this, there are way more boards than just the raspberry pi anyway which do not enforce their users too give microsoft more "Get rich quicker" data. Anyway I appreciate you actually trying to help instead of censoring every piece of so called "Microsoft bashing" and I hope you continue your work on DietPi for many years.

[MichaIng]

I rechecked the source code, where the commit has now been added (after the change has been released via package!): RPi-Distro/raspberrypi-sys-mods@655cad5
It should now be possible to simply remove the content of the file without having it repaired on upgrade.

But I'm currently working on a commit to make it a regular DEB config file so that it can easily be identified and blocked and removed without having it recreated.

too give microsoft more "Get rich quicker" data

To be true, unless you install software from this software, it's not more than pulling a small list file from their servers, so aside of the connecting IP, there is no further data transferred. But I don't like the way it is done, without a changelog, without a commit (let's say prior to having those two done), without a change to identify the origin of the file and without the ability to simply remove it permanently. Since it's for Raspberry Pi Pico users, even a check, if it's really a Pico system, could have been done, but nothing. And the discussion topic has been closed without even answering to the quite constructive feedback (doing the checks, adding it as regular package file, adding it to new Raspberry Pi OS full desktop images only, etc.).

Let's see how the reaction to my pull request will be, then we'll take appropriate action for our DietPi users.

[MichaIng]

Ah wait: RPi-Distro/raspberrypi-sys-mods@655cad5#diff-bcd0697853b9c0a4c45f968cf38e9f2135c6e28cb7367ea5189b281ce0d51f9cR122-R125
dpkg --compare-versions "${2}" lt-nl "20210125" means that the repo is only added on this one version change, not on every upgrade, and that it is not even done when installing the package freshly ($2 = previous version is empty). This means they would need to add it to their images via pi-gen instead, although I cannot see a related commit been done there.

The good thing is then that it indeed can be simply removed. I'll run some tests to verify.

[ghost]

Ah okay, maybe a whiptail for people that still want to keep this repository? That way you give people the option to keep it if they think its neccesary.

[ghost]

And yes I think the way that they implemented the repo is very poorly done, and the reaction from eben upton was even worse, saying that they've always done it this way (the sneaky way), but contradicting himself with their own blogpost about the December raspberry pi os update, this is the main reason I used dietpi, because of the clear changelog.

[MichaIng]

Tests:

• Fresh install of the current package: No repo added.
• Reinstall/upgrade of the current package: No repo added.
• Manual reduction of package version string + reinstall/upgrade: Repo added.

I think the guys reaction was a defensive one. They didn't think carefully about it, added it with good will as quick action to make Raspberry Pi Pico developer's life easier. Since the users reactions were quite harsh, in my case a result of a little shock, being worried about either our or (after I got pointed to the origin package) RPi sources being compromised, the reaction on the feedback came back harsh as well. I think, or hope, that it still arrived, so that in the future such changes are communicated and added transparently 😃.

[MichaIng]

Done:

• Via whiptail on next update: 0aa2c57
• By default for fresh images, since Raspberry Pi OS will likely be shipped with the repo pre-installed in the future: 2f864e4

[ghost]

Cheers! 🥂 Thanks for your concern about user-privacy and people that dislike windows-on-their-linux!

[MichaIng]

And if it's only the 99.5% unnecessary overhead on each "apt update" to pull and cache another APT repository.

[ghost]

Wouldnt vscodium be a better alternative anyway? https://vscodium.com/

[ravenclaw900]

And it's licensed under a free license because of that. It's what I use as a code editor, actually.

[MichaIng]

Not sure why Raspberry Pi Foundation chose to use the non-free repository, or what the benefit might be, likely they have some arrangement, like in other cases, with RealVNC, Broadcom for the SoC and parts of the firmware. I think it's fine with the notice and offer to remove the repository. Every VS coder will likely know about VSCodium and can decide best for themselves whether to use the MS repository or the FLOSS binaries: https://github.com/VSCodium/vscodium/releases

---

We are planning to add a few development environments/tools/languages and make some own install options, like PHP composer and Go. Aside of .NET, VSCodium could be added to the list. I'll keep that in mind.

[Lastat77]

Can I (also) block the repo Address(s) with my PiHole? Is there a list of MS addresses? (Yes, I am new)

[MichaIng]

This is the repository: https://packages.microsoft.com/repos/code/
So you can block packages.microsoft.com via Pi-hole. But honestly, simply remove the files and you don't need to worry about it 😉. The Raspberry Pi devs have well received the enormous negative feedback and won't re-add it without interactive permission.

[MichaIng]

@FredericGuilbault
Pinging you here as the other issue was locked while I was writing. Just to clarify your concerns about dpkg --compare-versions "${2}" lt-nl "20210125": In case the package is not currently installed, the $2 version will be an empty string and the lt-nl operator treats an empty string as higher version, only the lt operator would treat it as lower version. Aside of reading the man page, I also ran tests to verify this behaviour. So whatever action was suggested in those heated discussions, accepting the upgrade and removing the files afterwards it the safest and cleanest solution to never face them again.

And if I were you, I would not worry much about users who do now not upgrade now but might do later: I'm pretty sure according to XECDesign's reactions, that they'll soon release another package upgrade which won't add the repository the "sneaky" way anymore.

Only left issue is what to do about users which already did the package upgrade but did not recognise the repository yet to take action. But indeed that topic doesn't fit well into an issue on the RPi repo (what the issue was locked for) 😉.

[FredericGuilbault]

But indeed that topic doesn't fit well into an issue on the RPi repo

IDK, that's mainly questions they should have asked their self before and are probably asking their self Right now.

I could have stayed silent and just publish a solution on lysmarine and save chatting time. But I prefer to brainstorm with other concerned people. Sadly PRi people seem to prefer to have a private meeting then discussing this on Github. (Nothing new here)

---

gosh U are right.... there is something I deeply don't get about dpkg --compare-versions LOL

#> apt list raspberrypi-sys-mods
Listing... Done
raspberrypi-sys-mods/testing,now 20200812 arm64 [installed]

#>apt purge raspberrypi-sys-mods
#>apt install raspberrypi-sys-mods
#> ls /etc/apt/sources.list.d/
raspi.list

It's not here.

That's nice that you took time to actually test it. I stand corrected by facts :D

But that lead me to the other question then. This mean it's a limited offer ????

If I don't run apt upgrade raspberrypi-sys-mods before they publish their next version of this package. The repo will never be added ???

At a design level Or this shit will try (at least once) to add itself for eternity, or the amount of people who will receive it is limited. That't where I made false assumption that as from today, if postinst don't see the file. It tries to add it.

if it's the case that narrow the corrective I have to publish. ... untill they add it to pi-gen

[MichaIng]

I could have stayed silent and just publish a solution on lysmarine and save chatting time.

The general criticism and arguments against the whole thing was discussed at several places, making the point over and over and today XECDesign took it still surprisingly constructive, so I think it did reach and there is no need to make further noise, at least it won't have any positive effect, I believe 😉.

But you brought in another new suggestion with the conffiles, generally IMO a great one, which is why I yesterday had half finished a pull request to do exactly that, also based on the wrong assumption that the repo is re-added on every upgrade and after adding some angry posts to the RPi forum as well 😄. While altering postinst I recognised and checked lt-nl and realised that adding it to conffiles, allows the repo to be re-added while currently it is never. This is what I wanted to make clear at the issue over there. But I agree that conffiles is usually the best way to add anything to /etc, so that it is transparently seen in the package content list, dpkg -S works, path-exclude works, and any custom change is never overwritten without interactive permission (when not using force-confmiss|new) and a generic output about it.

If I don't run apt upgrade raspberrypi-sys-mods before they publish their next version of this package. The repo will never be added ???

As long as it is currently installed and it's version is below 20210125, it will be added (the way they choose to add it with the next upgrade). It's speculation, but would make sense is that the idea was to add it by default to all Raspberry Pi OS images a single time, to new images via pi-gen (hence no need to add it with fresh raspberrypi-sys-mods package installs) and to existing systems when upgrading from pre-20210125 to any newer version, but not repeatedly when upgrading from >=20210125. However, now that this caused so much discussion, we need to wait for the next version and see how it's handled then, as the postinst script will surely be changed.

[RicardoCst]

Sorry for deleting my account in anger, ive had a rough few months. But I think this is only the beginning of sneaky stuff added into the code, I hope they review their decisions in the future about who to add into their sources.list because with people pinging the microsoft repo they already get to know 3 things, people using linux or raspberry pi, IP adress, and city / where you are from.

EDIT: As in just setting the bar lower and then trying it again when nobody thinks its new news.

[FredericGuilbault]

you brought in another new suggestion with the conffiles,

Yes, and I was later making my arguments for proposing to separate the thing in a different package.

But they freezed the thread, So now the only thing left is :

wait for the next version and see.

Im pretty sure devs are talking about how they will get out of this situation in private RN. But so far, looks it's not happening on GitHub, and users brainstorming is not welcome. ....So it will be another surprise. A better one hopefully. But it's still the same game. I can't know if the fix I'm writing right now will be fucked up by their next release in 3 days not.

For that reason, I'm ok to be noisy.

---

this is only the beginning of sneaky stuff added into the code

This is not their first time, One day. people will be pissed off enough to fork it. But as armbian people respond to users that ask for RPi support. The Broadcom bloat prevent anyone to make a real FOSS OS for this SBC so, the gain don't worth the trouble.

The most "economic" thing to do I think is what DietPi and I do. Wait Use their codebase and strip it from the crap. But god I wish that armbian will support it one day.... This will make my life so much easier.

[FredericGuilbault]

As long as it is currently installed and it's version is below 20210125, it will be added (the way they choose to add it with the next upgrade).

Got it, this is clear now.

but would make sense is that the idea was to add it by default to all Raspberry Pi OS images a single time, to new images via pi-gen

So this mean they can't update raspberrypi-sys-mods before they have published a new ISO. Or they will have to extend the version check and shit, will be triggered again.... Gosh, they did it all backward.

Im sure they will find a solution. But I fear it won't be clean. lol.

[MichaIng]

So this mean they can't update raspberrypi-sys-mods before they have published a new ISO.

Why? It was only speculation based on how it was done, but if it's true, for new images pi-gen needs to be updated while raspberrypi-sys-mods doesn't play a role. And all running systems got or get the repo installed one time, so those are handled independent from images updates. Or did I overlook something 🤔?

I wouldn't be so pessimistic here. We're talking about about one mistake of this calibre, and it's ridiculous to assume that there are any evil plans to sneakily add evil companies software (replace "evil" with less polarising words like "data collecting" or "non-free", it doesn't change something about the point), as such is obviously always detected on a Linux system anyway, simply when you run "apt update". So it is in-transparently added, without active admin choice, yes, but "sneaky" in terms of "they want to hide it from users" is so obviously impossible, come on... 😄.

But god I wish that armbian will support it one day.... This will make my life so much easier.

Sorry for the huge text blocks, Saturdays...

Have you every run (I mean mid-long term, not for testing) a server with an Armbian(-based) image? I'm pretty sure you won't be as satisfied as with Raspberry Pi OS. They do an awesome job to have up-to-date mainline Linux running on nearly every SBC on the market, but that comes with it's prize: They need to drop old kernel support quickly, so you'll always run on the latest Edge version, often not well tested and with lack of features, as older, especially LTS versions are not updated anymore. The widely used SoCs, like RK3399 might be also mostly good supported feature wise (better tested, more contributors), but others are very limited, compared to the original manufacturer image (which is often hopelessly outdated). Also Armbian does not ship their kernels with a meta package structure, so every "apt upgrade" will upgrade the kernel as well, compared to Debian, where "apt full-upgrade" is required, so that you can handle this essential system part separately. And when you count it relative, based on the user amounts, Armbian-based images have a very large number of critical bug reports here, unbootable images (sometimes with single new kernel versions), instabilities, random crashes, network issues (very common), large numbers of random distracting kernel errors, where debugging actual recognised issues become a nightmare with. This in combination with the non-meta package system is not ideal to run a stable server wile keeping it updated security-wise. But that is no offence, it is simply the only possible way with limited time of volunteers to get mainline Linux running on this amount of SBCs, where large parts of the kernel and config is shared among large numbers of actual boards. And I'm happy that I'm not the one who needs to tinker with this but simply takes their work, so great respect at this point. With Raspberry Pi OS, you have always latest LTS Linux versions for all models, regardless how old, VERY well tested and exceptionally well featured, with an enormous number of device tree overlays for all thinkable hardware and features. That is no praise, but only simply possible as of their selling numbers. No other manufacturer has the chance to reasonably pay a kernel development team that keeps migrating to latest LTS Linux and keeps updating own images for all their boards.

And you did one time say that you ideally need a bare-bone image for lysmarine with no additional (boot) services, at best. Armbian ships a lot more of such services by default than us, that do notably slow down boot (okay in our case the forced time sync does as well, we need to allow this continuing in background, arg 😅) and imply a lot of automated system modifications, that go deeper than what we do. Whether it is overall reasonable or not, is a different question, however, we do a lot of effort to block all those services from being installed and always automatically enabled by their linux-root-... packages, which can be seen as the counterpart to RPi's raspberrypi-sys-mods, to no have collisions with our own user-space, or because I personally don't like to have /tmp and /var/log as zram drive, rather than tmpfs, I don't use ZFS and zsh (lol all with "z" I just recognise). And compared to raspberrypi-sys-mods, one cannot simply remove the linux-root-... package, as this breaks kernel package upgrades, also masking the services at least did create package upgrade failures, so we needed to use DPkg path-exclude to prevent them from being installed at all. Again, all no offence, similar to us, they implement a few things around the core system which they think is good to have, but it is not an ideal basis for an own distribution with own ideas about how user-space should look like 😉.

What I am really looking forward to in this regards is Debian Bullseye, where native support for a lot of SBCs and quite good open-source GPU support is possible. Similar to RPi, the Debian kernels are regularly updated LTS, but I cannot yet say something about the actual stability, I'm still tinkering with creating related images from scratch, best practice to install and configure U-Boot etc 😃.

[FredericGuilbault]

I wouldn't be so pessimistic here. We're talking about about one mistake of this calibre, and it's ridiculous to assume that there are any evil plans to sneakily add evil companies software.

I don't think they are evil, but I don't think they are naive either. If on Monday at my job the sell representative told me that I have to add a new sensitive corporate plugin in any client's wordpress we manage. My first question is how we gonna manage the burst of clients panicking and raging and how we decoil them without loosing our whole week with one-on-one with L1/L2 support.

They must had some concerns that at least few neck beard Stallman worshippers would get vocal about that. The obscure way they did it. They just called for Streisand effect. I mean. It's not their first drama. RPi fundation always had haters, They have should have know better by now IMO.

---

run a server with an Armbian(-based) image?

I run one on my boat for testing, but it's not online. So I never looked at package life cycle frankly

Also Armbian does not ship their kernels with a meta package structure, so every "apt upgrade" will upgrade the kernel as well, compared to Debian, where "apt full-upgrade"

ohhhh, I didn't realized that. Thx for sharing this knowledge with me.

And I'm happy that I'm not the one who needs to tinker with this

I had a bug and tried to look in their builder tool to fix it ..... and pfffffff . I think it's good code. But get why they don't have many contributors. It's a quite complex netowrk of patches and cross fix among kernels ans SBC. Rly intimidating.

Armbian ships a lot more of such services by default than us,

I try to strip Armbian down a bit. but IK what you mean. Im still struggling between what I think is the good way to do things and what Time I have. And sometime if I don't keep that balance I end up taking counterproductive decisions. As you know, I'm pretty opinionated about how things should be.

What I am really looking forward to in this regards is Debian Bullseye,

On that matter, Is there a place I can follow you on that subject ?
I haven't tested anything but yes, but been able to build everything straight from Debian with debootstrap would be the best solution for me.

I have saw they made their first freeze few weeks ago. So they must be stabilizing what it will look like. :)

[MichaIng]

but I don't think they are naive either.
...
They have should have know better by now IMO.

100% agree, I would have expected a more experienced/professional way of implementing such changes as well.

ohhhh, I didn't realized that. Thx for sharing this knowledge with me.

I mean on RPi it's the same, but with their multi-layer parallel testing/development stages of latest and latest-LTS kernel and firmware testing it's rare that any critical issues makes it into the final firmware package release.

I try to strip Armbian down a bit. but IK what you mean.

I was thinking to skip the linux-root-* package and place an own kernel/initrd to U-Boot conversion script. But the root package, similar to rpi-sys-mods contains a few other reasonable configs, which at least would need to be reviewed and in case ported as well.

On that matter, Is there a place I can follow you on that subject?

Not yet, it's still offline tinkering. I'll ping you once the debootstrap script and a first image is ready for review and testing.

[BangDroid]

I removed the repo and key. This thing likely to come back with update?

[MichaIng]

With the current package upgrade/postinst script: Nope, it is installed only a single time.

[Joulinar]

Hi guys,

today there was a new version of raspberrypi-sys-mods available and it did not install the MS repo again.

root@DietPi4:~# apt list --upgradable
Listing... Done
raspberrypi-sys-mods/testing 20210208 arm64 [upgradable from: 20210125]
N: There is 1 additional version. Please use the '-a' switch to see it
root@DietPi4:~# cd /etc/apt/sources.list.d/
root@DietPi4:/etc/apt/sources.list.d# ls -la
total 12
drwxr-xr-x 2 root root 4096 Feb  6 14:46 .
drwxr-xr-x 7 root root 4096 Aug 24 21:53 ..
-rw-r--r-- 1 root root   56 Aug 24 22:18 raspi.list
root@DietPi4:/etc/apt/sources.list.d# apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  raspberrypi-sys-mods
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.6 kB of archives.
After this operation, 3072 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://archive.raspberrypi.org/debian buster/main arm64 raspberrypi-sys-mods arm64 20210208 [12.6 kB]
Fetched 12.6 kB in 0s (52.6 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 16429 files and directories currently installed.)
Preparing to unpack .../raspberrypi-sys-mods_20210208_arm64.deb ...
Unpacking raspberrypi-sys-mods (20210208) over (20210125) ...
Setting up raspberrypi-sys-mods (20210208) ...
Failed to try-restart sshswitch.service: Unit sshswitch.service is masked.
Failed to try-restart sshswitch.service: Unit sshswitch.service is masked.
Failed to try-restart sshswitch.service: Unit sshswitch.service is masked.
Failed to try-restart sshswitch.service: Unit sshswitch.service is masked.
root@DietPi4:/etc/apt/sources.list.d# ls -la
total 12
drwxr-xr-x 2 root root 4096 Feb  6 14:46 .
drwxr-xr-x 7 root root 4096 Aug 24 21:53 ..
-rw-r--r-- 1 root root   56 Aug 24 22:18 raspi.list
root@DietPi4:/etc/apt/sources.list.d#

[MichaIng]

Great, thanks for the heads up. Let me review the package sources.

[MichaIng]

Okay while things are not worse, it is really a crippled change that does IMO not address the main concerns that have been made: RPi-Distro/raspberrypi-sys-mods@e6beae2

Now, when we remove the repo, the obsolete preferences are reinstalled with every package upgrade. Also since they are not very selective, other repos with "code" branch and "stable" suite are broken, since the pin is not tied to packages.microsoft.com, while this is made an own pin, where I'm not even sure how the conflict between two such pins are resolved then.

I'll suggest to make it a config file, so removal and edits persist.

EDIT: Ah, debhelper adds files in /etc to conffiles automatically. Hence when it is removed, it stays removed. I'll verify that files with .dpkg-dist ending are no valid APT preferences 😄.

• Yes works. Okay so we'll remove it as well when user chooses to remove the repo to assure is does not break packages from other repos unexpectedly.

Done: a279d2e 13fe64b

[c33s]

@MichaIng never thought about using a different OS for raspberry before but as i think that using raspberry OS can meanwhile be a GDPR violation (RPi-Distro/raspberrypi-sys-mods#43 (comment)), i think about switching to diet-pi. as far as i understand diet pi uses raspberry OS as base system or at least some packages of them. how do you ensure or do you have any plans to try to ensure that such illegal tracking stuff doesn't leak into your images?

[MichaIng]

how do you ensure or do you have any plans to try to ensure that such illegal tracking stuff doesn't leak into your images?

I doubt it is illegal only because Microsoft servers are pinged when you run "apt update". Also various Debian/Raspbian servers (as part of the mirror direction) are pinged, without asking users interactively, but I'm no lawyer. However, I agree that adding this repo without interactively asking the admin if the contained software/vendor is trusted/wanted is simply wrong, counteracting the idea and benefit behind APT itself, GNU/Linux package manager systems in general. It's like this nasty Windows installers that pull in toolbars or worse that you never asked for... very different level, but same principle 🙈. Thanks for bringing up in your comment over there:

1. That we talk about VS coders, not beginners.
2. That is looks like it's about advertising income, hidden behind the claim of end-user benefit, which is true for all those Windows installers with their toolbars, browsers using Google as default search engine and all those things. I do not claim that being true for RPi Foundation + Microsoft, but that this comparison can be done is an issue in itself.

I had those in my comment on the debconf PR that got just closed, but removed them again, concentrating on the fact that any knowledge about APT repos is irrelevant when simply asking the user if the software provided by the repo is ever wanted or not. Even Linux beginners will know such check boxes for those nasty toolbars from Windows installers 😄.

About your actual question:

Since we ship our images with the same package pre-installed, we currently do not ensure that it cannot add repos to our images. With the next update we check if this particular repo exists and interactively ask the user if it is wanted or shall be purged, we remove it as part of our images creation script for new images, and we currently inform users about the matter via login banner. As for the future:

• I'm watching the packages repository now, to get informed about every commit. But I'm optimistic that the RPi Foundation won't add any further repository that way, as the negative reputation impact and news on several well known magazines, blogs and social media platforms was enormous. They would be damn stupid, shooting into their own knees by causing such again.
• If my optimism turns out to be wrong, we'll remove the raspberrypi-sys-mods from our images and apply the useful system modification it contains manually, via own package or as part of our image creation script, that's for sure.

[MichaIng]

For the record. The VSCode package is now shipped via RPi repository: https://archive.raspberrypi.org/debian/pool/main/c/code/
The Microsoft repository is hence not required anymore and it is even actively blocked now by the raspberrypi-sys-mods package: RPi-Distro/raspberrypi-sys-mods@4d1afec
Respectable step, as this solves the issue while keeping it simple to install VSCode, when required, but implies additional effort for the RPi team to keep those packages updated/in sync.

In the meantime, we added VSCodium to dietpi-software options with DietPi v7.1, the FOSS variant without Microsoft telemetry, so comparable to Chromium vs Chrome.