packetized

I dare say that it’s annoying you as a result of cognitive dissonance about your employer paying six figures to migrate to it.

If you’re being paid well, obviously you’ll be annoyed by concepts contrary to your work.

e: edits are hated, but the downvotes prove out: Kubernetes is simply OpenStack for hipsters.

The finding in TLS-01-003 is surprising to me, mostly because it presupposes a lack of sophistication among users of this library who are also using X.509 NameConstraints. From RFC5280:

  For example, a name constraint for "class C" subnet 192.0.2.0 is represented as the octets C0 00 02 00 FF FF FF 00, representing the CIDR notation 192.0.2.0/24 (mask 255.255.255.0).

As they mention in the findings:

  Typically, subnet masks should be contiguous and the presence of a non-contiguous mask might indicate a typo (such as 225.255.255.0 vs. 255.255.255.0), or potentially an attempt to bypass an access control scheme. Therefore, it is recommended to treat certificates containing non-contiguous subnet masks in their name constraints as invalid.

This seems to run counter to the intent in the RFC. By allowing for a four-octet subnet mask, instead of simply an int to represent the a contiguous CIDR mask, the RFC authors may have intended that more complex IP-based NameConstraints could be constructed. This certainly would make a huge difference for something like an intermediate (CA:TRUE), where it becomes much more economical to specify a sparse mask for a highly templated network. Think certs for network equipment or VoIP phones with regular, repeatable IP addressing across many locations/networks. E.g., a VoIP provisioning system that has an intermediate issuing CA with the following NameConstraints: IP:172.16.0.0/255.255.1.239.

If any change comes from this specific finding, I would hope that it's simply a flag to allow or disallow the use of discontiguous masks. I do understand that this is specific to WebPKI; having said that, if a client is implemented using rustls (with these recommendations enabled) and it happens across a perfectly valid certificate issued by an intermediate with a discontiguous mask in the NameConstraints, presumably it would fail or otherwise break. And yes, I have previously configured precisely this in an intermediate CA.

This is absolutely a false dichotomy. A home-cooked meal is not one conventionally thought of as being from items hyperlocally sourced. At least, not in the last 70-100 years. We’ve had Sears Roebuck and the like for quite some time.

The fact that the OP had to resort to unofficial channels to get satisfaction is the problem, full stop.

I would say that is much more damning of their state of customer interest.

That you would have to communicate this to a customer via HN is pretty damning.

Vault is a phenomenal tool, full stop.

Agreed, I just found the juxtaposition of the two confusing at first.

On mobile, this site has a “toggle high contrast” widget on the left side that seems to directly contravene the points made in the article.

This position seems at odds with a recently opened WHATWG issue.

https://github.com/whatwg/html/issues/4986

The first two nota benes explicitly describe this document being outdated and not what most people expect when it comes to “memory controller”. I am not certain that citing this is a great example.

Arguably, private keys should not ever leave the device on which they were generated.

I’m curious to know what benefits accrue from sending the user’s private key over the wire (even encrypted). It seems a strange concept, at odds with ephemeral key usage.

This whole post smacks of a half-hearted attempt to memorialize Terry, while slyly smearing him.

n.b. I am not defending Terry’s outlook nor besmirching his efforts, simply calling out this post as a not great eulogy.

Your cellphone camera lens likely doesn’t have the requisite light-gathering capacity to burn out the CMOS image sensor in your phone. CCDs (commonly used in DSLR/M43 cameras) are far more sensitive, as I understand it.

Factual information isn’t always useful in another context.

This is an exceptionally self-serving take on the matter at hand. So much so that it’s frankly breathtaking that it’s been upvoted to #1.

Dear Israel del Rio,

As a Mariott and SPG member since history, kindly focus on not disclaiming responsibility in a public forum, since you almost assuredly aren’t as innocent as you claim.

This is a profoundly unhelpful comment.

The term “Windows autism” is pretty repugnant.

if you work for someone, do you owe them anything? beyond a customary standard of duty and notice of departure from employment?

no, Kylie’s Snapchat tweets were almost certainly more expensive (for $SNAP)

why on earth would they owe anything to the company?

Freedom of speech doesn’t mean freedom from consequence.

Title says `GlobalEntry.gov`, link points to `www.globalentry.gov`. And yes, presumably it's misconfigured.

`thisisunsafe` in Chrome.

globalentry.gov has a valid certificate. The link you shared is for www.globalentry.gov. Presumably, the admins there shouldn't simply be pointing www.globalentry.gov at the same IP as globalentry.gov.

This seems quite a bit like Heka. Very excited.

Looks nifty, but I'd ask: why use this over Trufflehog?

https://github.com/dxa4481/truffleHog

Interesting that the data accessed was very specifically only limited to:

* A complete copy of an old database backup containing very early Reddit user data -- from the site’s launch in 2005 through May 2007

* Logs containing the email digests we sent between June 3 and June 17, 2018

Also of note:

"Already having our primary access points for code and infrastructure behind strong authentication requiring two factor authentication (2FA), we learned that SMS-based authentication is not nearly as secure as we would hope, and the main attack was via SMS intercept."

If this doesn't put the nail in the coffin of SMS-based 2FA, I'm not sure what will.