View from our first campsite:

Hill City Flowers

There are always a suprising number of flowers in the grasses when you look closely. The prickly pear look like they're going to flower this year - nearly all the bunches I saw had buds starting. I'm not used to seeing so many buds, so I'm guessing that this is because we had a wetter year last year, providing the plant with enough energy and mostiure for this year.

Also saw two different colors of spiderwort, lupine, yarrow, and spreading dogbane.

Finally, I couldn't positively identify this one. It looks similar to smooth beardtounge, but I'm not sure it's the same plant. I've only seen smooth beardtongue as a striking blue flower in the hills.

We also ran into this vetch outside Hill City. Is't quite common out here, but the color difference from purple to pink in one group of flowers was quite pretty.

Ditch Creek

Not as many flowers outside Ditch Creek, as it was rather cold when we were up there. Interestingly, the rocky mountain irises were still blooming. I assumed they would be out of season by mid-June, but perhaps the higher elevation and reduced temperatures push back their season (or I could just be wrong). Also saw a flower I didn't recognize, turns out it's a western canada violet. It was quite prolific down by the creek.

Speaking of flowers, there were lots blooming, but I only grabbed pictures of a few. Bleeding heart, apple tree blossoms, and columbine:

Purple Carpet

In the grass around the lilac bushes, there were these tiny purple flowers interspersed with the green lawn. The pictures don't capture how striking it was - to look down on the bright grass and see myriad little purple flowers poking through. They were also growing in the grass driveway. It felt strange to park on top of them, but the plants are hearty like the grass - walk or drive on top of them, they care little.

I want to try and put together some kind of art based on the colors. Haven't had time yet. The photos are more to remind me, as they are not themselves very striking.

Rocky Mountain Iris from Centennial Trail (near Sheridan Lake):

A much larger iris from our front garden.

And after a short camping trip last weekend, I'm very glad we got one. It's a big step up in terms of our ability to camp, with a reduced effort. There are some tradeoffs, but overall I'm very happy we did this. We mounted it on our 4Runner, which is our normal go-somewhere vehicle. I should note that we are 'car-camping' - sleeping on pads, big tent, bringing lots of stuff with. It's a lot more fun for the kids this way, but if you're used to carrying all the gear, food, and fuel you need into a remote site, then my experience isn't going to resonate for you.

I'll get into the why, but first some pictures:

Which Tent?

After quite a bit of research, we ended up getting an iKamper X-Cover. This tent had a couple of advantages over other options we looked at:

• It's big enough to sleep 2 adults and 2 kids. And it's not just marketed that way, it's actually plenty big.
• It is relativly light weight (about 125 lbs), which means that it doesn't cut into the GVWR as much. I also don't have 200 lbs on top of my vehicle, so slightly better center of gravity than some other RTT options would be. Finally, the lighter weight means it's easier to get up on top of the vehicle and take down.
• The top is a hard alumnium sheet - so it should provide some protection in the event of adverse weather. We get a lot of hail in the Hills, and since the vehicle will be parked outside all summer, this was a concern with a soft shell tent.
• The tent is very fast to set up - I think iKamper claims 3 minutes. In reality, on my vehicle, it's more like 6-7 (I timed myself), but that's faster than any tent I've set up on the ground by far. Even a pop-up tent (which is itself very cool!) requires you to find flat enough ground, put down a tarp, and stake it once it's deployed.
• I can put the sleeping bags inside the stowed tent for transport. There's a foam pad for comfort, which compressed nicely to also carry 4 sleeping bags. This freed up a non-trivial amount of space inside the vehicle - 9 bags I would otherwise need to carry (4 sleeping bags, 4 sleeping pads, 1 tent).

Mounting

The tent does take up most of the (aftermarket) roof rack on my 4Runner, but that hasn't been a huge issue. The biggest challenge is getting it up and down without damaging anything. My wife isn't tall enough for us to just lift the tent, so I ended up rigging a wooden platform and a pulley to raise the tent up and slide it onto the vehicle. With this setup I was able to install the tent myself - it took about an hour once I had the platform built.

