Speaker 1: How'd you like to listen to dot net rocks with
no ads? Easy? Become a patron for just five dollars
a month. You get access to a private RSS feed
where all the shows have no ads. Twenty dollars a month,
we'll get you that and a special dot net Rocks
patron mug. Sign up now at Patreon dot dot NetRocks
dot com. Welcome back to dot net Rocks, the Internet
audio talkshow for dot net developers. Remember that tagline rich.
Speaker 2: Yeah, because we're not clever enough to come up the
word podcast, Well we.
Speaker 1: Were two years before that word could have thought of
the word yeah. I'm Carl Franklin, and I'm Richard Campbell,
Gary You and Park is here with us. We're gonna
be talking to him in a minute. But first, Richard, Hello,
where the heck are you?
Speaker 2: I am at build stuff in Vilnius, Lithuania.
Speaker 1: Wow.
Speaker 2: Yeah, cool? Last week I was in Brisbane, Australia, So
I do not know what time it is?
Speaker 1: Your uh? Your wife doesn't like you hanging around the
house too long, does she look?
Speaker 2: I'm good for about three weeks, right, and by somewhere
else three weeks She's like, don't you have somewhere to
go now. No, she was with me in Australia. We
did a month in New Zealand, Australia with the new
grand baby with a family.
Speaker 3: Yeah.
Speaker 2: Yeah, yeah. She went from seven months old to eight
months old. We're on the road and when we left
with her, she could just sit up and she had
do a little teth in the bottom. There's cool. And
by the end of the month she's got two up
and down and she's starting to crawl and she's pulling
herself to her feet. Like you forget how fast babies grow.
It's done.
Speaker 1: My grand baby is two years old and she's actually
visiting right now.
Speaker 2: Oh that's awesome.
Speaker 1: They came up for Thanksgiving weekend.
Speaker 2: I'm digging this grandparenting thing. Man, this is fun.
Speaker 1: Enough grandparent chit chat. Let's talk about what happened in
nineteen eighty because this is episode nineteen eighty twenty more
episodes and we've got we're now teenagers. Yes, that's right, thirteen,
I think. Yeah, so let's talk about it. Okay, Well,
this is the year that pac Man debuted. Yeah you
know that. Yeah, and CNN was launched, ye, and that
kind of changed everybody's worldview and made it seem like
the world was more dangerous.
Speaker 2: Yeah, we could cave. Twenty four hour news, right, cable news. Yeah.
Speaker 1: No, matter where the bad stuff happens, you'll know about it.
Speaker 2: Yes.
Speaker 1: Thirteenth Winter Olympics were held in Lake Placid, New York.
Oh right, yeah, starting February thirteen. Let's see US grane embargo.
On January fourth, Jimmy Carter announced the grain embargo against
the USSR. Of course, the Iran hostage crisis read its
ugly head. Let's see, there was an new Mexico State
penitentiary riot Mount Saint Helen's. Everybody remembers that we had
ash all the way over here in Connecticut on our
cars from Mount Saint Helen.
Speaker 2: Yeah, and we heard it up in Vancouver. It was
this Sunday morning.
Speaker 1: And that's all I'm gonna say. Because we've been getting
some negative feedback show we say about how long it
takes to get to our actual show.
Speaker 2: So I'll wrap it up right here. Okay, but you
can talk amazing. You didn't mention Lenin was killed in
nineteen eighty though.
Speaker 1: You know what, that's right, he was killed in oh Man.
That was a hard day.
Speaker 2: It was a bad day.
Speaker 1: That was a bad day. And we don't mean you
know lenin the leader. I mean John Lennon, of course, briefly,
what you got for science and tech and all that.
Speaker 2: On the space side, this is the year that Vorger
one flies by Saturn, first time we get close up
pictures of Saturn. This dose also well. The Russians are
operating to Salute six space station in orbit and routinely
supplying it and maintained it. This is the launch of
the Solar Max satellite on Delta two rocket that immediately
has attitude control failures after a couple of months of
operations and will be repaired by this Space Shuttle challenger
in a few years, because the Shuttle is well in development.
In fact, Columbia has spent all of nineteen eighty in
testing getting ready for its first flight in nineteen eighty one. Wow.
On the computing side, this is the year that Jack
Tramil unveils the VIC twenty, although it doesn't actually show
up in the US until nineteen eighty one. In nineteen
eighty it's released to Japan as the VIC one thousand
and one with sixty five oh two processor five K
of ram Because numbers are hard, although expandable to thirty
two k and he also pays it was only about
three hundred bucks. They sell two million of the things.
It'll get replaced by the CC four course. But one
of the key things he did is he got Scott
Adams to port the Scott out of Adventures, five of
them to the VIC twenty. Now with only five k RAM,
there's no way to make those games running there, but
the game would sload off a sixteen k ROM cartridge
as you played it, so that the sworage was in
the wrong cartridge. And they sell it makes one point
five million just on those games. Wow. So and it
comes to go very very quickly. Nineteen eighty also the
year that Tim berners Lee builds a tool called Inquire,
which is a network hypertext system. Hmmm yeah, okay, that'll
never go anywhere, never go anywhere. Two more things. Seagate
releases the ST five six, which is a five megabyte
three and a half inch full height hard drive which
I will make money from installing into the upcoming IBM
PC which will be released next year. And this is
also the year that a collaboration between deck Intel and
Xerox comes up with the Ethernet Dix standard for ten
megabit networking. Wow, this is at a time when every
company had their own kind of networking, and so they
try and create sentence on this, and so the I
triple lee will start what do we know as the
eight O two standard four lands. This is the beginning
of all of that. And that's what I got.
Speaker 1: Awesome, awesome, awesome, all right, Well let's get going with
better no framework, roll the music?
Speaker 2: Awesome? All right, man, what do you got?
Speaker 1: Okay? This is a tool called uni get ui, which
was formerly win get ui, and the main goal of
the project is created an intuitive guy for the most
common CLI package managers for Windows ten and eleven, such
as wind get Scoop, Chocolate, pip, NPM, dot Net tool, PowerShell, Gallery,
and moore. Check out the package manager compatibility table. So
they like to say that it's kind of like a
package manager manager package manager.
Speaker 2: It's package manager inception.
Speaker 1: But I thought that would be good because you know,
mister Chocolady is here and yeah, it's kind of and
it's kind of trending on GitHub right now. So kids
met cool.
Speaker 2: Yeah, who knew.
Speaker 1: I don't find a need for this myself, but you know.
Speaker 2: How many How often are you building machines?
Speaker 1: Well, that's true, but there's a little but you know,
there's package managers for NPM and and all of that
stuff as well PowerShell galleries. Yeah, it goes beyond just
you know, chocolatey and Windows. Anyway, that's what I got.
Who's talking to us today, Richard.
Speaker 2: Grabbing comment off show eighteen fifty nine when we did
with one Gary, you and Park back in twenty twenty
three talking about it. Oddly enough, chocolatey hey, and this
common comes to us from Curtis who this is about
a year ago, where he said, I'm maintaining most chocolate
packages fairly easily. I spent about an hour a month
managing patches that update the using the au tool, which
is on the GitHub repository by Digital Coyote. The manual
packages in that repo are is can really more time
intensive though multipass, for instance cars booting up a Windows
pro or enterprise system to build tests and deploy that package.
On the note of using older dot net frameworks, it's
one of the things we talked about back that show.
I've seen time and again someone go into a new
project to choose dot net four six two because quote
it's stable, or quote we know it works. As recently
as mid twenty twenty three, I see the same choices
in new get packages as well, where a team will
choose to stick with the deprecated version of a package
because it's known to work. Upgraded projects to each LTS
release since dot net core two point one without issues.
That includes upgrading most dependencies on each release pretty through
the release notes and weighing the risk benefit will almost
always cause you to upgrade. The security fixes alone are
usually worth any breaking changes in your app. Absolutely, that's
good advice, Curtis. I'm not gonna argue a bit. Absolutely,
you know it's worth getting moving on. And the new
tools for actually checking compatibility guiding off four to six
up to what it is now dot net ten, which
is the latest LTS release, they're impressively good. They will
not only tell you where you're gonna have problems, they
will give you good instructions on what to do about it. Yep. So,
with the exception of web forms and other obviously non ports,
if you you a lot of apps apportable, even the
wind forms from the win SDK really not really a
breaking change anymore. They've done a pretty good job there,
So Curtis, thank you so much your comment, and a
copy of music cobuy is on its way to you.
And if you'd like a copy of music, go buy.
I write a cam on the website at dot net
rocks dot com or on the facebooks. You publish every
show there and if you comment there and I read
in the show, will send you copy music Go buy.
Speaker 1: Music to Code by track twenty three is halfway done. Nice,
so I expect that to be published within the next
couple of weeks, maybe by Christmas, because why wouldn't you
get your favorite friends music to code buy for That's
a great idea. Yeah. And also you mentioned web forms,
the thing that just didn't move over to core, right, yep,
this is this is the main focus of my consultancy
now is doing dot net core you know, Blazer versions
of old web forms apps.
Speaker 2: Web forms apps. Yeah, I figured that'd be a path.
Speaker 1: Yeah, absolutely.
Speaker 2: And it's not that automatic either, is it like it's worked? No,
you don't know, I mean, but it's good to do
a rethink Jeff Fritz. Actually Fritz and friends had a
library that had the same interfaces as the web forms things.
But you end up with a lot of code that
isn't modern and all that stuff. But yeah, yeah, the
best thing to do is just start over use your
business logic. Well, you have a template for what people want,
you know that, but you also have a list of
things that people are annoyed by. Yeah, so it's a
great opportunity to rebuild and something makes them happier.
Speaker 1: Yep, Okay, let's introduce Gary and bring them back on
the show. Gary Ewan Park has over ten years experience,
probably more like twelve thirteen fifteen now right, working as
a developer on technologies such as ASPNAT, Windows Forms, WPF, Sharepoints,
silver Light, and many others. Throughout his career, Gary has
always looked to see how things can be automated, using
the mantra that if you do the same thing more
than twice, it's time for automation. In twenty seventeen, he
was awarded a Microsoft MVP in Developer Technologies, and in
twenty twenty one he was awarded a getthub Star. His
day job has him working for Chocolatey Software Incorporated. In
his spare time, Gary contributes a number of open source projects,
including Chocolatey box Starter, cake Cake contrib, get version and
get release manager.
Speaker 2: So enough, there's a scene to those projects. There's scenes. Hmmm, yeah,
there seems to be a theme there, Gary, that's weird.
Speaker 3: Yeah, it's a long sorted history that's put it out.
Speaker 1: Here, and we're funny, grateful.
Speaker 2: We just had Mattias on talking about Cake as well,
you know, like it's these are things that are part
of our lives. I don't even think about him anymore.
You just did the way that you build machines, the
way that you deploy applications, it's stuff you got to do, right.
This is the plumbing of software.
Speaker 1: I first heard about Chocolate from Alan Stevens.
Speaker 2: Yeah, yeah, he was.
Speaker 1: He was gung ho on it. He was really ahead
of his time in terms of, you know, embracing new
technologies when it came out, and probably still is. I
haven't talked to.
Speaker 2: Him in a while, but yeah, been Well, so what
have you been working on?
Speaker 1: Friend?
Speaker 3: We continue to be busy over here, to be honest,
I mean we are. We're obviously we're a small team Chocolate,
but we have been increasing our numbers Chocolate, and the
requests keep coming in in terms of what people are
looking for, So we are we are definitely kept busy.
Literally yesterday or yesterday, I'm into today. We've just shipped
new versions of four of our core products. So wow, yeah, no,
we're busy. We're absolutely making progress.
Speaker 1: Before you go on, we should probably define with chocolate
as I know that everybody probably knows, but there might
be a few people out there who are like, what,
so chocolate is like new Get for Windows, right, if
you think about it, that's way new Get chocolate.
Speaker 3: Yeah, no, absolutely, that's yeah, yep, that's where it started.
I mean Rob Reynolds, the original creator of Chocolatey, was
very much making use of new Get to manage his
project dependency, so you can actually install the libraries that
you need for under coding against. But what he found was,
and this is the story he'll tell the story himself,
but he would go to his a friend's machine or
a colleagues machine to help him do a pairing session,
and the tools that he wanted weren't on that machine.
So he wanted a simple way to get the tools
that he wanted onto that machine so that he could
aid with painting sessions. And he was using new Get
and he looked at them board and said, well, if
I can use new get to install libraries, then maybe
I can use new get to install applications. So he
took he started a project which Chocolate as a package manager.
Originally started as a PowerShell project, so it was written
in PowerShell scripted and PowerShell. The sole focus was to
use the new get client libraries to install applications. And
then as the project progressed, it morphed into a dot
Net application and c sharp and it's been that way
for quite a while now, and it continues to be
a mechanism for installing applications onto your machine in a simple,
maintainable and repeatable way. So that's kind of the aim
of what Chocolate is. It's a Windows package manager.
Speaker 2: Now there is a bunch of these. I mean, I
don't put new Getting Chocolate in the same category, but
I think wind get sits there certainly, Like how do
you rationalize all of these? Geary?
Speaker 3: So what it comes down to, and I've spoken to
a few people at different conferences and et cetera about this.
It comes down to it. It's choice. It's what is
it you want to what is it you want to use,
and how do you want to use it? So people
quite often hear people say, oh, the Windows doesn't have
a package package package management ecosystem. You look at Linux
where they've got four or five six different package managers
for installing things. But on the Windows side of the house,
where we're getting to a point where we have quite
a selection now. So there's chocolate E, there's wind Get
that you spoke about, there's scoop, there's other alternatives that
you can use to install tools nowadays, and there's things
like dot Net Global tools that the kind of that's
kind of changed the landscape in terms of how you
get tools into your Windows machine or into your cic
D pipeline, so you can use dot Net tool install
now as well. So that's list. There is a plethora
of options in the Windows ecosystem now for doing application
management and we Chocolate are one of those, and we're
aiming to make the one the Windows installation ecosystem as
simple as possible, because it literally is. When you start
digging into the differences between ms I installers and n
s I, n s I S installers and ex s's
a there's a multitude of them. So what we Chocolate
are trying to do is make that landscape easier to maintain.
Speaker 1: So you're mentioning some updates that you were that you're
coming out with or having that with yep.
Speaker 3: So the team shipped new product versions of so chocolate
as a product has Chocolate ECLI. That's the one that
most people might know about. It's the open source version
of chocolate and people can download install that freely. Even
in a commercial ecosystem, you can use Chocolate Cli. But
we've also got other products that the commercial offerings that
build on top of the Chocolate Cli. So there's new
releases to the Chocolate License Extension, a system that we
call Chocolate Agent, and also the Chocolate Gouy License Extension.
So there was updates to four of our coreate going
out the door yesterday and today.
Speaker 1: Did you really just say chocolately and Guy in the
same sense I did?
Speaker 3: I did. So Chocolate Gouey is our offering for using
chocolate but through a graphical user interface to Guy.
Speaker 1: Similar to framework there correct.
Speaker 3: So similar to win get UI. So Chocolate Gouey offers
support for trust the Chocolate package manager, whereas what wouldn't
get Ui is attempting to solve is as you mentioned,
is the package manager managers. You know, the UI version
of the package manager manager. So you might remember there
was a system called one get which was a PowerShell
version of a package manager manager, so it was driven
from the command line, and when UI kind of sits
above that obviously but allows the management of multiple package
managers on Windows. So actually, I've been in I've had
a longgoing issue with the maintainer of will get UI
to try and improve the traffic support and UNI get UI.
So it's a it's a great offering and we've actually
I've tried to have that conversation with him to improve
that support. But yeah, it's been working well.
Speaker 1: So I wonder when it's going to be before we
find package manager manager managers.
Speaker 3: It's good maybe hopefully, hopefully I will be happily retired
before that, but before that comes about get to.
Speaker 2: The third order. This is exactly this.
Speaker 1: It's sort of the reflects the corporate order of things,
doesn't it. Yeah, it's not a good thing. I think
it's too much, too much. Can we all just get
along really nice?
Speaker 2: Indeed, are you finding folks using chocolate for setting up
vms in the cloud these days as well?
Speaker 3: Yeah, I mean that's definitely that's definitely a use case
that we have heard of. Yes, there's it's the same
with whether it's a physical machine, whether it's a VM,
whether it's something else. There's always any to install the
applications that you need. And obviously the first approach that
you might use is to download it from the website,
double click on a click, click a click through the installers.
But it gets to the point where that's if you're
doing that over and over and over again, you're you're
looking for a way to automate that process and trying
to take that try to make that entry point that
bit easier by a single command to get all that
applications installed. That's the niche that Chocolate is trying to serve. So,
whether it's a physical device on your locally, whether it's
in the cloud, that are mechanisms to install and use Chocolate.
And then the natural progression of that is within a
CICD pipeline as part of your build, you might need
an application installed in order to perform the build. So
whether it's a tool, whether it's something like get Version,
whether it's something like get the lease Manager, you need
that on the host agent in order to perform the build.
If you look at the build agent that comes from
Have Actions, Chocolate is already on the box. So if
you need to perform an installation of an application as
part of your build, you can just add a new
step to your workflow, which is Choco install whatever the
application is.
Speaker 2: Yeah. Sure, so I could see this from the from
an ARM template point of view saying Okay, I need
to stand up this particular instance of a VM. I
want this SOS on it, and then once that's in place,
now I go into a get have actions they poke
to this, do your Choco installs start? To me, it's
all about repeatability, right like that, So every time I
call this that VM is exactly correct.
Speaker 3: So whether I say whether it's an ARM template or
whether it's something else. Like even Cody and our team
just now is looking to change our Packer builds to
regenerate some based golden images that we use, So Chocolate
is involved in that workflow as well. Packer defines what
needs to be installed and we use chocolate to perform
those actions. So that's definitely another mech and that we
can go through.
Speaker 1: If you have an exc that you want to always
install in your Windows machine that only has a gooey installer.
In other words, there is now command line switches or
anything like that. Is that throw a roadblock up for Chocolate?
Speaker 3: So yes and no, this is one of the what
I mentioned before that the Windows installer landscape is vast.
What you've described is just one of those. So the
creator of that installer, that native installer, hasn't included the
command line switches. So there is an immediate roadblock because essentially,
what Chocolate is trying to do is it's trying to
call out to just the ex to perform the installation.
So if it can't toggle the command line switches, then
there is a problem there. So what most package maintainers
do in that scenario is they will introduce something like
AutoIt or auto hockey. So they will have created an
auto hockey script. So for those who don't know, hockey
is essentially looking for triggers the Windows ecosystem. So whether
it's a form opening or whether it's a button becoming visible,
they will have created an auto hock key script that
will then do the action of clicking the buttons on
that native installer. So what the Chocolity package then looks
like is the Chocolate package takes a dependency on auto hockey.
So when Chocolatey comes along to install the first package,
it needs to install the dependency, which is all Hockey.
The script then says, run the auto hoockkey script and
look for these Windows triggers, and then it performs the
installation of your native installer. Auto hoot key kicks in,
it clicks all the buttons, and then the application is
then installed and the package is successfully installed after that.
So there is a mechanism to do it. But where
we get complaints source concerns is oh, where did this
auto hoot key come from on my machine? So then
we kind of have to explain that, Well, the native
installer didn't handle a clean installation or a clean unattended installation,
so you need to introduce something like a hockey to
perform that operation.
Speaker 1: It reminds me of when we used to do this
crazy show called Monday's and Mark Miller introduced his new
invention which was called the installed buddy. Okay, so basic
next next finished is in the days where everything was
a Windows installation and it would just click next, next, next, next, next, next, next,
finish for you installed buddy.
Speaker 2: It turns out it's a real thing. It's called auto
hot key. That's funny.
Speaker 3: It is the system is there. I mean it's it's
a viable solution for the underlying problem, which is the
native installer didn't have those plan line switches to make
it an unattended installation.
Speaker 2: I'm sure I imagine it's a little brittle if they've
changed it install steps well absolutely, yeah, yeah, So.
Speaker 3: What we do so as part of the so for
those who don't know, we have a Trotholate community repository,
which is where we host all of the Tropolic packages
that the community maintains. One of the things that we
do as part of that is the moderation process is
we will and the cloud will spin up a VM
to perform the installation to ensure that it actually installs correctly.
So if something were to change and the autohockey script
stopped working, then package verifier existing, which is when we
run through and check to make sure that things are
still installing correctly. It might ultimately fail and send a
message to the maintainer to say that there's a problem.
Those processes in place to help with that.
Speaker 1: This might be a good application of some sort of
AI thing that you know, can analyze the screen image
of you know the installer and figure out and you
can just tell it just you know, take select all
the defaults and it would do that. I don't know,
just thinking out loud, it'll be fifty bucks.
Speaker 2: Well, I keep thinking about like Microsoft has the form recognizer,
we will take pay per forms and generate them into
code for you. Like we're just not that far away
from saying, hey, just look at this dialogue and figure
out what should happen next. Yeah. Really, you really could
deeply automate that. So of course, if they the better
thing is just give us the command line yes please, yes, please. Yeah.
Speaker 3: I mean that's the for us from a package manager perspective,
that's the ultimate, because then that is what is No
one is repeatable, and it will continue to function the
way that we expect it to unless that a breaking
change in the installer or they switch installer technology, because
that sometimes happens as well. An application might the underlying
application doesn't change, but they might switch from a YSE
installer to an MSI or something changes in the native installer.
So that's where the package maintainer and the knowledge of
what is possible, that's where the package maintainer's job really
kicks in to help with keeping those packages install on
correctly nice.
Speaker 1: Are there any other sort of gotcha's or roadblocks besides
the the UI only installer that you guys deal with gracefully.
Speaker 3: So the one of the one of the hiccups that
sometimes have happened from a package maintenance point of view,
and it does cause problems for the package maintainers is
knowing what those silent arguments are. So again it comes
back to what is the underlying installer technology, because there
is a standard set. If you like, it's if it's
an MSI installer, these are the command line arguments, or
if it's this install technology is these command line arguments
or MSIs are actually sometimes better because they'll actually declare
within their manifest file these are the available command line arguments,
so you can pick which one you want to pass in.
So when you first get started with package maint and
then it's like, oh, I just want to install this thing,
but then you kind of have to dig into that
thing to understand how to manage it and how to
install it. So one of the things that we do
try to do and we provide this at the minute
and one of some of the commercial offerings is we
have a packaged builder, as we call it, so it
will actually look at the underlying installer technology and make
informed decisions about these are the sensible defaults for this
application type. So it's one of the it's one of
the features that we have been pushing within the team
to if we can bring it down to some of
the lower versions of Trocolate to make that package maintenance
story a bit easier. Something we'd like to have for
now that is a commercial only offering that we provide
that sort of installer detection logic and helping with the
provisioning of look packages.
Speaker 1: All right, go one more question before we take a
break here, and that is you know, sometimes we're installing
something and you need administrator approval, and so your whole
screen goes away and you get this dialogue box that
can't be automated. As far as I know, you have
to click the yes I approve button. Do you get
around on that by like just running the install scripts
in admin mode for example? I don't even know if
that is enough to get rid of that.
Speaker 3: From what you've described as one of the kind of
the fundamental principles of how Chocolate operates. So I know
that richer ops. That's going to go on when I
start saying this, but I'm already quivering. Bear with me,
doing a little bit right, Bear with me. So, Chocolate
as a product by default does require to be installed
by an administrator user, and it's installed to the c
program data folder with those administrative permissions, and as a result,
Chocolate Chocolate ex when it runs, needs to be running
as administrator because at the end of the day, most applications,
the most at least a significant proportion of the applications
that you want to install need administrator rights because they
might be installing to see program files folder, they might
be adding registry entries, they might be lots of stuff
that require admin permission. So way back when the decision
was made that chocolate as a product would require administrator
rights to run, and we have continued with that. Now
to answer your next question that might flow on to
that as well, how can I get other people within
my organization that don't have administrator rights to perform package installations.
That's where some of our other products, the likes of
background Service kicks in. So that's a mechanism where we
allow for a non administrator user to essentially request the
installation of a package, and that package installation is performed
by the background service that has those administrator rights. So
you're getting almost like a self service scenario where you
can say as a company, as an organization, I want
to allow the installation of these packages. But then as
a user, I can say, well, I want that one
and I want that one, and I'll self provision those,
so you kind of get the best of both worlds.
But yes, it's an age old problem. And the decision
that we chocolately made was that we would require administrator
rights by default now.
Speaker 1: So when you run under administrator rights, you don't get those.
Speaker 3: Dialogue normal no no, no correct. So you're you're you're
circumventing is the wrong word, but you're certainly side stepping
the need for the those ucps because you're escalated.
Speaker 2: Exactly.
Speaker 3: Okay, good, Now that has its own problems, and that's
kind of why I preempted the ops hack going on,
because then you're got administrator right, so malicious actors could
take advantage of.
Speaker 1: That, exactly.
Speaker 3: So that's there's all sorts of that we get into
within the team, within the organization, we get we have
lots of conversations along those lines as to whether this
is security vulnerabilities, et cetera. So all sorts of conversations
have along that.
Speaker 1: Well, we're gonna we're going to have that conversation after
the break carry so we'll be right back after these
very important messages stick around. Do you have a complex
dot net monolith you'd like to refactor to a micro
services architecture? The micro Service Extractor for dot Net tool
visualizes your app and helps progressively extract code into micro services.
Learn more at aws dot Amazon dot com, slash Modernize.
Speaker 2: And we're back. It's dot net Rocks. Amerger Campbell, Thatt's
Carl Franklin. You talking to our friend Gary and Park
a bit about the latest on the chocolatey side of things,
you know, I mean, you know, I'm the run ass
guy as well, and we certainly talk about install hacks
like there is.
Speaker 1: Like run as yeah there.
Speaker 2: Well, there are exploiters that are smart enough now that
they managed to get into a machine, recognize it, don't
leave it a process running that's waiting for escalated privileges
to intercept. But there's only so much you can do.
I mean, the reality here is we don't want users
to be able to install software. So you need to
ask privileges to install software. And where you're talking in
an enterprise environment. And as much as we talk about
granulating privileges for all of that, I know no one
I've ever spoken to that's done a large scale package deployment,
so multiple apps and so forth, installing where the privileges
are actually varying from install to install. They just go
super user push everything in, go out like it's just
not practical.
Speaker 1: And yeah, I think also the security risk come more
from people than they do from the software. I mean,
if you've got a good software bill materials and you
trust the software that you're installing goes without saying, then
the person the admin who writes the script is probably
going to be the one that runs it. So it's
not like somebody's gonna somebody like Patrick Kins to say,
if somebody just offered you a piece of food on
the street, here eat this, You're not going to eat it,
you know. Yeah, So if somebody says, here, run this script,
you'd be a little you should be a little apprehensive
about it until you check it out well.
Speaker 2: And more importantly, that's why we don't give you the
privileges so that you'll have to ask us about it.
We'll say, where did you get that from?
Speaker 1: Exactly?
Speaker 3: So exactly purely from a chocolatey point of view and
a chocolate ecosystem point of view, the default place to
get those packages that Carl's talking about there is the
chocolate community repository. So the problem that we have there
is that anyone can push to the chocolate community apositry,
so there is the potential for there being bad actors
in that space. Now we do what we can in
terms of moderating those packages and shooting a good package quality,
but ultimately there's no guarantee and we don't provide any
guarantee that there won't be something nefarious on that website.
But that's why we recommend due diligence in terms of
again that what you said, you wouldn't run any scripts
from the internet, you wouldn't install any package from the
internet either. There are a due diligence aspect to that.
Speaker 1: Well, so it depends on the package, right, I mean,
if it's version one point oh oh oh of some
new thing and nobody's installed it before, I wouldn't install it.
You know, you want to wait for there's definitely.
Speaker 2: Two.
Speaker 3: Yeah, no, absolutely absolutely.
Speaker 1: Package is mature and it's been vetted by the community.
Speaker 3: That's true too, yeah, absolutely. But where we're going to
go with that is that, in an organizational point of view,
we don't recommend the usage of the Chocolate community of
positry because it's not something that you as a company
would want to make use of. So what we recommend
instead is you take the packages that you vetted and
you put them into your own internal repository, and that's
where you get to your what you describe their car,
which was someone's done all the vetting, someone's done all
the package installations to make sure that they're valid, and
then you offer them up to the internal organization to say,
have your pick of these ones. But they don't get
to use the community depository.
Speaker 2: And this is the commercial version of Chocolate, right, that's
the central management tool and install our controls and all
those sorts of things. So for me as an oh, really,
that's exactly.
Speaker 3: Well, there was a slight clarification there. So the repository
itself so which is not to be confused with a
GitHub repository and one FNTO, here is a repository of
packages that's not something that we chocolately offer. So we
would look to something like a progate or an Nexus
or an arch factory to provide the actual.
Speaker 2: The actual package.
Speaker 3: Okay, so those are stored there, and what you're refering
to there is the Chocolate Central management. It would build
on top of that to allow the deployment of packages
to across your suite of computers. But we we at
a minute, don't offer a repository solution for packages.
Speaker 2: That's not something. And you also get to the other aspect,
which is rarely as an administrator of infrastructure, and do
I actually want the latest version of anything? Right? We
have an accepted set of versions of Adobe Reader, and
those are the ones we're going to install. I don't
care if there's new one coming out until it's gone
through the process. It's not in the package.
Speaker 1: I think the problem is you've chosen Adobe Reader. Yeah,
well fair, real problem.
Speaker 2: Yeah, but you know the the when when you get
to hundreds of thousands of seeds, you're trying to manage
the total landscape of different versions of things. Yeah, sure,
and so you get a little more strict and this
is the stuff you pay for and why you get
paid to do your job. So privileges are one thing,
but known versions of another. Because this whole conversation about
supply chain attack like this is only getting worse.
Speaker 1: It's serious.
Speaker 2: Yeah, and they're definitely besieging open source.
Speaker 3: So on that note that the flip side of that
is that there are thads out there that do want
the latest and greatest. And what happened the other month
was last month when dot Net shipped one of our
one of our core community maintainers, Jacob, he went about
and set about set created packages for all the new
dot Net packages. So whether that's the desktop version, the
runtime version, the SDK, he flooded us. He literally flooded
us with the dot Net related packages on the community pository.
So it's great because we then have all the dot
Net ten packages that people can then install. But that's
him literally being on the bleeding edge. It was it
was announced and he had packages ready to go and
ship to the community positors.
Speaker 1: And he said, I'm done then, you know.
Speaker 3: So the great thing about the open source is that
the option there and then is that someone could pick
those packages up. So all the work that Jacob does,
it's all on a gihub repository, all of his packaging scripts,
all of his automation to create those packages and keep
those packages up today, that's all on GitHub. So if
Jacob were to step away, and we've had people step
away from the community, that's absolutely something that happens. But
what we find is that there's always people that come
along and I say I'm interested in maintaining that package
and ultimately gets picked up. So Jacob would be sorely missed,
let's put it that way, if he were to step
away from the community. But for the he's been involved
in the all of the dominant packages since I can't
even remember when he started, and he's probably been around
as long as I have to be honest because his
name is so familiar.
Speaker 1: So go Jacob.
Speaker 3: Absolutely, absolutely, I'm not going to try and pronounce the
second name because it's not one that's in my remit,
I don't think. But he goes by Jacob, so that's well,
I'll stick with.
Speaker 1: Somebody should send him a pizza.
Speaker 2: What are your thoughts on the whole supply chain attack
landscape these days? Like do you do you give advice
to to developers that are using these tools on? Like
what do I got to think about to make sure
I'm not a part of a supply chain attack.
Speaker 3: I mean, it's definitely, it is definitely an issue. Is
prevalent with an hour, with an hour and ecosystem. It's
something we need to be conscious of. And if you
are using package management solutions like Chocolate or whether it's
something else, just installing the latest and greatest is probably
not the best advice. It would be maybe I'd carl
kind of hinto that with the first version of that application,
Maybe wait that thirty days or something to see whether
there's bugs, see whether there's anything with this.
Speaker 2: Is the ITAM mentality. Change is good. You go first,
you go exactly exactly.
Speaker 3: A great way of putting it. So it just just
to be sensible, to be honest. I mean, there's what
we offer on the community pository is any package that's
pushed to the CCR of the Trocolate Community postry, we
send all the related files and packages over divirus total
to let them scan it as well, and we report
that information on virus Total. So if there were something
that comes through, then that information is available on the
package page, so you'll be able to see that there's
a there's maybe a higher rate of virus detections for
this package version, and it might give you pause to
think about what that's maybe not a good idea, or
it gives you more pause to take it onto some
sort of DMZ within your organization, install it there without
letting it, letting it across your organization. There's mechanisms that
you can use to prevent those potential supply chain attacks.
But at the end of the day, I mean, it's
it is. It's something that we all have to be
conscious of because there's there are malicious actors out there
that we need to be careful of. It's unfortunately as
part of the world that we've lived in today.
Speaker 2: Well and these recently just the past couple of years,
we've found now long term maintainers that may have been
plants the whole time thence quiet, you know, getting that
maintainer of privilege that they could approve their own prs
and adding really like crazy sneaky things like the xz
util ones comes to mind, where literally, you know, this
is a utility for data compression that and numerous numerous people,
millions of people use, and this longtime maintainer slipped in
this bit of code that was sending telemetry of everything
being compressed to China. And the only reason it was
detected is that there was a Microsoft guy was his
name Andres who was doing performance testing version of version
and the new version was five hundred milliseconds slower, and
so he dug in like what made this slower? And
I covered this whole thing like it's quite a story.
Thank goodness, people like this exists. But it also speaks
to part of our instrumentation on updated versions. It really
is looking at the subtle changes.
Speaker 1: I kind of think automation is a good place for
these kinds of things to look like. GitHub has depend
abot right, and I don't know how much of it
is automated, but it seems like it is. And you know,
to do automated testing of things like this, Richard that
you know that this guy had a human had to
find that based on some timing. But some of these
things could be automated. I think maybe in the future
they will be more.
Speaker 2: Yeah, and I wonder this is what's againing well. Llm's
working for us right, not being part of the problem
where they to be able to assess the risk of
data changes and maybe raise a red flag because ultimately
that a self approved PR bad like giant red flag
right away. But okay, so you have two people involved,
but just having very detailed assessments of what's early in
that PR and what and what its potential risk is.
Like I wonder if we aren't already maturing and I
don't have evidence, but I'll look for it. That we
are starting to build lms. Who's specially who are going
to be And I shouldn't say who because it's software
that analyzed security risk on co changes constantly.
Speaker 1: Well you mean you already have you know, things like
gethub copilot.
Speaker 2: Yeah, well it depends on what we'll catch like keys
in code.
Speaker 1: Yeah yes, but it isn't going to test right. But
you know the thing about gethub copilot is you tell
it to do something, it just goes off and does it.
Or the get ub Copilot code Assistant I think it's called,
so you know, there could be back background process he's
running and get hub per se I mean not just there,
but anywhere where something new is checked in. I mean
it's just another pipeline really if you think about it.
Speaker 2: Something that you know the same way that used to
be so fixated on performance at SLA testing for a
lot of software where it's like, is this still going
to comply with the SLA or the performance levels that
we agreed to, you know now, and I'm thinking back
of the day where we were talking about just needing
provision new hardware because we were running our own rigs. Right,
it's like, hey, we added. The classic one was when
we added the recommendation engine and brought the whole place
of it's knees because it was so much more computationally
intensive and so we fortunately we ab switched it, figured
out how much more it was, and then like did
the math and said, we have to buy this many
more computers if we're going to be able to run
this thing. You know, So those kinds of benchmarking, the
fact that we're going to benchmark it to see was
malicious code added, Like wow, this is the world we're
living in now. It's really you know, package management ain't
what it used to be. You've been doing this longer
than anybody, Gary, Like, obviously the demands only get bigger.
I mean, is it getting better?
Speaker 3: I mean it's definitely as we continue to see more
people using it and we continue to see more packages
being pushed to the repostentry that we maintained. So it
is always, it's always that all of the graphs that
we have and that we maintain, more people are wanting
it and more people are using it. Right, But I mean,
I go back to where I started. I set up
and in this game quite a long time now, But
when I started, it was just literally I want a
quick way of installing this thing, but it's now morphed
into I want to bring up a whole suite of
computers that all have different applications on them, or a
whole different different applications on them to test these different
scenarios as part of my CICD pipeline. So whereas before
we would have been constrained to here's one build agent
that's got all the stuff on it that is maintained
in secrecy by the whole ops team, now transferred all
of that over to vms running in the cloud that
you can spin up on a whim, but you still
need to do the application management over it. And that's
where something like chocolate comes in. So it's it's a
never changing landscape, but it's one that continues to need
solutions like chocolate. So it's it's a very interesting space
to be involved in.
Speaker 1: Yeah, I bet never a dull moment.
Speaker 3: I bet never a dull moment.
Speaker 2: Yes, But you said pack. I think about how much
more complicated CICD pipelines are these days, and this package
management pipeline, including the feed in of new versions is
going to be at least as complicated now. Absolutely, it's
all part of the equation and it's.
Speaker 3: It's it's the landscape is ever increasing as you start
talking in the likes of ARM. ARM is now a
thing that people want to build on, and file for
and package for. So that's one of the conversations that
we're having internally is well, what is how does chocolate
fit into that ARM landscape and what do we need
to do to perform it because chocolate chocolate ex Today
runs under the emulation layer with on ARM, Right, but
do we want or do we need? Do you want
a native version of chocolate ex The answer to that
is probably yes, but then eventually eventually that but then
that causes our bills then need to change because we
need to introduce having the ARM hardware to then build on,
compile on, test on, package on. So it increases our
landscape of what we need to do in order to
provide that increase landscape for the customer.
Speaker 2: It's my experience with the Snapdragons, the Snapdragon ultras is
the emulator is very fast, and you'd be very happy
with that until you just see you see how much
faster it is running native correct, and the emulated version
was not bad until you saw the native version went wow,
I want that more of that.
Speaker 3: It's just and also some of the some of the
APIs they get lied to because of the emulation layer.
So where we would say what are you running on,
it will go well, I'm running on this, when actually
it's running on this completely separate things. So there's different
APIs that we need to call into for certain things
to get some of that information out. So the landscape
changes ever so slightly. But you if you're using the
emulation layer, but if you're running natively, that's those problems
no longer exist.
Speaker 2: And you guys don't tend to poke into ring zero
for any reason.
Speaker 3: You know, no, No, that's not no.
Speaker 2: That's and that's where the real WAMI comes for arm
is that all of that architecture is fundamentally different. Yeah,
as long as you're staying in the user layer. The
user layer lies to you really efficiently.
Speaker 3: Yes, So that's something that we're definitely looking at. It's
the conversations are being had about what we need to
do and what we need to do, because right now,
for Chocolate, we will say the helper scripts that we
have will say give me the thirty two bit installer
or give me the sixty four bit installer, and then
Chocolate does the right thing based on where it's running.
But then we would need to extend that to have
well are you on ARM and then is it ARM
thirty two? Is ARM clutter two still a thing? Is
it ARM sixty four? Yeah, there's all these questions here.
Speaker 2: When it's only ARMS sixty four, like just one last thing,
it's pretty hard. Thirty two is pretty much over.
Speaker 3: That's it. So but I say those questions are those
questions are being asked. Those we're trying to provide answers.
So that that I said, that landscape is ever changing
and we're trying to But I mean there's the other
parts of it from a development perspective. We had this
conversation last time where we've literally just done the switch
from dot net four up to dot net four point
eight we're in a similar chasm now where we're at
four point eight, but we want to jump to dot net,
to actual dot net. So there's conversations around what we
do there, what do we do again? Our builds need
to change, our testing needs to change. So there's it's
a never ending sea of things that need to be
thought about in conversations.
Speaker 1: All right, you're gonna love this question, Gary, what is
the wackiest tech support ticket you ever saw?
Speaker 2: For chocolate?
Speaker 3: So so the one that comes to mind is one
that I briefly spoke about and our last meeting, but
it was we had a customer who the customer that
was running CCM and CCM at the time. It does
a thing where we do deployment and it installed on
the computer that you're running on. So this customer happened
to be running on Windows Server twenty twelve, and the
deployment would work the first time, and then if you
ran it again it would fail. So there was it was.
It was in explosive. It would always just work. So
in our testing it always just worked. We were testing
on not Windows Server twenty twelve. So it turns out
that there was a problem with the SMA assembly the
PowerShell SMA assembly had a bug, and the first deployment
it worked just fine, and the second deployment, I think
it was an internal array that had been set and
therefore it didn't work the same way that it worked before. Literally,
after literally debugging or decompiling the SMA assembly and looking
at the generated code, I figured it out, found a
way to reset the array on each deployment, and I
was able to fix it for that customer. But that's
That's one of the the fundamentals of Chocolate is that
we try to be backwards compatible, but that end the
end result of that is we end up with customers
running on older operating systems that we're trying to support
and maintain.
Speaker 1: Yeah, and they're like, how dare you not run on
a ten year old operating exactly exactly you guys? Do
you freaking guys?
Speaker 3: So that's the one that immediately springs to mind. So
that was me splunking into the internals of the SMA
assembly to figure out how things work.
Speaker 2: And I mean, so there's no point in pushing to
the PowerShell guys. They're gonna go a sorry, now, that's
not a supported operating system.
Speaker 3: That's exactly it, so we were able to find a solution.
So sometimes these things happened, and that's literally there's nothing
we can do in this suggestion as well, you need
to upgrade to X whatever it is to upgrade. But
we try to support because we know that people are
running those older operating systems of older applications. So Chocolatey
tries to be as backwards compatible as we can be.
So we can say that we've got both the one
point X branch of chocolate and the two point X
branch of chocolate. Both of them are supported. So one
point X goes all the way back to dot net four.
If you really wanted to wow, I hope I I
would like to think there's not many people still on
dot net four. But yeah, stranger things have happened.
Speaker 1: Well, but this whole story about Windows twenty twelve and
I don't know when it happened, but it was probably
ten years later, right that, So.
Speaker 3: We're talking within the last three years, the last three
years that this was that man.
Speaker 2: But it.
Speaker 1: Just it speaks to the point that somebody has been
using Windows, a version of Windows for ten years, a
server version of Windows for ten years.
Speaker 2: Which by the way, only went out of support in
twenty twenty two.
Speaker 1: That speaks volumes, right.
Speaker 2: Like Microsoft used to offer ten years.
Speaker 1: If speaks volumes about the quality of Windows Server. I
think it does well. It does except for that one
stupid DLL that is the program didn't stupid initialize the array.
Speaker 2: But also you notice not Microsoft's pushing back and starting
to shorten those timelines to encourage upgrade. There's also some
vulnerabilities in twenty twelve that are really freaking serious, right,
like it's time to retire that.
Speaker 3: And it's one of those situations that yes, we know
people are using these systems, but we're also hoping it's
in some sort of air gun network that has less
to the Internet. Yeah, but again, stranger things well you know.
Speaker 2: Now, then back to my run ass hat. It's like
the Halfnium exploit of all of those old Exchange servers,
tens of thousands of them, which is sort of proof
that not leading people not upgrading, they are also putting
them on the internet.
Speaker 1: I told you, I think I told you many times
about my sister in law who just last year was
still running Windows Vista well on her home computer, not.
Speaker 2: Only running an old version of Windows, but a.
Speaker 1: Really bad but not only yet so, but her excuse was,
but I like it, and I'm like, I don't care.
You know what likes you, malware, that's what likes you.
Speaker 3: I remember, I think it was the Windows XP. I
remember trying to set up I think with my granny's
computer at the time, and I was trying to do
Windows updates on Windows XP and I got I remember
which bug it was, but it was one of those
bugs that in the time that it took me to
download the Windows updates, malware had attacked the machine. It
was already infected, and there was at that point there
was no mechanism to do downloads of Windows updates out
with the Windows Update interface. So it was a race
literally to try and get the update to fix the
bug before the bug got onto your machine, before.
Speaker 2: You got exploited through that bug.
Speaker 3: Yeah.
Speaker 2: Yeah, they those who ever looked up the half new exploit.
In the end, the FBI used the vulnerability to patch
the vulnerability. Wow, rather because people weren't fixing it. Yeah, wow,
is that bad?
Speaker 1: Halfnium? Is that what you called it?
Speaker 2: The coxploit? Yeah, it's a few years ago. There's a
whole run as on it. For those who care but
you know, this is all you know, this is all
the stuff that that the security people scare us with, right, right,
but these were these were crucial sort of turning point
of vulnerabilities. Right, it's twenty twenty one.
Speaker 1: Every Thursday, after I record Security this Week with Patrick
Hines and Duine Laflatte, Kelly sits down and says, so
what should I be scared about today?
Speaker 2: Just put the tinfoil on your head and be quiet. Right,
It's gonna be fine.
Speaker 1: Sometimes it feels like we're all screwed. It's just a
matter of how long it's going to be before that
happens somehow.
Speaker 2: Sometimes, well, the good news is the good The good
guys are smarter than the bad guys. But the good
guys have to be right every time they get guys
only have to write once.
Speaker 1: I don't know. The bad guys have countries behind them though,
So that's what bothers me. Armies of hackers. You know,
it's scary world out there. But as Rory said, once
cut off your hands, live in a box, you'll be fine.
Speaker 2: There's a tone for the show.
Speaker 1: Everything's going to be fine.
Speaker 2: Baggage management it's great, No, really, it's great.
Speaker 1: Great, No, it's fine. Gary. What's next for you? What's
in your inbox?
Speaker 3: So obviously more chocolate you work. I'm hoping to go
to ps COM for you in Germany in June the CONFI. Yeah,
so it's the EU version of the PowerShell Summit that
happened at State Side, so as a really good event.
I was there last year or sorry this year, and
I'm hoping to go next year as well. But yeah,
other than that, just being a dad, being a husband,
doing all the day to day stuff. It's not it's
not it's not exciting, but it is what it is.
Speaker 2: So oh, it's exciting being It's bloody rewarding is what
it is.
Speaker 3: That's very true.
Speaker 1: All right, Well Gary, thanks a lot. We always learn
a lot when we talk to you, and this was
no difference. So thanks than all right, We'll talk to
you next time on dot net rocks. Dot net rocks
is brought to you by Franklin's Net and produced by
Pop Studios, a full service audio, video and post production
facility located physically in New London, Connecticut, and of course
in the cloud online at pwop dot com.
Speaker 4: Visit our website at d O T N E t
r o c k S dot com for RSS feeds, downloads,
mobile apps, comments, and access to the full archives going
back to show number one, recorded in September two.
Speaker 1: Thousand and two. And make sure you check out our sponsors.
They keep us in business. Now go write some code,
see you next time. Got tad middle vans now the
summer time that means home. Then my Texas in line
read