Introduction

This document provides a high-level overview of the identified dependencies for the Mall on Rails project, including purpose, versioning, contact information, and contingency plans.

Internal Dependencies

Internal dependencies are those that originate inside the greater WTI ecosystem. For example, libraries that we created, have direct maintainership over, or otherwise control. These dependencies have unique characteristics:

• They carry less risk of being abandoned, because we are directly responsible for their care.
• They carry a higher risk of causing project delays, because changes that need to be done with them will fall to us directly.

External Dependencies

External dependencies are projects, libraries, or services that are necessary for the project that do not originate inside the greater WTI ecosystem. These dependencies must be evaluated for at least the following criteria:

• Risk of being abandoned upstream.
• Risk of security issues on overall project security.
• Ability to contact project maintainer, vendor, or support agent with issues.
• Version lifecycle and project-specific policy on upgrades.

Preface

This document contains preliminary information about a forthcoming software product from Wilcox Technologies Inc.

The information contained within may not reflect the final product, and may change rapidly during the development process.

Always ensure you have the latest document revision before raising an issue.

Abstract

This document describes identified dependencies of Mall on Rails, a software project being developed by Wilcox Technologies Inc.

Overview

We have identified the following internal dependencies:

• Adélie Linux, used as the operating environment for Docker images.
• Finland, used for infrastructure for Web and database services.
• WTI SSO, used for authenticating logins to the administration panel.

Adélie Linux

Adélie Linux is used as the base operating environment for the Docker container which runs the Rails application portion of the Mall on Rails system.

CI test runs are performed on systems running Adélie, which are the ppc64 and x86_64 CI Linux/Ruby runners in the WTI GitLab instance.

Updates to the system are included on Docker build via the apk upgrade -al command in the Dockerfile.

Testing updates to the system before integrating for an image build, for example if the Ruby interpreter is updated upstream, can be accomplished using TPCL.

Finland

We will utilise the Finland server infrastructure for hosting both the Web and database infrastructure for Mall on Rails.

The initial Key Treasures deployment will be run on our existing server systems as it is considered internal to WTI. Deployments for external customers will be deployed on one or more servers that are dedicated to running customer workloads. Each deployment will have a dedicated Web and database container. Containers will run in parallel, that is, multiple customer systems may be running on the same physical server. This has security implications. It is assumed by the developers that any security holes that would allow for container escape will be mitigated as soon as reasonably possible to keep customer data secure.

WTI SSO

Administrator logins to Mall on Rails will utilise the WTI SSO infrastructure.

The Key Treasures deployment will use our existing LDAP system. Customer deployments will use LDAP groups to allow for centralised authentication, allowing them access to services like GitLab as well. This group-based authorisation will be part of the configuration of Keycloak and will not require modification of the Mall on Rails system.

If a customer wishes to self-deploy Mall on Rails, they will need to set up database authentication using the Devise gem. This scenario is outside the scope of this planning document.

Overview

We have identified the following direct external dependencies:

• Bulma, used as the base CSS framework for the frontend.
• CarrierWave, used as a library for handling uploaded images and generating thumbnails.
• Dart Sass, used for compiling user-facing CSS.
• Devise, used for authenticating customers and administrators.
• Font Awesome, used for iconography.
• jQuery, used as a JavaScript framework for optional enhancement of the Administrator Panel.
• OmniAuth, used for communicating with external systems for user authentication.
• OmniAuth Apple, used as an OmniAuth provider for Sign In with Apple support.
• OmniAuth Facebook, used as an OmniAuth provider for Sign In with Facebook support.
• OmniAuth SAML, used as an OmniAuth provider for SAML based administrator sign in support.
• PostgreSQL, used as the database storage system.
• RuboCop, used to ensure adherence to best practices and catch some types of security issues in a static scan.
• Ruby on Rails, used as the Web application framework.

We have identified these indirect external dependencies:

• Hotwire, used as a site-wide JavaScript framework.
• ImageMagick, used by MiniMagick for image processing.
• MiniMagick, used for generating thumbnails with the CarrierWave library.
• omniauth-rails_csrf_protection, used to prevent CSRF attacks on OmniAuth forms.
• Puma, used as the interface between Rack and the TLS terminator.
• Ruby SAML, used by omniauth-saml to process SAML.

The following development-only dependencies are outside of the scope of this document, but are still mentioned here for full system documentation.

