Live data from Hacker News

AWS CodeArtifact: A fully managed software artifact repository service

aws.amazon.com

21–30 of 92 posts

Re: AWS CodeArtifact: A fully managed software artifact repository service

#21
post #11
post #6

Earlier quoted context omitted.

The benefit is being able to keep your existing maven/npm/pip workflows as well as use the same workflow for both internal and public dependencies.

I still don't see what's different. I can configure pip to look at my git server, so that all I have to do is `pip install my_thing` and it will automatically download all public and private deps. I don't know what you mean by "workflow" in this context but this is just about as simple as can be.

You’re not the target user here. In highly secure environments you can’t just “pip install your-thing”.

Re: AWS CodeArtifact: A fully managed software artifact repository service

#22
post #7

It’s frustrating to not see more system package management (deb, rpm) from these new services (github and gitlab for instance). Are others not packaging their code in intermediate packages before packing them into containers?

What's the purpose of intermediate packages if you're already using containers?

Very large c++/python/cuda application that is packed into various different images (squashfs images, but functionally the same).

We end up having a lot of libraries that are shared across multiple images.

Re: AWS CodeArtifact: A fully managed software artifact repository service

#23

The login credentials expire after 12 hours (or less)[1], just like with their Docker registry (ECR). That makes it pretty annoying to use, especially on developer laptops. GCP has a similar offering[2]. And GitHub[3]. [1] https://docs.aws.amazon.com/codeartifact/latest/ug/python-co... [2] https://cloud.google.com/artifact-registry [3] https://github.com/features/packages

I could not disagree more re. the expiring credentials. It is a bad practice to have credentials that never expire, especially on developer laptops, especially credentials of this nature. Developers frequently store this stuff in plain text in their home directory or as environment variables. That's a huge security risk! This service manages the process of generating and expiring credentials automatically, which is awesome.

Re: AWS CodeArtifact: A fully managed software artifact repository service

#24

The login credentials expire after 12 hours (or less)[1], just like with their Docker registry (ECR). That makes it pretty annoying to use, especially on developer laptops. GCP has a similar offering[2]. And GitHub[3]. [1] https://docs.aws.amazon.com/codeartifact/latest/ug/python-co... [2] https://cloud.google.com/artifact-registry [3] https://github.com/features/packages

Can’t imagine any serious tech environment still allowing non-temporary creds. If they do, good luck when the security audit happens.

Re: AWS CodeArtifact: A fully managed software artifact repository service

#25
post #4

I don't get it. The git server you use supports artifacts already. You could also just put all of your artifacts on an S3 bucket if you needed somewhere to put them, which is exactly what this is but more expensive. I don't understand when this would save you money or simplify devops.

For python at least, fetching something from git is far slower than fetching it from pypi.

Re: AWS CodeArtifact: A fully managed software artifact repository service

#27

Earlier quoted context omitted.

You should have a shell alias to rapidly top up your auth token, just like with the Docker ECR. Short lived tokens are best practice, and a 12 hour TTL is reasonable. That’s no more than two auths in a day as a dev.

And every developer needs to have that alias. And all automation needs to be changed to call that command before trying to use pip, or mvn, or whatever. It sucks. No other hosted artifact repository does this.

If only devs had a way to share code with one another...

Re: AWS CodeArtifact: A fully managed software artifact repository service

#29
post #23

The login credentials expire after 12 hours (or less)[1], just like with their Docker registry (ECR). That makes it pretty annoying to use, especially on developer laptops. GCP has a similar offering[2]. And GitHub[3]. [1] https://docs.aws.amazon.com/codeartifact/latest/ug/python-co... [2] https://cloud.google.com/artifact-registry [3] https://github.com/features/packages

I could not disagree more re. the expiring credentials. It is a bad practice to have credentials that never expire, especially on developer laptops, especially credentials of this nature. Developers frequently store this stuff in plain text in their home directory or as environment variables. That's a huge security risk! This service manages the process of generating and expiring credentials automatically, which is a…

This service is for code artifacts. What credential to the developers use to access source code? Do they expire?

It is common for developers to use Git to store source code, in a hosted service like GitHub. It is common to use SSH keys to access Git. Frequently those SSH keys are generated without passphrases. Those are non-expiring credentials stored on disk. If HTTPS is used to access Git, it will likely be with non-expiring credentials.

I'm not saying short lived credential are bad, not at all. I'm pointing out how this service differs from similar services, requiring a change it workflow, which might be annoying to some people. Not everyone is operating under the same threat model.

Re: AWS CodeArtifact: A fully managed software artifact repository service

#30
post #4

I don't get it. The git server you use supports artifacts already. You could also just put all of your artifacts on an S3 bucket if you needed somewhere to put them, which is exactly what this is but more expensive. I don't understand when this would save you money or simplify devops.

It’s not “exactly what this is”. Every time AWS or Azure or GCP releases a service, there are a droves of people on HN decrying them as “just ”, without bothering to understand if that’s actually true. It’s not.

Skim the docs and you will see it is not “just S3”.

Post reply on HN