Why Microsoft repo is needed?

[merkys]

Recently pushed commit 655cad5 adds Microsoft repo to /etc/apt/sources.list.d, as well as /etc/apt/trusted.gpg.d/microsoft.gpg. Why is this actually needed?

[pelwell]

As has been stated repeatedly on the Forums, this is to make it easier for Pico users to install VSCode.

[XECDesign]

Just to make installing VS Code simpler. Perfectly safe to remove those files if you don't have intention of doing so and it won't be added again.

[Valentin-N]

How are packages that are unrelated to VSCode protected from getting upgraded from the Microsoft repo?

[merkys]

Isn't VS Code MIT-licensed? If so, it could be packaged and installed using regular means, via separate Debian package.

What worries me here, is unexpected addition of things under /etc/apt/. Maybe Microsoft can be trusted to install precompiled and unverified binaries, but this has to be absolutely unavoidable, and must come with big red warning.

[pelwell]

I'm sure there are plenty of people like your good selves who will let us know if Microsoft start publishing anything unrelated to VS Code, anything that replaces an existing package, in their repo.

[XECDesign]

How are packages that are unrelated to VSCode protected from getting upgraded from the Microsoft repo?

You mean if MS were to maliciously try to override our or Raspbian/Debian packages with their own versions?

If it would put people at ease, we could add something to reduce the priority of that repo so that it never overrides any packages outside of it.

Isn't VS Code MIT-licensed? If so, it could be packaged and installed using regular means, via separate Debian package.

Correct me if I am wrong, but I believe there are parts of VS Code that aren't entirely open - microsoft/vscode-cpptools#5980. Otherwise, we would just take vscodium or do our own builds.

[Valentin-N]

You mean if MS were to maliciously try to override our or Raspbian/Debian packages with their own versions?

If it would put people at ease, we could add something to reduce the priority of that repo so that it never overrides any packages outside of it.

Since the stated reason for adding the Microsoft repo for everyone is to provide easy access to VSCode, how about whitelisting only the VSCode packages and default disabling everything else? Sample preferences file that achieves this behavior for another repo:

$ cat /etc/apt/preferences.d/syncthing 
Package: syncthing*
Pin: origin apt.syncthing.net
Pin-Priority: 990

Package: *
Pin: origin apt.syncthing.net
Pin-Priority: -1

I'm sure there are plenty of people like your good selves who will let us know if Microsoft start publishing anything unrelated to VS Code, anything that replaces an existing package, in their repo.

I guess my imagination is going wild thinking of all the possible attack vectors this opens up.

[XECDesign]

Since the stated reason for adding the Microsoft repo for everyone is to provide easy access to VSCode, how about whitelisting only the VSCode packages and default disabling everything else?

Yeah, I have no problem with that.

[merkys]

How are packages that are unrelated to VSCode protected from getting upgraded from the Microsoft repo?

You mean if MS were to maliciously try to override our or Raspbian/Debian packages with their own versions?

There may be unintended namespace collisions.

If it would put people at ease, we could add something to reduce the priority of that repo so that it never overrides any packages outside of it.

I'd say this is necessary.

Isn't VS Code MIT-licensed? If so, it could be packaged and installed using regular means, via separate Debian package.

Correct me if I am wrong, but I believe there are parts of VS Code that aren't entirely open - microsoft/vscode-cpptools#5980. Otherwise, we would just take vscodium or do our own builds.

OK, I stand corrected. But if VS Code is optional, and required only by some users, why not creating a separate metapackage with MS repo and GPG key? Because now every installation of raspberrypi-sys-mods silently attaches the MS repo.

[XECDesign]

Well, not silently, I added a message to make it clear what is happening, so it's a little strange to see conspiracy theories (not here, but elsewhere) attaching malicious intent saying that we were trying to hide it or something.

But if VS Code is optional, and required only by some users, why not creating a separate metapackage with MS repo and GPG key?

