aws / aws/containers-roadmap

[ECR] [request]: Limit generated login password to 2500 characters or less

Open
#1,589 4 comments 53 reactions 0 assignees View on GitHub
ECR Proposed
Dominant language
Shell
Stars
5.4k
Forks
334
PR merge metrics
No merged PRs in 30d

Description

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
What do you want us to build?

Currently, ECR may generate Docker login passwords over 2500 characters (in my testing I see 2714 characters). This is an issue on Windows as Docker uses the wincred API to store the password securely. Wincred has a limit of 2500 characters for a password, so this will always fail on Windows. The only workaround is to remove or rename the docker-credential-wincred binary file to prevent Docker from using wincred. There is no configuration option possible to prevent Docker from using wincred if it is available.

Therefore, ECR should limit the generated password length to 2500 characters or less to support better Windows default installations.

One way to achieve this would be to generate a smaller random blob of data (256 bits of randomness for example) for the password and then when authenticating requests, lookup that blob as the primary key in a table and map it to the larger blob (2714 characters) which contains the necessary authentication/authorization data. This way not much on the backend needs to change except for an initial lookup in a table to get to the data which is currently expected.

**Which service(s) is this request for?**
This could be Fargate, ECS, EKS, ECR

ECR

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.

Described above.

Here are issues from other customers who are affected by this problem:
https://github.com/aws-greengrass/aws-greengrass-nucleus/issues/1140
https://github.com/aws/aws-cli/issues/5636

For Greengrass specifically, we do not want to require our users to perform any additional setup. Simply installing Docker and then using Docker in Greengrass ought to work out of the box.
The impact of not solving this issue is that customers on Windows using Greengrass will not be able to use Docker and ECR together without using some manual workaround and that manual workaround is not secure as the password is stored on disk in plain text.

**Are you currently working around this issue?**
How are you currently solving this problem?

**Additional context**
Anything else we should know?

**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

Contributor guide

Open the contributing guide

Research direction

No repository files, tests, or implementation entry points are named. Start by locating the ECR Docker login-password generation and authentication flow, then review the Windows wincred 2500-character constraint; done means generated passwords are 2500 characters or less and ECR authentication still works.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker
Domain
cloud
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.