Re: handling GDPR requests
Konstantin Ryabitsev wrote: > Quick follow-up -- is it possible to edit the content of the message > instead of purging it entirely? Not yet. Purge + re-add of the edited message works, but NNTP ordering would be affected (and maybe that would be desirable). Anyways, it seems like whoever wants the removal is Streisand-ing themselves in the process :> -- unsubscribe: meta+unsubscr...@public-inbox.org archive: https://public-inbox.org/meta/
Re: handling GDPR requests
On Mon, Apr 01, 2019 at 05:55:51PM +, Eric Wong wrote: > Try the -purge tool: > https://public-inbox.org/meta/20190111041008.24361-...@80x24.org/ > > I haven't used it outside of tests, so try it in a throwaway repo, > first :) > > It doesn't need to do a full reindex. And the "rebase" should > be quick when done via fast-import (doesn't need to rewrite > blobs, only commit history). The repack might be the slowest > part of the operation. Quick follow-up -- is it possible to edit the content of the message instead of purging it entirely? Since the emails in question actually involve patches, I'd like to leave those around for the historical record and remove just the offensive PII data. Best, -K
Re: handling GDPR requests
On Mon, Apr 01, 2019 at 05:55:51PM +, Eric Wong wrote: Well, I have my first GDPR request. What's the recommended mechanism of dealing with that? The message in question dates back to mid-last year and I see two problems with deleting it from the repository: 1. It's in the previous epoch repo of LKML 2. Deleting/editing that message would require a massive repo rebase with associated db reindexing. I'm not sure I want to think about how long that would take. Try the -purge tool: https://public-inbox.org/meta/20190111041008.24361-...@80x24.org/ I haven't used it outside of tests, so try it in a throwaway repo, first :) It doesn't need to do a full reindex. And the "rebase" should be quick when done via fast-import (doesn't need to rewrite blobs, only commit history). The repack might be the slowest part of the operation. Thanks, Eric! I'm not acting on it yet, since the proper process needs to be followed via LF legal. Notably, this person's name and email address ended up making its way into actual git commits (via "Reported-By:"), so at this point I'm mostly sitting back with a large bucket of pop-corn. -K
Re: handling GDPR requests
Konstantin Ryabitsev wrote: > Hello: > > Well, I have my first GDPR request. What's the recommended mechanism of > dealing with that? The message in question dates back to mid-last year and I > see two problems with deleting it from the repository: > > 1. It's in the previous epoch repo of LKML > 2. Deleting/editing that message would require a massive repo rebase with > associated db reindexing. I'm not sure I want to think about how long that > would take. Try the -purge tool: https://public-inbox.org/meta/20190111041008.24361-...@80x24.org/ I haven't used it outside of tests, so try it in a throwaway repo, first :) It doesn't need to do a full reindex. And the "rebase" should be quick when done via fast-import (doesn't need to rewrite blobs, only commit history). The repack might be the slowest part of the operation. -- unsubscribe: meta+unsubscr...@public-inbox.org archive: https://public-inbox.org/meta/
handling GDPR requests
Hello: Well, I have my first GDPR request. What's the recommended mechanism of dealing with that? The message in question dates back to mid-last year and I see two problems with deleting it from the repository: 1. It's in the previous epoch repo of LKML 2. Deleting/editing that message would require a massive repo rebase with associated db reindexing. I'm not sure I want to think about how long that would take. -K
