fix: Don't install recommended packages in base image

[MoritzWeber0]

Get rid of pynvim, which is flagged as malicious in XRAY.

Resolves #313.

[MoritzWeber0]

Tried the change with the t4c/client/remote image and works fine so far. Quickly checked the list of installed packages. The only relevant missing one was gnupg, added it to the list.

[jamilraichouni]

I trust you :-)

[kacper-ka]

Apparently this fix has broken the image for me: I have relied on the presence of ssh inside the container and have used it along with other components in order to use the identity keys present on the host (mounting gpg-agent and ssh-agent sockets inside the container). What would be your recommended approach to mitigating this? On the host I use KeePassXC and its ssh-agent feature in order to not store private keys on the disk. I require maintaining this state, therefore it would be necessary for the Eclipse inside the container to fetch the keys from the agent running on the host.

I would be grateful for any insight regarding this issue, either some solution I haven't thought of or simply adding ssh to the container explicitly.

[MoritzWeber0]

Apparently this fix has broken the image for me: I have relied on the presence of ssh inside the container and have used it along with other components in order to use the identity keys present on the host (mounting gpg-agent and ssh-agent sockets inside the container). What would be your recommended approach to mitigating this? On the host I use KeePassXC and its ssh-agent feature in order to not store private keys on the disk. I require maintaining this state, therefore it would be necessary for the Eclipse inside the container to fetch the keys from the agent running on the host.

I would be grateful for any insight regarding this issue, either some solution I haven't thought of or simply adding ssh to the container explicitly.

Hey @kacper-ka, definitely an interesting use case that I didn't consider yet. Until there is a solution, you can continue to use version v2.5.2.

I mainly see two options:

1. You create a small Dockerfile that inherits from our image and installs an ssh-agent on top. This would be the easiest solution.

   FROM [IMAGE_THAT_YOU_CURRENTLY_USE]
   USER root
   RUN apt-get update && apt-get install openssh-client
   USER techuser

   Then, you have to build the image with docker build -t [NAME_OF_THE_NEW_IMAGE] .. Please note that you have to repeat the step after each update of the base image.

2. We add openssh-client to the image again. I just see the risk that we don't want to have ssh installed in the remote image for security reasons. The remote image inherits from the base image, so that would be affected as well. This situation will improve with buildpacks because we can individually combine layers, but it will take some time to finish the buildpacks PR and there are some higher priorities in the next few weeks. (build: Use buildpacks for better caching #300).

[MoritzWeber0]

Hey @kacper-ka, a short update from my side. We decided in the team that we want to support SSH officially in the image. Thanks for raising the nice use-case. The client was added in #319 and will be part of the next release (next week).

[kacper-ka]

Great, thanks for the update @MoritzWeber0 !

[MoritzWeber0]

Great, thanks for the update @MoritzWeber0 !

Took a bit longer than expected because we had to fix the pipeline first. The update is released in v2.6.0. Feel free to try it out.