From f5352ba3a5676377b766bb415c7cc209c681012a Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Wed, 16 Oct 2024 15:14:36 +0000 Subject: [PATCH 01/14] content: draft: Harden 'safe-expunging-process' fixes #1135 Hardens the 'safe-expunging-process' by: 1. Suggesting that SCSs should document and log changes when possible. 2. SCSs should use multi-party approval when possible Also clarifies that some of these changes may need to be kept private to comply with local laws. Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 406ebd840..5fbfb16f8 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -46,37 +46,46 @@ Consumers can examine the various source provenance attestations to determine if ## Safe Expunging Process -Administrators have the ability to expunge (remove) content from a repository and its change history without leaving a record of the removed content. -This includes changing files, history, or changing references in git and is used to accommodate legal or privacy compliance requirements. +SCSs MAY allow _administrators_ to expunge (remove) content from a repository and its change history without leaving a public record of the removed content. +This includes changing files, history, or changing references in git and is used to accommodate legal/privacy compliance requirements as well as administrative +changes within a repository (see below for more information on the various scenarios). When used as an attack, this is called “repo hijacking” (or “repo-jacking”) and is one of the primary threats source provenance attestations protect against. +As such great care must be taken by SCSs when implementing these changes for legitimate purposes. + +SCSs SHOULD require multi-party approval for any changes made under this process. + +The Safe Expunging Process MUST be documented and describe how requests and actions are tracked and SHOULD log the fact that content was removed. On the git VCS, force pushes allow you to remove data from a branch. If a branch has been identified as consumable branch, force pushes to that branch must follow the safe expunging process. -TODO: Determine how organizations can provide transparency around this process. -At a minimum the organization would need to declare why data was removed from the branch. - -The goal of this sections is to document that this process is allowed. Different organizations and tech stacks may have different approaches to the problem. -Scenarios that need to be addressed: +Safe Expunging Scenarios: ### Legal Takedowns -A DMCA takedown request will be addressed by following an agreed-upon process. +A legal takedown request will be addressed by following an agreed-upon process. That process should be documented itself and followed. It may be the case that the specific set of commits targeted by the takedown can be expunged in ways that do not impact revisions. +This process and the resulting logs MAY be private to both prevent calling attention to potentially sensitive data (e.g. PII) or to comply with local laws +and regulations which may require the change to be kept private to the extent possible. + ### Commit metadata rewrites A team may decide that all reachable commits in the history of a revision need to follow a new metadata convention. In git VCS, compliance with this new policy will require history to be rewritten (commit metadata is included in the computation of the revision id). Policies in this category include things like commit signatures, author / committer formatting restrictions, closed-issue-linkage, etc. +SCSs SHOULD make the fact of these changes public when they occur (e.g. an issue, announcement, or other mechanism). + ### Repository renames When a repo is transferred to a new organization ("donated"), or if a repo must be renamed or otherwise have its url changed within the same org, attestations for previous revisions of this repo will no longer be matched because the combination of the repository id and the revision id will have changed. +SCSs SHOULD make the fact of these changes public when they occur (e.g. an issue, announcement, or other mechanism). + ## Levels ### Level 1: Version controlled From 690fd9bc9c3d83864b1e96107fdc56d07eea34a5 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Thu, 17 Oct 2024 20:49:00 +0000 Subject: [PATCH 02/14] strengthen requirement for non-legal changes Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 5fbfb16f8..a64d6168f 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -61,7 +61,7 @@ If a branch has been identified as consumable branch, force pushes to that branc Different organizations and tech stacks may have different approaches to the problem. -Safe Expunging Scenarios: +Safe Expunging Scenarios (non-exhaustive): ### Legal Takedowns @@ -78,13 +78,13 @@ A team may decide that all reachable commits in the history of a revision need t In git VCS, compliance with this new policy will require history to be rewritten (commit metadata is included in the computation of the revision id). Policies in this category include things like commit signatures, author / committer formatting restrictions, closed-issue-linkage, etc. -SCSs SHOULD make the fact of these changes public when they occur (e.g. an issue, announcement, or other mechanism). +Organizations MUST make the fact of these changes public when they occur (e.g. an issue, announcement, or other mechanism). ### Repository renames When a repo is transferred to a new organization ("donated"), or if a repo must be renamed or otherwise have its url changed within the same org, attestations for previous revisions of this repo will no longer be matched because the combination of the repository id and the revision id will have changed. -SCSs SHOULD make the fact of these changes public when they occur (e.g. an issue, announcement, or other mechanism). +Organizations MUST make the fact of these changes public when they occur (e.g. an issue, announcement, or other mechanism). ## Levels From 72dc8ef3842ba6675f8cef14b510348ae013d897 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Fri, 18 Oct 2024 09:52:57 -0400 Subject: [PATCH 03/14] Update docs/spec/draft/source-requirements.md Co-authored-by: Zachariah Cox Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index a64d6168f..461f8609b 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -84,7 +84,8 @@ Organizations MUST make the fact of these changes public when they occur (e.g. a When a repo is transferred to a new organization ("donated"), or if a repo must be renamed or otherwise have its url changed within the same org, attestations for previous revisions of this repo will no longer be matched because the combination of the repository id and the revision id will have changed. -Organizations MUST make the fact of these changes public when they occur (e.g. an issue, announcement, or other mechanism). +Organizations MUST inform all consumers of a repo of these changes when they occur. +Organizations SHOULD provide a means to resolve previous revision IDs to the new revision IDs. ## Levels From 3e446a5e4caa294ceb761f0b427d3a4f83838bc7 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Fri, 18 Oct 2024 09:53:57 -0400 Subject: [PATCH 04/14] Update docs/spec/draft/source-requirements.md Co-authored-by: Zachariah Cox Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 461f8609b..86a16a599 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -46,7 +46,7 @@ Consumers can examine the various source provenance attestations to determine if ## Safe Expunging Process -SCSs MAY allow _administrators_ to expunge (remove) content from a repository and its change history without leaving a public record of the removed content. +SCSs MAY allow the organization to expunge (remove) content from a repository and its change history without leaving a public record of the removed content. This includes changing files, history, or changing references in git and is used to accommodate legal/privacy compliance requirements as well as administrative changes within a repository (see below for more information on the various scenarios). When used as an attack, this is called “repo hijacking” (or “repo-jacking”) and is one of the primary threats source provenance attestations protect against. From a8832cb695f5e2c044eacfce62cc1e11e37de438 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Wed, 23 Oct 2024 17:25:23 +0000 Subject: [PATCH 05/14] limit expunging to legal requests Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 31 +++++++++----------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 86a16a599..d5c55a5be 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -47,8 +47,12 @@ Consumers can examine the various source provenance attestations to determine if ## Safe Expunging Process SCSs MAY allow the organization to expunge (remove) content from a repository and its change history without leaving a public record of the removed content. -This includes changing files, history, or changing references in git and is used to accommodate legal/privacy compliance requirements as well as administrative -changes within a repository (see below for more information on the various scenarios). +This includes changing files, history, or changing references in git and is used to accommodate legal/privacy compliance requirements. + +Removing a revision from a repository is similar to deleting a package version from a registry: it's almost impossible to estimate the amount of downstream supply chain impact. +In version control systems like git, removal of a revision changes the object id of all subsequent revisions that were built on top of it. +Although there is no "safe" way to do it, it sometimes necessary and there are steps you can take to mitigate the damage. + When used as an attack, this is called “repo hijacking” (or “repo-jacking”) and is one of the primary threats source provenance attestations protect against. As such great care must be taken by SCSs when implementing these changes for legitimate purposes. @@ -61,32 +65,19 @@ If a branch has been identified as consumable branch, force pushes to that branc Different organizations and tech stacks may have different approaches to the problem. -Safe Expunging Scenarios (non-exhaustive): +Safe Expunging Scenarios: ### Legal Takedowns -A legal takedown request will be addressed by following an agreed-upon process. -That process should be documented itself and followed. +The only currently acceptable scenario to expunge data is in response to some legal or compliance request. + +The takedown request MUST be addressed by following an agreed-upon process. + It may be the case that the specific set of commits targeted by the takedown can be expunged in ways that do not impact revisions. This process and the resulting logs MAY be private to both prevent calling attention to potentially sensitive data (e.g. PII) or to comply with local laws and regulations which may require the change to be kept private to the extent possible. -### Commit metadata rewrites - -A team may decide that all reachable commits in the history of a revision need to follow a new metadata convention. -In git VCS, compliance with this new policy will require history to be rewritten (commit metadata is included in the computation of the revision id). -Policies in this category include things like commit signatures, author / committer formatting restrictions, closed-issue-linkage, etc. - -Organizations MUST make the fact of these changes public when they occur (e.g. an issue, announcement, or other mechanism). - -### Repository renames - -When a repo is transferred to a new organization ("donated"), or if a repo must be renamed or otherwise have its url changed within the same org, attestations for previous revisions of this repo will no longer be matched because the combination of the repository id and the revision id will have changed. - -Organizations MUST inform all consumers of a repo of these changes when they occur. -Organizations SHOULD provide a means to resolve previous revision IDs to the new revision IDs. - ## Levels ### Level 1: Version controlled From 15a645d4d338c65216da2a28b8c952d5990ec8f6 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Wed, 23 Oct 2024 17:29:12 +0000 Subject: [PATCH 06/14] make linter happy Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index d5c55a5be..56d1e880a 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -49,8 +49,8 @@ Consumers can examine the various source provenance attestations to determine if SCSs MAY allow the organization to expunge (remove) content from a repository and its change history without leaving a public record of the removed content. This includes changing files, history, or changing references in git and is used to accommodate legal/privacy compliance requirements. -Removing a revision from a repository is similar to deleting a package version from a registry: it's almost impossible to estimate the amount of downstream supply chain impact. -In version control systems like git, removal of a revision changes the object id of all subsequent revisions that were built on top of it. +Removing a revision from a repository is similar to deleting a package version from a registry: it's almost impossible to estimate the amount of downstream supply chain impact. +In version control systems like git, removal of a revision changes the object id of all subsequent revisions that were built on top of it. Although there is no "safe" way to do it, it sometimes necessary and there are steps you can take to mitigate the damage. When used as an attack, this is called “repo hijacking” (or “repo-jacking”) and is one of the primary threats source provenance attestations protect against. From c9c561470950c4c3a15c1b363951eed83bb325b1 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Thu, 24 Oct 2024 13:05:44 -0400 Subject: [PATCH 07/14] Update docs/spec/draft/source-requirements.md Co-authored-by: Aditya Sirish <8928778+adityasaky@users.noreply.github.com> Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 56d1e880a..7fa6f6652 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -50,7 +50,7 @@ SCSs MAY allow the organization to expunge (remove) content from a repository an This includes changing files, history, or changing references in git and is used to accommodate legal/privacy compliance requirements. Removing a revision from a repository is similar to deleting a package version from a registry: it's almost impossible to estimate the amount of downstream supply chain impact. -In version control systems like git, removal of a revision changes the object id of all subsequent revisions that were built on top of it. +In version control systems like Git, removal of a revision changes the object IDs of all subsequent revisions that were built on top of it. Although there is no "safe" way to do it, it sometimes necessary and there are steps you can take to mitigate the damage. When used as an attack, this is called “repo hijacking” (or “repo-jacking”) and is one of the primary threats source provenance attestations protect against. From 5b63aac8093104a296149684dbb2328e65530b06 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Thu, 24 Oct 2024 13:13:58 -0400 Subject: [PATCH 08/14] Update docs/spec/draft/source-requirements.md Co-authored-by: Aditya Sirish <8928778+adityasaky@users.noreply.github.com> Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 7fa6f6652..2308e40ac 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -75,7 +75,7 @@ The takedown request MUST be addressed by following an agreed-upon process. It may be the case that the specific set of commits targeted by the takedown can be expunged in ways that do not impact revisions. -This process and the resulting logs MAY be private to both prevent calling attention to potentially sensitive data (e.g. PII) or to comply with local laws +The application of the safe expunging process and the resulting logs MAY be private to both prevent calling attention to potentially sensitive data (e.g. PII) or to comply with local laws and regulations which may require the change to be kept private to the extent possible. ## Levels From 240c95b74550319a91d700ee8ed163894ac553a6 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Thu, 24 Oct 2024 17:35:20 +0000 Subject: [PATCH 09/14] simplify wording of process Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 34 +++++++++++--------------- 1 file changed, 14 insertions(+), 20 deletions(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 2308e40ac..8dcd585ff 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -46,37 +46,31 @@ Consumers can examine the various source provenance attestations to determine if ## Safe Expunging Process -SCSs MAY allow the organization to expunge (remove) content from a repository and its change history without leaving a public record of the removed content. -This includes changing files, history, or changing references in git and is used to accommodate legal/privacy compliance requirements. +SCSs MAY allow the organization to expunge (remove) content from a repository and its change history without leaving a public record of the removed content, +but MUST only allow these changes in order to meet legal or privacy compliance requirements. +Content changed under this process includes changing files, history, references, or any other metadata stored by the SCS. -Removing a revision from a repository is similar to deleting a package version from a registry: it's almost impossible to estimate the amount of downstream supply chain impact. -In version control systems like Git, removal of a revision changes the object IDs of all subsequent revisions that were built on top of it. -Although there is no "safe" way to do it, it sometimes necessary and there are steps you can take to mitigate the damage. +### Warning -When used as an attack, this is called “repo hijacking” (or “repo-jacking”) and is one of the primary threats source provenance attestations protect against. -As such great care must be taken by SCSs when implementing these changes for legitimate purposes. +Removing a revision from a repository is similar to deleting a package version from a registry: it's almost impossible to estimate the amount of downstream supply chain impact. +For example, in VCSs like Git, removal of a revision changes the object IDs of all subsequent revisions that were built on top of it, +this can break downstream consumers ability to refer to source they've already integrated into their products. -SCSs SHOULD require multi-party approval for any changes made under this process. +It may be the case that the specific set of commits targeted by the takedown can be expunged in ways that do not impact revisions which can mitigate these problems. -The Safe Expunging Process MUST be documented and describe how requests and actions are tracked and SHOULD log the fact that content was removed. +It is also the case that removing content from a repository won't necessarily remove it everywhere. +The content may still exist in other copies of the repository, either in backups or on developer machines. -On the git VCS, force pushes allow you to remove data from a branch. -If a branch has been identified as consumable branch, force pushes to that branch must follow the safe expunging process. +### Process +An SCS MUST document the Safe Expunging Process and describe how requests and actions are tracked and SHOULD log the fact that content was removed. Different organizations and tech stacks may have different approaches to the problem. -Safe Expunging Scenarios: - -### Legal Takedowns - -The only currently acceptable scenario to expunge data is in response to some legal or compliance request. - -The takedown request MUST be addressed by following an agreed-upon process. - -It may be the case that the specific set of commits targeted by the takedown can be expunged in ways that do not impact revisions. +SCSs SHOULD require multi-party approval for any changes made under this process. The application of the safe expunging process and the resulting logs MAY be private to both prevent calling attention to potentially sensitive data (e.g. PII) or to comply with local laws and regulations which may require the change to be kept private to the extent possible. +Organizations SHOULD prefer to make logs public if possible. ## Levels From a3ff7420fbacad4574f4e57ae0c733cf0a7af771 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Thu, 24 Oct 2024 13:54:14 -0400 Subject: [PATCH 10/14] Update docs/spec/draft/source-requirements.md Co-authored-by: Aditya Sirish <8928778+adityasaky@users.noreply.github.com> Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 8dcd585ff..c17ebfe36 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -56,7 +56,7 @@ Removing a revision from a repository is similar to deleting a package version f For example, in VCSs like Git, removal of a revision changes the object IDs of all subsequent revisions that were built on top of it, this can break downstream consumers ability to refer to source they've already integrated into their products. -It may be the case that the specific set of commits targeted by the takedown can be expunged in ways that do not impact revisions which can mitigate these problems. +It may be the case that the specific set of changes targeted by the takedown can be expunged in ways that do not impact consumed revisions, which can mitigate these problems. It is also the case that removing content from a repository won't necessarily remove it everywhere. The content may still exist in other copies of the repository, either in backups or on developer machines. From 5af39ffb59b1a4f8fdc01e7f31c244cbe8d3b6fa Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Thu, 24 Oct 2024 16:56:05 -0400 Subject: [PATCH 11/14] Update docs/spec/draft/source-requirements.md Co-authored-by: Aditya Sirish <8928778+adityasaky@users.noreply.github.com> Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index c17ebfe36..c7a9662f9 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -54,7 +54,7 @@ Content changed under this process includes changing files, history, references, Removing a revision from a repository is similar to deleting a package version from a registry: it's almost impossible to estimate the amount of downstream supply chain impact. For example, in VCSs like Git, removal of a revision changes the object IDs of all subsequent revisions that were built on top of it, -this can break downstream consumers ability to refer to source they've already integrated into their products. +, breaking downstream consumers' ability to refer to source they've already integrated into their products. It may be the case that the specific set of changes targeted by the takedown can be expunged in ways that do not impact consumed revisions, which can mitigate these problems. From 919988240bd64d21af55d2e977d21646bbda31cf Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Thu, 24 Oct 2024 21:30:09 +0000 Subject: [PATCH 12/14] multi-party clarification Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 8dcd585ff..7d28fb30e 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -66,7 +66,7 @@ The content may still exist in other copies of the repository, either in backups An SCS MUST document the Safe Expunging Process and describe how requests and actions are tracked and SHOULD log the fact that content was removed. Different organizations and tech stacks may have different approaches to the problem. -SCSs SHOULD require multi-party approval for any changes made under this process. +SCSs SHOULD have technical mechanisms in place which require multiple Trusted Persons to trigger any expunging (removals) made under this process. The application of the safe expunging process and the resulting logs MAY be private to both prevent calling attention to potentially sensitive data (e.g. PII) or to comply with local laws and regulations which may require the change to be kept private to the extent possible. From 075d7682b537adf8c56898875089d1d0e9c239bc Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Thu, 24 Oct 2024 21:32:31 +0000 Subject: [PATCH 13/14] multi-party clarification Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index aba97958a..efa978e61 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -66,7 +66,7 @@ The content may still exist in other copies of the repository, either in backups An SCS MUST document the Safe Expunging Process and describe how requests and actions are tracked and SHOULD log the fact that content was removed. Different organizations and tech stacks may have different approaches to the problem. -SCSs SHOULD have technical mechanisms in place which require multiple Trusted Persons to trigger any expunging (removals) made under this process. +SCSs SHOULD have technical mechanisms in place which require an Administrator plus, at least, one additional 'trusted person' to trigger any expunging (removals) made under this process. The application of the safe expunging process and the resulting logs MAY be private to both prevent calling attention to potentially sensitive data (e.g. PII) or to comply with local laws and regulations which may require the change to be kept private to the extent possible. From ab601b23cc2d22898c37509a75476068a043c036 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Thu, 24 Oct 2024 17:33:41 -0400 Subject: [PATCH 14/14] Update docs/spec/draft/source-requirements.md Co-authored-by: Marcela Melara Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index efa978e61..48764e7e2 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -56,7 +56,7 @@ Removing a revision from a repository is similar to deleting a package version f For example, in VCSs like Git, removal of a revision changes the object IDs of all subsequent revisions that were built on top of it, , breaking downstream consumers' ability to refer to source they've already integrated into their products. -It may be the case that the specific set of changes targeted by the takedown can be expunged in ways that do not impact consumed revisions, which can mitigate these problems. +It may be the case that the specific set of changes targeted by a legal takedown can be expunged in ways that do not impact consumed revisions, which can mitigate these problems. It is also the case that removing content from a repository won't necessarily remove it everywhere. The content may still exist in other copies of the repository, either in backups or on developer machines.