• FactoryBot, used for creating mock objects in the test suite.
• RSpec, used for the test suite.
• SimpleCov, used for generating test suite coverage data.
• SQLite 3, used in the development and test environments to ensure future portability to other RDBMS if necessary.

Bulma

External contacts

The Bulma repository on GitHub includes a public issue tracker. Merge requests can be performed for any improvements we identify locally.

Security posture

As a CSS framework, there is virtually no way to use Bulma to exploit the Mall on Rails system. If upstream was somehow compromised, the only way to exploit development systems would be through Dart SASS.

Abandonment risk

Bulma has a great community, and project lead Jeremy Thomas is a dedicated steward of the web design community.

When we are able, financially supporting Bulma would be highly recommended.

If somehow Bulma became unmaintained upstream, it would still be usable for the Mall on Rails project, just without further updates or improvements. We would need to determine what would be needed for future browser compatibility, and work with the wider community to determine interest in maintaining a fork of it.

Versioning policy

Mall on Rails will continue using updates to the Bulma 1.x branch. Assuming a release of a 2.0, evaluation shall take place within one month of release, including determination of whether the 1.x branch will receive further updates, the amount of churn required in the MoR codebase, and any new features that would be directly useful for MoR.

CarrierWave

External contacts

The CarrierWave team is reachable via their public GitHub issue tracker. Security issues can be reported privately via GHSA.

Security posture

CarrierWave is used for handling:

• Collection thumbnails
• Item photos and thumbnails
• Site logo (header) and favicon

All of these endpoints are only accessible by administrators. For the Key Treasures deployment of Mall on Rails, the threat is very small as WTI SSO enforces 2FA for all WTI staff. For customer deployments, this does provide a potential entrypoint to reach into the container and attempt to perform a container escape. This threat is low, as store provisioning involves a manual verification of business legitimacy.

Abandonment risk

CarrierWave is a very mature gem including multiple corporate sponsors and nearly a dozen publicly listed members in the GitHub organisation. It is very unlikely to be abandoned.

Versioning policy

Point releases will be picked up by bundle during our monthly updates.

If a major upgrade (4.0) is released, evaluation shall take place within two weeks of release, including how the release will affect MoR, code changes needed for compatibility, and continued maintenance of the 3.x branch.

Dart Sass

External contacts

The Sass team is reachable via their public GitHub issue tracker. Security policy is not defined.

Security posture

Any exploit in Dart Sass (including in the Dart language runtime, which has significant trust concerns itself) could allow a malicious update of Bulma to compromise a developer workstation. This is not a very likely attack method as it requires the discovery of a Dart Sass vulnerability, the ability to push to the Bulma repository, the ability to release a version to RubyGems, and for it to not be caught by anyone until after our monthly update cycle. Still, it is a security consideration for the MoR project.

Abandonment risk

Dart Sass is the reference implementation of the Sass language. It is very unlikely that it will be abandoned, and if it were, our CSS frameworks would likely be forced to respond by changing to an alternative language.

Versioning policy

Any update will be pulled in via bundle during our monthly updates.

There are already deprecation warnings when we build our bundles due to Font Awesome, so future updates will need to be measured against compatibility with our stack. We don't pin Dart Sass ourselves, relying on FA/Bulma, but we can always pin to a specific version if needed and if it does not affect our security posture.

Devise

External contacts

The Devise team is reachable via their public GitHub issue tracker. Security reports are taken via a private Google Groups alias.

Security posture

OmniAuth is used to authenticate both external customers and administrators. Any security vulnerability in OmniAuth or any of the plugins that we use (termed strategies upstream) could allow unauthorised access to the administrator panel, or customer order history. This makes OmniAuth one of the most critical dependencies for the security of MoR.

Abandonment risk

The Devise project is mature and its primary maintainers have a consultancy around it. It is very unlikely to be abandoned. If it were, the wider Rails community should be surveyed to determine if continued maintenance could be negotiated between us.

Versioning policy

Minor / point releases will be pulled in via bundle during our monthly update.

If a Devise 5.x were to be released, evaluation shall take place within one week of the release. We have a large amount of test coverage, so core flows are unlikely to break. However, we use custom views for the Customer sign in (to support our OmniAuth flows) and OmniAuth controller integration which would need to have deeper inspection for continued compatibility.

Font Awesome

External contacts

The Font Awesome team is contactable via public GitHub issue tracker, email, and a Pro support contract. Security reports are taken via a private email.

Security posture

