Proposal to provide an api for sharing secrets

[yassinm]

An Api for sealing and un-sealing secrets could be useful for a locally encrypted payload. As such someone could use the tool from any programming language.

An example APi could be an endpoint with TTL and a payload with the encrypted text as in :

POST /v1/seal/
body:
{
  ttl: 2,
  ttlTyp: "hours",
  encText: "EWRYERTYER",
}

Feel free to change the payload and the url. This is just an example

[chronark]

This would be simply storing pre-encrypted data right?
I would assume it simply returns an id, where you can later retrieve it like this:

GET /v1/{id}

{
  "remainingReads": 4,
  "expires": 129417238
  "encText": "EWRYERTYER"
}

Or am I misunderstanding the idea?

[yassinm]

That is correct ! The get should return whatever was stored in the {id} . But maybe with a /v1/unseal/{id} endpoint to be future consistent. Naming things is hard ! and so is naming endpoints !

[chronark]

ok got it, makes sense

[Mahmoudgalalz]

I was saying the same thing on twitter, If you want to implement a serverless function for that, I'm open to help

[chronark]

Yeah let's do it.
I'm just not 100% sure on the path names yet.

Maybe POST /api/v1/secret and GET /api/v1/secret/{id}

Do you have a suggestion?

[chukwumaokere]

POST /api/v1/secret and GET /api/v1/secret/{id}

I'm for these route names. Keeps it RESTful.

POST /v1/seal/ and GET /v1/unseal/{id} isnt really good because RESTful resources should be named after the resource noun not a verb per the standard. It also makes assuming what the POST/GET route is very easy for new users

Also kudos using NextJS 13.1
I help out in the Vercel community with Next13. I should be able to get PR up for this addition shortly

[Mahmoudgalalz]

I will say we will have the two option as an interface, and as an endpoint

POST /api/v1/secret and GET /api/v1/secret/{id}
those names are more easy to understand, and most Key value DB follow the same approach, so it's not going to be smth new to the community of DevOps or SRE, and also, we should consider the return type to be text or json, and the text for example to be a bash or powershell, to inject them immediately to the system

export API_URL=https://name.com/api

for curl usage
curl -s https://envshare.dev/api/secret/{id} | bash

and we could build a small CLI to make it really easier, so we should plan those two options

it will be cool tool, cuz it's quite harder to pass env from CI/CD to an instance

let me know if you are ready to make those happen, I can handle both and work on them together

[chukwumaokere]

A cli tool would be cool, but I think that would warrant another proposal so we can design it separately and properly, should the maintainer (Andreas) want to support/maintain that.

I'm currently working on the public API routes for POST /api/v1/secret and GET /api/v1/secret/{id}

[Mahmoudgalalz]

I would like to create the CLI, I have a previous expreiance to build it, also consider the options

That I told you about that, api can response text
As we could make it export the env and inject them to the system or we can leave this to the CLI,

This is would make a point for us cause there's no tool for that

[Mahmoudgalalz]

I going to add this enhancement as an issue to discuss there, and I take a look at your pr, It was good and the same as the store file

[chronark]

Yes sounds good, thanks for creating #13

[chronark]

I see two options for the POST /api/v1/secret endpoint

1. Treat the request body as the secret in plain text or json or whatever the user wants, configuration like ttl will be in http headers (ENVSHARE_TTL: 60)
2. Require the request to be json, similar to the existing api route

not 100% sure what's better here

[Mahmoudgalalz]

This is would be clear and good to pass those to the header, it would be a better option