breser

Endpoint Detection and Response. Basically a new term for antivirus/antimalware but that reports back to defenders and helps them respond to malicious software that may be on the device.

There's one on there that's $28.58 - $8,000.00 per hour that's especially hilarious. Assuming 40 hours a week for 52 weeks that's roughly $60k - $16.6 million for a salary range. Obviously bogus.

That you can make money through arbitrage is not the definition of a security. See my link above.

See the Howey Test: https://www.investopedia.com/terms/h/howey-test.asp

Airline Miles don't grant you access to a portion of the profits from the airline. They aren't an investment. They are a currency for future travel.

Your example is George Floyd.

* He was accused of passing a counterfeit $20 bill, we still don't know if Floyd created the bill or even knew it was counterfeit. For all we know he might have been an innocent victim of someone else. https://web.archive.org/web/20220409101419/https://www.nytim...

* Floyd did not die of the results of fentanyl overdose: https://www.usatoday.com/story/news/factcheck/2021/04/16/fac...

* He died because a police officer knelled on his neck after he was already in handcuffs for 9 minutes and 29 seconds. https://web.archive.org/web/20210410114811/https://www.start...

* They had him in the car but then pulled him onto the ground and started kneeling on him. There were 4 officers present at that point. They did this despite calling for EMS. They did this despite Floyd saying he couldn't breath. They did this despite bystanders pointing out that he couldn't breath. The position continued even after he was clearly unconscious. They only got off his neck when EMS arrived and told them to. With EMS on site and asking for Fire Department help, the police didn't direct the Fire Department to Floyd, delaying their help for 5 minutes. https://www.youtube.com/watch?v=vksEJR9EPQ8

This behavior was so shocking that these officers were convicted of crimes for their behavior. It is VERY rare for police officers to be indicted, let alone tried and convicted for killing someone. I seriously doubt that they would have been tried and convicted if it weren't for the shocking video showing them kneeling on his neck for a long period of time.

I find it impossible to reconcile police refusing to do their jobs with a VERY rare conviction for misconduct that is so utterly shocking. If you don't want what happened to those officers to happen to you, simply don't kneel on someones neck for a long period of time. Carrying out a search warrant for a laptop is unlikely to result in that sort of situation. Simply because there's not really a good explanation for any of the behavior that resulted in Floyd's death on the part of the police.

Maybe they choose not to do their jobs for the other reasons you gave. But the facts of the George Floyd case do not support your conclusion.

For what it's worth the phone portion is a voice call where you have to enter a number with touchtone.

You do not have to even talk to AWS to remove the MFA from the root account. You simply need access to the phone number on the account (though there are ways around the phone number, see below) and the email address for the root account.

It's been a little over a year since I've done it but as I recall this is how it goes. You receive an email with a link that takes you to a site that starts a verification process via the phone. You get a number from the site that you are prompted to enter when they call you on the phone. Once that's done you can log into the account with the MFA device and then even remove the MFA device entirely.

