phasmantistes

Sorry, can you clarify what you mean by this? The ACME spec (RFC 8555: https://www.rfc-editor.org/rfc/rfc8555.html) fully specified both the HTTP-01 (Section 8.3) and the DNS-01 (Section 8.4) challenges nearly four years ago. The TLS-ALPN-01 challenge was fully specified in RFC 8737 (https://www.rfc-editor.org/rfc/rfc8737) about a year later.

In addition, the new work mentioned in this letter is ARI, or ACME Renewal Info, which is not directly tied to any of the aforementioned renewal methods.

The new ACME feature isn't just about surviving the revocation event itself. Suppose that the new API didn't exist, but every client polled on a daily basis to check to see if their cert was revoked. Then great -- within 24 hours, every server gets the new replacement certificate.

And then 60 days later, every single client tries to renew that certificate. That's another 200 million certs in 24 hours. And that'll repeat every 60 days.

So the ACME draft is also about being able to pro-actively smooth out that renewal spike. Some clients would be told to renew again immediately, less than 24 hours after their replacement. Others would be told to wait the whole 60 days. And then after a couple months of managing that, things would be back to normal.

While I appreciate and agree with the last section regarding replacing GitHub's "fork" model with something lighter-weight, it amuses and saddens me that the author puts a lot of effort into describing something that they feel is wholly novel... but is actually just the model already implemented by Gerrit (https://www.gerritcodereview.com/). There are alternatives to GitHub already! Some do things better than GitHub already! Give it a shot.

The reader team didn't exist (and hadn't for years) at the time the decision was made to shut it down.

That's actually not the argument that was made, as I understand it. The argument was that the Java API -- by virtue of being part of Java, which was openly released -- was also open. The APIs that MicroG is reimplementing don't seem to have been openly released in a similar fashion.

I love this paragraph of the Request:

> The singular includes the plural; the plural includes the singular. The masculine gender includes the feminine and neuter genders; and the neuter gender includes the masculine and feminine genders. "And" as well as "or" shall be construed either disjunctively or conjunctively, to bring within scope of this Special Order all responses that might otherwise be construed to be outside the scope. "Each" shall be construed to include "every", and "every" shall be construed to include "each". "Any" shall be construed to include "all", and "all" shall be construed to include "any". The use of a verb in any tense shall be construed as the use of the verb in a past or present tense, whenever necessary to bring within the scope of the document requests all responses which might otherwise be construed to be outside its scope.

I've seen similar paragraphs on other legal documents, but this is the most thorough I've seen. It's basically just a huge middle finger to all (any?) armchair lawyers who want to weasel out of the order.

In Chromium (well, actually depot_tools[1], the closest thing Chromium has to a developer SDK) we provide `git freeze`[2] and `git thaw`[3]. These behave similarly to 'stash', but instead of taking your content and putting it who-knows-where, they commit it on top of your current branch in a special FREEZE commit (or multiple commits, if you have both staged and unstaged changes) which they then know how to thaw out again. Our other tools (such as `git rebase-update`[4]) also know how to deal with FREEZE commits, and can automatically thaw them for you when you go back to working on that branch.

[1] https://chromium.googlesource.com/chromium/tools/depot_tools... [2] https://commondatastorage.googleapis.com/chrome-infra-docs/f... [3] https://commondatastorage.googleapis.com/chrome-infra-docs/f... [4] https://commondatastorage.googleapis.com/chrome-infra-docs/f...

Some projects (like Chromium) squash all of the contributor's commits into a single commit representing their entire local branch history (it was local, no one needs to see their "aw shit I broke the tests" commit), and then rebases that commit and lands it directly on top of master.

Please update (perhaps by switching to getting Chromium from a PPA). Chromium 37 is nearly 2 years old, and is missing many features and many security fixes.

Likely also related to the fact that this is arguably the first time than an iPhone release has removed a feature. The highest top-level comment in this thread is about the removal of the headphone jack, and that subthread alone has 644 comments.

