Hi on a side note, I am curious about how did you get to know that your company was mentioned in this thread? Did the OP reach out to you first? Or did you find this comment while reading HN?
Yeah, it can be done easily using lockfiles, both yarn and npm allow that. You would seldom run npm update directly in production without testing the updated deps first
We'll be deleting comments on dead links; I don't think they serve much purpose since they don't show up on the main site's aggregator, nor will people likely be visiting dead links with the extension installed.
There's quite a bit of funky edge cases with URLs actually, and we'll just keep chipping away at them based on the feedback we're getting!
There are three types of S3 server side encryption:
- SSE-KMS
- SSE-S3
- SSE-C
Without having an AWS support person test each type and report back, one must assume that the only bulletproof s3 encryption methods are client-side (where you handle encryption and decryption yourself and they just store the blob) and SSE-C (where AWS don't store your keys, you send them in every bucket API request). But even that latter method has other caveats:
- What does the S3 service log? Who can access those logs?
- Where does TLS for your S3 https request get terminated? Who can view the traffic?
I'm assuming that this isn't just a regional issue, and that any AWS Support person globally could access buckets in any region. If so, then that's a big deal. If you're in Europe and your bank or healthcare provider is an AWS customer, how much trouble could you cause them (and by extension, AWS) right now?
Furthermore, with the antiwork movement and backlash amongst employees for their treatment of warehouse workers, one cannot guarantee that an AWS worker wouldn't do something to hurt the company.
Amazon need to head this of with a very thorough explanation of what happened and what was exposed directly and indirectly.
> SSE-C (where AWS don't store your keys, you send them in every bucket API request)
Since this is symmetrical encryption we're talking about, let's just be completely aware that the technical possibility to also store the encryption key definitely exists. It would violate the terms of service, of course.
For those who don't know how SSE-C works, it's that you send both the unencrypted data and a key in a request. AWS will encrypt the data with the key, and store it encrypted. To get your data back, you supply the same key in your subsequent request. AWS will decrypt the data using the key, and send the unencrypted data back to you.
During both those times when you gave AWS your key, you entirely trust that they will not also happen to store it for their own use.
> Without having an AWS support person test each type and report back, one must assume that the only bulletproof s3 encryption methods are client-side
It is normal practice to have a 3rd party access to your technical infrastructure (for example for purpose of support/maintenance). I was once contracted to maintain database for another company. You sign NDAs, you sign penalties, you sign your children to slavery and the right of first night with your wife. You know, standard business practice.
But if you care enough that you would not have contracted 3rd party access to the data, client-side is the only solution assuming the client is under your sole control.
Yes but this role did not add the necessary privileges for it to use customer KMS keys. You can’t get an S3 object that’s encrypted with a KMS key if you don’t also have permission to decrypt with that key.
Of course Amazon could just give themselves access to decrypt with your KMS keys too, but that didn’t happen here.
Objects encrypted with S3-managed encryption keys (SSE-S3) are affected, as these keys are set up with a non-configurable resource policy granting the S3 service decryption permissions.
Yes, but (without being a scholar of religion) I had always assumed that Hinduism was far older than its oldest surviving texts, just as Judaism, in some form, is older than whatever year we date the Torah to.
it depends on what you call 'hinduism'. it's one of the world's most heterodox religions and has absorbed a huge amount of cultural tradition from at least 300 languages.
The rig veda is probably what most people agree is one of the foundational texts of hinduism, but it dates to about 1500 BC.
However, the vedas probably absorbed a lot of earlier cultural tradition from the indus valley civilization, especially worship of Shiva-like deities. How much is however, debated.
just like mesopotamia, there was a lot of syncretism.
I imagine that when your career is arts based, you've likely assimilated that society's labels are arbitrary and determined in large part by competitive interests, because there is less of a fundamental truth than they would imply once established. Since this is a software engineering forum, we tend to expect more objectivity in our labels. Ironically when you think about it because software labels are so obviously artificial.
My read is that it's the other way around. i.e. what one could reasonably call Judaism is a good deal younger than the Torah, Hinduism a good deal younger than the Vedas. There are of course traditions within the religions that go back to those writings and further, but take that to its extreme and they all presumably stem from some ur-religion.
