Add in a restriction that only the postbasho user can create packages that start with the name @postbasho/ and we basically have namespaces, right?
Yes. Yes. Yes please.
binarytemple
0
josevalim
Creator of Elixir
If we are going in this direction, then we should have it as: bitcask@postbasho, since it is a valid atom today and it won’t need special quoting:
{:bitcask@postbasho, "3.0.0"}
All Hex SCM needs to do is to check the name for a @ and automatically inflect the app name to be whatever is on the left side of @ and the organization to be whatever is on the right.
2
ericmj
Elixir Core Team
I have never been a big fan of namespaces and I have already voiced my concerns for them earlier in this thread, so I just want to make it clear that I am still not sure if we should add them.
I like that syntax 
.
The idea was to not make this part of organizations because it would require a lot more work on the backend and you would have to add the organizations with mix hex.organization first which would probably be annoying. I was thinking it should just be a different name in the global repository. This means that namespaced packages and private packages in an organization are different in usage and how you declare them but that may not be a bad thing since it makes it very clear what is public and private.
0
josevalim
Creator of Elixir
OvermindDL1
zazaian
Hey @ericmj - could you please comment on the measures taken to ensure the privacy and security of packages scoped to an organization? I’m trying to assess whether organizations are a viable option for my security needs.
Thanks for all the great work on Hex.pm and on the organizations functionality. These are hugely valuable contributions to the Elixir community.
0
ericmj
Elixir Core Team
Hi @zazaian!
This is a very broad question so I will give a general description of some of our infrastructure, how we authenticate access, and store private information. Some if this applies in general to all of hex.pm and some of it is specific to private packages.
All communication to the hex.pm API and repository happens over HTTPS. When a user authenticates a new machine with mix hex.user auth we generate three keys:
- A repository key used to authenticate against the repository when fetching private packages
- An API key for performing read-only actions on the API
- An API key encrypted with your passphrase for performing write actions on the API (for example publishing a new package)
All keys use HMAC, which means we never store your user secret.
Packages are stored on a private Amazon S3 bucket and we use Fastly as CDN to access the bucket. Based on the URL of the request to the repository we determine if the package requires authenticated access, if it does the CDN edge node makes a “preflight request” to the hex.pm API to verify the repository key against our database. Only if it succeeds do we continue with the request to the S3 bucket.
Our API servers run on Google Cloud servers and our database uses Google Cloud SQL with at rest encryption.
As I said this is a broad question so if you can elaborate on your security needs or if you have more specific questions you will probably get better answers. If you have any questions you cannot share in public please contact us on support@hex.pm.
All the code around organizations and private packages is open source so if you want to review the security the best thing may be to look at the sources themselves: GitHub - hexpm/hexpm: API server and website for Hex · GitHub.
7
zazaian
Thanks @ericmj for the prompt and thorough response. I had only briefly reviewed the hex codebase and while I had seen the Fastly CDN and various mirrors, I wasn’t aware of the multi-key authentication process. It’s extremely helpful to have this high-ish level overview of auth and data flow into and out of Hex.pm. I do have some addiitonal questions about controls for wiping data and packages that have been published to organizations, but I’ll forward these to the support@hex.pm. Thanks again for your support here and all of your great contributions to the Elixir community.
0