Would be nice to feature a :musl tag for building musl Rust binaries!

As an example, see https://github.com/mcandre/docker-linux-rust/blob/master/musl.Dockerfile

I was trying to dockerize a Rocket app, and wanted to use the official Rust Docker image, but it seems there's no nightly?

Also, I'm new to Docker, so I may be mistaken.

When running cargo build | check inside a container based with this image, the crates get downloaded but don't compile. This is the error I get:

    (Omitting big list of crates being downloaded and checked)

    Checking trust-dns-resolver v0.10.0
    Checking actix v0.7.8
    Checking hyper-tls v0.3.1
    Checking reqwest v0.9.5
    Checking actix-net v0.2.4
    Checking sparkpost v0.4.1
    Checking actix-web v0.7.15
    Checking simple-auth-server v0.1.0 (/app)
error: Edition 2018 is unstable and only available for nightly builds of rustc.

error: Could not compile `my-rust-program`.

To learn more, run the command again with --verbose.

I know this issue has been raised already a couple of times (#16, #36, even by me). But with latest stable 1.31 release and 2018 edition landing, the clippy and rustfmt components are part of stable toolchain (so no versions mess). Maybe they worth to be included into rust image by default as are widely used in comparing to other rustup components?

The current situation with CI is relatively OK:

fmt:rust:
  stage: test
  dependencies: []
  image: rust:1.31
  services: []
  before_script:
    - rustup component add rustfmt
  script:
    - cargo fmt --check

But is trickier when it comes to CLI Docker usage:

docker run --rm -v "$(pwd)":/app -w /app rust:1.31 cargo fmt

error: 'cargo-fmt' is not installed for the toolchain '1.31.0-x86_64-unknown-linux-gnu'
To install, run `rustup component add rustfmt`

Having them baked into the image already will make its usage smoother for almost any project.

Hey,

I've just ran into a separate issue when trying to set up CI for my little project (https://github.com/rust-lang/cargo/issues/7563). I wanted to try other alternatives on my Raspberry Pi 4, but I noticed that Alpine-based images are provided only for x64.

Would it be possible to add ARM platforms to the list as well?

As I explained in my answer to a StackOverflow question, currently one has to carefully mount all subdirectories of /usr/local/cargo that Cargo will use as cache during the crate build, to avoid redownloading the crates.io registry and the dependencies with every container run. This is troublesome also because some of these depend on the choice of the VCS that the dependencies use, and basically need trial-and-error to discover them all.

Bind-mounting the entire /usr/local/cargo is not currently possible, because the official images also install the toolchain binaries under it. It would be much more convenient if the binaries would be installed elsewhere where PATH inside the container would find them, and the whole /usr/local/cargo would be treated as a perishable cache directory (what with it being world-writable).

It is convenient to have the rustfmt already installed so we avoid getting it every time we build.

If agreed, I can prepare a pull request to include it.

My very simple cli program wont compile in the official rust image but will compile on mac. The official image shouldn't need tinkering to build.

to reproduce

build docker image from latest official image:

FROM rust:1.63
RUN apt-get update -y && apt-get install -y vim tmux htop nano gcc-multilib libgpgme-dev unixodbc unixodbc-dev
WORKDIR /
CMD ["sleep", "86400"]

cargo new test

use this cargo.toml:

[package]
name = "test"
version = "0.1.0"
edition = "2021"
author = "NA"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
crossterm = { version = "0.19", features = [ "serde" ] }
serde = {version = "1.0", features = ["derive"] }
serde_json = "1.0"
chrono = { version = "0.4", features = ["serde"] }
rand = { version = "0.7.3", default-features = false, features = ["std"] }
tui = { version = "0.14", default-features = false, features = ['crossterm', 'serde'] }
thiserror = "1.0"
clipboard = "0.5.0"
itertools = "0.10.3"

cargo build --release or cargo run

result:

error: linking withccfailed: exit status: 1

note: /usr/bin/ld: cannot find -lxcb-shape
          /usr/bin/ld: cannot find -lxcb-xfixes

Note: have tried also installing gcc-multilib libgpgme-dev unixodbc unixodbc-dev to no effect and running RUSTFLAGS='-L /db2-query/clidriver/lib' cargo build --release

to no effect.

I am basing my dockerfile on the rust base image. When deploying my image to an azure container, I receive this log: ./bot: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./bot)

