tursodatabase / tursodatabase/libsql

Support AWS credential profiles in bottomless S3 replication ##

Open
#2,121 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
17.2k
Forks
531
Avg merge
1h 12m
Merged PRs (30d)
1

Description

Currently, libsql's bottomless S3 replication feature only accepts AWS credentials through environment variables:

  • LIBSQL_BOTTOMLESS_AWS_ACCESS_KEY_ID
  • LIBSQL_BOTTOMLESS_AWS_SECRET_ACCESS_KEY
  • LIBSQL_BOTTOMLESS_AWS_SESSION_TOKEN (optional)
  • LIBSQL_BOTTOMLESS_AWS_DEFAULT_REGION

The implementation does not read from the standard AWS credentials file (~/.aws/credentials) and doesn't support specifying a particular AWS profile.

Problem

This limitation creates several issues:

  1. It doesn't align with AWS best practices of using credential files and profiles
  2. It requires users to explicitly set environment variables even when credentials are already configured
  3. It makes it difficult to use in environments with multiple AWS accounts/roles
  4. It doesn't leverage the AWS SDK's built-in credential chain capabilities
Proposed Solution

Enhance the AWS credential handling in bottomless S3 replication to:

  1. Follow the standard AWS SDK credential provider chain
  2. Add support for reading from ~/.aws/credentials
  3. Add an optional environment variable to specify which profile to use
  4. Fall back to environment variables if no profile is specified or found

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the bottomless S3 replication credential-handling entry point and reviewing how the listed LIBSQL_BOTTOMLESS_AWS_* variables are consumed. Compare that behavior with the AWS SDK credential provider chain and determine the intended profile environment variable. Done means credentials can be loaded from the standard AWS credentials file, a selected profile is supported, and the existing environment-variable behavior remains available.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws
Domain
cloud
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.