That's actually exactly what "standard" means in a discussion where people know we're likely referencing ISO and IEEE.

Yes, sandboxing and ephemeral machines are far and away the best defense a CI system has against compiling/testing malicious code. But the vast majority of CI systems don't actually use ephemeral executors because imaging between runs is slow and rebuilding your whole checkout/object cache is expensive.

You don't need to own the CI server in order to own a project. You can take over all of the individual executors and replace their linker with your own version that links against an attacker-supplied backdoored fork of openssl (for an extreme and topical example). Doesn't even require constantly-running code which might be detected by a monitoring system, and naturally persists across reboots (but not reimagings).

I'm glad that GitLab is paying attention to these things. The Travis which is tightly integrated with GitHub also seems to do a good job, although I haven't looked into it extensively. But plenty of orgs run self-hosted CI that simply isn't up to proper security standards in this respect.

The armonica is a truly beautiful instrument, but in terms of technical difficulty and impressive performance I still much prefer original many-cups-of-water glass harmonicas/harps: https://www.youtube.com/watch?v=QdoTdG_VNV4

Owning someone's CI system via the CI system is all well and good, but not surprising in the slightest. All these things expose web-based admin interfaces, so of course they're vulnerable at the very least to social engineering.

The real trick is owning someone's CI system via the code under test. And it's even more versatile because it works even for projects which keep their executor scripts checked in to source.

1) Check out and gain an understanding of the target's CI scripts

2) Create a pull request (or whatever) which makes some reasonable code change but also introduces a vulnerability into the build/test scripts themselves. For example, curl'ing a domain you control.

3) Kick off pre-commit runs of all the tests to see if your patch should be accepted.

4) Own all the devices testing your patch.

Yep, it's due to gofmt, which enforces tabs for all semantic indentation and spaces for all alignment indentation (which means lines never start with a space).

Why does running the simulation with N>6 cause a stack overflow? In this naive implementation, the deepest the recursion stack can be is N^2 cells, which for (e.g.) 7 is only 49 cells deep. That shouldn't be enough to cause a stack overflow, even in a js interpreter like this.

This is actually what I did in my first internship -- generating Delaunay triangulations (or more often, tetrahedralizations) of points, and then adjusting the underlying sets of points to help ensure that the corresponding Voronoi cells have good properties (generally reasonable surface area to volume ratios).

We didn't use Fortune's for historical reasons (the first versions of the code were in Fortran 77, and written well before he published his paper). Instead we generated triangulations and then flipped edges until they were Delaunay, and then used the corresponding Voronoi diagram. It turns out that flipping edges to produce a nicer triangulation is reasonable in two dimensions, but intractable in 3D and up.

The OP actually cites that project as the method they use for initial polygon generation, and tells everyone to go read it.

You don't want to work for a company that operates that way anyway, if you can avoid it.

Most simple regular expression evaluators are basically state machines. They hold a few variables:

a) what part of the regex am I currently trying to match

b) what point in the string am I currently starting at

c) how much of the string has this piece of the regex consumed so far

Then the state machine basically has three transitions:

* if (b+c) terminally matches (a), increment both (a) and (b) and reset (c)

* if (b+c) matches (a), but more could be consumed, increment (c) and check again

* if (b+c) doesn't match (a), increment (b) and reset (c)

So yeah, you could put in short cuts for things like "well this didn't match because the next piece of the regex is matching on a line ending", but keeping it simple is straightforward and generally smiled upon.

There are a lot of commits in the history of this repo that seem like actual typos on the behalf of the creator of the repo. For example, the line "that among these are life, liberty, and the pursuit of happiness" was accidentally removed here[1], and re-added in the next commit here[2]. It seems silly to have a project purporting to be various drafts of the Declaration to contain diffs which are entirely anachronistic/accidental/have nothing to do with the actual drafting process.

