ReidZB

Agreed. It's a great loss to the community that they have decided to step away from Stack Exchange: https://crypto.meta.stackexchange.com/questions/1361/im-leav...

I think there's skepticism in the community that NSA et al actually have such a far head-start now.

That said, historically speaking, back in the early 70s DES was being designed. The NSA made some unjustified changes to its S-boxes. At the time, there were allegations that they had made them intentionally weaker. (Or so I've read; I wasn't born yet.) In the early 90s, differential cryptanalysis was discovered for the first time, and it turns out that DES was already resistant to it (unlike other block ciphers at the time): in fact, the NSA already knew about differential cryptanalysis, 20 years ahead of the general public, and intentionally strengthened DES. (Also, IBM discovered it, too, but kept it quiet at the NSA's request.)

I like making the internet less dangerous to handle, so to speak, but there are always trade-offs, and I'm not sure that changing the default brings enough benefit to warrant all the pain.

To me, it seems like it would've been better to use this energy to push the community into opting into SameSite={Lax,Strict} by default (make it a 'best practices' thing). Get it added to automated security tooling, make the browser console print messages for cookies missing SameSite, etc.

Albeit, it is much harder to reach all the web devs in the world, and so some sites may not opt into SameSite and be bitten by CSRF, but that is in line with e.g. X-Frame-Options / Content-Security-Policy. It's not ideal, but it preserves backwards compatibility, which is a thing I value very, very highly.

I work for a company whose endpoints end up being embedded in iframes in external systems, and this change is currently causing no small deal of heartburn for several folks here.

I really don't like that the Powers That Be have decided to make this change, for many reasons:

1. Changing the default behavior of a thing on the 'net that's been around for so long. Like the article says, I can't wait to see the various and sundry things that are all broken as a result.

2. To set SameSite=None and get back to the old behavior (more on this in a second), you need to do... user agent sniffing, because some browsers (as the sibling comment by swang says) will choke on None and fall back to Strict. Great, so sometimes set SameSite=None, sometimes don't set it or else things will break. eye roll

3. As the article says, SameSite=None is only allowed on Secure cookies, which means you actually can't get back to the old behavior. Now, my company has been telling people for years to stop using HTTP (and customers have to contact support to even get HTTP support enabled). However, there are a few enterprise-y holdouts. In several cases, we've had to go be the bearers of bad news. Albeit, there is an undercurrent of glee in finally forcing them to stop being bad stewards of data (assuming they don't just enterprise-policy it away), but still, from a business perspective it's very frustrating.

So, in sum, it'll break stuff that's not updated (my guess: a lot of stuff), setting SameSite=None requires a user-agent-sniffing hack, and even setting SameSite=None is not a complete solution if you're using HTTP for some reason.

And for what, exactly? This would've been nice in 1995, but it's a bit late now. Though, I guess maybe twenty years from now we can rip out (or stop writing) some anti-CSRF code or something.

Ah, well, the output of what I wrote above isn't actually a Docker image. It ends up writing a cross-compiled binary to the local FS, which I then later attach to a GitHub Release. (The goal was to automatically attach platform binaries to a release once it was made.)

...unless your Dockerfile ends up doing that too? If so I'd be interested to see it if you're willing to share!

I read an article[0] on HN[1] recently — it talks about the different types of documentation. To quote it directly:

"Documentation needs to include and be structured around its four different functions: tutorials, how-to guides, explanation and technical reference. Each of them requires a distinct mode of writing. People working with software need these four different kinds of documentation at different times, in different circumstances - so software usually needs them all."

I agreed with its premise — I've found things that only have "story format" docs (i.e. explanation / how-to guides) to be really frustrating. On the other hand, if all that's available is a deep and highly particular technical reference, it's really difficult to get started sometimes.

[0] https://www.divio.com/blog/documentation/

[1] https://news.ycombinator.com/item?id=21289832

I'm not sure if this is the 'right way' or not, but for a recent Go project, I just scripted the build via

    - name: build
      run: |
        docker run --rm -v \
          "$PWD":/usr/src/my-project \
          -w /usr/src/my-project \
          -e GOOS -e GOARCH \
          golang:1.13 go build -v -o my-project-$GOOS-$GOARCH
      env:
        GOOS: ${{ matrix.os }}
        GOARCH: ${{ matrix.arch }}

(GitHub Actions's build environment already has Docker installed/configured, so there's no setup necessary for "run: docker run" to work.)

I did this explicitly because I didn't want to use that "setup-go" action you linked, which at the time (I haven't doubled checked it recently) didn't support Go 1.13. Far better to me to use the Docker image, which has explicit instructions even for cross-platform compilation in its README, than rely on some weird action setup, in my opinion.

I know that Pulumi can use Terraform providers, at least. I'm not sure how good the integration is or if it's in the main way of doing things, though. I'd love to hear more details if anyone here has used it.

I mean, I agree in spirit, but everyone has a different sense of cost/complexity vs. return.

I don't advocate for ever-more-complicated solutions as a rule. e.g. I think multi-cloud setups are probably way more trouble than they're worth for most companies.

I certainly agree that graceful degradation where possible and not too expensive is ideal. For example, if S3 is having problems in one region, being able to fall back (gracefully degrade) into read-only mode might be a nice thing to have.

(In this particular case having a secondary region also probably helps with disaster recovery, which is pretty much mandatory in B2B, for better or worse.)

I think it's still a reduction in risk overall. In the old model, they were vulnerable to S3 failing in one region, a thing that's happened many times. Now they've mitigated the S3-failure-in-one-region issue, at least mostly (though as you point out, how they do so is unknown), and in exchange they've picked up a dependency on Lambda@Edge. But Lambda@Edge, like CloudFront, is a global service distributed across many regions, and to my knowledge AWS has never had a global Lambda@Edge outage.

It's not impossible, of course. Some kind of control plane error could probably knock the whole global service offline. But I'd rather bet on a multi-region service than have all my eggs in one regional basket.

That's a relatively new feature (from November 2018... wow, has it been a year already?). My guess is that they implemented this stuff before that existed or maybe near to its release.

I have not used origin failover either, though I'm pretty sure you're right that this is its exact use-case.

If the "Cross-region replication" line in the picture is talking about the native S3 cross-region replication (as I assume it is), beware the replication latency in this setup. AWS recently released "replication with an SLA" for S3 [0], but at "99.99% of the objects will be replicated within 15 minutes", it's not a good enough SLA to rely on in setups like this.

Presumably Part 2 of this post will address this limitation, or maybe their product isn't affected by it. (I've never looked into Contentful, though maybe I will now -- blog post purpose achieved?)

