<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Krotscheck.net</title><link>https://krotscheck.net/posts/</link><description>Recent content in Posts on Krotscheck.net</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 01 Apr 2024 15:23:15 +0000</lastBuildDate><atom:link href="https://krotscheck.net/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>How /.well-known is your Issuer?</title><link>https://krotscheck.net/posts/2024-04-01-how-well-known-is-your-issuer/</link><pubDate>Mon, 01 Apr 2024 15:23:15 +0000</pubDate><guid>https://krotscheck.net/posts/2024-04-01-how-well-known-is-your-issuer/</guid><description>TL/DR: Never have an issuer claim with a path component.
There’s an unintended interaction between the OIDC base specification, the OIDC Discovery specification, and the Well-known URI RFC, one which I think is fascinating because it creates a requirement which many implementors may have missed.
The Problem Let me set it up for you in three quotes:
REQUIRED. Issuer Identifier for the Issuer of the response.
The iss value is a case-sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.</description></item><item><title>OIDC Federation on a Grand Scale</title><link>https://krotscheck.net/posts/2023-11-10-oidc-federation-on-a-grand-scale/</link><pubDate>Fri, 10 Nov 2023 12:15:42 +0000</pubDate><guid>https://krotscheck.net/posts/2023-11-10-oidc-federation-on-a-grand-scale/</guid><description>Content Warning: Identity Nerd, snapshot 2023.
The OIDC Federation Specification (draft) has been stuck in my brain for about a year now because it changes how I think about my job. On its surface, the concept is relatively simple: Provided that there is a federation of actors, it provides a method by which these actors can establish a common trusted root actor. A simple example might be that I claim that I’m Michael, but you have no reason to trust me.</description></item><item><title>EV's, and the return of the Great American Road Trip</title><link>https://krotscheck.net/posts/2022-08-09-evs-and-the-return-of-the-great-american-road-trip/</link><pubDate>Tue, 09 Aug 2022 13:27:55 +0000</pubDate><guid>https://krotscheck.net/posts/2022-08-09-evs-and-the-return-of-the-great-american-road-trip/</guid><description>My family and I took a well-earned road trip back in the spring; two days in Portland, after which we picked up the kids and took them up to the Olympic Peninsula. We drove our EV, bought as a splurge after an unfortunate accident in February resulted in a car-shopping scramble. The trip itself was wonderful, yet more importantly, it made me really think about American Car Culture, and my own history.</description></item><item><title>How to write a Recommendation</title><link>https://krotscheck.net/posts/2021-04-14-how-to-write-a-recommendation/</link><pubDate>Wed, 14 Apr 2021 14:08:20 +0000</pubDate><guid>https://krotscheck.net/posts/2021-04-14-how-to-write-a-recommendation/</guid><description>Here’s a quick, three-paragraph template for writing a letter of recommendation. Don’t overthink it; these should be quick to read, and leave a strong positive feeling on behalf of the candidate.
Paragraph 1: What are you doing, and why? The opening is a simple statement of what you are doing: “I am recommending [candidate] for [promotion/acceptance] to [level/program].” This is then followed by your reasoning; choose one or two qualities that represent the program they are applying for, and give an example about how they express this quality.</description></item><item><title>Free (as in Tier) OAuth2</title><link>https://krotscheck.net/posts/2021-04-09-free-as-in-tier-oauth2/</link><pubDate>Fri, 09 Apr 2021 14:16:29 +0000</pubDate><guid>https://krotscheck.net/posts/2021-04-09-free-as-in-tier-oauth2/</guid><description>Are services like Auth0 or Okta really worth paying for? For a business, perhaps; the overhead of paying for an auth-focused software engineer, as well as the operational overhead of monitoring, could very well be more expensive than handing over a credit card. However, if you have made the decision to host your own, it turns out you can do so on AWS’s Free tier, with only a few strategic technical choices.</description></item><item><title>Running a Successful Bug Bash</title><link>https://krotscheck.net/posts/2020-08-02-running-a-successful-bug-bash/</link><pubDate>Sun, 02 Aug 2020 12:13:07 +0000</pubDate><guid>https://krotscheck.net/posts/2020-08-02-running-a-successful-bug-bash/</guid><description>A bug bash, much like any coordinated effort, requires planning. Here’s a guide on how to get the most out of everyone’s time.
Preparation Step 1: Collect your use cases This is where you scour all the documentation that has been generated – via wiki, tickets, discussions, meetings, designs, etc – and capture the use cases that your feature needs to satisfy. In a perfect world, this is a collation effort; in an imperfect world, you’ll be writing them by exploring your application.</description></item><item><title>The case for Edge on OSX &amp; Linux</title><link>https://krotscheck.net/posts/2019-12-03-the-case-for-edge-on-osx-linux/</link><pubDate>Tue, 03 Dec 2019 12:06:50 +0000</pubDate><guid>https://krotscheck.net/posts/2019-12-03-the-case-for-edge-on-osx-linux/</guid><description>Ever since Microsoft Edge was leaked for OSX, I’ve used it. Not exclusively, however as a UI Architect it’s both my job and my hobby to keep an eye on the landscape. I’ve certainly gotten a lot of flack for it – both from friends and coworkers – however when presented with my reasoning, they all agree that it makes sense (though it’s often not for them).
The reasoning is simple: I can keep my work browsing separate from my personal browsing.</description></item><item><title>Angular > React</title><link>https://krotscheck.net/posts/2018-10-17-angular-react/</link><pubDate>Wed, 17 Oct 2018 13:41:32 +0000</pubDate><guid>https://krotscheck.net/posts/2018-10-17-angular-react/</guid><description>I’ve been overseeing UI projects for … oh, decades now. I’ve shipped production applications in backbone.js, SproutCore, Angular 1, Angular 2, React/Redux, even going back to the old days of the Adobe Flex ecosystem with Cairngorm, PureMVC, and Parsley. I’m old, I’m grouchy, I’ve been around the block a few times, I’ve made all the mistakes.
I still think Angular is better than React.
Now, don’t get me wrong – I understand the appeal of React, and why Angular’s a tough sell (even though they can work together rather well).</description></item><item><title>Encrypting sensitive variables in terraform using GnuPG agent</title><link>https://krotscheck.net/posts/2018-07-25-encrypting-sensitive-variables-in-terraform-using-gnupg-agent/</link><pubDate>Wed, 25 Jul 2018 01:57:00 +0000</pubDate><guid>https://krotscheck.net/posts/2018-07-25-encrypting-sensitive-variables-in-terraform-using-gnupg-agent/</guid><description>This post will walk you through how to encrypt sensitive terraform variables in a way that still permits them to be committed to VCS, while also being reasonably easy to decrypt. Examples use bash, however are easily adapted to other environments. Special thanks to this post on encrypting the ansible vault password, as my examples draw heavily from that source.
This method is particularly awesome, because you can explicitly declare who is permitted to decrypt it.</description></item><item><title>How to simulate an OpenStack Infra Slave</title><link>https://krotscheck.net/posts/2016-06-01-how-to-simulate-an-openstack-infra-slave/</link><pubDate>Wed, 01 Jun 2016 14:25:58 +0000</pubDate><guid>https://krotscheck.net/posts/2016-06-01-how-to-simulate-an-openstack-infra-slave/</guid><description>Situation: You’ve committed your code, you’ve submitted a patch, and yet for some reason, and regardless of the number of rechecks, your tests simply won’t pass the gate? How can you test the gate, locally, to triage what’s happening? By creating a local slave VM.
Prerequisites To complete this tutorial, you will need the following:
Vagrant VirtualBox A local clone of OpenStack’s system-config repository: git clone git://git.openstack.org/openstack-infra/system-config Create a local.pp manifest.</description></item><item><title>JavaScript RoadMap for OpenStack Newton</title><link>https://krotscheck.net/posts/2016-04-21-javascript-roadmap-for-openstack-newton/</link><pubDate>Thu, 21 Apr 2016 09:26:21 +0000</pubDate><guid>https://krotscheck.net/posts/2016-04-21-javascript-roadmap-for-openstack-newton/</guid><description>This post contains the current working draft of the OpenStack JavaScript roadmap. It’s a big list, and we need help to land it during the Newton cycle. Overall themes for this cycle are Consistency, Interoperability, and engaging with the JavaScript community at large, all topics which I’ve written about at length. Our end goal is to build the foundations of a JavaScript ecosystem, which permits the creation of entirely custom interfaces.</description></item><item><title>JavaScript on the Trailing Edge</title><link>https://krotscheck.net/posts/2016-04-14-javascript-on-the-trailing-edge/</link><pubDate>Thu, 14 Apr 2016 17:30:14 +0000</pubDate><guid>https://krotscheck.net/posts/2016-04-14-javascript-on-the-trailing-edge/</guid><description>The public opinion of the JavaScript community is that it’s fast. We break things, we’re hungry for the latest features, and none of us want to return to the days of slow innovation that ended with the death of IE6. This really isn’t true; there are several core JavaScript projects, such as Angular, JQuery, and React, which have solid governance, and measured release cycles, that would mesh well with OpenStack. It just happens that those projects are surrounded by thousands of smaller ones, run by handfuls of engineers who are volunteering their time.</description></item><item><title>OpenStack Infra now uses Node.js v4 and npm v2</title><link>https://krotscheck.net/posts/2016-04-07-openstack-infra-now-uses-node-js-v4-and-npm-v2/</link><pubDate>Thu, 07 Apr 2016 11:50:29 +0000</pubDate><guid>https://krotscheck.net/posts/2016-04-07-openstack-infra-now-uses-node-js-v4-and-npm-v2/</guid><description>OpenStack’s Infrastructure is now running all of its NPM and NodeJS-based test jobs using the newer NodeJS v4, and npm 2.15. That’s pretty awesome, given that previously we were running on 0.10.25. ES6, anyone?
LTS is important Here in OpenStack we try to stick as closely as possible to LTS packages. We do this for multiple reasons, chief of which is that many of our customers have governance and compliance constraints that prevent them from installing arbitrary bits on their hardware.</description></item><item><title>Securely publishing to NPM, the OpenStack way</title><link>https://krotscheck.net/posts/2016-03-27-securely-publishing-to-npm-the-openstack-way/</link><pubDate>Sun, 27 Mar 2016 16:44:57 +0000</pubDate><guid>https://krotscheck.net/posts/2016-03-27-securely-publishing-to-npm-the-openstack-way/</guid><description>The following article has been making the rounds, claiming a new worm exploit against npm. First of all, this is not a new exploit, nor is it in any way unique to npm – pip, gem, rpm, and deb have the same issue. Many may not even consider this an exploit at all – it’s a known feature, provided by package repositories, that permit compiling platform-specific bytecode. This is useful if, for instance, your package depends on a c-level library.</description></item><item><title>Horizon Usage Survey</title><link>https://krotscheck.net/posts/2015-05-15-horizon-usage-survey/</link><pubDate>Fri, 15 May 2015 16:31:23 +0000</pubDate><guid>https://krotscheck.net/posts/2015-05-15-horizon-usage-survey/</guid><description>Over the past few weeks, I’ve run a survey that attempts to discover how people use OpenStack’s Horizon (aka openstack-dashboard), and I’d like to publish some preliminary results. I’ll be soliciting responses during the Vancouver Summit next week, so if you haven’t participated yet, you still have time to do so. The link to do so is here: http://tinyurl.com/horizon-usage-survey.
Results In two weeks, the survey gathered 36 responses. Due to the small sample size and the non-random selection of participants, this data should not be considered statistically significant — Self-selected populations rarely are — however it does provide us with a window into how Horizon is used in the real world.</description></item><item><title>JavaScript Dependency Management in OpenStack</title><link>https://krotscheck.net/posts/2015-03-23-javascript-dependency-management-in-openstack/</link><pubDate>Mon, 23 Mar 2015 14:10:12 +0000</pubDate><guid>https://krotscheck.net/posts/2015-03-23-javascript-dependency-management-in-openstack/</guid><description>A problem that I’ve been working on the last week has been JS dependency management – driven by npm and bower – inside of OpenStack. To be honest, this problem can be extended to JS dependency management in any application that wants to be packaged within a Linux distribution, as that is the ultimate bar that needs to be met. In this case, however, we’re just going to focus on OpenStack.</description></item><item><title>Goodbye Launchpad, Hello Storyboard</title><link>https://krotscheck.net/posts/2014-11-20-goodbye-launchpad-hello-storyboard/</link><pubDate>Thu, 20 Nov 2014 10:46:39 +0000</pubDate><guid>https://krotscheck.net/posts/2014-11-20-goodbye-launchpad-hello-storyboard/</guid><description>The OpenStack Infrastructure team has successfully migrated all of the openstack-infra project bugs from LaunchPad to StoryBoard. With the exception of openstack-ci bugs tracked by elastic recheck, all bugs, tickets, and work tracked for OpenStack Infrastructure projects must now be submitted and accessed at https://storyboard.openstack.org. If you file a ticket on LaunchPad, the Infrastructure team no longer guarantees that it will be addressed. Note that only the infrastructure projects have moved, no other OpenStack projects have been migrated.</description></item><item><title>StoryBoard Authentication and Authorization</title><link>https://krotscheck.net/posts/2014-11-10-storyboard-authentication-and-authorization/</link><pubDate>Mon, 10 Nov 2014 17:38:09 +0000</pubDate><guid>https://krotscheck.net/posts/2014-11-10-storyboard-authentication-and-authorization/</guid><description>During the OpenStack Summit in Paris this last week, we made a concerted effort to finally migrate the openstack-infra projects over to StoryBoard. This is a pretty big milestone for us, because it’s the first real set of users that we’ve had on our system – basically our beta users. Of course the best laid plans ran into some problems, one of which is forcing us to make a decision on how to handle user identity.</description></item></channel></rss>