Just say you have a chance to win a PS5 like @hcritter.bsky.social competition has. Give them a cd with the PS5 installer on it.

They've been modernising every release with 7.5 with each one causing regressions in the build outputs, delaying of the release timeframe, and wasting of the teams resources so they can no longer deal with issues and prs. Seems like it's a never ending story and now 7.7 will have this new problem...

It's alright, they've now got a year to waste trying to update their build process (for the 3rd time) and deal with the fallout/breakages there. Meanwhile PRs/Issues continue to pile on and community users get frustrated by the lack of any new features while internal problems are sorted.

I get that it's not great and maybe we want to discourage it's usage but it does have benefits in PowerShell to use a SecureString outside of the whole "encrypted in memory". There are problems yes but those problems still exist (and are made worse) by using a String instead.

If it was about keeping the status quo then sure I would agree with you but you are actively saying you want to remove SecureString which is a step backwards.

> If you don't want secrets in logs DON'T WRITE THEM TO THE LOGS.
it's almost as if developers and scripters get lazy so maybe it's a good thing it doesn't log by default. It's a good thing that you need to go out of your way to get the plaintext value here and we shouldn't move away from that.

Accidental logging is a big problem, especially since things like scriptblock logging is triggered by simple words like "property" and non-admins have the ability to see those logs by default. I thought defence in depth was a good thing but obviously not when it doesn't protect everything.

Yet you mention in other replies that there still needs to be work done in .NET to try and improve GC zeroing and other things. At least with SS you have a way to easily mask values when used in logging, parameter metadata to denote this is a secret, and clear out the value in memory after use.

I personally don't get the hate that SecureString seems to have in the .NET land. Yea it's not perfect but it still has some benefits. To me it's very much throwing the bathwater out with the baby by saying it's bad and we should remove it vs trying to improve it where we can.

The team did remove the key exchange work done for SecureString over PSRemoting. The bigger issue is just the use of SecureString in the ecosystem in general, e.g. Parameter types, logging, etc. That still needs an alternative which never came forward because perfect got in the way of good enough.

It’s going to fun for me with automation being a key driver. Let’s hope they solve the inboxing problem for 7.8 so we can just all go back to relying on that.

My understanding of msix packaging (I could be wrong) is that it fundamentally doesn’t have a system wide installation option. You can provision it machine wide but that only works for new profiles created afterwards. Not sure how it could ever be used for some of the mentioned scenarios.

Definitely unfortunately especially since there are known problems with MSIX that haven’t had any fixes in the years they’ve been open. Time will tell if this is the impetus to actually fix them but great even more reasons for 7.7 to be delayed due to “build” changes yet again.

Might add a comment on the thread, worst case I get shamed into deleting my GH account :P

Thank god, this has been a major annoyance with .NET. Would have loved to have seen an option to specify the parent process but can understand how complicated that would make HANDLE inheritance and stdio pipe redirection if they did that.

Against my better judgement I decided to post the code for the directory service last night.

github.com/SteveSyfuhs/...

All good, just curious if you had a specific reason. It’s a common problem where people try and use aliases like bash aliases then come unstuck. In most cases people just need the function defined with that name.

Any reason why you use an alias here rather than just the functions those names? Are you relying on the alias beating any other command found?

Did all your desired changes go in? IIRC there was a slightly more controversial change that needed some WG review or something? Still I love the extra detail here, very useful.

CredSSP Test Server CredSSP Test Server. GitHub Gist: instantly share code, notes, and snippets.

I'm torn, I've started to use it a bit more during the prototyping phase. The latest thing was gist.github.com/jborean93/d9... where I used LLMs to do some of the boring work like defining the ASN.1 structs and packing/unpacking logic. Has allowed me to focus on analysing the problem itself.

At least MIT krb5 just doesn’t seem to support it at all. gss_accept_sec_context expects the first input buffer on Kerberos to be an InitialContextToken with the Kerberos mech. From there it also expects the underlying message to be an AP-REQ and nothing else.

CredSSP Test Server CredSSP Test Server. GitHub Gist: instantly share code, notes, and snippets.

in the negotiate exchange (SPNEGO NegTokenInit/InitialContextToken with Kerb MECH not U2U mech). Lastly I needed to setup a keytab with the TGT so the acceptor can decrypt the ticket. All of it is in my POC at gist.github.com/jborean93/d9....

I ended up getting something working but unfortunately it doesn't seem to be possible in pure GSSAPI. The underlying kerb bits don't support the TGT-REQ so I needed to extract the ticket data and return that. The subsequent AP-REQ needs to be rewrapped so it looks like the first AP-REQ...

New release of the #PowerShell module `TextMate` (0.2.1)

added a builtin pager and partial ALC.
supports search highlighting and sixel images.

Accessible via the `-Page` parameter or `Out-Page` cmdlet.
github.com/trackd/TextM...

The issue is really how does it all interop with GSSAPI. So far I’ve parsed the TGT-REQ from the initiator, used the krb5 API to request the ticket ala kinit, send back the ticket data. But now the hiccup is dealing with the AP-REQ that is encrypted with the TGT session key and GSSAPI cred objects.

I definitely need to create a debug build of mit krb5 and step through it to see why it’s failing. It’s most likely just my keytab or credential handling as it looks like I need an actual TGT than a keytab for a SPN. I do see the req with the U2U mech oid and service names from the initiator.

Thanks, I hadn’t thought of the remote assistance but makes sense if the acceptor in that scenario is the user principal and not a service principal with an SPN. I’ll continue playing around but ultimately I’m trying to do the acceptor side for U2U on GSSAPI but seems like it may not be supported

Hmm I traced InitializeSecurityContextW and it looks like maybe it's ISC_REQ_USE_SESSION_KEY and CredSSP just always sets that? Can you think of a reason why CredSSP would want to use U2U here, what are the advantages of doing so?

@syfuhs.net is there some configuration or API flag to set somewhere to tell SSPI to use Kerberos User to User from the initiator side? I'm trying to setup a test CredSSP acceptor for a WinRM server and Windows uses U2U but I'm curious how it does that and whether CredSSP itself just forces it.

Nice, I’ve been meaning to create a source generator that builds the scaffolding to make a cmdlet run the blocks as an async task. A lot of the newer IO based APIs are async only and is a massive pain to use in pwsg sometimes.