I'm also not sure if "active-active" is the best name for this setup, since objects can't be written to the 2nd bucket (replication only goes one direction). Generally I associate "active-active" with "writes can happen anywhere", though maybe I'm wrong?

[0] https://aws.amazon.com/blogs/aws/s3-replication-update-repli...

You can do this with `git add -p` as well, except maybe not trivially (ha). There's the 's' command to split hunks into smaller ones, and then there's also 'e' to open the patch in your editor where you can change the raw patch to whatever you'd like, although in my experience editing it correctly is not straightforward.

I agree 100%: if it provides good enough suggestions, it could pay for itself pretty easily on regular day-to-day PRs. (Although: not all 500 line PRs are made equal.)

My original comment was definitely unclear. I actually had two separate thoughts (that I didn't communicate well at all):

(1) if your team has occasional large, automated PRs (code generation, automated refactors, etc), you probably don't want to run this tool on them because of cost, so anyone that has these large PRs and uses CodeGuru probably needs to build a way into their automation to suppress CodeGuru (or build a way to invoke it for specific PRs)

(2) I also wonder if it's good enough to justify the price on regular PRs

We don't have many situation (1) PRs where I work now, but they do come up occasionally. For example, I've used IntelliJ IDEA's structural find-and-replace to do very large automated refactors where CodeGuru would be very expensive and probably provide little value. We also do check in some generated code (we usually don't do this, but there are a couple exceptions where we weighed the tradeoffs and decided checking in the generated code was a better solution, in our eyes).

The code review feature seems too expensive to run on every PR automatically (to me): $0.75 per 100 lines of code. From their example pricing: "if you have a typical pull request with 500 lines of code, it would only cost $3.75 to run CodeGuru Reviewer on it." I wonder if it's actually good enough to justify that price.

> I believe there's a reason that homomorphic encryption has not been broadly accepted as an allowed standard.

Well, yes... Practical homomorphic encryption is cutting-edge research, and standards bodies like NIST aren't going to deal with an area like this until it's much closer to "solved" (by which I mean much more efficient, with more practical applications, widely used and scrutinized schemes, etc.)

I think whether or not LASIK is suitable depends on corneal thickness, corneal steepness, and the level of correction needed, just as a baseline, or so it was explained to me. I was investigating intraocular lenses not too long ago as an alternative because my ophthalmologist advised that I'd probably have difficulty seeing in low-light conditions if I underwent LASIK.

(Apparently my "parameters" are such that I'm in a gray area where some surgeons will perform LASIK, but others won't. My prescription is pretty high in one eye (around -8). I ended up not being a great candidate for any corrective eye surgery, intraocular lenses included.)

Anyway, intraocular lenses are definitely more invasive, but from what I recall they sounded like a better option to me than LASIK in general: apparently vision quality is better than LASIK with IOLs, there's no removal of corneal tissue, and chance for complications was lessened. (Well, as I understood it, there were fewer minor complications, but more possible major complications, which is maybe not a trade-off many people want to make.)

Of course, they cost about 2x as much as LASIK.

I'm pretty sure they are FDA approved, especially given their use in cataract surgery, although the ones in cataract surgery replace the natural lens whereas the corrective type typically do not...

