From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Eric Wong <e@80x24.org>
Cc: meta@public-inbox.org, a.fatoum@pengutronix.de,
u.kleine-koenig@pengutronix.de
Subject: Re: Indicating the mirror's origin
Date: Thu, 15 Jun 2023 10:47:46 -0400 [thread overview]
Message-ID: <20230615-focal-erosion-poop-df8246@meerkat> (raw)
In-Reply-To: <20230614235015.M82055@dcvr>
On Wed, Jun 14, 2023 at 11:50:15PM +0000, Eric Wong wrote:
> Konstantin Ryabitsev <konstantin@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
next prev parent reply other threads:[~2023-06-15 14:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-14 18:42 Indicating the mirror's origin Konstantin Ryabitsev
2023-06-14 20:18 ` Uwe Kleine-König
2023-06-14 20:56 ` Konstantin Ryabitsev
2023-06-14 23:50 ` Eric Wong
2023-06-15 14:47 ` Konstantin Ryabitsev [this message]
2023-06-19 6:09 ` Uwe Kleine-König
2023-06-20 2:37 ` [RFC] support publicinbox.$FOO.appendHeader in read-only endpoints Eric Wong
2023-07-05 14:27 ` Ahmad Fatoum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://public-inbox.org/README
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230615-focal-erosion-poop-df8246@meerkat \
--to=konstantin@linuxfoundation.org \
--cc=a.fatoum@pengutronix.de \
--cc=e@80x24.org \
--cc=meta@public-inbox.org \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).