Marginal benefit, I'd say. It's an additional check that you're getting the expected file.
I've heard anecdotally that the checksums once identified a case where an rsync had been interrupted and result in a truncated file.
Before we dig into the details, we'll first give an overview of how the relevant parts of the CPAN ecosystem work.
If you're not interested in the details, skip to the section "What do you need to do?"
TL;DR: make sure your CPAN client uses https and a trusted mirror – such as cpan.org
]]> How a CPAN module gets from the author to youAn author creates a new module and wants to share it on CPAN. They build a release, and upload the resulting tarball to PAUSE, where it goes into their author directory (my PAUSE id is NEILB and my author directory can be found on CPAN at https://www.cpan.org/authors/id/N/NE/NEILB). If the uploader has the relevant indexing permissions, PAUSE will update the CPAN Index. The Index is a big file which lists all modules on CPAN; here's the entry for the "enum" module, which I currently maintain:
enum 1.12 N/NE/NEILB/enum-1.12.tar.gz
It says "if you want enum, the latest version is 1.12 and it's found in the tarball enum-1.12.tar.gz at this path in the authors directory.”
PAUSE also generates checksums for all files in author directories. Every directory has a file called CHECKSUMS (here's an example CHECKSUMS file for user GLASSER. After generating a new CHECKSUMS file, PAUSE signs it with GnuPG.
If you want to install a module, you can download the tarball and install it manually, but most people use a CPAN client. There are four main CPAN clients (cpan, cpanm, cpm, and cpanp) but we'll describe use of cpan, which is the client that's bundled with perl itself. To reduce confusion, we'll use "CPAN.pm" to refer to this client (that's the module that the cpan script uses).
To install the module, you run:
$ cpan Foo::Bar
The client makes sure it has a recent copy of the index, and looks for the module. If it's in the index, the client looks up the associated tarball and downloads it, along with the CHECKSUMS file that's in the author's directory on CPAN. The client generates a checksum for the downloaded file and compares it with the one in the CHECKSUMS file, and if they match, it goes ahead and installs it.
By default CPAN.pm doesn't check that the signature on the file is valid, but you can optionally enable that check as well. Since it's not enabled by default, the vast majority of us haven't been checking for a valid signature.
If you want to know more, you could start with a blog post on how PAUSE and CPAN work, and read a CPAN glossary which defines the terminology.
There were three issues identified, each of which has a separate CVE. This is a summary here; read the original advisory for the full story. Here are the CVEs: CVE-2020-16154, CVE-2020-16155, and CVE-2020-16156.
All three issues involve someone setting up a malicious CPAN mirror, and getting people to start using it.
The first issue is that the CHECKSUMS file only included the name of the tarball. For example, here's a snippet from the CHECKSUMS file in my author directory, as they appeared before the changes described below:
'Date-QuarterOfYear-0.04.tar.gz' => {
'md5' => '8dd1a29e60af035a652aee121ab0919d',
'md5-ungz' => '85ba26240f1396a147dcc09413a97db4',
'mtime' => '2021-06-14',
'sha256' => '1d13f55e5a1e84a7b05ce8cfd1d4cf9d9da80addd8f5f9fc845d2973daa06200',
'sha256-ungz' => 'b4808c921b994656498ed74fbbba0677ff88d9624dabeabc4ef4f97b0655482f',
'size' => 10763
},
There's no mention of the path there. Someone could create a malicious version of my module and upload a file with the same name to their PAUSE where it winds up in their author directory. Then they could upload copies of everything else in my author directory to PAUSE, so that their author directory looks the same as mine, except one file has been replaced with their malicious copy. Their author directory will have a CHECKSUMS file which looks the same as the one in my author directory, apart from different hashes for the one modified file. Plus it's been signed by PAUSE. They can set up their own CPAN mirror that swaps their author directory in place of mine, and if anyone downloads this tarball, even with the signing of CHECKSUMS validated, they get the malicious code but it looks like it’s coming from me.
The other two CVEs are for an issue that affects both CPAN.pm and cpanm. These again relate to someone setting up a malicious CPAN mirror. They can generate checksums for a directory and prepend an unsigned version of the checksum data to the CHECKSUMS file. Both CPAN.pm and cpanm will take the unsigned checksum data, ignoring the signed version that's also in the same CHECKSUMS file. It turned out that if you enabled the signature verification checks in CPAN.pm and cpanm, if an unsigned version of the CHECKSUM data has been injected above the signed data, then the clients would happily install the tarball for you anyway.
The first line of protection is to not use untrusted mirrors. In the early days of CPAN, when the internet was slower and more flakey, most of us used a local mirror, so a network of hundreds of CPAN mirrors sprang up. In 2021 they are largely irrelevant. Since 2019, the mirror list was truncated to just www.cpan.org. Most CPAN clients already default to this or to cpan.metacpan.org (which we also consider a trustworthy source).
If an attacker controls your network traffic, then they could inject malicious tarballs and checksums as well. Using https is the easiest thing you can do here.
CPAN.pm has defaulted to use only cpan.org since 2013 and with the truncation of the mirror list in 2019, any newly configured CPAN.pm clients are not vulnerable to a malicious mirror. The latest release of CPAN.pm will use https if at all possible.
PAUSE has been updated so that the CHECKSUMS files now include cpan_path
for each file, which gives the relative path to the directory for which the checksums were generated. CPAN.pm will fail to validate if the paths don’t match so a signed CHECKSUMS file can’t be used from a different directory without detection.
CPAN.pm has been updated so that if you have configured it to validate the signature on CHECKSUMS, it will refuse to install a tarball if the associated CHECKSUMS file isn't signed.
In this section we'll summarise how the various CPAN clients work as of 2021-11-23, so you can make an informed decision on whether to continue using your current client, whether to upgrade, reconfigure, or to switch.
check_sigs
to true, it will require the CHECKSUMS file to have a valid signature.--verify
option tells it to validate the signature and content of the CHECKSUMS file.prefer_bin
to true, and configure hosts
for https, then it will use https://www.cpan.org as the source.Use only https://www.cpan.org/ or https://cpan.metacpan.org/. Do not use any other mirror that you have not personally verified is trustworthy.
Here’s how to configure that in different CPAN clients:
prefer_bin
option to true and make sure you've got curl installed. Then set the hosts
parameter to { 'scheme' => 'https', 'path' => '/', 'host' => 'www.cpan.org' }
If you insist on using an untrusted mirror, configure your CPAN client to verify CHECKSUMS. Here’s how to do that in different CPAN clients:
check_sigs
option set to true ("o conf check_sigs true" then "o conf commit"), it will check the signature as well.At the moment CPAN clients can't make https mandatory, because Perl doesn't support https out of the box. We've raised this on p5p, and this will hopefully lead to an RFC and support for https in the not-too-distant future.
Fixes are being worked on for cpanm, so unsigned CHECKSUMS will be fatal if you've given --verify, and also to support the cpan_path key in the CHECKSUMS files.
We're hoping that CPANPLUS will be updated to try and use https by default, as we've done with CPAN.pm.
The best way to ensure you're downloading the original versions of CPAN releases is to use a trusted CPAN mirror, and only talk to it over https.
If you are aware of any further potential security issues with PAUSE, or the CPAN clients, you can raise them via email to the PAUSE Admins private email list: pause-admin at perl dot org.
Firstly, thank you to Stig Palmquist, who identified these issues, and who has been patient and helpful as they were being addressed.
As ever with Perl, this has been a team effort of volunteers. Thank you to the CPAN client authors and others, who have worked on changes, and in some cases are still working. Thank you to everyone who read drafts of this post, and improved it with their input.
]]>Can you give a bit more details on how you use taint please? Very few people have said "yeah, I love taint, please keep it", so it would be helpful to hear more details. Thanks!
]]>In this post I'll explain what we're considering, and why. The purpose of this post is to let everyone beyond p5p know about this, and give you a chance to comment.
]]> One of the themes for work being done on p5p is tidying up Perl — removing features that aren't widely used, or which turned out to be a bad idea. There are a number of reasons why we might do this:One such feature is taint mode. When taint mode is enabled, Perl runs various checks, such as ensuring that path directories aren't writable by others. In taint mode any data that came from outside your program, for example by reading it from a file, is marked as tainted. Any expression that involves tainted data is itself tainted. You can launder the data to remove the taint flag. See the section in perlsec for more details.
Support for taint mode adds a runtime overhead, that we think is on the order of 10% in some scenarios. This overhead affects all Perl programs, whether or not you're using taint mode.
If you're concerned about the security of your code, you're probably familiar with the OWASP top 10, and will be doing a lot more than taint provides. As a result we think very few people use taint mode. Therefore we think it is a candidate for removal from Perl.
The path we currently envisage is this:
We're interested to hear what people think about this. Maybe more of you use taint than we think, in which case we might stick on step 1 of the above plan. If you want to give feedback on this, add comments here or on reddit.
]]>We want to express our disappointment with the recent transparency reports and associated actions from the Community Affairs Team (CAT).
On Monday 19th March, a first Transparency Report was issued, which said that an individual had been investigated for (1) behaviour on IRC and Twitter, and (2) behaviour at a Perl event in 2019. The report also reported that they had "found many instances of communication which alone may not have constituted unacceptable behavior, but when taken together did constitute unacceptable behavior", but no further details were given on those. The report issued a ban from all TPF events "in perpetuity", and furthermore issued a ban on the individual’s participation on irc.perl.org and any perl.org mailing lists. A second individual was issued a warning.
Prior to the 19th, one of the Perl Steering Council (PSC) members explicitly asked you not to issue a ban, saying that the PSC were already starting work on improving discourse in and around p5p. That person felt that a ban would be counterproductive when the PSC were trying to improve things in a more inclusive way. The second event was the Perl Toolchain Summit (PTS). The incident was investigated at the time, resulting in two of the organisers (Philippe Bruhat and Neil Bowers) asking the individual to leave. He left peacefully, expressing regret that he had upset and offended the other party. The PTS is not a TPF event.
Nearly two weeks after the initial report, TPF issued a Transparency Report Update, which retracted parts of the first report, but left other parts hazy. For example, the first report mentions other "unacceptable behaviour", but gives no further details in either report. The warning for the second individual was retracted.
The use of "transparency" seems incongruous:
These behaviours don't demonstrate the values and behaviours that we could reasonably expect of a body investigating community affairs. As the most visible and official Perl organization, TPF should hold itself to a higher standard.
This felt like a clumsy attempt by TPF to establish control over all Perl communities, and only when you got push-back did you attempt to wind some of that back. You do not have jurisdiction over IRC, email lists, or most other parts of our communities. It is not TPF/CAT’s role to request that people stop participating. We have not given you consent to unilaterally define policy across our communities, nor impose punishments on behalf of them.
We are all firm supporters of codes of conduct, where the goal is to set expectations for behaviour. Many of our individual communities have long defined and enforced their own guidelines and standards of conduct. That said, we believe that our communities could benefit from harmonising standards. This was an opportunity for TPF/CAT to demonstrate leadership, and start bringing our communities together towards a unified policy. Instead the TPF acted seemingly without consideration for the varied needs and devolved leadership of the communities it purports to represent.
This is not to say that we condone the individual's behaviour. Some signatories to this letter were part of the governing bodies that issued the initial corrective actions on the two incidents the CAT cited. We also do not want to diminish the upset and offence that the individual has caused to a number of people over the years.
We would like to see TPF acknowledge its failings in how this has been handled, and make changes to ensure these aren't repeated, but we're not looking for a blood-letting and further division. We would like to see this debacle as a catalyst for our communities coming together to move things forward. We need to clarify the organisation and governance structures of our communities, and start the process of defining common values and expectations around behaviour. This needs to be a community-led activity: given recent events, we don't feel that TPF/CAT is currently fit for a leadership role in this, but we would absolutely want your participation.
In volunteer communities such as ours, leadership is about doing the hard work of building consensus, not imposing your will on the rest of us. Leadership should be a service we provide to our communities.
Signed
Andreas König, Chief PAUSE Admin, White Camel award recipient
Andrew Shitov, conference organiser, White Camel award recipient
Ask Bjoern-Hansen, Perl NOC, runs perl.org, White Camel award recipient
Chris Prather, Admin for irc.perl.org, White Camel award recipient
Dave Cross, Perl trainer, regular speaker, author, Facebook group admin, White Camel award recipient
Kenichi Ishigaki, CPANTS Admin, PAUSE Admin
Neil Bowers, PAUSE Admin, event organiser, PSC member, White Camel award recipient
Olaf Alders, MetaCPAN founder and project lead
Philippe Bruhat, longtime event organiser, White Camel award recipient
Robert Spier, Perl NOC, runs perl.org/pm.org , White Camel award recipient
Thomas Klausner, event organiser, CPANTS Founder, White Camel award recipient
Tim Bunce, founder of the Module List, PAUSE Admin Emeritus, author of DBI, White Camel award recipient
Kent was a prolific contributor to CPAN and Perl. He released more than 150 distributions of his own to CPAN, but also helped countless other authors and distributions, with bug reports, puil requests, and more.
When a CPAN author dies, their indexing permissions are dropped from PAUSE, and where they had the first-come permission, that will be passed to the pseudo-user ADOPTME. This flags the distribution as being available for adoption.
So as of now, all of Kent's distributions are available for adoption.
]]> If you look at Kent's author page on MetaCPAN, you'll see 178 distributions (at the time of writing). This means that he was the last person to release those distributions, but in a few cases he didn't have the first-come permission.When you look at his author page on MetaCPAN, notice the leftmost column, with the blue bars. The bars are an indication of the distribution's position on the CPAN River — a measure of how many other CPAN distributions use that distribution. The more bars, the more dependent distributions. If you hover your mouse pointer over the bars, you'll see the number of dependents.
As you can see, many of Kent's distributions are relied on by other CPAN distributions, and in some cases by thousands. As a result, the PAUSE admins will consider adoption requests carefully, and try to ensure that such distributions are passed into safe hands.
When you release a new module, PAUSE assigns you the first-come indexing permission for the module. This means that your releases of the module will be considered for inclusion in the CPAN Index, and also that you can give other people the co-maint indexing permission. People with co-maint can do releases, but they can't grant co-maint to others. For more on indexing permissions, see the relevant section in the PAUSE Operating Model.
If you want to contribute to someone else's distribution, and do releases of it, then the usual model is that you talk to the person who has the first-come indexing permission, and they'll give you co-maint. You haven't adopted the distribution, you became a contributor.
Adoption of a distribution is the process of being given the first-come indexing permission on all modules in the distribution. Most of the time it is the current maintainer (the person with first-come) who transfers the indexing permissions, but in special circumstances, the PAUSE admins can do this.
If you want to adopt a distribution, please email the PAUSE admins (modules at perl dor org), and make your case.
If it's a distribution that doesn't have any dependents, then you just need to explain your interest, and demonstrate that you have experience as a CPAN author.
The further up the CPAN River the distribution is, though, the stronger your case will need to be: you should have experience maintaining similar modules, both in terms of dependencies, and the type of module. If your existing distributions are tier 0 or tier 1 (either no blue bars or 1), then you'd have to make a strong case for anything above tier 3.
Here are the sorts of things we'd expect from a tier 3+ author:
A more thorough discussion of this topic can be found in Tux's release checklist.
This is not meant to discourage you from adopting a distribution, rather to encourage you to step up, but not to overreach. If the prospect of adopting a distribution terrifies you with the prospect of breaking half of CPAN, it's probably not the right one for you. At least for now.
If you have used one or more of Kent's distributions, maybe you could consider adopting one of them, to keep it maintained going forward. It's a great way to give back to the Perl community.
If you don't already have a PAUSE account, maybe this is a good time to sign up for one?
]]>So if you've got repos with issues that you'd be happy to receive pull requests on, add the topic hacktoberfest, and make sure that your repo turns up in searches.
]]> Opt-in to hacktoberfestWhen you're looking at the Code tab of your repo, you'll see "About" on the right, with a cog:
If you click on the cog, you'll get a popup, and in the middle of that you'll see a text box for entering topics. Add hacktoberfest as a topic.
You can find Perl repos on github that have been opted in to Hacktoberfest using these two terms in their search box:
language:Perl topic:hacktoberfest
Or just use this link: Perl hacktoberfest repositories on github.
When you search for repos on github, it doesn't return forks. If you created the module and created the repo, then you're fine. But if you adopted a CPAN module, and forked the previous maintainer's repo, then your repo won't turn up in the search.
I have adopted a number of modules, and started off by forking a gitpan repo. So when you look at the repo, you see something like this:
End-users can't break that "forked from" link. If you want to do this you have to get in touch with GitHub support. Tell them that you want to break the link with the repo that you originally forked from, and give them the URL for your repo. They were pretty responsive for me, last night.
So now my Text-Table-Tiny repo looks like this:
And now that repo turns up in a search.
]]>If you're interested, please read this post, and if you still would like to adopt a distribution, contact the PAUSE admins (modules at perl dot org) and not Gisle.
]]> Gisle's distributionsIf you look at Gisle's author page on MetaCPAN, you'll see 34 distributions (at the time of writing). This means that he was the last person to release those distributions, but in a few cases he doesn't have the first-come permission (see the next section).
The distributions that aren't available for adoption are:
When you look at his author page on MetaCPAN, notice the leftmost column, with the blue bars:
The bars are an indication of the distribution's position on the CPAN River — a measure of how many other CPAN distributions use that distribution. The more bars, the more dependent distributions. If you hover your mouse pointer over the bars, you'll see the number of dependents.
As you can see, many of Gisle's distributions are relied on by hundreds, and in some cases thousands, of other CPAN distributions. As a result, the PAUSE admins will consider adoption requests carefully, and try to ensure that such distributions are passed into safe hands.
When you release a new module, PAUSE assigns you the first-come indexing permission for the module. This means that your releases of the module will be considered for inclusion in the CPAN Index, and also that you can give other people the co-maint indexing permission. People with co-maint can do releases, but they can't grant co-maint to others. For more on indexing permissions, see the relevant section in the PAUSE Operating Model.
If you want to contribute to someone else's distribution, and do releases of it, then the usual model is that you talk to the person who has the first-come indexing permission, and they'll give you co-maint. You haven't adopted the distribution, you became a contributor.
Adoption of a distribution is the process of being given the first-come indexing permission on all modules in the distribution. Most of the time it is the current maintainer (the person with first-come) who transfers the indexing permissions, but in special circumstances, the PAUSE admins can do this.
In this case, Gisle is happy for his distributions to be adopted, but wants the process to be managed by the PAUSE admins.
If you want to adopt a distribution, please email the PAUSE admins (modules at perl dor org), and make your case.
If it's a distribution that doesn't have any dependents, then you just need to explain your interest, and demonstrate that you have experience as a CPAN author.
The further up the CPAN River the distribution is, though, the stronger your case will need to be: you should have experience maintaining similar modules, both in terms of dependencies, and the type of module. If your existing distributions are tier 0 or tier 1 (either no blue bars or 1), then you'd have to make a strong case for anything above tier 3.
Here are the sorts of things we'd expect from a tier 3+ author:
A more thorough discussion of this topic can be found in Tux's release checklist.
This is not meant to discourage you from adopting a distribution, rather to encourage you to step up, but to not overreach. If the prospect of adopting a distribution terrifies you with the prospect of breaking half of CPAN, it's probably not the right one for you. For now.
Thank you to Gisle for everything he has done for Perl, CPAN, and our community.
]]>We had wondered about delaying it, or seeing whether there's interest in a virtual PTS, but right now we all have much more important things to worry about. When the time is right, we'll see what makes sense.
In the meantime, stay safe, and look after yourselves, your loved ones, and your neighbours.
Philippe, Laurent, Thomas, & Neil
]]>This blog post is brought to you by Fastmail, a gold sponsor for PTS. More information about Fastmail is provided at the end of this article.
]]> As a seasoned participant at the Perl Toolchain Summit, we wanted to ask Rik a few questions related to Perl and the summit, including why the event is valuable to companies like Fastmail. For this interview, Rik is being asked questions by Lacey Althouse, one of his colleagues at Fastmail (FM).FM: How did you get started using Perl?
RS: When I was going into high school (for non-Americans, roughly aged 16), I hadn’t been programming for a while. I had done some BASIC and C, and just a little Pascal and Hypercard, but I hadn’t touched much of it in years. A friend of mine convinced me I should install Linux, promising that it would give me much better control over what I was doing with my computer, and I listened. At the time, this meant running Slackware Linux, which shipped with Perl. I think my attention got drawn to it because around that time, Perl 5 was pretty new, and the installer would ask, “Do you want good old fashioned Perl 4, or new experimental Perl 5 with lots of weird new features?” I picked Perl 4 and used it for all kinds of simple one-off tasks. For me, it was a glorified awk, which was useful but not very interesting. I probably would’ve forgotten all about Perl if it wasn’t for almost ten years later, when I found myself writing PHP (4!) to build in-house applications at my first job after college. I kept thinking, “There must be a way to break these programs up better than I can right now!” and that led me back to Perl 5, which made it much easier to componentize my software, test it, and re-use it. I stuck with it and kept diving deeper into the toolchain of libraries that made all that possible.
FM: Tell me more about why Fastmail uses Perl. How is Fastmail participating generally in open source communities?
RS: Perl is flexible and reliable. It has a few strong opinions, but for the most part it’s eager to give you the freedom to write your bugs in whatever idiom you’d like. This means that it can be easy to get started on solving problems without first internalizing a weird, foreign conception of reality. Some terrific languages only work when you submit to their model of reality, which can pay off, but can also be limiting, especially when your view of the world changes over time. With Perl, we can build a system the way that makes sense to us, but still integrate with the software written by the rest of Perl world. (Another one of Perl’s strength’s is the huge amount of software out there to reuse!) Despite all this flexibility — which means internal complexity — Perl has been very good about remaining stable over the years. Backward compatibility is a big priority for the ongoing development of Perl and its supporting infrastructure, which means that upgrading to newer versions rarely includes much cost. The cost gets mostly swallowed by the Perl system maintainers, instead.
FM: What’s the best part of working at Fastmail?
RS: I’m terrible at picking favorites, so here are a few. The people are great, and we’ve done a good job at keeping individual teams connected. They’re all very good at different things, and it’s good to know that there’s almost always somebody who’ll be able to answer any question correctly and also — and this is key — clearly. The product is great. I feel like we’re building something used by real humans to address their real human problems, and we actually talk to our customers to figure out how we can most effectively make their lives easier. Our values are great, but only because we’re really invested in them. We spend time, effort, and money on trying to keep the internet open and trying to keep your data easy to manage not just in the browser, but all through the stack. I also very much like being able to visit the National Gallery Victoria (Fastmail’s HQ is in Melbourne, Australia) a few times a year on the company’s dime!
FM: How long have you been participating in the Perl Toolchain Summit and what are some of the main benefits of attending?
RS: To my great surprise, I was invited to the first PTS in 2008, in Oslo. Back then, though, we called it the Perl QA Hackathon. We renamed it because we’d sometimes be told “well, a hackathon is more a bunch of people working a bunch of twenty-hour days to produce a half-baked proof of concept.” What we were doing was something else. We worked normal hours and tried to come up with plans and solutions that would last for years to come, even with only the limited time we had to work on them.
I think there are two big benefits, for me. Firstly, I’m able to feel like I’m putting my money where my mouth is. I put in real effort to help fix problems in the CPAN toolchain and to make it as resilient as possible, rather than just hoping for the best. This also means I can try to make the toolchain an ecosystem that works at least somewhat how I’d like, so I feel comfortable working on it continuously over time.
Secondly, and more personally, I always find my time at PTS to be reinvigorating. It’s several days where I’m disconnected from other work and put into a room with a few dozen really motivated, talented people who all share the same goals as me, at least in the broad strokes. When I head home, I often feel like I can accomplish anything.
FM: What’s the best part of the summit?
RS: Well, I’d be lying if I didn’t say it was reconnecting with all the people who I love working with but only see once a year. On a more work-oriented topic, though, it's the debates we have about weighing progress against stability. Perl has a well-earned reputation for not breaking things during upgrades, and the toolchain is where we’re at our most conservative. The debates about what we can change, how, and over what time frame are interesting both technically and on another level that speaks to how different people view the cost and benefit of technical change.
FM: What’s next for your work with Perl and/or at Fastmail?
RS: These days, I’m mostly an observer in the big changes in Perl, but I’ll continue to work with the toolchain gang to keep the CPAN going strong. I half-threatened to start a complete rewrite of PAUSE, the CPAN upload server, this spring. So far, though, I haven’t followed through, which might be the best thing for everybody involved!
We (Fastmail) have quite a few cool things planned for the near (and less near) future, from user-facing features (like better undo) to protocol-level enhancements (like JSCalendar) to internal updates (like new hardware platforms). Right now, I’m most excited when I see more and more of our internal tools move from legacy protocols to JMAP. I’m also working hard to continue to improve our ability to function effectively as a two-site company, in part by adding staff (for example, hiring to build a client and UI team in Philadelphia) and in part by improving our tooling for communication and documentation.
Also, there’s some discussion about installing a disco ball in the office, which would be another pretty good development!
Fastmail is email, calendars, and contacts that give customers privacy and control. While other companies ask users to give up their privacy in exchange for email, at Fastmail, customers are treated like people, not products. Since 1999, Fastmail has provided a human-centered email alternative by putting customers first and offering reliable service, customer privacy and support, and thoughtfully designed experiences. Fastmail works to make email better for everyone through their work on open standards projects like IMAP and JMAP. JMAP is a new email standard that has been recently introduced through RFC8260 and RFC 8261 at the Internet Engineering Task Force (IETF).
Fastmail has developers in Philadelphia, USA and Melbourne, Australia, who work in Perl on a regular basis, and is often hiring. Job opportunities can be found at: fastmail.com/about/jobs
Ricardo Signes led the core Perl 5 programing language team for five years. During that time, he established the Standards of Conduct for the development community. He’s a prolific CPAN author, part of the "Toolchain Gang" that maintains the PAUSE and CPAN infrastructure, and is a noted speaker at Perl and open source conferences around the world. Currently he is a member of the Perl Foundation’s Board of Directors and CTO at Fastmail.
If you want to read more about Rik’s time as Pumpking, you could read this interview, from 2016.
]]>