90 days moving to 45 but you can and should renew earlier than that. Automating this process means that you should be request a new certificates roughly 60 days (or 30 soon) after the issuance of the previous certificate. That way you would have plenty of time to deal with renewal issues. The process for renewal should have back off and retries built in. This prevents a situation where a down time for the issuer means that your production environments are non-functional.
This is a very accurate take. There is a ton of collection that the government is explicitly not allowed to do. However, the ability to purchase this data is much less regulated. So the work around is, get contractors to do the data collection and then purchase that data.
This is an interesting idea. One thing that might help targeting is to have some sort of chemical that attracts the mosquitoes. In that way you can bring your target to you.
I work for a company that is open source and has a large community. I blows my mind (and often aggravates me) how rude some people can be.
For some reason people feel that it is appropriate to throw barbs in their issue reports. Please to everyone out there, if you find an issue and want to report it (hurray open source!) please be kind with your words. There are real people on the other side of the issue.
Always remember, you catch more flies with honey than vinegar.
That has already begun. Saw stop technology is already working it's way into regulations. A decent non saw stop table saw will cost you ~500 USD. A saw stop saw will be 1200.
Super excited to see Airbyte finally make 1.0. Tons of great features in the release that represents a lot of hard work from the Airbyte team over a number of years.
Yes, this is the trade off. If you are working in an industry where you need to be highly sensitive for data access even for short periods of times then oauth/oidc/jwts are probably not for you. If you really need an emergency escape hatch you can always rotate your singing keys and jwks and invalidate all of your tokens and force everyone to sign back in.
I have not seen an authorization server that makes it easy to configure no signing algorithm or even one that might be considered insecure. Most of the client authentication providers I have used (I.e frameworks) have also forced a secure algorithm, usually starting with rsa 256. So while technically you can use a no algorithm signer, I have never seen this happen.
I would add two pros of jwts (I guess oauth 2 and oidc more specifically)
1. It standardizes your auth system. While sessions auth is mostly implemented in the same way across systems, learning oauth and oidc gives you a standard across the industry.
2. Jwts give an easy path to make “front end” applications and api authentication work in the same way. This in theory reduces your security surface area as all of your authnz code can be shared across your offerings.
I have been building this on and off for a number of years. Mostly focused on the document management side of things: https://github.com/bgroff/kala-app
For those that might not follow the link: “[ai code] is presumed to be tainted (i.e. of unclear copyright, not fitting NetBSD's licensing goals) and cannot be committed to NetBSD”.
So more of a provenance issue w.r.t licensing than an ideological one.