Ryan Voots

ED: This is also posted on reddit, https://www.reddit.com/r/perl/comments/zp8d5g/perl_fediverseactivitypub_social_network/ so please check there also

A while back I bought the https://perl.social/ domain without much immediate use for it. I originally had it redirecting to the perl twitter community. However with the recent twitter drama going around I started setting up an activitypub based network to take the place of the twitter community in the advent that there was an exodus of Perl programmers from twitter. That seems to have been happening so I finally kicked into gear to get it ready for use.

https://perl.social/ should show you the public face of the community, (if it doesn't let me know). In the upper right you'll find the login button, and can register a new user. Once registered, like all fediverse things you'll be able to be followed by people as such @username@perl.social and can follow other users on other servers by putting them in the search box at the top and then following them.

I've set it up using Friendica as the backend of the social network, as it offered some features that I felt were important.

1. Moderate resource usage, mastodon tends to be rather heavy to run.
2. Child/group managed accounts, so say the Perl Steering Committee can have an account that is managed by the people in it rather than there being a fully separate account with it's own password
3. SAML support, hear me out on this down below
4. Some other addons that look like they'll be interesting going forward like the twitter plugin to let users post to perl.social and mirror the posts to their old twitter accounts.
5. Mastodon API support, this should let mastodon clients and some other fediverse clients work with the site too, enabling more things to be done. We should really develop a Perl client for all this too.

On the SAML front, this ended up being a desire when setting up the site because none of the current fediverse systems really seem to provide first class support for MFA and a lot of user management tools that I believed I would need once things were up and running. I setup Keycloak to be the identity provider for this all since it'll handle all the passwords reasonably securely, can allow for things like github login or other OIDC providers, etc. This should make running the site a lot less burdensome going forward since users should be able to add WebAuthn, FIDO, TOTP and a few other things to keep their account secure.

It should also let me create a small slightly privileged group that can help do account recovery and other tasks without giving them easy access to reading people's DMs or other private things.

Things left to do:

Create a proper Terms of Service and Code of Conduct. Long term these will be fairly critical to keeping the site safe to use and helping enforce any community rules that get made. I'm looking for any kind of advice on how this should be done as it shouldn't just be me making these kinds of decisions. Right now you can assume that at least the following vague rules exist: "Don't be a jerk in a way that gets me yelled at, Don't do anything illegal, Be excellent to each other" until anything more formal is created. Once it is, we'll be able to make it show up on everyone's next login so that they can read it and agree or read it and come complain to me.

I've reserved a number of names that have both been requested and ones that I believe would be contentious to have someone registered (perl, psc, p5p, etc.) and if those groups or people are ready to take them over then just message me and we'll get it worked out.

When registering, the email is almost certainly going to go to your spam folder right now. The fact that we're on a non-standard TLD, and the email is being sent by a VPS, means that the server reputation just doesn't exist and isn't trusted yet. It should eventually get better once more people mark it all as not spam but I'll also eventually also look into getting it sent by a real provider that won't have those issues, but I'm not going to pay for that until it actually makes sense to do so.

Please check it all out and let me know about any issues you run into, or let me know if you want to help. I've started getting the infrastructure setup so that I can start letting people help but it wasn't the first priority to getting it all setup.

With the upcoming 5.26 release series of Perl, there's a breaking change that's part of the release. The current directory, '.', is being removed from @INC. It's a good thing, it deals with a bunch of potential security problems and has been discussed more thoroughly elsewhere http://www.nntp.perl.org/group/perl.perl5.porters/2017/03/msg243763.html and http://www.nntp.perl.org/group/perl.perl5.porters/2017/03/msg243722.html

This means that a number of common patterns in many perl scripts, particularly tests, no longer work the way that they did in the past.

use inc::Module::Install;  # To get the bundled copy of Module::Install with a CPAN dist

# Usually used to setup some common test environment
#  or common functions for the tests
require 't/common_thing.pl';
use t::common;

# I'm not sure what the actual common use of this is, but it's also impacted.
do 'config.pl';

All of the above are going to fail to locate the files that you'd previously expect. Instead you'll get an error like this:

Configuring HTML-Tree-5.03 ... Can't locate inc/My_Build.pm in @INC 
  (you may need to install the inc::My_Build module) (@INC contains: 
    /home/ryan/perl5/perlbrew/perls/perl-blead/lib/site_perl/5.26.0/x86_64-linux 
    /home/ryan/perl5/perlbrew/perls/perl-blead/lib/site_perl/5.26.0 
    /home/ryan/perl5/perlbrew/perls/perl-blead/lib/5.26.0/x86_64-linux 
    /home/ryan/perl5/perlbrew/perls/perl-blead/lib/5.26.0) at Build.PL line 4.

There's a few things you can do to work around or fix your modules for this change.

# Quickly add '.' back into @INC, 
# not what I'd recommend as it just brings back the
# same potential security issues that need to be fixed
# but it will fix most issues almost immediately
use lib '.';

# explicitly say you want it from ./, This will also help prevent it
# from trying to load an appropriately named file in @INC that you didn't expect    
require './t/common_thing.pl'; 
do './config.pl';

With this big of a change, nobody really knew exactly what the impact would be on either users or CPAN, so a stop-gap measure was put in place. New versions of CPAN and CPANMinus now set the environment variable PERL_USE_UNSAFE_INC to tell perl to put '.' back into @INC when they're building, testing and installing modules. This works well enough but does mean that a badly written dist can still be subject to the potential problems that having '.' in @INC. You can prevent this, by explicitly setting the environment variable yourself to 0 but many modules will then fail to build or test properly.

Watching the p5p mailing list I saw some chatter about this that seemed that nobody had a complete picture of just how much of CPAN was actually impacted by this. There were a few users using the normal CPAN smoking tools to try to figure this out, but those tools won't find problems in some cases, i.e. something depends on something that's also broken. So I built a custom smoker to run through everything referenced on cpan in the index or as a dependency of another dist, and test them with '.' both in and out of @INC to see if they'd fail and then be able to continue on to anything that depended on them regardless of if they passed or failed.

It's taken a few weeks but it's finally finished running through every module it can. It's identified 2996 dists on CPAN that don't build with '.' removed from @INC. You can get a complete list of those failures, and the build logs, at http://cpan.simcop2387.info/failed.html

Of the failures, 2096 appear to be caused by/related to Module::Install and not being able to find inc::Module::Install during some phase of cpanm installing the module. I've also produced a report for every author at http://cpan.simcop2387.info/by_author/ There's also a list of all authors with failing modules, and how many they have at http://cpan.simcop2387.info/authors.txt.

There's also a gigantic 10MB page of every test result, http://cpan.simcop2387.info/test.html but be careful it'll make your browser hate you.

In the next few days I plan to rerun every failure to look for fixed modules and to clean up some of the general failures (those that failed regardless of @INC) by fixing up the most depended on modules and others that are easy to deal with. There are a few that I know failed during some periods where my internet went down and so those will get cleared up by rerunning them.

The code I used to produce all this can be found at https://gitea.simcop2387.info/simcop2387/treedeps. There's two storable files also in the repo that contain data about the tests: modcache.stor has the entire dependency tree for cpan (excluding loops), everything.stor has the high level test results and the order of how everything was tested.