Repository admins or members of the security manager role can now enable or disable private vulnerability reporting on respositories via REST API.
Learn more about private vulnerability reporting.
Repository admins or members of the security manager role can now enable or disable private vulnerability reporting on respositories via REST API.
Learn more about private vulnerability reporting.
Users with secret scanning enabled on their free public repositories will now receive alerts for any potential secrets exposed in an issue’s title, description, or comments, including historical revisions. Alerts can be viewed within the UI or the REST API.
New issues are being scanned starting today and existing issues will be scanned over the coming weeks. You can expect all public repositories to be fully scanned by September 1, 2023.
In 3.2.8, GitHub Desktop is shipping two great community contributions of highly requested features — “Check Out a Commit” and “Double Click to Open in Your External Editor”.
Alongside that, we have a nice addition to the clone dialog where you can quickly see if a repository has been archived, as well as many accessibility enhancements.
A big thanks to @kitswas for his work in adding the ability to check out a commit from the history tab, a much asked for feature.
We would also like to give a shout out to @digitalmaster with another highly requested feature add of being able to double click on a file to open it in your external editor, whether that is in the history or changes view.
Another great add with this release is being able to tell at a glance which repositories in your cloning dialog are archived and likely not suitable for cloning.
GitHub Desktop is actively working to improve accessibility in support of GitHub’s mission to be a home for all developers.
In so, we have the:
– addition of aria-label
and aria-expanded
attributes to the diff options button – #17062
– number of pull requests found after refreshing the list screen reader announced – #17031
– ability to open the context menu for the History view items via keyboard shortcuts – #17035
– ability to navigate the “Clone a Repository” dialog list by keyboard – #16977
– checkboxes in dialogs receiving initial keyboard focus in order not to skip content – #17014
– progress state of the pull, push, fetch button announced by screen readers – #16985
– inline errors being consistently announced by screen readers – #16850
– group title and position correctly announced by screen readers in repository and branch lists – #16968
– addition of an aria-label
attribute to the “pull, push, fetch” dropdown button for screen reader users – #16839
– aria role of alert applied to dialog error banners so they are announced by screen readers – #16809
– file statuses in the history view improved to be keyboard and screen reader accessible – #17192
– ability to open the file list context menu via the keyboard – #17143
– announcing of dialog titles and descriptions on macOS Ventura – #17148
– announcing of the “Overwrite Stash”, “Discard Stash”, “Delete Tag”, and “Delete Branch” confirmation dialogs as alert dialogs – #17197, #17166, #17210
– improvements of contrast in text to links – #17092
– tab panels in the branch dropdown announced by screen readers – #17172
– stash restore button description associated to the button via an aria-describedby
– #17204
– warnings in the rename branch dialog placed before the input for better discoverability – #17164
– errors and warnings in the “Create a New Repository” dialog are screen reader announced – #16993
Automatic updates will roll out progressively, or you can download the latest GitHub Desktop here.
Introducing support for multiple GitHub accounts within GitHub Mobile! Log in with your work and personal accounts to stay in touch with your projects, wherever they're happening.
To add multiple accounts to GitHub Mobile, either navigate to Profile > Settings > Accounts, or long-press on the Profile tab to get to the account switcher. See the number of unread notifications across each account, swap to another account, or sign in or out of accounts.
Receive push notifications for each account, with just the right amount of context to keep you focused on the work that matters. Keep your data separate between each account, ensuring the right accounts are active when viewing private content.
Download or update GitHub Mobile today from the Apple App Store or Google Play Store to get started.
Learn more about GitHub Mobile and share your feedback to help us improve.
We have released a new API for people who write custom CodeQL queries which make use of dataflow analysis. The new API offers additional flexibility, improvements that prevent common pitfalls with the old API, and improves query evaluation performance by 5%. Whether you’re writing CodeQL queries for personal interest, or are participating in the bounty programme to help us secure the world’s code: this post will help you move from the old API to the new one.
This API change is relevant only for users who write their own custom CodeQL queries. Code scanning users who use GitHub’s standard CodeQL query suites will not need to make any changes.
With the introduction of the new dataflow API, the old API will be deprecated. The old API will continue to work until December 2024; the CodeQL CLI will start emitting deprecation warnings in December 2023.
To demonstrate how to update CodeQL queries from the old to the new API, consider this example query which uses the soon-to-be-deprecated API:
class SensitiveLoggerConfiguration extends TaintTracking::Configuration {
SensitiveLoggerConfiguration() { this = "SensitiveLoggerConfiguration" } // 6: characteristic predicate with dummy string value (see below)
override predicate isSource(DataFlow::Node source) { source.asExpr() instanceof CredentialExpr }
override predicate isSink(DataFlow::Node sink) { sinkNode(sink, "log-injection") }
override predicate isSanitizer(DataFlow::Node sanitizer) {
sanitizer.asExpr() instanceof LiveLiteral or
sanitizer.getType() instanceof PrimitiveType or
sanitizer.getType() instanceof BoxedType or
sanitizer.getType() instanceof NumberType or
sanitizer.getType() instanceof TypeType
}
override predicate isSanitizerIn(DataFlow::Node node) { this.isSource(node) }
}
import DataFlow::PathGraph
from SensitiveLoggerConfiguration cfg, DataFlow::PathNode source, DataFlow::PathNode sink
where cfg.hasFlowPath(source, sink)
select sink.getNode(), source, sink, "This $@ is written to a log file.",
source.getNode(),
"potentially sensitive information"
To convert the query to the new API:
module
instead of a class
. A CodeQL module
does not extend
anything, it instead implements
a signature. For both data flow and taint tracking configurations this is DataFlow::ConfigSig
or DataFlow::StateConfigSig
if FlowState
is needed.DataFlow::Configuration
or TaintTracking::Configuration
. Instead, now you define your data or taint flow by instantiating either the DataFlow::Global<..>
or TaintTracking::Global<..>
parameterized modules with your implementation of the shared signature and this is where the choice between data flow and taint tracking is made.override
anything, because you are defining a module.isBarrier
and it applies to both taint tracking and data flow configurations. You must use isBarrier
instead of isSanitizer
and isBarrierIn
instead of isSanitizerIn
.isAdditionalTaintStep
you use isAdditionalFlowStep
.DataFlow::PathGraph
. Instead, the PathGraph
will be imported directly from the module you are using. For example, SensitiveLoggerFlow::PathGraph
in the updated version of the example query below.PathNode
type from the resulting module and not from DataFlow
.from
and where
clauses. Instead of using e.g. cfg.hasFlowPath
or cfg.hasFlow
from a configuration object cfg
, you’ll use flowPath
or flow
from the module you’re working with.Taking all of the above changes into account, here’s what the updated query looks like:
module SensitiveLoggerConfig implements DataFlow::ConfigSig { // 1: module always implements DataFlow::ConfigSig or DataFlow::StateConfigSig
predicate isSource(DataFlow::Node source) { source.asExpr() instanceof CredentialExpr } // 3: no need to specify 'override'
predicate isSink(DataFlow::Node sink) { sinkNode(sink, "log-injection") }
predicate isBarrier(DataFlow::Node sanitizer) { // 4: 'isBarrier' replaces 'isSanitizer'
sanitizer.asExpr() instanceof LiveLiteral or
sanitizer.getType() instanceof PrimitiveType or
sanitizer.getType() instanceof BoxedType or
sanitizer.getType() instanceof NumberType or
sanitizer.getType() instanceof TypeType
}
predicate isBarrierIn(DataFlow::Node node) { isSource(node) } // 4: isBarrierIn instead of isSanitizerIn
}
module SensitiveLoggerFlow = TaintTracking::Global<SensitiveLoggerConfig>; // 2: TaintTracking selected
import SensitiveLoggerFlow::PathGraph // 7: the PathGraph specific to the module you are using
from SensitiveLoggerFlow::PathNode source, SensitiveLoggerFlow::PathNode sink // 8 & 9: using the module directly
where SensitiveLoggerFlow::flowPath(source, sink) // 9: using the flowPath from the module
select sink.getNode(), source, sink, "This $@ is written to a log file.", source.getNode(),
"potentially sensitive information"
While not covered in this example, you can also implement the DataFlow::StateConfigSig
signature if flow-state is needed. You then instantiate DataFlow::GlobalWithState
or TaintTracking::GlobalWithState
with your implementation of that signature. Another change specific to flow-state is that instead of using DataFlow::FlowState
, you now define a FlowState class
as a member of the module. This is useful for using types other than string
as the state (e.g. integers, booleans). An example of this implementation can be found here.
This functionality is available with CodeQL version 2.13.0
. If you would like to get started with writing your own custom CodeQL queries, follow these instructions to get started with the CodeQL CLI and the VS Code extension.
Today's update brings the ability to set an allowlist for languages within the IntelliJ extension, quickly switch to an annual GitHub Copilot for Individuals plan, and the private preview of code referencing.
The previous disabledLanguages
configuration is replaced with a new, more flexible languageAllowList
configuration. This change allows enabling or disabling all languages at once using the *
wildcard.
The github-copilot.xml
file is located at
~/Library/Application Support/JetBrains/<IDE+VERSION>/options/github-copilot.xml
For example the path to github-copilot.xml
for IntelliJ
version 2022.3
is
~/Library/Application Support/JetBrains/IntelliJIdea2022.3/options/github-copilot.xml
<application>
<component name="github-copilot">
<languageAllowList>
<map>
<entry key="*" value="true" />
</map>
</languageAllowList>
</component>
</application>
You can now specify an individual language override if your configuration also includes a wildcard.
<application>
<component name="github-copilot">
<languageAllowList>
<map>
<entry key="*" value="false" />
<entry key="kotlin" value="true" />
<entry key="java" value="true" />
</map>
</languageAllowList>
</component>
</application>
A new hidden languageAllowListReadOnly
configuration property has been added that makes languageAllowList
readonly in the UI.
<application>
<component name="github-copilot">
<option name="languageAllowListReadOnly" value="true" />
<languageAllowList>
<map>
<entry key="*" value="true" />
</map>
</languageAllowList>
</component>
</application>
We've heard confusion from users on how to switch between monthly and annual billing. We want you to feel fully in control of your GitHub Copilot plan so we've updated the Plans and Usage
page to make it easier to swap between your plan options. Just head down to the Copilot plan section and hit the Manage subscription
button to see your options.
We've also added the option to activate your Copilot trial directly from this page and while we'd hate to see you go, if you find that Copilot isn't for you during your trial, you can quickly cancel it before it converts into a paid plan.
Last week, we announced our private beta for code referencing in Copilot. Learn more by heading to our blog post or join the waitlist today!
Join the conversation in the Copilot community discussion. We'd love to hear from you!
GitHub Advanced Security customers can now perform on-demand validity checks for supported partner patterns, and the alert index view now shows if a secret is active. This builds on our release of enabling automatic validation checks for supported partner patterns back in April.
When the “Automatically verify if a secret is valid” setting is enabled on a repository, users will see a “Verify secret” button on the alert page. This sends the secret to our relevant partner provider to see if the secret is active and updates the status on the alert and index pages.
As we work with our partners to add support for more secrets, we'll update the "Validity check" column in the documented supported secrets list.
If you are using the Dependabot grouped version updates feature (currently in public beta), you can now tell Dependabot to ignore updates in the group (similar to how you can do it for Dependabot's individual updates). While closing a grouped pull request will still not create ignore conditions, you can use Dependabot comment commands to tell Dependabot to ignore certain updates in the group – either a specific minor update, a specific major update, or all updates for one dependency.
On a grouped pull request, you can now also tell Dependabot to stop ignoring certain updates that you have already ignored. By commenting @dependabot unignore
, you can specify either to stop ignoring a specific range of updates, all updates for a specific dependency, or all updates for every dependency in the group. Dependabot will now also list in the pull request body all the ignore conditions it used to build the pull request. Alternatively, you can comment @dependabot show <dependency-name> ignore conditions
and Dependabot will list the ignore conditions for that dependency.
For more information on Dependabot ignore conditions and chat commands, please see the documentation.
If you are using the Dependabot grouped version updates feature (currently in public beta), you can now group your pull requests by dependency type in ecosystems that support this. Instead of listing all the dependencies by name or pattern for your groups, you can now also use the dependency-type
key (set to either "production" or "development") to create groups based on dependency type. Then, on your version updates schedule, Dependabot will try to open one pull request to update all available dependencies of that type.
For more information on how to use this feature, check out our documentation on configuring groups for Dependabot pull requests.
Today’s Changelog brings you the brand new slice by, updates to issue forms, and a group menu across layouts!
You can now slice by field values in your project views! Configuring a Slice by
field allows you to quickly toggle through and review your project items broken down by a field, saving you additional filters and views to quickly understand the state and details of your project. While you can slice by your issue and project fields to customize your view, some helpful slice by views include:
– Single select fields to view items broken up by status, priority, or team
– Labels
to group items by repository labels
– Assignees
to see who is working on what
Select a Slice by
field from the view configuration menu. This will pull the field values into the panel on the left, allowing you to click through the values in the list to adjust the items shown in the view.
See it in action on the GitHub public roadmap, and check out the documentation for more details.
You can now configure custom issue forms to automatically add an issue to a project as well as set defaults for drop downs by adding a YAML form definition file to the /.github/ISSUE_TEMPLATE
folder in your repository.
For more comprehensive instructions on syntax for issue forms, check out the documentation.
We’re looking to improve the experience around issue forms and templates. If you have any feedback 👉 drop a comment in our community discussion!
We’ve added a group menu to quickly take action on items in a group or on the group itself. Click ...
from the group header on your tables, boards, or roadmaps to archive or delete all items in a group, edit the group details directly, hide the group from the view, or delete it from your project.
Make a copy
from the project ...
menu@next
filter qualifier for iteration fields was referencing the incorrect iterationField sum
decimal precisionSee how to use GitHub for project planning with GitHub Issues, check out what’s on the roadmap, and learn more in the docs.
Questions or suggestions? Join the conversation in the community discussion.
A new header will be sent back to API callers that use the fine-grained permission model (GitHub Apps and fine-grained PATs) to help developers discover which permissions are needed to call an API route. This new header, x-accepted-github-permissions
, contains the list of permissions required to access the endpoint.
In the fine-grained permission model more than one permission may be needed to access an endpoint. Multiple sets of permissions may also be valid, since there are multiple ways to access data within GitHub. All valid sets are included in the header, each set separated by a semicolon (;
).
For example, when calling "List project collaborators", you'll recieve the header x-accepted-github-permissions: repository_projects=write; organization_projects=admin
. This indicates that to get the list of collaborators on a project, you need either the repository_projects
Write permission or the organization_projects
Admin permission.
This header is used in the same way as the x-accepted-oauth-scopes
header for coarse-grained scope actors (OAuth apps and PATs (Classic)).
To learn more about troubleshooting permissions issues with GitHub Apps and fine-grained PATs and to get more information about this header, see "Insufficient permission errors". To see the permissions needed for each endpoint, see "Permissions required for GitHub Apps" and "Permissions required for fine-grained PATs".
GitHub environments can be configured with deployment branch policies to allow-list the branches that can deploy to them.
We are now security hardening these branch policies further by blocking runs triggered from forks with branches that match the protected branch name. We are also preventing tags with the same name as a protected branch from deploying to the environments with branch policies around protected branches.
Learn more about configuring environments with deployment protection rules to set up rigorous and streamlined guardrails for your deployments.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.
As an organization owner or member of the security manager role, you can now use the repository security advisories REST API to get all repository security advisories across your organization.
Learn more about repository security advisories.
Secret scanning's push protection feature prevents supported secrets from being pushed into repositories, and has to date been enabled at the repository, organization, or enterprise level.
Now, everyone across GitHub can enable push protection for themselves within your individual settings. This ensures your pushes are protected whenever you push to a public repository on GitHub, without relying on that repository to have push protection enabled.
To opt in, go to the "Code security and analysis" section of your personal settings. Next to "Push protection for yourself", click Enable.
GitHub will enable push protection for all GitHub Free individuals by default in January, 2024.
The administrator account (ending in _admin
) of Enterprise Managed User enterprises is now required to enter sudo mode before taking sensitive actions. As with standard user accounts, the administrator must provide their password or a second factor credential to enter sudo mode.
Sudo mode is a GitHub security feature that validates the user's session before they perform a sensitive action, like creating a personal access token, deleting an organization, or updating their credentials.
Until now this mode was disabled for all Enterprise Managed Users (EMUs), as they had no credentials on GitHub.com and therefore could not provide one for the sudo mode prompt. As a result, EMU accounts are able to take sensitive actions without being asked for a credential. However, the admin for the EMU enterprise does have credentials on GitHub.com and will now be asked for them before taking sensitive actions.
For more information about sudo mode, see "Sudo mode". To learn more about Enterprise Managed Users, see "About Enterprise Managed Users".
GitHub Enterprise Server 3.10 gives customers more control over how their instance is used and run. Here are a few highlights:
If you are upgrading from Enterprise Server 3.8 then this release also includes an upgrade from MySQL 5.7 to 8, which will increase I/O utilization. Please read this page for more details on this increase and how to mitigate it if you see an unacceptable degradation of performance on your instance.
Release Candidates are a way for you to try the latest features at the earliest time, and they help us gather feedback early to ensure the release works in your environment. They should be tested on non-production environments. Here are some highlights for this release. Read more about the release candidate process.
Read more about GitHub Enterprise Server 3.10 in the release notes, or download the release candidate now. If you have any feedback or questions, please contact our Support team.
For security reasons, source IP addresses have been removed from error messages that are returned from the GitHub API when callers try to access protected resources from non-permitted IP addresses.
To learn more about IP allow lists, visit Restricting network traffic to your enterprise with an IP allow list in the GitHub documentation.
If you'd like to learn more about your source IP addresses, please contact GitHub Support.
The code scanning REST API updated_at
field has been improved to help you review your most recently changed alerts.
The updated_at
timestamp now returns the alert's most recent state change on the branch that you requested. We consider a state change to be a significant event, including an alert being introduced, fixed, dismissed, reopened or reintroduced. This is implemented in both the repo API and org API so it can be used consistently at scale.
Previously, the updated_at
timestamp changed whenever an alert was found in an analysis or the alert state changed, and so was updated very regularly. This improvement lets you efficiently use updated_at
to sort and focus on your most recently changed alerts.
The code scanning REST API list alerts endpoints code-scanning/alerts
returns the value for the default branch, unless another branch is specificed. The alert endpoint code-scanning/alerts/{alert_number}
reports at the alert level, so will return the maximum value for the alert across all branches.
This is now live on GitHub.com for the repository level API. This will be live for the organization level API over the next few days because it requires data reindexing. This will ship to GitHub Enterprise Server version 3.11. For more information, see the code scanning REST API documentation.
When you migrate to GitHub.com with GitHub Enterprise Importer, user activity (e.g. issues, pull requests, comments) is linked to placeholder identities called "mannequins".
After you've finished migrating, you can "reclaim" those mannequins, linking the migrated activity to users' GitHub.com accounts. As part of this process, users receive invitations, asking them to accept the mannequin attribution.
Now, organizations using Enterprise Managed Users (EMU) can reclaim mannequins immediately, skipping the invitation process. This can be done one-by-one, or in bulk using a CSV.
To use this new feature, you'll need to update to the new v1.0.0 version of the GitHub Enterprise Importer CLI, released today.
For more details, see "Reclaiming mannequins for GitHub Enterprise Importer" in the GitHub Docs.
We are excited to announce the alpha release of Copilot in GitHub Support, a faster way to find answers to your GitHub related questions! Copilot in GitHub Support is an AI-powered assistant that answers questions based on our official GitHub Enterprise Cloud documentation.
Initially, we’re offering the Copilot experience to a limited number of randomly selected GitHub Enterprise Cloud customers. We hope to continue rolling out the experience to a wider audience over the coming months.
If your ticket is selected, you’ll be provided with an option to opt-in while creating your support ticket. During the alpha, GitHub will be reviewing answers provided and collecting feedback from participating customers to improve the accuracy.
Copilot in GitHub Support is part of our ongoing effort to make GitHub the best place for all developers to collaborate, innovate, and ship great software. We believe that Copilot in GitHub Support will enhance your experience and productivity.
We look forward to hearing from you and learning from your feedback.