That would make it an opt-in thing rather than an opt-out thing, which I guess is the crux of the objection people have. It comes down to simplicity: apt install code vs apt install something-else; apt update; apt install code

One email I got about this raised the concern that there's no reason lite image users would want this, so I'm taking a look at taking it out in those cases.

It also doesn't do anything if the vscode.list file already exists, so you could add a blank one before upgrading to avoid ever making contact with MS servers (ignoring that we're using GitHub right now).

There may be unintended namespace collisions.

I'm not expecting them to add any non-vscode packages to their code-specific repo, but I can understand that some people might want to have more certainty than hope.

[Djiko]

The binary VSCode is not MIT licenced. Only the vscode repo is, ie the source code. VSCodium could be a better option, no?

[merkys]

Well, not silently, I added a message to make it clear what is happening, so it's a little strange to see conspiracy theories (not here, but elsewhere) attaching malicious intent saying that we were trying to hide it or something.

That's right, and thank you for adding this message. However, it easily gets buried between everything else the dpkg prints out. I expect that rarely anyone actually eyeballs through that.

But if VS Code is optional, and required only by some users, why not creating a separate metapackage with MS repo and GPG key?

That would make it an opt-in thing rather than an opt-out thing, which I guess is the crux of the objection people have. It comes down to simplicity: apt install code vs apt install something-else; apt update; apt install code

Exactly. This was my point.

One email I got about this raised the concern that there's no reason lite image users would want this, so I'm taking a look at taking it out in those cases.

Agree.

It also doesn't do anything if the vscode.list file already exists, so you could add a blank one before upgrading to avoid ever making contact with MS servers (ignoring that we're using GitHub right now).

OK, but no one doing routine apt-get upgrade knows that in advance.

There is a difference between using some source hosting website, and trusting execution of compiled binaries with root privilege. I have nothing against MS in particular in this case. I just don't want anyone tampering with anything under /etc/apt/ unless it is unavoidable.

There may be unintended namespace collisions.

I'm not expecting them to add any non-vscode packages to their code-specific repo, but I can understand that some people might want to have more certainty than hope.

For sure. Thanks.

[fladi]

As a Debian Developer: Why was this not announced in a NEWS.Debian entry? I mean, adding a non-vanilla-distro key to /etc/apt/trusted.gpg.d/ is a pretty shady move. A simple echo ... in the postinst script is not enough as it never requires the operator to acknowledge this important change (and is likely overlooked). A lower priority for packages.microsoft.com would also have been a sane addition, if only to prevent any mishaps with overriding packages from this repo. After all, Microsoft does not own the "code" package name in upstream Debian.

And please don't belittle people by making misleading statements, comparing intentional usage of a code hosting site with giving an unacknowledged third party potentially unfettered root access to their systems.

[XECDesign]

The binary VSCode is not MIT licenced. Only the vscode repo is, ie the source code. VSCodium could be a better option, no?

Not if you want access all the features and extensions. Unfortunately it looks a bit like the Chrome vs Chromium situation.

That's right, and thank you for adding this message. However, it easily gets buried between everything else the dpkg prints out. I expect that rarely anyone actually eyeballs through that.

I guess a news entry would make it clearer for everybody, but I'm not sure it's appropriate to spam everybody with potentially confusing information a small percentage of users will care about. I'll mull it over.

There is a difference between using some source hosting website, and trusting execution of compiled binaries with root privilege. I have nothing against MS in particular in this case. I just don't want anyone tampering with anything under /etc/apt/ unless it is unavoidable.

Yeah, that was mostly addressing the concern I've seen elsewhere about MS knowing when you run apt update.

[XECDesign]

And please don't belittle people by making misleading statements, comparing intentional usage of a code hosting site with giving an unacknowledged third party potentially unfettered root access to their systems.

Just addressed that as your message came through.

Anyway, this is getting unnecessarily hostile for my liking. Thanks for the productive contributions so far, but I think I'll bow out now.