./bot is my application. The error also occurs when I perform docker run on my Linux Mint desktop.

How can I get GLIBC into my container?

I'm getting the following error when trying to build docker image:

  Installing myapp v0.1.0 (file:///usr/src/myapp)
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading sqlite v0.23.9
error: failed to compile `myapp v0.1.0 (file:///usr/src/myapp)`, intermediate artifacts can be found at `/usr/src/myapp/target`

Caused by:
  unable to get packages from source

Caused by:
  [60] Peer certificate cannot be authenticated with given CA certificates (SSL certificate problem: unable to get local issuer certificate)
The command '/bin/sh -c cargo install' returned a non-zero code: 101

Here is my dockerfile:

FROM rust:1.24.0

WORKDIR /usr/src/myapp
COPY myapp/ .

RUN cargo install

CMD ["myapp"]

Trying to build 3rd party project with rust:1.20-stretch gives this error:

error: override toolchain 'stable' is not installed

info: caused by: the toolchain file at '/build/rust-toolchain' specifies an uninstalled toolchain

Is it possible to ship the stable toolchain with those images?

The apt-get update call fails with an signature error.

W: GPG error: http://deb.debian.org/debian bullseye InRelease: At least one invalid signature was encountered.
E: The repository 'http://deb.debian.org/debian bullseye InRelease' is not signed.
W: GPG error: http://deb.debian.org/debian-security bullseye-security InRelease: At least one invalid signature was encountered.
E: The repository 'http://deb.debian.org/debian-security bullseye-security InRelease' is not signed.
W: GPG error: http://deb.debian.org/debian bullseye-updates InRelease: At least one invalid signature was encountered.
E: The repository 'http://deb.debian.org/debian bullseye-updates InRelease' is not signed.
The command '/bin/sh -c apt-get update && apt-get install -y pkg-config libssl-dev build-essential cmake' returned a non-zero code: 100

Adds a tools version of the containers, that adds the following rust components: rustfmt, clippy and llvm-tools-preview. More rust components could be added. But this seams to me the most applicable set for CI.

Al lot of firsts in this pull-request so let me know if I need to change something.

Solves issue: #97

The description for the nightly images (i.e. rustlang/rust:nightly) from Docker Hub says:

This image has two tags, nightly and nightly-slim, which are updated every day to match the current Rust nightly. The nightly tag is configured identically to that of the latest tag of the official image, except that the nightly toolchain is selected via rustup. The nightly-slim tag is configured identically to that of the slim tag of the official image, except that the nightly toolchain is selected via rustup.

However, this is not correct. The official images are created using --profile minimal (which significantly reduces the image size). The --default-host is also set, but this has little practical difference as only one toolchain is installed.

The nightly images should either use --profile minimal to match the official builds, or the description text should be updated to indicate this difference.

What is the status of the rust:1.64-alpine3.15 regarding to the Openssl 3.0.0 - 3.0.6 vulnerabillity?

New version of alpine 3.15.1 was released. https://alpinelinux.org/posts/Alpine-3.15.1-released.html

https://www.openssl.org/news/secadv/20221101.txt

Hi

I've tried several flavours of container, the official rust container (latest stable), alpine and ubuntu 18. Im mounting an EFS volume inside the container im running notify in using Amazon EKS kubernetes 1.20

If i exec into the container seperately i can get an event when i add a file (or do anything as normal) into the mounted volume from inside the container, but if i try to add a file to the mounted volume from another machine which has the volume mounted i get no event.

This also doesnt work if i exec into a different container with the same mount.

Does anyone know why this is the case / what i can do to try and fix it? i need to watch the contents of EFS for files that are uploaded using sftp.

Thanks

│ libarchive13 │ CVE-2022-26280 │ CRITICAL │ 3.4.3-2+deb11u1 │ │ libarchive: an out-of-bounds read via the component │ │ │ │ │ │ │ zipx_lzma_alone_init │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2022-26280

───────────────────────────────────────────────┤ │ libdb5.3 │ CVE-2019-8457 │ CRITICAL │ 5.3.28+dfsg1-0.8 │ │ sqlite: heap out-of-bound read in function rtreenode() │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2019-8457 │