I would have preferred an overhead lift of some kind, but I don't have access to one, and my garage door is too low to get the vehicle in and out with the tent mounted.

If the 4Runner was a daily driver for us, I'm not sure I would have mounted the tent. The extra weight and wind resistance are impacting fuel economy on an already ineffecient vehicle. But we've been using the 4Runner as a second vehicle when only needed, so this isn't really a concern. Our use case is not for it to be effecient daily transport, we wanted something that would be able to take us into the hills without concerns, haul the bikes, tow small loads, etc.

First Outing

We went out last weekend on a short camping trip. It was just at the end of shoulder season (first half of May), when many of the first-come first-serve sites are open for use, but don't charge fees. The weather was also very good for camping.

The tent was as fast to set up at a campsite as it was in my driveway. It was cooler than tents I've used in the past - good ventiliation on all 4 sides and being 7 feet in the air meant that it caught a nice breeze. The kids also really liked playing in it, which is great, especially when tents I've used previosuly tended to get hot quickly in the sun.

The RTT has a couple of skylights in the top, which are nice for letting in light. Once they were closed up, the tent got quite dark - the material of the walls blocks light very well. It turns out not waking up at first light is quite nice - where my other tents get bright very quickly as soon as day breaks (at 5:30), the light wasn't a problem in the morning and we were able to sleep in a bit.

The kids took to the ladder pretty quickly - no issues there. We also got a shoe-holder bag that gives you a place to put shoes, hanging in the air off the tent. While this was nice, I imagine it would be much nicer if you were camping in a place where you needed to worry about things crawling into your shoes overnight.

While I have seen pictures of dogs inside RTTs, I don't think our dog would have handled the ladder well. I cleared space and had him sleep in the back of the vehicle - no problem there.

The only negative thing we noticed was that our feet were slightly raised compared to our heads. It looks like that was half where I parked the 4Runner (at a slight angle), and half the design of the tent. This wasn't a huge issue, but it's the only downside I could think of. There was less slope than I often find when putting down a tent on the ground, so I consider this a very minor thing, but I should note it.

I think it took us a little under 45 minutes to break camp in the morning, which is a big improvement over past outings. And I didn't have to roll up 4 sleeping matts and 4 sleeping bags in a hot tent! I'm really looking forward to more trips this summer with the family.

The Good

• Fast setup and teardown at camp.
• Additional cargo capacity.
• Kids love it.
• Good ventiliation and black-out qualities.
• Sleeping up high is pretty cool.

The Bad

• RTTs are not cheap.
• It is heavy enough that I'm not planning on taking the tent off again until the Fall.
• On a multi-day trip, if you want to drive somewhere during the day you need to pack up the tent first.
• Mileage reduction if the mounted vehcile is a daily driver.
• No ability to carry other items on top of the vehicle (ie, canoe).

Final Thoughts

This thing is sweet!

Microsoft page mentioning the JWT Decode option.

As part of remediation, it's often useful to know where the transitive package dependency came from - David Jarman had a post a while back where he talked about dotnet nuget why, which is a pretty slick tool to see the dependency chain for a given package. It does occasionally have bugs (that I was unable to consistently reproduce 😕), but it's been very helpful so far in tracking down the source of vulnerable package versions.

Problem

However.

If you're doing this, you may run into the following situation:

• Project A depends on Project B.
• Project B reports no vulnerable packages or vulnerable transitive packages.
• Project A reports vulnerable transitive packages (in my case, System.Formats.Asn1 v5.0.0).
• When you run dotnet nuget why on Project A, you find that the transitive dependency runs through Project B which just said that it didn't have any vulnerable transitive packages.

There are some hints online about why this might be the case, but I haven't found anything concrete. Google's AI summary seems pretty confident that it depends on the SDK, but it's slightly incoherent, and when I check the cited sources, they don't mention the SDK type (that I can see). So I'm uninclined to belive that it's fully correct.

