This month's update captures the work done just prior to the Unversity of North Carolina (and the rest of the world) significantly changing work patterns due to the ongoing COVID-19 pandemic. We hope that all of you are safe and trying to keep your part of the world going strong while we weather the worst of this storm. Please reach out if there is anything you think the community can help you with.
We have created a couple new milestones at GitHub to better capture the amount of remaining work for each release. Until now, the Consortium has provided a roadmap with the big picture changes coming in the next year or two as well as maintaining branches of the main code repository, one for each 'major' release set (aka 4-1-stable, 4-2-stable, etc.). Upon discussion with a few Consortium Members, we will now provide a Backlog milestone for things that are not-yet-pulled-into a particular release. The new 4.2 Backlog milestone captures the items not already specifically targeted for 4.2.8 or 4.2.9. Feedback on this new process is welcome.
In addition to the monthly Technology Working Group, the iRODS Consortium has been holding monthly meetings of the Metadata Templates Working Group for a couple years. This next month, we are adding a third standing meeting for the Authentication Working Group. The existing iRODS authentication plugins allow for a single challenge/response conversation to determine whether to allow a particular API call to proceed. This is insufficient in the face of multi-factor or multi-party authentication protocols (like OpenID, etc.) This new working group's charter is to define and implement a new authentication mechanism for iRODS that is more flexible and can handle the full conversation between a client and third-party identity provider, regardless of the technology chosen to handle the formal authentication. Meetings are scheduled for the fourth Tuesday of each month at 10am Eastern.
New work this month focused on defining a client API whitelist for iRODS. There has long been an understanding that any API available in the source code was available for client and server use (because the server is a client when speaking to another server), but we need something better. Server-to-server communication can be identified and allowed greater latitude to make use of the iRODS API, but regular clients should be boxed in with a whitelist of allowable API endpoints. This will limit the surface area of 'attack' for the bad guys and define a supportable surface for the Consortium moving forward. This will not affect any existing, well-behaved clients.
Other work this month included efforts to make the AWS Lambda function allow S3->SNS->Lambda connections, a finalization of the new Metadata Guard Policy Engine and Logical Quotas, significant progress on the Cacheless S3 plugin with dstreams, and Hard Links for use with NFSRODS.
Metadata Templates Working Group
TRiRODS
New Development Work
Active Development Work
C++-based REST API
C++ S3 API
Storage Tiering Capability
Parallel Transfer Engine
Continuous Integration (CI)
Background Items
Discussion