user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: Eric Wong <e@80x24.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: meta@public-inbox.org
Subject: [RFC 1/2] config: inbox name checking matches git.git more closely
Date: Wed,  9 Jan 2019 11:43:26 +0000	[thread overview]
Message-ID: <20190109114327.1901-2-e@80x24.org> (raw)
In-Reply-To: <20190109114327.1901-1-e@80x24.org>

Actually, it turns out git.git/remote.c::valid_remote_nick
rules alone are insufficient.  More checking is performed as
part of the refname in the git.git/refs.c::check_refname_component

I also considered rejecting URL-unfriendly inbox names entirely,
but realized some users may intentionally configure names not
handled by our WWW endpoint for archives they don't want
accessible over HTTP.
---
 lib/PublicInbox/Config.pm | 20 ++++++++++++++++++--
 lib/PublicInbox/WWW.pm    |  4 +++-
 t/config.t                | 36 ++++++++++++++++++++++++++++++++++++
 3 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/lib/PublicInbox/Config.pm b/lib/PublicInbox/Config.pm
index a2b721d..bea2617 100644
--- a/lib/PublicInbox/Config.pm
+++ b/lib/PublicInbox/Config.pm
@@ -152,6 +152,23 @@ sub git_config_dump {
 	\%rv;
 }
 
+sub valid_inbox_name ($) {
+	my ($name) = @_;
+
+	# Similar rules found in git.git/remote.c::valid_remote_nick
+	# and git.git/refs.c::check_refname_component
+	# We don't reject /\.lock\z/, however, since we don't lock refs
+	if ($name eq '' || $name =~ /\@\{/ ||
+	    $name =~ /\.\./ || $name =~ m![/:\?\[\]\^~\s\f[:cntrl:]\*]! ||
+	    $name =~ /\A\./ || $name =~ /\.\z/) {
+		return 0;
+	}
+
+	# Note: we allow URL-unfriendly characters; users may configure
+	# non-HTTP-accessible inboxes
+	1;
+}
+
 sub _fill {
 	my ($self, $pfx) = @_;
 	my $rv = {};
@@ -185,8 +202,7 @@ sub _fill {
 	my $name = $pfx;
 	$name =~ s/\Apublicinbox\.//;
 
-	# same rules as git.git/remote.c::valid_remote_nick
-	if ($name eq '' || $name =~ m!/! || $name eq '.' || $name eq '..') {
+	if (!valid_inbox_name($name)) {
 		warn "invalid inbox name: '$name'\n";
 		return;
 	}
diff --git a/lib/PublicInbox/WWW.pm b/lib/PublicInbox/WWW.pm
index c1c3926..3562e46 100644
--- a/lib/PublicInbox/WWW.pm
+++ b/lib/PublicInbox/WWW.pm
@@ -19,7 +19,9 @@ use URI::Escape qw(uri_unescape);
 use PublicInbox::MID qw(mid_escape);
 require PublicInbox::Git;
 use PublicInbox::GitHTTPBackend;
-our $INBOX_RE = qr!\A/([\w\.\-]+)!;
+
+# TODO: consider a routing tree now that we have more endpoints:
+our $INBOX_RE = qr!\A/([\w\-][\w\.\-]*)!;
 our $MID_RE = qr!([^/]+)!;
 our $END_RE = qr!(T/|t/|t\.mbox(?:\.gz)?|t\.atom|raw|)!;
 our $ATTACH_RE = qr!(\d[\.\d]*)-([[:alnum:]][\w\.-]+[[:alnum:]])!i;
diff --git a/t/config.t b/t/config.t
index 6a6b98c..5f0a95b 100644
--- a/t/config.t
+++ b/t/config.t
@@ -114,4 +114,40 @@ my $tmpdir = tempdir('pi-config-XXXXXX', TMPDIR => 1, CLEANUP => 1);
 		}, 'known addresses populated');
 }
 
+my @invalid = (
+	# git rejects this because it locks refnames, but we don't have
+	# this problem with inbox names:
+	# 'inbox.lock',
+
+	# git rejects these:
+	'', '..', '.', 'stash@{9}', 'inbox.', '^caret', '~tilde',
+	'*asterisk', 's p a c e s', ' leading-space', 'trailing-space ',
+	'question?', 'colon:', '[square-brace]', "\fformfeed",
+	"\0zero", "\bbackspace",
+
+);
+
+require Data::Dumper;
+for my $s (@invalid) {
+	my $d = Data::Dumper->new([$s])->Terse(1)->Indent(0)->Dump;
+	ok(!PublicInbox::Config::valid_inbox_name($s), "$d name rejected");
+}
+
+# obviously-valid examples
+my @valid = qw(a a@example a@example.com);
+
+# Rejecting more was considered, but then it dawned on me that
+# people may intentionally use inbox names which are not URL-friendly
+# to prevent the PSGI interface from displaying them...
+# URL-unfriendly
+# '<', '>', '%', '#', '?', '&', '(', ')',
+
+# maybe these aren't so bad, they're common in Message-IDs, even:
+# '!', '$', '=', '+'
+push @valid, qw[bang! ca$h less< more> 1% (parens) &more eql= +plus], '#hash';
+for my $s (@valid) {
+	my $d = Data::Dumper->new([$s])->Terse(1)->Indent(0)->Dump;
+	ok(PublicInbox::Config::valid_inbox_name($s), "$d name accepted");
+}
+
 done_testing();
-- 
EW


  reply	other threads:[~2019-01-09 11:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09 11:43 [RFC 0/2] support for /~/$MESSAGE_ID endpoint Eric Wong
2019-01-09 11:43 ` Eric Wong [this message]
2019-01-09 11:43 ` [RFC 2/2] www: add /~/$MESSAGE_ID global redirector endpoint Eric Wong
2019-01-27  2:06   ` Eric Wong
2019-01-28 13:50     ` Konstantin Ryabitsev
2019-02-01  9:00       ` Eric Wong
2019-02-01 18:31         ` [PATCH v2] newswww: add /$MESSAGE_ID " Eric Wong
2019-02-04 11:11           ` [PATCH v2] examples/newswww.psgi: demonstrate standalone NewsWWW usage Eric Wong
2019-02-19 19:53         ` [RFC 2/2] www: add /~/$MESSAGE_ID global redirector endpoint Konstantin Ryabitsev
2019-02-19 22:55           ` Eric Wong

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=20190109114327.1901-2-e@80x24.org \
    --to=e@80x24.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=meta@public-inbox.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/public-inbox.git

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).