In my case, Project A is a <Project Sdk="Microsoft.NET.Sdk.Web"> project, while Project B is <Project Sdk="Microsoft.NET.Sdk">, but that's really the only difference. I played with swapping those values around - no difference in the vulnerable package lists.

So, for now - this remains a mystery as to 'Why'. But it's real darn frustrating.

Solved!

Ok, I figured this thing out.

What was happening is that Project B has a transitive dependency on System.Formats.Asn1, but allows a higher version (ie, does not require v5.0.0 exactly). However, additional packages that Project A depends on have a dependncy on the explicit version of the vulnerable package - v5.0.0. So, when you run the package vulnerability checker on Project B, there is no vulnerable package - it does not depend on a vulnerable verison, it's presumably resolving a higher version.

But when you run against Project A, the resolved package version is v5.0.0, which is vulnerable. This then reports a vulnerable package, chained under Project B and version 5. It is important to note that initially I did not see the other vulnerability chains under Project A, I focused on the path through Project B.

The fix is to find the package references from Project A that have a transitive dependency on Systsem.Formats.Asn1, and update those - this allows us to resolve the vulnerable dependency.

I found this pattern repeated several times for different vulnerable packages with some variation during this process, including problems when the target framework changed from Any CPU locally to win-x64 in the CI build. It does make sense, but it's a very frustrating thing to deal with. I now appreciate more NPM's use of a package-lock.json file to fix the resolved version - it makes tracking down problems like this somewhat easier.

Note:

This was initially written on 4/29, but didn't have time to finish it up, so it's getting published 5/4/25.

The drawing area was done using a canvas via vue-konva, and then I generated a path for the drawing and rendered it as an SVG. Nothing very fancy.

Updating

I built the tool in late 2021, and, wouldn't you know it - it doesn't build on my machines any longer. There was a breaking change in node verisons (something to do with SSL, if I remember properly), and the old dependencies don't build on any of my dev machines in their current configuration. Instead of trying to get an old version of the dependencies set up, I figured it would be easier to port the logic forward. So, I've set about porting the components up to a new Vue 3 project with up to date packages.

Fortunately for me, vue-konva has an updated package, so this was a relativly straightforward update. The biggest bit of work was uptaking some of the changes in Vuetify between version 2 and 3 - noteably, the output of the <v-color-picker /> component has changed from an object to a hex string.

Images

I need to do some polish on the tool before I publish it anywhere (but that's on the list!), but I find myself playing with the different lines and color options longer than I intend to every time. As an example, here are a handful of quick SVGs I generated tonight using the tool:

Since I'm using VuePress, I grabbed the VuePress feed plugin. Installation was straightforward.

However, I found that the default filters were pulling in more than I wanted - in particular the get-started.md file that I'm leaving around for reference. I also added a frontmatter 'archive' property as a simple way to ignore pages, and I wanted the feed's filter to honor that as well. After a bit of tinkering, this is what I ended up with:

feedPlugin({
      hostname: "https://jeremywarner.net",
      atom: true,
      count: 10,
      devServer: true,
      filter: ({ frontmatter, filePathRelative }) =>
        (frontmatter.feed ?? true) &&
        !(frontmatter.archive ?? false) &&
        frontmatter.layout == null &&
        filePathRelative != "get-started.md",
    }),

Not particularly elegant, but easy enough to understand in 6 months when I've forgotten exactly why it's configured this way.

It's nice working in a Vue environment, so I can focus on making what I want happen instead of learning how XYZ framework should be hooked together.

Consistent Colors

It's a pretty common pattern, but I enjoyed setting up the color calculation for the tags. I've got a preset list of colors, and then based on the text of the tag, I compute a number, mod it by the size of the tag color list, and then use that as the list index. This means everywhere I use the same tag text, I can compute a consistent color, and new tags automatically get a new color - no other config needed.

I'm not sure when I'd find the time, but I'd like to explore doing something similar to his sand creatures. I suspect modern browsers could adequately render an animated, randomly changing version.