It turns out[3] that Jefferson wrote a first draft (of which only a fragment survives), then wrote the "original Rough draft" which is very similar to the document we know. 47 alterations were made before the vote for Independence, and 39 more between then and the official adoption of the document on July 4th.

I'd really like to see a version of this git repository accurately reflecting the fragment, original draft, all 86 revisions (in approximate order and attributed as well we can), and final version published as the Dunlap Broadside, instead of this anachronistic heap.

[1] https://github.com/usgov/forget-the-king/pull/1/commits/f9ff...

[2] https://github.com/usgov/forget-the-king/pull/1/commits/d041...

[3] https://www.loc.gov/exhibits/declara/declara3.html

I guess I meant the former in terms of it simply being the worker's job to get the review taken down. No actual threat of being fired at all, but the company has given their implicit (or worse, explicit) 'ok' for using that threat as a manipulation tactic.

Both are forms of moral bankruptcy, I was just curious whether the seemingly-desperate employee was a victim or a player.

I'm not sure if I'm more scared of a company that makes horridly insecure devices and then tells its employees "do everything you can, be as manipulative as you can, but get this review taken down", or if I'm more scared of a company that actually tells its employees "I will fire you if you don't get this review taken down".

Because this is a thing I feel strongly about, I'd just like to say: As long as you have more qualified candidates than you have seats to fill, you don't have to lower the bar to increase diversity.

This is demonstrably not true. Suppose I have a pool of 100 candidates, 20% of whom are female. Suppose further that 10% of the pool (8 men, 2 women) meets my "bar", and are therefore people that I want to have in my company. But finally suppose that I only have budget for 2 people, not 10.

By your logic, I should hire 2 men, because dividing that candidate pool in half leaves the women at "less than half of a person". Equivalently, I should leave it up to a coin flip, which has an expected value of E(two men).

But why? Since we have already established that the candidates are in all other respects equal, why shouldn't I choose the candidates that I think will do my company the most good: bring in the most diverse perspectives, life experiences, and skill sets?

Of course it is a simplified example. And maybe you think that expressing an interest in diversity in this fashion is "reverse sexism". But I think it is a clear win for my company, a clear win for women everywhere, and I don't care if it isn't a clear win for men -- we win often enough anyway.

Yes, you're absolutely right. But that's also a terrible excuse: "Oh, the problem is before the candidates reach me, so there's no need for me to do anything to fix the problem myself." Everyone at all stages -- from folks who bully nerds in primary school, to toymakers who promote scientific fields as 'for boys', to college admissions offices, to CS professors, to CS classmates, to hiring processes -- can work together to remove bias everywhere. Just because you think the problem is someone else's fault doesn't mean you can't help solve it.

Because even Ultron doesn't want to `git merge` those personalities, memories, and experiences back together.

Some companies have trade secrets. Do you think Google is really going to let you come in and poke at the Search stack for a week just to see if you're hireable?

This isn't about the number of departments. This is about companies needing to make very real tradeoffs between maintaining their current speed/security/stability and investigating future talent.

I don't think fraud is a driving cause here.

The real cause is downgrade protection. When your browser loads an HTTPS page, it will refuse to load (or at least warn when loading) any other resources over HTTP: js, css, iframes, etc.

This is to ensure that the icon you see in your URL bar is actually accurate: if a page loads over HTTPS, but consists entirely of a single HTTP iframe, that nice green lock is totally meaningless.

So when the OP switched their site to HTTPS-only, they lost the ability to ever display any from HTTP-only bidders. So the set of people bidding on their ad slots went down, the price went down, and their revenue went down.

Assigning pull requests to multiple people is fantastic: sometimes you're modifying a library and want the owner of that library to review your code, but you're simultaneously modifying the clients of that library and want their owners to review the change as well.

Assigning issues to multiple owners is a recipe for complete and utter inaction from all parties involved.