On Wed, Jun 14, 2023 at 11:50:15PM +0000, Eric Wong wrote: > Konstantin Ryabitsev <konstan...@linuxfoundation.org> wrote: > > Good day: > > > > We've had a few requests to mirror public-inbox archives that originate on > > other systems so they can also be searchable and viewable via > > lore.kernel.org. > > I've been dragging my feet on these requests, because they are a potential > > liability in terms of GDPR compliance. > > I just tried using `git replace' for the first time:
I think I didn't quite convey my idea -- let me try to step back a bit. What I have is lore.kernel.org, which is actually 3 different frontends all pulling git repositories from some other source of origin. Currently, I have two: - lkml.kernel.org, which subscribes to external lists via regular SMTP - subspace.kernel.org, which is our own mlmmj server and where public-inbox repositories are created via public-inbox-watch Since we control both lkml and subspace, we are the origin of the data, so if anyone requests archive removal, we can easily comply. Now, I want to be able to add other external public-inbox repositories to be mirrored on lore.kernel.org, but with some clear indication that we're not the origin of that data, we're merely mirroring it. Any GDPR removal requests need to be sent to $ORIGIN and we'll just propagate any changes. > git replace --edit $BLOB_OID I don't want to go down that route, because while we can do such surgery on a node, it would need to be rerun again if we bring up a new mirror node, and it's almost guaranteed to be forgotten. > I sometimes use the $INBOX_DIR/description file for that and it > affects WWW and NNTP, but not IMAP/POP3. I'm not sure if I want > to reintroduce header injection in case there's some conflict > with DKIM or other signature mechanisms[1] I don't think we need to worry about it if we pick a header that's almost certain to not be included in the default DKIM signature set. X-Originally-Archived-At: or some other header is guaranteed to never be signed. -K