I don't mind systemd and I've administered a lot of stuff with it at this point, well beyond just start/stopping services -- I've written plenty of unit files, written drop-in unit file overrides, written timer units, written auto-mount units, looked at startup timing profiles, debugged issues using journalctl, etc.

If I had to guess, it's probably because I've never ran into any of the weird systemd problems that I see people report sometimes. For me, it's always pretty much just worked, and more often than not it natively has the functionality that I want.

My largest complaint is that I have to bounce across several manpages to write a comprehensive unit file.

Do you count signals as inter-process communication? I'd argue they are, and the init system definitely needs to cleanly shut down the system (using signals, at least). What degree of inter-process communication is acceptable, then?

I can confirm that. We had a single-AZ RDS instance whose underlying storage (a "magnetic" EBS volume) unrecoverably failed, according to AWS. It had to be restored from a backup. Fortunately, "point-in-time recovery" meant there was very little data loss, just some downtime.

(Not that data loss or downtime mattered for this instance, which was just used for internal testing.)

Power-up is very stressful for hard drives, so it's not too surprising that some failed when the power turned back on. EBS does offer spinning rust storage options, so maybe mLab was using those for some of those failed volumes. I don't know if the same is true for SSDs or not.

They did add that: https://aws.amazon.com/backup/

I do something similar, though I use git's built-in aliasing so that I keep everything namespaced under "git". Mine are, for example, "git st" (status), "git ci" (commit), "git co" (checkout), "git dfc" (diff --cached), etc.

That said, my best advice for folks new to git, or folks who find themselves doing destructive actions often, is to embrace WIP commits. I "checkpoint" work somewhat frequently with "git add -A; git ci -m wip". They can be cleaned up later with soft resets, rebases, or similar. Once a commit is created, it's in the reflog, and it's quite rare to lose that set of work, even if a rebase or reset goes "wrong".

I agree that Fastmail's location is problematic, but other than that, I would argue it is a better Gmail already, features-wise.

The latest Assassin's Creed games have single-player microtransactions. It's crazy:

https://kotaku.com/ubisoft-explains-assassin-s-creed-odyssey...

For instance, you could buy things like XP boosters, unique-appearance gear, map unlocks, etc. Though if I remember correctly, you could pretty easily use Cheat Engine to give yourself as much of the microtransaction currency as you wanted—after all, it was a single-player game.

Oh yes, definitely. But SHA-384's output is 128 bits wider, which uses more bandwidth. Although for the AEAD ciphersuites, it doesn't make much of a difference, admittedly.

I'd expect very few clients to negotiate using SHA-384. It's widely viewed as overkill compared to SHA-256, and it hurts performance.

I'm not saying it invalidates the benchmark results or anything—I just wanted to address your "not used" question.

Ah, sorry, I didn't mean to imply that Cryptol itself doesn't matter. It does seem very useful for its intended purpose (though again this is from an outsider's perspective).

Rather, I meant to say that you do still need to worry about what sort of code Cryptol generates if you want to address the points raised in the original article (e.g. clearing secret memory). That was my original point, anyway: Cryptol doesn't address low-level side-channel problems.

As far as integrating FaCT and Cryptol, couldn't you use Cryptol to build the reference version of a construction, then implement a fast and side-channel-resistant variant in FaCT, then use SAW to prove the two were equivalent? (Maybe not as ideal as combining the two languages, exactly, but workable.)

I really appreciate you taking the time to reply. This stuff isn't my area of expertise, obviously, but I still find it very interesting.

Well, it doesn't matter if Cryptol is compiled down to "safe" machine code, like FaCT, right? But that's not something I've seen explicitly stated in the Cryptol docs, so I would not make that assumption myself.

Are SAW or CompCert able to do formal verification around things like ensuring no branching on secrets, ensuring that memory is cleared after use, ...? Or does Cryptol make guarantees about the machine code it generates?

I see that SAW is able to do things like prove that hand-written, optimized code is equivalent to the Cryptol specification, which is certainly very neat - but that does not preclude potential side-channel vulnerabilities in the hand-written, optimized variant. After all, much of the scariness of side-channel attacks is that they're explicitly not targeting the (highly analyzed) mathematics of a construction, but rather its implementation.

I admit I've only ever taken cursory glances at Cryptol, but it's never seemed like a replacement for the sort of low-level programming described in the article. If anything, it goes the opposite way - its Haskell base inherits one of Haskell's flaws, namely that it can be difficult to understand the runtime/performance implications of Haskell code without careful analysis.

Cryptol's README describes it as a sort of standardization/prototyping language.

That said, I don't know these things for sure, and I'd love to be corrected if I'm wrong.

From hours and hours of studying math, those symbols are imbued with implicit meaning - in a way, they are simultaneously a data type, a name, and often a purpose or context (e.g. delta-x).

That's a lot of information for such a compact representation. And that's mostly unconscious, which is great. I really found the Julia example above to be far, far easier to understand than the linked JS (though I think that JS was not particularly great).

To me, it seems like it'd be nice-to-have, but alone, I don't think it would be enough to make me switch languages.