Font Awesome is primarily a client-side icon font used for iconography in the Mall on Rails system. It does use the Sass language, so it can potentially be used in a chained attack as explained in the Dart Sass section. Additionally, any supply chain attack on Font Awesome could have repercussions as font processing libraries are historically responsible for a number of Web browser security vulnerabilities.

All in all, we rank the overall security risk low, but still present.

Abandonment risk

Font Awesome is a popular font icon library, maintained by a company that has significant sponsorship, and also has an open source component. It is very unlikely that it would be abandoned. If it were to be abandoned upstream, it would still be useable in its present state by Mall on Rails for the foreseeable future, especially since the Web Font standard is unlikely to see churn.

Versioning policy

We utilise Font Awesome 6. Font Awesome 7 was announced the day this document was written. Since Font Awesome is the source of the entirety of our deprecation warnings during Sass compilation, we expect to evaluate its suitability for Mall on Rails within two weeks of its release.

jQuery

External contacts

The jQuery team is reachable via their public GitHub issue tracker, email, and IRC. Security reports are taken via private email.

Security posture

jQuery is used in the administrator panel for optional quality-of-life enhancements including multiple collection selection and multiple photo upload. It is also used for the "carousel" functionality of the item gallery for the customer-facing site.

We do not perceive any security risks, as no untrusted input is given to the library. However, JavaScript is in general a minefield, so we rate the risk Low instead of Very Low.

Abandonment risk

jQuery is run by the OpenJS Foundation, whose members include IBM, Microsoft, Joyent, GoDaddy, and the German government. It powers over half of the Web. It is virtually impossible to even fathom it being abandoned.

Versioning policy

We have vendored jQuery 3.7.1 in Mall on Rails. jQuery only supports a single major version, so when 4.0 is released, 3.x will be unsupported. They provide a migration tool for each major version that will allow us to evaluate the upgrade easily. Evaluation of jQuery 4.0 shall take place within one month of the release, including testing our (limited) dependent functionality and ensuring browser compatibility with our target platforms.

OmniAuth

External contacts

The OmniAuth team is reachable by their public GitHub issue tracker. Security reports are taken via Tidelift.

Security posture

OmniAuth is used to authenticate both external customers and administrators. Any security vulnerability in OmniAuth or any of the plugins that we use (termed strategies upstream) could allow unauthorised access to the administrator panel, or customer order history. This makes OmniAuth one of the most critical dependencies for the security of MoR.

Abandonment risk

OmniAuth is a mature gem with support via Tidelift and private sponsors. It is used by GitHub, GitLab, dev.to, FreeRADIUS, and others. It is very unlikely to be abandoned, and it is very likely that (at least) one of the Git forges would take up maintenance if it was required.

Versioning policy

Minor / point releases will be picked up by bundle during our monthly updates.

If a major release (3.0) is released, evaluation shall take place within one week of the release. This must include determination of compatibility with our used strategies, our error handling code, and test of flows for each strategy.

OmniAuth Apple

External contacts

There is a public GitHub issue tracker.

Security posture

This gem is responsible for the Sign In with Apple authentication strategy and therefore is of high importance for the security of MoR. Sign in bypass could expose customer order history to a third party attacker.

Abandonment risk

It is the opinion of the authors of this document that this gem has already been abandoned. It has had no activity in two years, and multiple pull requests fixing issues and potential security risks have gone unmerged.

We believe it is in the best interest of WTI, moving forward, especially if we are going to use this gem in future projects (such as Curator or Palmerston), that we should consider forking this gem and releasing our own version.

Versioning policy

Any updates will be pulled in via bundle during our monthly updates.

OmniAuth Facebook

External contacts

The maintainers are reachable via the project's public GitHub issue tracker.

Security posture

This gem is responsible for the Sign In with Facebook authentication strategy and therefore is of high importance for the security of MoR. Sign in bypass could expose customer order history to a third party attacker.

Abandonment risk

The project's README notes that maintainers are desired. There are stale pull requests dating to 2018 (7 years), despite a recent release (May 2024).

We consider there to be a high risk that the project could be abandoned, or changes to Facebook's API or OmniAuth rendering it unusable or broken.

Versioning policy

Any updates will be pulled in via bundle during our monthly updates.

In the event of a major release of OmniAuth, this gem will need to be evaluated deeply. It may require a fork if the OmniAuth strategy API changes in a significant fashion.

OmniAuth SAML

External contacts