The email address I believe can only be changed by AWS (and at least the last time this was an issue for me can't ever be reused for a new AWS account).

The phone number can be changed by anyone with aws-portal:ModifyAccount, which probably means someone with admin access. It is NOT restricted to being modified by the root account.

So if you have a working access to an account with that permission and access to the email you can change the phone number to one you have access to and go through the whole process. Meaning if you have the above permission you really only need access to the email.

Link to the documentation for this flow: https://aws.amazon.com/blogs/security/reset-your-aws-root-ac...

How excellent the ASN.1 tooling is depends on which subset of ASN.1 you're using. Some of the tooling supports one iteration of ASN.1 or the other. To the degree that the IETF had to write a document on how to deal with this since some of the standards use the older ASN.1 and some use the newer ASN.1: https://tools.ietf.org/id/draft-ietf-pkix-asn1-translation-0...

Interoperability with ASN.1 is very fragile at best.

I know of at least one problem with ASN.1. The string encodings other than UTF-8 are terrible. Most of the string encodings are very limited and weird subsets of ASCII that nobody actually uses anymore. ASN.1 itself doesn't define the encodings and just refers to other standards.

The problem with this is probably most notable with the T.61 encoding which changed over the years and since ASN.1 references other standards nobody is quite sure exactly what you have to support to have T.61 actually work right.

Within X.509 certificates though nobody bothers to actually implement T.61 and just uses the T.61 flag for ISO-8859-1.

There are a bunch of gory details around this mess in this (now quite old) write-up here: https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

Since that write up I believe UTF-8 is pretty much the expectation for character encoding for X.509.

I documented some of the quirks around 6 years ago when I took an existing X.509 parser and improved it for use in certificate trust management in Subversion: http://svn.apache.org/viewvc/subversion/trunk/subversion/lib...

Basically ASN.1 wasn't well defined and it only works well when people agreed to only use certain features or to interpret things in a particular way when ambiguous.

It's also notoriously difficult to parse well. It's very easy to have bugs in your parser, even if you're implementing a subset of it that's needed for X.509. Especially if you're doing so in a non-memory safe language.

I can't speak for why Google invented Protobufs, but I can't imagine anyone sane picking up ASN.1 for anything modern and deciding that this is what they want to use.

There is an option in the settings to make it not actually call unless you press a further UI button on the iPhone.

In Settings go to Emergency SOS. Uncheck Auto Call

I think you need to turn on the power button clicking 5 times feature by turning on the "Call with Side Button" option in Settings under Emergency SOS. I'd also suggest turning off Auto Call if you want to use it like this.

Yes this is kinda buried and not clear at all that this function also disables FaceID but it does.

At least on iPhones though they have a way to activate a mode that prevents the use of TouchID and FaceID. If I press the power button on my phone 5 times in a row that turns that off.

Yes I still run the risk of my device being unlocked against my will if I'm caught by surprise. But I'm able to disable this functionality in places where I think the risk of that may be higher, e.g. while traveling.

I'll still take the trade off of longer password (not just a few numbers) on my phone while using a biometric test for normal access.

Of course not everyone may have the same threats to consider and others may make different choices. Doesn't make either of our choices wrong.

Could be. I don't believe the old fobs were bluetooth.

For what it's worth I also didn't mention that at least the old fobs also had an RFID in them that if the battery was dead you could just hold them up to certain spots on the car to open/drive it.

No the car does not require a remote connection to work. See my detailed explanation here: https://news.ycombinator.com/item?id=29283262

There are 4 ways to unlock a Tesla.

* Via Bluetooth from your phone. Model 3 and Y used this as the primary way of unlocking. This does not require a Tesla server. It's just local communication between the car and the phone. The car and the phone are paired.

* Via a key card. Model 3 and Y use this as the method when you get the car until you pair it with the phone and what you use if you want to give someone temporary access to the car (e.g service, valets).

* Via a key fob. Model S and X used this in the past (not sure if the latest refresh changed this but older S and X vehicles didn't support Bluetooth or Key cards) as the primary method.

* Remotely via the phone app. As in you make an API call to Tesla with your Tesla credentials and Tesla sends a remote command to the car. This requires Internet access for the device making the request and to the car in order to receive the command. This last bit is what's broken. Given the requirements this has never been very reliable and nobody would want to use this on a day to day basis.

So I seriously doubt very many people are locked out of their cars. I am able to get into my 2015 Model S via the key fob and my 2018 Model 3 via Bluetooth from my phone.

By the economic catastrophe causing us to elect a president who dismantled a group that worked to monitor and respond to global health issues to prevent them from becoming a pandemic. I think it's hard to say if that group could have prevented Covid-19. Nor am I necessarily saying that the economic crises of 2008 caused us to elect Trump. But I think you could possibly find a path from one one to the other.

Yubikey 4 and newer supports 4096 bit keys with PGP: https://www.yubico.com/products/compare-yubikey-4-neo/ https://www.yubico.com/products/compare-yubikey-5-series/

My signature ended up changing over time and I had to update my signature with the county elections office in Washington to stop my ballots from being rejected. So really not sure how you're slipping by.

There's quite a few MIG-17 with FAA registrations. https://registry.faa.gov/aircraftinquiry/AcftRef_Results.asp...

The original article says it's the last airworthy MIG-17PF, while this site just says MIG-17. I suspect the PF is critical to the last airworthy claim. There were a number of variants of the MIG-17.

I find it strange that the article says that Java uses /dev/urandom by default. When I've been having to configure Java to use /dev/./urandom for years to deal with the fact that it defaults to /dev/random and setting it to /dev/urandom doesn't work because the Java code treats the two as the same.

There are collision attacks against SHA-1. But the currently known collision attacks aren't a big problem for git for a variety of reasons.

Git uses hashes that include more data than just the hash of the content of an object. Meaning the existing known collisions don't work and you'd have to develop collisions specifically to target git.

Additionally, the current known collision attacks require generating the two colliding contents as a pair. You can't take an existing document and then generate a collision for that document. Further, the technique is not particularly good for text documents because you need to include some data to force the collision. This is easily missed in binary documents but not the text documents most people are committing into git repos (granted you can put binary files into git and that would still work but the other reasons for this not being very useful still apply).

Git also has code to deal with possible collisions and will fall back to full comparison and will fail a commit that creates a collision. Finally, generating these document pairs leaves detectable patterns in the content. GitHub scans for these patterns as part of their process.

https://github.blog/2017-03-20-sha-1-collision-detection-on-...

So if it were me trying to bypass this system rather than trying to make increasingly complex and expensive projectiles to try and defeat the system I'd just make increasingly cheap projectiles to make it easier to spray the target with them and eventually get some through. The article even mentions that a laser can only point at a single target at a time. To your point if you also target the defensive system you're bound to sooner or later damage the system with one you managed to get through. Seems to me that this system is easily defeated with tactics.

All this is doing is allowing the server (or client since the protocol allows client certificates to do the same thing) to use a different key pair with a shorter validity period than the CA signed certificate.

The delegated credential is not another cerificate and doesn't have a DNS name in it at all. The original certificate who's private key was used to create the delegated credential still has that information and the client still gets that. The delegated credential only consists of four pieces of information: validity interval, public key, signature algorithm and signature. I.E. just enough information to provide the public key and verify it is signed by the CA signed certificate.

RFC is here if you want to read the details: https://tools.ietf.org/html/draft-ietf-tls-subcerts-04

You do realize that all vehicles have risks of fire or explosion. In order to make a vehicle with sufficient energy density to be usable for transportation you have to take those risks.

While it's true that Tesla has had a relatively small number of vehicle fires with the Model S and X. To date there has not been a single fire with a Model 3. Even with the Model S and X fires they were far rarer than ICE vehicle fires. It's just that nobody bothers reporting on ICE vehicle fires because they happen all the time. The relative rarity of the Tesla fires is what made them news not a high incident rate.

It is possible to run Docker in Docker in CI. At a previous job I built containers that ran docker as Bamboo build agents. The containers did not use the docker socket and instead had their own and their own `/var/lib/docker` directory. However, the containers have to run docker as root (I started docker and then dropped privileges to run the bamboo agent) and have to run with the `--privileged` option. The advantage of doing it that way was that the hosts image storage was cleaned up with the containers and separate from the host. Disadvantage was that you have to use loopback based storage which makes docker a little slower. I don't think there's a huge difference in security since docker would end up being accessible via the socket anyway and by dropping privileges for the build agent you're losing the capabilities that you get from `--privileged`.

Generally a footgun is something that's designed in such a way as to be extremely likely to be used in a way that's going to cause problems for yourself.

Yes it's a play on shooting yourself in the foot, the idea is that you designed a gun designed to shoot yourself in the foot.

https://www.urbandictionary.com/define.php?term=footgun

No the base price is $35,000. They simply haven't started letting anyone buy the $35,000 versions yet. You can say this is a failure on the part of Tesla. But this is not the first time they've had a lower end model that was planned but not immediately available upon production. Case in point when the All Wheel Drive Model S was announced, they didn't make non-performance versions available for several months after.

You've got a mighty big crystal ball there then.

Sarcasm aside. A major part of the allure of Kubernetes is that it's not a single vendor project. It's unlikely to die if something happens to RedHat. Say someone like Oracle comes along and buys you guys. But that's not the case with OpenShift.

Maybe you're right that things will continue as is and OpenShift will always be better and that RedHat will always maintain it.

But not particularly a risk that I think is worth taking.

I'm against forks like OpenShift because as an upstream maintainer on a major open source project, distribution patches caused us nothing but headaches. Their well meaning patches almost always caused problems. Users routinely ended up at our doorstep with the issues they caused. We then either told the user to go bug their distribution, spent time digging into the issue, or got lucky and the distribution maintainers actually paid attention to our lists. The latter one was actually pretty rare.

You presume I don't have experience with open source projects and don't understand why things might not be accepted, which isn't really true. I used clout as short hand for doing the work to actually get changes into upstream. I'll admit I probably chose a poor word there.

I really can't fathom why Routes wasn't just adopted into Kubernetes directly instead of a complete rewrite of Ingress being added. I don't know all the details, but when I went digging what I found was RedHat folks explaining what they did and Google engineers writing Ingress.

Please also understand, I totally agree that RedHat and other packagers are fully within their rights to patch things. I think they really shouldn't. They cause at least as many problems as they solve in my experience. But it's also my right to say that I don't want to use their patched stuff.

I don't see the situation with the Linux Kernel as a success story. I see it as a failure. It's downright impossible to tell someone if something is going to work with their kernel because the version numbers are utterly meaningless since the distributions patch all sorts of things in and out. I have been running Linus' mainline kernels for the last several years and I've been broken exactly once and even then only very slightly.

I tend to think that if distributions avoided patching unless absolutely necessary and worked with upstream to get things included first we'd all be a lot better off. Those reasons why the patches weren't accepted quicker would get dealt with before things were in the hands of users.

But frankly the distributions incentive is to create value for themselves. Not help the project along. Helping the project is utterly secondary to any value creation they are doing for themselves. In fact you give an excellent example. You say that upstream is terrible at release engineering. So rather than just applying a patch to a distribution, it's really beyond me why distros don't work with the upstreams to improve their release processes if that's the problem with staying with a pure upstream.

That's not to say that distros don't create any value for the overall community. It's just my opinion that they don't create as much value as I think they should. These companies are taking in massive amounts of money off the open source projects. Sure, in some cases they have maintainers/contributors to upstream projects on their staff. But those are usually the cases where what I'm talking about isn't what is happening.

Now all of that sounds like I don't think distros should ever patch. Which is probably an exageration of my position. I think there are times when it's needed. Security fixes, unresponsive upstreams, etc...

But adding completely distinct functionality. I don't want to touch that with a 10 foot pole.

Edit: Forgot to say, your comment about the migration to upstream feature bit. I flat out asked RedHat how they planned to get people to migrate to Ingress. Their answer was they didn't have a plan.

That is a fair point. I'm only talking about the "Kubernetes" implementation within OpenShift. It's modified from the upstream one and includes things that aren't part of upstream Kubernetes.