Recent improvements to Artifact Attestations

We released a collection of improvements to Artifact Attestations to make the verification of attestations easier and more consistent.

Artifact Attestations let you create provenance signatures, which provide an unforgeable paper trail that links your artifact back to its originating workflow run. By verifying the signature, you can gate deployments to ensure that what you deploy is exactly what you built, guaranteeing that the artifact has not been tampered with.

Today we are announcing multiple improvements based on the user feedback we have received:

  • Attestation verification defaults to build provenance: Build provenance is just one type of information that can be attested to an artifact. It provides a verifiable trail that links the artifact back to its originating workflow run, ensuring its authenticity and integrity. However, other types of information can also be attested to an artifact, for example a Software Bill of Materials (SBOM). Attestations can be verified by running gh attestation verify using the GitHub CLI. Previously, verification succeeded as soon as there was any attestation associated with the artifact. However, we observed that provenance is verified in the vast majority of cases. Therefore, we altered the CLI to default to provenance when no predicate type is specified. This change ensures that verification does not pass merely because, for example, an SBOM was attested to the artifact. To verify an SBOM, the predicate type must be explicitly supplied as a parameter using gh attestation verify with the --predicate-type parameter.
  • CLI outputs evaluated policies during verification: When verifying an attestation, the CLI now outputs all the policies it evaluated to determine whether the verification succeeds or fails. This increases transparency, making it easier to understand the reasons behind the verification outcome.
  • Attest actions support multiple subjects: Following the release to support attesting multiple subjects, we have enhanced our attest, attest-build-provenance and attest-sbom actions to also accept a checksum file that contains a list of artifacts and their corresponding digests as input.
  • Attestation verification is now monotonic: This means that once verification passes for an artifact, the addition of another attestation cannot change that status. Verification now succeeds if at least one attestation passes verification. This ensures that downstream processes, such as gated deployments, are not affected for any legitimate build that has a valid provenance attestation, even if someone adds another attestation that is bad or malformed.

For more information about Artifact Attestations, see Using artifact attestations to establish provenance for builds in the GitHub documentation. If you have any feedback on Artifact Attestations, join the discussion in the GitHub Community.

New GPT-4o Copilot code completion model available now in public preview for Copilot in VS Code

Header introducing GPT-4o Copilot model

A new code completion model, GPT-4o Copilot, can now be enabled by VS Code users.

This new model based on GPT-4o mini has additional training on over 275,000 high-quality public repositories in over 30 popular programming languages. As a result, you can expect this model to provide more accurate suggestions and to have better performance.

Getting started with GPT-4o Copilot in VS Code

To get started, open the Copilot menu in the VS Code title bar, select Configure Code Completions... > Change Completions Model.... Alternatively, open the Command Palette and select GitHub Copilot: Change Completions Model....

GPT-4o Copilot access notes

If you are a Copilot Business or Enterprise user, you will first need your administrator to enable this model for your organization by opting in to Editor preview features in the Copilot policy settings on github.com.

If you are a Copilot Free user, using this model will count toward your 2,000 free monthly completions.

The model will also be available soon to Copilot users in all JetBrains IDEs.

Please share your feedback as you try out the new model. It will help us improve the experience for all Copilot users.

See more

GitHub Issues & Projects – February 18th update

Today’s changelog brings you a snappier issue creation flow in projects, the ability to convert checklist items to sub-issues, required fields on private repositories, and important updates on tasklist blocks and single issue templates.

✍️ Improved issue creation flow in projects

Creating a new issue from a project is now easier than ever. Previously, when you started typing in an issue title in a project, the default was to create a draft issue. However, we’ve heard from user feedback that the primary
desired use case is to create an issue instead of a draft. Now, with this update, you can directly create a new issue by pressing Enter or create a draft with Cmd / Ctrl + Enter.

🔒 Required fields on issue forms for private repositories

You can now specify required fields on issue forms in private repositories, which ensures that contributors provide essential information before submitting an issue.

➡️ Convert checklist items to sub-issues

You can now convert checklist items in issues directly to sub-issues, making it easier to turn draft or to-do tasks into actionable work items.

🌇 Tasklist blocks will be retired and replaced with sub-issues

The private preview feature, tasklist blocks, will be retired on April 30, 2025. Your feedback from the private preview has been invaluable, helping us shape the release of sub-issues, the replacement for tasklist blocks.

Sub-issues provide a dedicated section within each issue, making it easier to track related work without relying on Markdown. You can manage up to eight levels of hierarchy within a single issue and monitor progress directly in your projects.

Migrate to sub-issues

We recommend migrating your tasklists to sub-issues before the retirement date.

To migrate, first simply remove the tasklist Markdown syntax to display the list as an issue checklist.

- ```[tasklist]
- - [ ] task 1
- - [ ] https://github.com/github/github/issues/123
- ```
+ - [ ] task 1
+ - [ ] https://github.com/github/github/issues/123

Then, use the Convert to sub-issue feature to convert desired issues or checklist items into sub-issues.

After April 30, 2025, remaining tasklist blocks will no longer be rendered and will instead be converted to raw Markdown. The Tracked and Tracked by fields on projects will no longer be available.

🌅 Single issue templates (ISSUE_TEMPLATE.md) will be retired

The legacy ISSUE_TEMPLATE.md feature will be retired on March 30, 2025. As a replacement, we encourage creating an ISSUE_TEMPLATE/ subdirectory in any of the supported folders to store multiple issue templates. You can then use the template query parameter to specify which template should populate the issue body. For more details, see the documentation.

After March 30, 2025, repositories still using ISSUE_TEMPLATE.md will default to a blank issue form, allowing users to start fresh when creating issues.

✨ Additional improvements

On top of the many bug fixes we’ve shipped, we’ve also introduced the following improvements:

  • You can now create new milestones directly from the milestone picker in any issue.
  • The issue template selection will now be bypassed if only one template is available and the blank issue template is disabled.
  • You can now create and edit iteration fields via the ProjectV2 GraphQL API.
  • We’ve introduced a move dialog in Projects, allowing you to rearrange items and views with precision. You can move views from a tab’s view options menu, while items can be moved through the row actions menu. This allows users who rely on screen readers, keyboards, and other assistive technology to use projects more accessibly.

✍ Tell us what you think!

Join the discussion within the GitHub Community.

See how to use GitHub for project planning with GitHub Issues, check out what’s on the roadmap, and learn more in the documentation.

See more
View all changes