The OmniAuth team is reachable by their public GitHub issue tracker. Security reports are taken via GHSA.

Security posture

This gem is responsible for the WTI SSO authentication strategy used for authenticating administrators. It is therefore is of critical importance for the security of MoR. Sign in bypass could expose all aspects of the storefront to a third party attacker, including customer addresses, order histories, and API credentials for Stripe, Facebook, and others.

Abandonment risk

This gem is maintained by the OmniAuth group themselves. There is very little risk to it being abandoned without the wider OmniAuth project suffering abandonment. See the discussion in the OmniAuth section.

Versioning policy

Updates will be pulled in via bundle during our monthly updates.

In the event of a major release of OmniAuth, we expect this gem to move with it; updates will be evaluated at the same time as OmniAuth.

PostgreSQL

External contacts

The PostgreSQL team, along with a very wide community, are contactable via mailing lists and IRC. Commercial support is available via partners.

Security posture

The database holds all customer order history information, authentication information for customers who choose to use a password, and self-hosted administrator authentication information. As such, PostgreSQL is one of the most critical dependencies for security in MoR.

However, it runs in its own container, which isolates it from some issues. Additionally, Active Record sanitises SQL query parameters, making it harder to exploit from public endpoints. Due to these mitigations, we have ranked it a Medium risk.

Abandonment risk

There is a public Foundation, multiple consultancies, and several Fortune 50 enterprises relying on PostgreSQL. It is very unlikely to be abandoned during the lifetime of MoR.

Versioning policy

Presently, all WTI systems have standarised on PostgreSQL 16, which will remain supported until 2028. We plan on evaluating 18 some time in mid-2026.

If, for some reason, release 18 is inappropriate, 17 can be evaluated as a replacement. 19 is scheduled to be released before 16 is retired as well, providing us multiple options for update and upgrade.

RuboCop

External contacts

The RuboCop team is reachable via their public GitHub issue tracker. Security reports are handled via Tidelift.

Security posture

RuboCop is a development-only dependency. It is mentioned here only because it is used to perform scans which include potential security vulnerabilities. This includes our custom cop which ensures all Admin controllers inherit from AdminController, which ensures that admin resources require authentication.

Abandonment risk

RuboCop has multiple enterprise sponsors, including Airbnb, Coinbase, and DigitalOcean. It has a very well funded OpenCollective and a well defined team including many contributors. It is also part of Tidelift. For these reasons, we find it very unlikely to be abandoned.

When we are able, financially supporting RuboCop would be highly recommended.

If it were to be abandoned, it would still be useful to the Mall on Rails project in its present state. Further maintenance would likely be performed by the community.

Versioning policy

We presently pin RuboCop to 1.56.x, because that is the version used by the built-in GitLab CI/CD pipeline. When the GitLab CI/CD pipeline is updated, evaluation shall take place within one week. This includes ensuring that our code still meets any built-in expectations and that our custom cop still works correctly.

Ruby on Rails

External contacts

The Ruby on Rails team is reachable via their public GitHub issue tracker. Additionally, a Discourse instance and an official Stack Overflow tag are both available for non-security related issues. Security issues are reported via HackerOne.

Security posture

The Rails framework is the underpinning of MoR and therefore is a critical dependency for the security of MoR.

Abandonment risk

The Ruby on Rails project is maintained by the corporation that started it and uses it, to this day, in their products. It is very unlikely to be abandoned.

Versioning policy

Presently, MoR uses Rails 7.1, matching the version of Rails in use for the Website project. Both MoR and Website are planned to update to 7.2 in Q2 2025, which is before the 7.1 EoL date of October 2025.

Rails 7.2 will EoL in August 2026. We plan to evaluate Rails 8 by the end of Q4 2025. Future updates will track a yearly cadence.

Hotwire

External contacts

The Hotwire team is reachable via their public GitHub issue tracker. Security policy is not defined.

Security posture

Hotwire, including Turbo, is used in the entire application on browsers with JavaScript enabled (which is virtually all of them). A security issue inside Turbo, while very unlikely, could cause any number of client-side risks.

Since Turbo caches pages and DOM content, admin content may persist after an administrator signs out (i.e. of a public computer) if the tab is not also closed.

It is for this reason that we classify Hotwire as a medium risk.

Abandonment risk

Hotwire is developed by the same developers as Ruby on Rails, and therefore has a very low risk of abandonment. See the Ruby on Rails section.

