Re: Bug related to (maybe?) / in Message-Id
Eric Wong wrote: > Thomas Weißschuh wrote: > > > # in file "msgid" next to muttrc > > > # put any command within the backticks > > > my_hdr Message-ID: <`uuidgen -r`@t-8ch.de> > > I didn't notice this earlier, but IMHO having Message-IDs > prefixed with `%Y%m%d%H%M%S' can convey human-meaningful > information in the URL without having to open the URL. Btw, mutt may gain a more reasonable default: https://marc.info/?i=20230307_213502_4a7zc...@breakpoint.cc (not sure how I feel about underscores, though) (I brought this up a few years back, but wasn't successful: https://marc.info/?i=20210110213922.iqTO594q5DM@dcvr )
Re: ActivityPub <=> email bridge?
Konstantin Ryabitsev wrote: > On Tue, Mar 07, 2023 at 10:12:10PM +, Eric Wong wrote: > > > Something tells me that if ActivityPub reaches high-enough > > > adoption levels; it'll have to deal with a spam problem that > > > email folks have been dealing with for decades, too. > > > > > > So ActivityPub seems like a duplicated effort as far as it's use > > > for messaging for software development goes... > > > > Still true, but it seems to have caught on, lately... > > > > If we manage to try this, it'll be using AP as a transport layer > > and still requiring plain-text and RFC5322 (or 822/2822) plain-text > > messages compatible with git-am. > > I'm not sure about the bridge, but I would very much welcome ability to > archive activitypub messages in a public-inbox archive, with full threading. *shrug* email messages may be able to reach a wider audience via AP. > > That would allow SpamAssassin or similar to perform spam > > filtering w/o modification. > > > > Allowing markup or images from arbitrary posters is a nightmare > > in terms of spam, phishing and illegal content, though; so > > normal mailing list etiquette still applies. > > Perhaps it's possible to allow attachments from specific instances, but the > default for any federated content is just plaintext content? Yes, basically anything acceptable to the existing mail community. I realize sometimes people will need to post photos of failed boot attempts, so I think those should be federated, too[1] but absolutely NOT displayed by default in any UI. [1] especially if they can be fetched via git
Re: ActivityPub <=> email bridge?
On Tue, Mar 07, 2023 at 10:12:10PM +, Eric Wong wrote: > > Something tells me that if ActivityPub reaches high-enough > > adoption levels; it'll have to deal with a spam problem that > > email folks have been dealing with for decades, too. > > > > So ActivityPub seems like a duplicated effort as far as it's use > > for messaging for software development goes... > > Still true, but it seems to have caught on, lately... > > If we manage to try this, it'll be using AP as a transport layer > and still requiring plain-text and RFC5322 (or 822/2822) plain-text > messages compatible with git-am. I'm not sure about the bridge, but I would very much welcome ability to archive activitypub messages in a public-inbox archive, with full threading. > That would allow SpamAssassin or similar to perform spam > filtering w/o modification. > > Allowing markup or images from arbitrary posters is a nightmare > in terms of spam, phishing and illegal content, though; so > normal mailing list etiquette still applies. Perhaps it's possible to allow attachments from specific instances, but the default for any federated content is just plaintext content? -K
Re: ActivityPub <=> email bridge?
Eric Wong wrote: > Is it worth the effort? Maybe... > Something tells me that if ActivityPub reaches high-enough > adoption levels; it'll have to deal with a spam problem that > email folks have been dealing with for decades, too. > > So ActivityPub seems like a duplicated effort as far as it's use > for messaging for software development goes... Still true, but it seems to have caught on, lately... If we manage to try this, it'll be using AP as a transport layer and still requiring plain-text and RFC5322 (or 822/2822) plain-text messages compatible with git-am. That would allow SpamAssassin or similar to perform spam filtering w/o modification. Allowing markup or images from arbitrary posters is a nightmare in terms of spam, phishing and illegal content, though; so normal mailing list etiquette still applies.
[PATCH] test_common: run_script: drop special-case for -clone
`make check' and `make check-run' actually work fine with it,
and TMPDIR=/dev/shm prove -lvw t/clone-coderepo.t is 2-3x faster
---
lib/PublicInbox/TestCommon.pm | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/PublicInbox/TestCommon.pm b/lib/PublicInbox/TestCommon.pm
index 8a34e45a..a550a5a1 100644
--- a/lib/PublicInbox/TestCommon.pm
+++ b/lib/PublicInbox/TestCommon.pm
@@ -295,7 +295,6 @@ sub run_script ($;$$) {
my ($cmd, $env, $opt) = @_;
my ($key, @argv) = @$cmd;
my $run_mode = $ENV{TEST_RUN_MODE} // $opt->{run_mode} // 1;
- $run_mode = 0 if $key eq '-clone'; # relies on SIGCHLD + waitpid(-1)
my $sub = $run_mode == 0 ? undef : key2sub($key);
my $fhref = [];
my $spawn_opt = {};
[PATCH] cgit: fix smart HTTP clone interception
We need to use the proper hash and key to do coderepo lookups
since we culled a redundant data structure a few months back.
Fixes: 1802dc29bda25a54 ("www_coderepo: do not copy {-code_repos} from config")
---
lib/PublicInbox/Cgit.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/PublicInbox/Cgit.pm b/lib/PublicInbox/Cgit.pm
index 336098ca..a1a2e828 100644
--- a/lib/PublicInbox/Cgit.pm
+++ b/lib/PublicInbox/Cgit.pm
@@ -91,7 +91,7 @@ sub call {
# handle requests without spawning cgit iff possible:
if ($path_info =~ m!\A/(.+?)/($PublicInbox::GitHTTPBackend::ANY)\z!ox) {
my ($nick, $path) = ($1, $2);
- if (my PublicInbox::Git $git = $self->{"\0$nick"}) {
+ if (my $git = $self->{pi_cfg}->{-code_repos}->{$nick}) {
return serve($env, $git, $path);
}
} elsif ($path_info =~ m!$self->{static}! &&
[PATCH] sha: fix compatibility with old OpenSSL + Net::SSLeay
In older OpenSSL, EVP_get_digestbyname() didn't work properly
without calling OpenSSL_add_all_digests(), first. However,
OpenSSL_add_all_digests() is deprecated by OpenSSL 1.1.0 in
favor of OPENSSL_init_crypto(). Of course, OpenSSL_init_crypto()
isn't available in OpenSSL 1.0.1k nor Net::SSLeay as of 1.93_02
(2023-02-22).
Thus, instead of relying on string lookups and conditional
subroutine calls, just call EVP_sha1() and EVP_sha256() which
work on both old and new systems.
Tested with Net::SSLeay 1.55 and OpenSSL 1.0.1k on on CentOS 7.x
---
lib/PublicInbox/SHA.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/PublicInbox/SHA.pm b/lib/PublicInbox/SHA.pm
index da70beef..81f62618 100644
--- a/lib/PublicInbox/SHA.pm
+++ b/lib/PublicInbox/SHA.pm
@@ -20,8 +20,8 @@ BEGIN {
unless (eval(<<'EOM')) {
use Net::SSLeay 1.43;
my %SHA = (
- 1 => Net::SSLeay::EVP_get_digestbyname('sha1'),
- 256 => Net::SSLeay::EVP_get_digestbyname('sha256'),
+ 1 => Net::SSLeay::EVP_sha1(),
+ 256 => Net::SSLeay::EVP_sha256(),
);
sub new {
Re: Bug related to (maybe?) / in Message-Id
Thomas Weißschuh wrote: > > # in file "msgid" next to muttrc > > # put any command within the backticks > > my_hdr Message-ID: <`uuidgen -r`@t-8ch.de> I didn't notice this earlier, but IMHO having Message-IDs prefixed with `%Y%m%d%H%M%S' can convey human-meaningful information in the URL without having to open the URL. (I made git-send-email do that in 2016, too)
