Confidential (private) issues on public repo #1376

@guillep2k commented on GitHub (Jan 8, 2020):

@jamesponddotco How do you imagine this feature at work? Will the issue be marked as "restricted" on creation? Will you have a specific team that has access to these restricted issues (this would only be possible if the project owner is an organization)? What about PRs? How do you plan to hide the work in progress (if you intend to)?

The thing is there's plenty of outlets in Gitea that can easily expose an issue to users (e.g. statistics, listings by label, author, milestone, etc., mail notifications, webhooks, API, migration, etc.). There's also the issue of how to deal with assignments, for example, or @mentions. Then you have the obvious "holes" in the issue numbering that point out to something fishy going on. It all depends on your level of paranoia, of course.

@guillep2k commented on GitHub (Jan 8, 2020): @jamesponddotco How do you imagine this feature at work? Will the issue be marked as "restricted" on creation? Will you have a specific team that has access to these restricted issues (this would only be possible if the project owner is an organization)? What about PRs? How do you plan to hide the work in progress (if you intend to)? The thing is there's plenty of outlets in Gitea that can easily expose an issue to users (e.g. statistics, listings by label, author, milestone, etc., mail notifications, webhooks, API, migration, etc.). There's also the issue of how to deal with assignments, for example, or `@mentions`. Then you have the obvious "holes" in the issue numbering that point out to something fishy going on. It all depends on your level of paranoia, of course.

GiteaMirror commented

@jamesponddotco commented on GitHub (Jan 8, 2020):

@guillep2k Honestly? No idea. Whatever take this would probably need to look at how Gitlab does it.

In the ideal world — at least to me —, there should be a checkbox when creating an issue that mark it as visible only to the creator of the issue and the members of the organisation.

This is how it looks in Gitlab:

Someone from outside would be able to open an issue to report a vulnerability, for example, and everyone from the organisation and the person who created the issue would participate in the discussion. Confidential issues should probably not be available over the API.