Versioning policy

Our usage of Hotwire comes from Rails and therefore follows their versioning policy. As we update and upgrade Rails, we will receive the co-released version of Hotwire. Evaluations shall be taken as part of Rails evaluations.

ImageMagick

External contacts

The ImageMagick team is reachable via their public GitHub issue tracker. Security reports are taken via GHSA.

Security posture

ImageMagick is used underneath MiniMagick (via CarrierWave) to process images. Image processing is fraught with security vulnerabilities; however, these endpoints are only accessible to administrators. This significantly lowers the risk for the Key Treasures deployment. However, for customer deployments, any method of container escape could risk compromise of other customers. For this reason, we consider ImageMagick to be of medium security concern for the Mall on Rails system.

Abandonment risk

ImageMagick is a well established, long standing open source package with a small LLC organised around it. It is unlikely to be abandoned.

When feasible, it would be highly recommended to financially support ImageMagick.

Versioning policy

We use the ImageMagick package from Adélie Linux. Security updates will be handled by the distro. We will evaluate releases as they are provided in the distro repository.

MiniMagick

External contacts

The MiniMagick team is reachable via their public GitHub issue tracker. Security policy is not defined.

Security posture

This gem is used internally by CarrierWave and therefore has the same security posture as CarrierWave. The biggest inherent risk in MiniMagick could be somehow triggering an unescaped shell invocation which could be used for arbitrary code execution inside the container, which could allow a container escape. This is still a somewhat unlikely scenario, as the only people capable of interacting with MiniMagick would be administrators.

Abandonment risk

The MiniMagick gem is mature and future releases would primarily be to ensure compatibility and feature-parity with future ImageMagick releases. It is not likely to be abandoned. If it were abandoned, the main concern for future directions would be to ensure no security issues are present and ImageMagick compatibility is retained.

Versioning policy

Any releases will be picked up by bundle during our monthly updates.

We do not pin MiniMagick to any specific version, and rely on CarrierWave having their own versioning policy for MiniMagick.

omniauth-rails_csrf_protection

External contacts

The developers behind this gem are contactable at the project's public GitHub issue tracker.

Security posture

This gem prevents an active CVE (CVE-2015-9284) from being exploited in any Rails project that uses OmniAuth. This would allow CSRF attacks on OAuth2 strategies, which includes the Facebook strategy we use. Therefore, this gem is a critical dependency for security in MoR.

Abandonment risk

This project has been maintained for 11 years by mostly the same team that works on OmniAuth. Additionally, the codebase is under 100 lines (not including tests and fixtures), so maintaining our own copy in the event of sudden abandonment would be feasible.

Versioning policy

Any updates will be pulled in via bundle during our monthly update.

If a new version of OmniAuth is released, we may need to temporarily pin this gem so that we can evaulate compatibility with the old version vs new version.

Puma

External contacts

The Puma team is reachable via their public GitHub issue tracker. Security issues are reported privately to the maintainer, Evan Phoenix.

Security posture

The Puma server parses HTTP requests from clients and passes them on to Rack and Rails, which is then interpreted by MoR code. Any security exploit could lead to a DoS or, in the worst case, request smuggling. Therefore, Puma is considered a critical dependency for the security of MoR.

Abandonment risk

The Puma community is vibrant, and has multiple private sponsors. It is considered very unlikely that Puma would be abandoned.

Versioning policy

Presently, MoR uses the Puma 5.x branch, as recommended by Rails 7. This version is still supported upstream for security fixes. We expect to evaluate Puma 6.x in Q2 2025.

Ruby SAML

External contacts

The maintainer is reachable via the public GitHub issue tracker. Security reports are taken via GHSA.

Security posture

This gem implements the logic for SAML authentication, which is used for the OmniAuth SAML strategy used by MoR for authenticating administrators. It is therefore is of critical importance for the security of MoR. Sign in bypass could expose all aspects of the storefront to a third party attacker, including customer addresses, order histories, and API credentials for Stripe, Facebook, and others.

Abandonment risk

The primary maintainer runs his own consultancy around SAML. It is very unlikely that the gem will be abandoned.

It would be great to financially support ruby-saml when we are able to do so.

Versioning policy

Updates will be picked up by bundle during our monthly updates. We are not directly pinning any specific version, though OmniAuth SAML is doing so.

Updates, even patch releases, may have breaking changes per their documentation. We must be careful to test all SAML flows when updating the gem.