I don’t use Twitter, but if I did, I would certainly want to archive the content of my timeline so I could refer back to it for journalistic reasons, perhaps, via a browser extension? No reason to lock down my “ownership” here, because it’d only be public posts. There are obvious fair use reasons for when I want to quote someone when I do acts of journalism. I’d even be willing to share my archive with anyone else, and advertise the tweet_ids I have in case another journalist wanted them. Sort of like… I dunno, napster? That’d be great.
Previously, they’ve stated that they raised merely to give customers confidence that they are in it for the long haul. You don’t want to buy racks from a company that won’t be around tomorrow. Raising money is likely being used to create a war chest, with some amount of it being used to grow the team and operations, to fill demand, and support their customers. Those functions have to grow sustainably, but the demand also signals to investors that it’s working, and continued investment is a good move.
In reality, it could very well be investors just saying “we’re so happy with how things are going, we want more, take our money!!!”
Closures indeed! A key concept of Scheme that distinguished it from most Lisps at the time:
(LAMBDA ( <identifier list> ) <body> )
Lambda-expressions evaluate to procedures. Unlike most LISP systems, SCHEME does not consider a lambda-expression (an s-expression whose car is the atom LAMBDA) to be a procedure. A lambda-expression only evaluates to a procedure. A lambda-expression should be thought of as a partial description of a procedure; a procedure and a description of it are conceptually distinct objects. A lambda-expression must be “closed” (associated with an environment) to produce a procedure object. Evaluation of a lambda-expression performs such a closure operation.
The resulting procedure takes as many arguments as there are identifiers in the identifier list of the lambda-expression. When the procedure is eventually invoked, the intuitive effect is that the evaluation of the procedure call is equivalent to the evaluation of the <body> in an environment consisting of (a) the environment in which the lambda-expression had been evaluated to produce the procedure, plus (b) the pairing of the identifiers of the <identifier list> with the arguments supplied to the procedure. The pairings (b) take precedence over the environment (a), and to prevent confusion no identifier may appear twice in the <identifier list>. The net effect is to implement ALGOL-style lexical scoping [Naur], and to “solve the funarg problem” [Moses].
Hmm. Is this why rail maps tend to look like circuit traces?
It’d kind of make sense for the operator status map to look like the map you hand out, or put in stations. The design is an abstraction good enough for understanding switching status for operators, why not for riders trying to get to Manhattan Beach?
How many layoffs does a company have to do before realizing it’s in their best interest to start asking other companies to take the employees they don’t want to employ anymore?
Also, 75% placement seems wildly successful. Why isn’t Cisco also a head hunting firm?!
But the encrypted API key doesn't work, it needs to be decrypted first. Let's give the server access to the private key so it can decrypt the API key. We can do this by putting the private key in an env var. But now the private key is unencrypted. Ah, it doesn't work.
You’re thinking too much. When you run the app, the system decrypts the secrets and makes them available as env vars (or some other mechanism).
In an admin ui, you list the names of secrets only, and provide a “reveal” or a “replace” on each one. They are never decrypted unless explicitly asked for.
Is this perfect? Absolutely not. The key is controlled by the company, but it can be derived in a manner that doesn’t allow for the dump of everything if it’s leaked.
My gripe is that, if some additional authentication is then not required for deployments or SSH access, that whoever has access to the admin UI will still be able to access the box and extract all secrets, just with extra steps. There's usually no real security boundary between "admin UI controls the box" and "box requires secrets in plain text".
I still like the approach, but I'm afraid that it feels more secure than it is, and people should be aware of that.
It’s absolute baseline, but yes, it relies entirely on the platform’s permissions model, the administrator who assigns permissions, and the application authors to not create vectors for env var dumps. :)
But honestly, if you’re in the container, and the application running in the container can get secrets, so can a shell user.
_Maybe_ there’s a model where the platform exposes a Unix domain socket and checks the PID, user, group of the connection, and delivers secrets that way? This has its problems, too, like it being non-standard, only possible in some scenarios and otherwise fallible… but better than nothing? If you reap the container when that process dies, you can’t race for the same PID, at least. I dunno
My understanding is this is exactly how Vercel works. The users hadn’t checked the “don’t ever reveal, even to me” box next to the sensitive values. If they had, the attacker would only have been able to see the names of the variables and not their values.
reply