@jamesponddotco commented on GitHub (Jan 8, 2020): @guillep2k Honestly? No idea. Whatever take this would probably need to look at [how Gitlab does it](https://docs.gitlab.com/ce/user/project/issues/confidential_issues.html). In the ideal world — at least to me —, there should be a checkbox when creating an issue that mark it as visible only to the creator of the issue and the members of the organisation. **This is how it looks in Gitlab:** ![](https://i.imgur.com/vSdH9SI.png) Someone from outside would be able to open an issue to report a vulnerability, for example, and everyone from the organisation and the person who created the issue would participate in the discussion. Confidential issues should probably not be available over the API.

GiteaMirror commented

@sapk commented on GitHub (Jan 8, 2020):

For the amount, I don't exactly know. I suggest you based yourself on current and past bounty. For the issue that I cited it was 200$. The main contributor post 100$ and added 95$ one month later and someone added 5$. If you look at current issue they should be around 100$ but they are stuck for a little time.
If your need is urgent, I would say start at least at 100$. The issue is basic at first glance but will need refactor of other part of code like doing a private fork of a public repo (for PR/MR like gitlab).
I will finish by saying thanks to propose a bounty this help contributor and even if it is tricky to put a number/price/time it is always really appreciated.

@sapk commented on GitHub (Jan 8, 2020): For the amount, I don't exactly know. I suggest you based yourself on current and past bounty. For the issue that I cited it was 200$. The main contributor post 100$ and added 95$ one month later and someone added 5$. If you look at current issue they should be around 100$ but they are stuck for a little time. If your need is urgent, I would say start at least at 100$. The issue is basic at first glance but will need refactor of other part of code like doing a private fork of a public repo (for PR/MR like gitlab). I will finish by saying thanks to propose a bounty this help contributor and even if it is tricky to put a number/price/time it is always really appreciated.

GiteaMirror commented

@kolaente commented on GitHub (Jan 9, 2020):

I'd say we could add private issues first, and then private PRs later on since that would require a lot more work - as @guillep2k already pointed out.

@kolaente commented on GitHub (Jan 9, 2020): I'd say we could add private issues first, and then private PRs later on since that would require a lot more work - as @guillep2k already pointed out.

GiteaMirror commented

2025-11-02 03:58:30 -06:00

@lunny commented on GitHub (Jan 10, 2020):

If someone would like to create a PR, he has to consider something as below.

An issue could be changed to private or to public.
Repository issues list and global issues list should ignore the private issues if they have no permissions.
APIs about issues list / single issue.
References and dependencies: When you reference an public issue on a private issue, it should not be displayed on public issue's comment if user has no permission.
Notifications: only send information to special users but not all repository watcher when comment on a private issue.

@lunny commented on GitHub (Jan 10, 2020): If someone would like to create a PR, he has to consider something as below. - [ ] An issue could be changed to private or to public. - [ ] Repository issues list and global issues list should ignore the private issues if they have no permissions. - [ ] APIs about issues list / single issue. - [ ] References and dependencies: When you reference an public issue on a private issue, it should not be displayed on public issue's comment if user has no permission. - [ ] Notifications: only send information to special users but not all repository watcher when comment on a private issue.

GiteaMirror commented

@Programmierus commented on GitHub (Jan 10, 2020):

Just my 5 cents: we'd love a feature where issues in a special repository are being seen only by issue starter and maintainers. Scenario exactly as mentioned: vulnerabilities reporting. We love to get them reported but want to discuss them internally and only with the reporter before we patch the issue.

At the moment we achieved the same using templates-hack but it's a pain to maintain our changes when updating gitea.

If the above-mentioned will be done I am ready to add another $100 to the bounty.

@Programmierus commented on GitHub (Jan 10, 2020): Just my 5 cents: we'd love a feature where issues in a special repository are being seen only by issue starter and maintainers. Scenario exactly as mentioned: vulnerabilities reporting. We love to get them reported but want to discuss them internally and only with the reporter before we patch the issue. At the moment we achieved the same using templates-hack but it's a pain to maintain our changes when updating gitea. If the above-mentioned will be done I am ready to add another $100 to the bounty.

GiteaMirror commented

2025-11-02 03:58:30 -06:00

@jamesponddotco commented on GitHub (Jan 10, 2020):

Bounty posted:
https://www.bountysource.com/issues/52815258-confidential-private-issues-on-public-repo

@jamesponddotco commented on GitHub (Jan 10, 2020): **Bounty posted:** https://www.bountysource.com/issues/52815258-confidential-private-issues-on-public-repo

GiteaMirror commented

2025-11-02 03:58:30 -06:00

@raucao commented on GitHub (Mar 8, 2020):

Just adding another use case that would be covered by this: a simple user support/help desk system. A service would have a public repo for end user support, and the user could decide if they want to have their request be public or confidential. And the support team can have access to the confidential issues.

@raucao commented on GitHub (Mar 8, 2020): Just adding another use case that would be covered by this: a simple user support/help desk system. A service would have a public repo for end user support, and the user could decide if they want to have their request be public or confidential. And the support team can have access to the confidential issues.

GiteaMirror commented

@6543 commented on GitHub (Apr 16, 2020):

I'll take it - If I have enouth time It perhaps get ready before feature freeze

@6543 commented on GitHub (Apr 16, 2020): I'll take it - If I have enouth time It perhaps get ready before feature freeze

GiteaMirror commented

@ni4 commented on GitHub (Oct 7, 2020):

Thanks for starting this. Any progress so far? It would be really useful to track security issues on public repositories, and to have helpdesk-like system, where not all issues could be public due to personal information disclosure and so on.

@ni4 commented on GitHub (Oct 7, 2020): Thanks for starting this. Any progress so far? It would be really useful to track security issues on public repositories, and to have helpdesk-like system, where not all issues could be public due to personal information disclosure and so on.

GiteaMirror commented

@6543 commented on GitHub (Oct 7, 2020):

still planed, didnt had time to work on it at the moment.

@6543 commented on GitHub (Oct 7, 2020): still planed, didnt had time to work on it at the moment.

GiteaMirror commented

@radrow commented on GitHub (Apr 12, 2021):

I absolutely appreciate and support this idea. Should be fairly simple to implement and will have huge impact on open source projects that need to keep some critical tickets confidential (for security reasons, surprises, potential misuses, etc).

@radrow commented on GitHub (Apr 12, 2021): I absolutely appreciate and support this idea. Should be fairly simple to implement and will have huge impact on open source projects that need to keep some critical tickets confidential (for security reasons, surprises, potential misuses, etc).

GiteaMirror commented

@techknowlogick commented on GitHub (Apr 12, 2021):

Should be fairly simple to implement

PRs are welcome in that case.

@techknowlogick commented on GitHub (Apr 12, 2021): > Should be fairly simple to implement PRs are welcome in that case.

GiteaMirror commented

@delvh commented on GitHub (May 24, 2021):

One thing I notice when talking about private issues is an additional security aspect:
Such an issue will most likely get its ID from the public ID pool.
Even if it will not get displayed, users will know that there is an issue that is not being displayed here because they will receive either a 404 - Not Found or a 401 - Forbidden, depending on the implementation. And since issues cannot be permanently deleted without access to the database, that is a pretty clear indicator.
Are we fine with notifying users that such issues exist?
In favor of this approach are the following two aspects:

there is most likely nothing to fear, if the user knows such an issue exists
Its way easier to implement this way

Against it speaks that if any part of the application is not robust enough to protect against accidental intrusion (see i.e. above, most likely there are even more - I can think spontaneously of linking to the issue in PRs, Milestones or Projects), then you have a huge security leak where hackers can see security issues before they are publicly known, and most likely before they are fixed.
Even worse: How can you handle PRs referencing to fix this issue?
Do you simply hide a link to a private issue from the user (i.e. in a fixes/closes #test), do you show it, or how do you handle that?

@delvh commented on GitHub (May 24, 2021): One thing I notice when talking about private issues is an additional security aspect: Such an issue will most likely get its ID from the public ID pool. Even if it will not get displayed, users will know that there is an issue that is not being displayed here because they will receive either a `404 - Not Found` or a `401 - Forbidden`, depending on the implementation. And since issues cannot be permanently deleted without access to the database, that is a pretty clear indicator. Are we fine with notifying users that such issues exist? In favor of this approach are the following two aspects: 1. there is most likely nothing to fear, if the user knows such an issue exists 2. Its **way** easier to implement this way Against it speaks that if any part of the application is not robust enough to protect against accidental intrusion ([see i.e. above](https://github.com/go-gitea/gitea/issues/3217#issuecomment-572820673), most likely there are even more - I can think spontaneously of linking to the issue in PRs, Milestones or Projects), then you have a **huge** security leak where hackers can see security issues before they are publicly known, and most likely before they are fixed. Even worse: How can you handle PRs referencing to fix this issue? Do you simply hide a link to a private issue from the user (i.e. in a `fixes/closes #test`), do you show it, or how do you handle that?

GiteaMirror commented

@lunny commented on GitHub (Jun 1, 2021):

Depends on deleting issue or the index could be non-continuous.

@lunny commented on GitHub (Jun 1, 2021): Depends on deleting issue or the index could be non-continuous.

GiteaMirror commented

2025-11-02 03:58:33 -06:00

@zack-vii commented on GitHub (Jul 17, 2021):

Hi there,
I was just searching for this feature and stumbled upon this thread. I did not read all of it but concerning the last comment by @delvh I think there is no harm in being open about private issues. In fact for user without access on the lowest level the issue may present itself as something like this:

ID: "visible"
Title: "Private issue"
Only Comment: "This issue is  for <minimum_access_level> only. Currently, you have no permission to its content. Please log in or request permission if you feel like you should be allowed to see this."
Permission: readonly

where <minimum_access_level> may be different in case you can choose to make an issue private to Owner/Maintainer/Developer/Reporter... etc.

@zack-vii commented on GitHub (Jul 17, 2021): Hi there, I was just searching for this feature and stumbled upon this thread. I did not read all of it but concerning the last comment by @delvh I think there is no harm in being open about private issues. In fact for user without access on the lowest level the issue may present itself as something like this: ``` ID: "visible" Title: "Private issue" Only Comment: "This issue is for <minimum_access_level> only. Currently, you have no permission to its content. Please log in or request permission if you feel like you should be allowed to see this." Permission: readonly ``` where <minimum_access_level> may be different in case you can choose to make an issue private to Owner/Maintainer/Developer/Reporter... etc.

GiteaMirror commented

@6543 commented on GitHub (Jul 17, 2021):

I dont understand what this comment is about, just an info: this is still on my todo list for features ... (1. rss, 2. this)

@6543 commented on GitHub (Jul 17, 2021): I dont understand what this comment is about, just an info: this is still on my todo list for features ... (1. rss, 2. this)

GiteaMirror commented

2025-11-02 03:58:33 -06:00

@tobiasBora commented on GitHub (Mar 8, 2022):

Just adding another use case that would be covered by this: a simple user support/help desk system. [...]

This is also the scenario I'm interested in. In this setting, it could also be cool to allow only one kind of issue on a repo (for privacy reasons, I may want to ensure that my users never write public issues). It could also be nice to be able to specify at the time of writing the issue who (among the developers) has the right to see this issue, for instance by specifying a list of team. This may be interesting on security issues (you may not want all the dev to learn about the issue).

@tobiasBora commented on GitHub (Mar 8, 2022): > Just adding another use case that would be covered by this: a simple user support/help desk system. [...] This is also the scenario I'm interested in. In this setting, it could also be cool to allow only one kind of issue on a repo (for privacy reasons, I may want to ensure that my users never write public issues). It could also be nice to be able to specify at the time of writing the issue who (among the developers) has the right to see this issue, for instance by specifying a list of team. This may be interesting on security issues (you may not want all the dev to learn about the issue).

GiteaMirror commented

2025-11-02 03:58:33 -06:00

@6543 commented on GitHub (Mar 9, 2022):

well confidential issues should only be accessible if you are the A. creator; B. a Repo Admin; C. Assigned to this repo

@6543 commented on GitHub (Mar 9, 2022): well confidential issues should only be accessible if you are the A. creator; B. a Repo Admin; C. Assigned to this repo

GiteaMirror commented

@lunny commented on GitHub (Mar 9, 2022):

well confidential issues should only be accessible if you are the A. creator; B. a Repo Admin; C. Assigned to this repo

D In future, creator or admin could invite others to view this issue.

@lunny commented on GitHub (Mar 9, 2022): > well confidential issues should only be accessible if you are the A. creator; B. a Repo Admin; C. Assigned to this repo D In future, creator or admin could invite others to view this issue.

GiteaMirror commented

@tobiasBora commented on GitHub (Mar 9, 2022):

I guess it makes sense for confidential issues. The application I have in mind is maybe a bit outside the scope of gitea, as I was also thinking to use gitea as a kind of project manager in the administration (issues with notifications and history, edition, wiki, being able to reference issues from other issues, assignee, kanboard, milestones, reactions, labels, time tracking... are many things that could certainly be beneficial there as well and could replace or complete emails). In this scenario, some issues should be shared only to parts of the administration : for instance, I guess not everybody in the administration should have access to discussions concerning the budget, and each team may have internal issues they don't want to share by default with others. Also, when external users want to fill tickets about some issues/questions, they often want the ticket to be private, and typically want to notify only a part of the team. That's why I think it would be really cool to provide a way to notify, restrict and invite different kinds of members/teams in the issue (the default configuration may be automatically configured by the issues templates).

@tobiasBora commented on GitHub (Mar 9, 2022): I guess it makes sense for confidential issues. The application I have in mind is maybe a bit outside the scope of gitea, as I was also thinking to use gitea as a kind of project manager in the administration (issues with notifications and history, edition, wiki, being able to reference issues from other issues, assignee, kanboard, milestones, reactions, labels, time tracking... are many things that could certainly be beneficial there as well and could replace or complete emails). In this scenario, some issues should be shared only to parts of the administration : for instance, I guess not everybody in the administration should have access to discussions concerning the budget, and each team may have internal issues they don't want to share by default with others. Also, when external users want to fill tickets about some issues/questions, they often want the ticket to be private, and typically want to notify only a part of the team. That's why I think it would be really cool to provide a way to notify, restrict and invite different kinds of members/teams in the issue (the default configuration may be automatically configured by the issues templates).

GiteaMirror commented

@6543 commented on GitHub (Mar 13, 2022):

we dont need an invite feature - just add the user as assignee and it's good to go ... if implemented that way

@6543 commented on GitHub (Mar 13, 2022): we dont need an invite feature - just add the user as assignee and it's good to go ... if implemented that way

GiteaMirror commented

@6543 commented on GitHub (Mar 13, 2022):

@tobiasBora what you try to do can already be done by teams and orgs ...

@6543 commented on GitHub (Mar 13, 2022): @tobiasBora what you try to do can already be done by teams and orgs ...

GiteaMirror commented

@ell1e commented on GitHub (Oct 8, 2022):

This would be really useful for reporting security issues, so a user can file an issue as usual but in a way where it's not necessarily paired with a maybe-not-so-responsible disclosure to everyone. What's the current stance on this? So far from above it reads like it won't be added, which would be a shame.

@ell1e commented on GitHub (Oct 8, 2022): This would be really useful for reporting security issues, so a user can file an issue as usual but in a way where it's not necessarily paired with a maybe-not-so-responsible disclosure to everyone. What's the current stance on this? So far from above it reads like it won't be added, which would be a shame.

GiteaMirror commented

@6543 commented on GitHub (Oct 8, 2022):

So far from above it reads like it won't be added, which would be a shame.

no there is just not enough time to implement atm and it's nothing one should contribute if he is not familiar with the codebase already

@6543 commented on GitHub (Oct 8, 2022): > So far from above it reads like it won't be added, which would be a shame. no there is just not enough time to implement atm and it's nothing one should contribute if he is not familiar with the codebase already

GiteaMirror commented

@lunny commented on GitHub (Dec 14, 2022):

One thing I notice when talking about private issues is an additional security aspect: Such an issue will most likely get its ID from the public ID pool. Even if it will not get displayed, users will know that there is an issue that is not being displayed here because they will receive either a 404 - Not Found or a 401 - Forbidden, depending on the implementation. And since issues cannot be permanently deleted without access to the database, that is a pretty clear indicator. Are we fine with notifying users that such issues exist? In favor of this approach are the following two aspects:

there is most likely nothing to fear, if the user knows such an issue exists

Its way easier to implement this way

Against it speaks that if any part of the application is not robust enough to protect against accidental intrusion (see i.e. above, most likely there are even more - I can think spontaneously of linking to the issue in PRs, Milestones or Projects), then you have a huge security leak where hackers can see security issues before they are publicly known, and most likely before they are fixed. Even worse: How can you handle PRs referencing to fix this issue? Do you simply hide a link to a private issue from the user (i.e. in a fixes/closes #test), do you show it, or how do you handle that?

Since issue could be deleted today, the issue is gone. It maybe deleted.

@lunny commented on GitHub (Dec 14, 2022): > One thing I notice when talking about private issues is an additional security aspect: Such an issue will most likely get its ID from the public ID pool. Even if it will not get displayed, users will know that there is an issue that is not being displayed here because they will receive either a `404 - Not Found` or a `401 - Forbidden`, depending on the implementation. And since issues cannot be permanently deleted without access to the database, that is a pretty clear indicator. Are we fine with notifying users that such issues exist? In favor of this approach are the following two aspects: > > 1. there is most likely nothing to fear, if the user knows such an issue exists > 2. Its **way** easier to implement this way > > Against it speaks that if any part of the application is not robust enough to protect against accidental intrusion ([see i.e. above](https://github.com/go-gitea/gitea/issues/3217#issuecomment-572820673), most likely there are even more - I can think spontaneously of linking to the issue in PRs, Milestones or Projects), then you have a **huge** security leak where hackers can see security issues before they are publicly known, and most likely before they are fixed. Even worse: How can you handle PRs referencing to fix this issue? Do you simply hide a link to a private issue from the user (i.e. in a `fixes/closes #test`), do you show it, or how do you handle that? Since issue could be deleted today, the issue is gone. It maybe deleted.

GiteaMirror commented

2025-11-02 03:58:36 -06:00

@delvh commented on GitHub (Dec 14, 2022):

Yep, at the time of writing I didn't think such a thing would ever exist.
That's now of course completely outdated.

@delvh commented on GitHub (Dec 14, 2022): Yep, at the time of writing I didn't think such a thing would ever exist. That's now of course completely outdated.

GiteaMirror commented

@tobiasBora commented on GitHub (Dec 14, 2022):

Since issue could be deleted today, the issue is gone. It maybe deleted.

Well… someone that really wants to attack softwares this way could create a bot that automatically logs all newly created issues, so that it can see if the issue was a really deleted or actually exists (I admit that such users would need to pool quite frequently the repository… but when it comes to security people can do crazy things sometimes). Or if an attacker knows that users typically prefer to close an issue than deleting it (maybe because the UI to delete an issue is hard to find), then they can safely assume that a missing issue is a security issue. It's maybe possible to randomly skip ID to mitigate this attack… but it's still not perfectly secure.

A solution that should be perfectly secure (and that avoids creating a new table) is to allow security issues to only be, say, multiple of 100 (i.e. ending with two zeros), and normal issues should not be multiples of 100. In practice you could create two counters, one to maintain the last ID of a normal issue, one to maintain the last ID of a security issue, skipping the forbidden numbers. As far as I see, this should not cause any backward compatibility issue, as skipping an issue is more or less like adding+directly removing an issue.

Warning: you still want to make sure to display the same error message when an issue does not exist and when you don't have the right to see an issue… or otherwise you could directly count the security issues of a repository (this is also true for any approach proposed so far).

@tobiasBora commented on GitHub (Dec 14, 2022): > Since issue could be deleted today, the issue is gone. It maybe deleted. Well… someone that really wants to attack softwares this way could create a bot that automatically logs all newly created issues, so that it can see if the issue was a really deleted or actually exists (I admit that such users would need to pool quite frequently the repository… but when it comes to security people can do crazy things sometimes). Or if an attacker knows that users typically prefer to close an issue than deleting it (maybe because the UI to delete an issue is hard to find), then they can safely assume that a missing issue is a security issue. It's maybe possible to randomly skip ID to mitigate this attack… but it's still not perfectly secure. A solution that should be perfectly secure (and that avoids creating a new table) is to allow security issues to only be, say, multiple of 100 (i.e. ending with two zeros), and normal issues should *not* be multiples of 100. In practice you could create two counters, one to maintain the last ID of a normal issue, one to maintain the last ID of a security issue, skipping the forbidden numbers. As far as I see, this should not cause any backward compatibility issue, as skipping an issue is more or less like adding+directly removing an issue. **Warning:** you still want to make sure to display the same error message when an issue does not exist and when you don't have the right to see an issue… or otherwise you could directly count the security issues of a repository (this is also true for any approach proposed so far).

GiteaMirror commented

2025-11-02 03:58:36 -06:00

@ell1e commented on GitHub (Dec 14, 2022):

I don't think just knowing a potential security issue exists should be considered a problem. Often, that is even officially announced in advance sometimes days before the patch drops so I don't think it's worth hiding with a lot of effort. (As long as the title and contents of the issue remain private.)

@ell1e commented on GitHub (Dec 14, 2022): I don't think just knowing a potential security issue exists should be considered a problem. Often, that is even officially announced in advance sometimes days before the patch drops so I don't think it's worth hiding with a lot of effort. (As long as the title and contents of the issue remain private.)

GiteaMirror commented

@tobiasBora commented on GitHub (Dec 14, 2022):

Maybe, I don't have strong opinion on that. If it significantly eases the development of the option not to consider that case, then it might be worth doing it without. But in any case it's something to keep in mind.

@tobiasBora commented on GitHub (Dec 14, 2022): Maybe, I don't have strong opinion on that. If it significantly eases the development of the option not to consider that case, then it might be worth doing it without. But in any case it's something to keep in mind.

GiteaMirror commented

@lunny commented on GitHub (Dec 14, 2022):

Whatever it's deleted or private, it will return 404 if they are visited by a person with no permission.

@lunny commented on GitHub (Dec 14, 2022): > Whatever it's deleted or private, it will return 404 if they are visited by a person with no permission.

GiteaMirror commented

@christianTF commented on GitHub (Jan 20, 2023):

My use-case as a maintainer for a Private issue would be, to set an open issue to private to be able to ask the issue starter to add logfiles or config files that may contain GDPR-relevant information or credentials.
Currently we switch to email for that situations, that usually is not comprehensible anymore for the other maintainers.
Sometimes, issue openers aren't aware of such Information is contained in their logs or screenshots, so we would have a quick win to set an issue private instead of deleting or truncate such information.

@christianTF commented on GitHub (Jan 20, 2023): My use-case as a maintainer for a Private issue would be, to set an open issue to private to be able to ask the issue starter to add logfiles or config files that may contain GDPR-relevant information or credentials. Currently we switch to email for that situations, that usually is not comprehensible anymore for the other maintainers. Sometimes, issue openers aren't aware of such Information is contained in their logs or screenshots, so we would have a quick win to set an issue private instead of deleting or truncate such information.

GiteaMirror commented