[tdobes]

One email I got about this raised the concern that there's no reason lite image users would want this, so I'm taking a look at taking it out in those cases.

Thank you for considering this. Adding the repo only if other full-image GUI packages are present would be a significant improvement.

...

That said, merkys' suggestion of a meta-package to simplify adding the external repo and package seems like a good solution to all the problems cited:

if VS Code is optional, and required only by some users, why not creating a separate metapackage with MS repo and GPG key? Because now every installation of raspberrypi-sys-mods silently attaches the MS repo.

This would simplify the process of adding the VS Code repo for use with the Pico but ensure that it's only added if end users intentionally request it.

[fladi]

I'm sorry if you perceived my comment as hostile, this was not my intention. I am trying to point out possible improvements to this situation, seeing the ruckus it is causing right now on different platforms. From an OpSec POV at least the priority pin for this repo should be added. The privacy aspect of pinging an additional repo is a different topic as the vanilla repos are already hosted on a variety of third party mirrors.

[XECDesign]

I'm sorry if you perceived my comment as hostile, this was not my intention. I am trying to point out possible improvements to this situation, seeing the ruckus it is causing right now on different platforms. From an OpSec POV at least the priority pin for this repo should be added. The privacy aspect of pinging an additional repo is a different topic as the vanilla repos are already hosted on a variety of third party mirrors.

No worries, thanks for clarifying. I agree with everything you said there.

I'm not sure about adding the news entry, but I'll run it by the others and see where we land.

[eriol]

Hello, please don't consider this message hostile, I'm writing because I care.
I also speak from the point of view of a Debian Developer.

If the goal is to make it easier to install VS Code, why not leverage extrepo[¹]? It already manage the VS Code repository and it's already backported for buster. See https://grep.be/blog/en/computer/debian/Software_available_through_Extrepo/

[¹] https://tracker.debian.org/pkg/extrepo

[XECDesign]

Hello, please don't consider this message hostile, I'm writing because I care.
I also speak from the point of view of a Debian Developer.

No worries, I wouldn't have. After reading some comments elsewhere which were definitely hostile, I may have read some previous messages here in a tone they were not intended.

If the goal is to make it easier to install VS Code, why not leverage extrepo[¹]? It already manage the VS Code repository and it's already backported for buster. See https://grep.be/blog/en/computer/debian/Software_available_through_Extrepo/

I wasn't familiar with it, but honestly it looks like the exact tool for the job. The existing metadata for the vscode repo only lists amd64, but I'm sure that's trivial to update. I'll take a closer look.

[fladi]

@eriol Hi Daniele! Thanks for mentioning extrepo, it would surely be the most sensible way to handle such repos. The only issue I can see with it is that for buster, it is only available through backports right now.

[XECDesign]

The only issue I can see with it is that for buster, it is only available through backports right now.

We can pull it into our repo and point it to our own metadata. It looks useful regardless of whether it ends up being used specifically for this case.

[sabotagebeats]

Just to make installing VS Code simpler. Perfectly safe to remove those files if you don't have intention of doing so and it won't be added again.

how?

[pelwell]

Unconstructive comments will be deleted.

[ghost]

Just like in the forum, now developers/mods have turned to damage control and censoring comments by calling them unconstructive, I wish there was more transparancy and no animosity, there were clearly better options like https://vscodium.com/ but even that was called "unconstructive" and my issue was closed because it was a "duplicate issue" even though I clearly mentioned https://vscodium.com/ repo, and that while NO one has mentioned it in this github, so I dont see how its a duplicate issue. People here are mentioning the issue, I just said an alternative.

But I must say that I am sorry for the language in the closed issue, it was just angering to see a linux OS resorts to using microsoft.

[XECDesign]

Press ctrl-f, type codium. You will see it mentioned, and the reason why it's not used instead in the comment of mine that you have already put a thumbs down next to without reading, apparently.

[XECDesign]

Answered