Skip to content

Conversation

@tfoote
Copy link
Contributor

@tfoote tfoote commented Jun 3, 2025

This embeds everything at template generation time instead of at build time.

As per the discussion in docker-library/official-images#19162

The template genration is failing on Noetic right now due to the Noetic EOL logic. I don't think that the new index is updated on snapshots for it yet.

I'm going to look at if #116 will fix that if merged into this.

@tfoote
Copy link
Contributor Author

tfoote commented Jun 3, 2025

This is validated and passing on test build osrf/docker_images#809

I'm going to merge this to get the non-noetic builds working as they're the ones that aren't EOL. Noetic will likely start working again with #116 and Noetic being successfully snapshotted.

@mikaelarguedas @ruffsl a post review would be appreciated.

Copy link
Contributor

@mikaelarguedas mikaelarguedas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice,

noticed 1 bug for EOL distros, its addressed in #116

source_suffix = 'testing'
repo_url = f'http://packages.ros.org/ros{apt_suffix}/ubuntu'

# Get the latest tag
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be in the else block as apt_suffix variable doesnt exist in the if branch

tag_name = r.json().get('tag_name')

# Get the latest version and compute the checksum
fetch_url = f"https://github.com/ros-infrastructure/ros-apt-source/releases/download/{tag_name}/ros{apt_suffix}-apt-source_{tag_name}.{os_code_name}_all.deb"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this fundamentally solve the issue raised in docker-library/official-images#19162 (comment) (ie: should the hash not have been generated during the build of the .deb / should the hash from the build output be used)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The package is fetched over a TLS connection and hashed. Even if the hash was precomputed and posted somewhere, we'd still be fetching that over something like https as well, so chain of trust still inherently hinges upon the installed ca-certificates ( and integrity of the CI runtime of course).

In truth, this really only helps alleviate the library's build farm from having to interact with GitHub's public API endpoint, which is severely rate limited.

Hardcoding the public key or fingerprint would be more foolproof, but the template was being expanding that already before via "trusted" CI runtime anyhow. But I guess it would still be more apparent if the fingerprint changed in the diff review process as apposed to an ever evolving checksum of a moving target file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants