Support sudo

Steps to reproduce
sudo Remove-Item foo.txt where foo.txt is owned by root
Expected behavior
foo.txt is deleted
Actual behavior
sudo: Remove-Item: command not found

Hum! Very interesting.  But, I think the actual behavior is as expected.  As in Windows we don't have a command like sudo.
But, you could use 'sudo powershell' and then do the remove foo.txt (which was created using 'sudo powershell') then it works when using Remove-Item.  Of course, it won't work in a non-elevated permission.
I would only use 'sudo' on Linux commands ("sudo nautilus") from within PowerShell.
:)

Even on Windows, it would be good to have similar capability to run a cmdlet as another user or elevated and something that could relied on in portable scripts.  May need an RFC for this.

This functionality would be useful to work around #3506.

This is going to become a blocker for adapting Linux for me if this is not resolved. We are not allowed to sudo bash and similarly will not be able to do sudo powershell.
I agree with Maximo, we should leave sudo to bash and make a new cmdlet for doing elevation in powershell using sudo as scaffolding on expected functionality.

@dantraMSFT has been investigating this, Dan can you provide an update on some current thinking for this?

@pixelrebirth Can you provide more detail as to what you expect?  Are you expecting simple execution with a wait, output redirection or pipeline redirection?

@dantraMSFT For sake of the argument I am going to call the new sudo like cmdlet: Invoke-Elevated
This is how sudo works and would translate to Invoke-Elevated in a powershell way
$cred = Get-Credential
Invoke-Elevated -credential $cred -command {
        Get-ChildItem ./test | Remove-Item -force
} | Get-SomeCmdlet

In this example, everything in the scriptblock would be executed elevated and then piped to a NON elevated Get-SomeCmdlet
Cred can be a different user or yourself as an elevated user (permissions needs to be kept somewhere like sudoers file does aka a whitelist)
Logging should be enabled, by default for instances where Invoke-Elevated is executed:
User | Command | DateTime or similar format logging
Maybe some of this gets extended or changed later, but this is what would remove my blockers

It should also work like:
Get-ChildItem ./test | Invoke-Elevated -command {Remove-Item -force}
Where the credential is your current user and it just asks for the password...
Get-ChildItem is NON elevated, Remove-Item is elevated in this example

I was on the community call today asking about this, but my wife got hurt during the explanation of the challenges for it and I missed a lot of it. Can you please put notes here so I can relay them to my boss?
I will help however possible and put pressure wherever I need to.

@pixelrebirth hope she's okay! We'll be putting up a recording of the call in the next day or two, so you can catch up if you like.
Basic summary is that @dantraMSFT is doing an initial investigation to figure out how to do this in a non-hacky way. Today, you can sudo powershell -c "invoke-foo" from another shell, but that's obviously not workable.
@dantraMSFT : as you work through your investigation, maybe post some status to make sure that everyone understands the tradeoffs with different approaches?

It may seem obvious, but maybe take a look at the sudo source code and see how they manage it-- maybe it requires some low level coding. I wish I had a deeper code understanding to help.

@pixelrebirth For reference, sudo uses the setuid bit, see https://unix.stackexchange.com/a/80350/86669 for details. It would probably be a bad idea to set that on a whole shell, though.

Native Windows sudo would be must  to have (so the issue probably doesn't belong here, although option where it is usable only via Powershell is acceptable for me ). I have used Powershell since the beginning and have seen 99 variants of sudo script around, like  Invoke-Elevated above (my own that I use every day). Including cmdlet like that in Powershell would be step forward, however, they all feel cumbersome relative to how this works on Linux.
One of the annoying things for me is that it starts a new shell window (not on linux ) which I would like to see implemented in Powershell, not sure if this is technically possible on Windows tho.

Although I like the idea of another cmdlet ("Invoke-Elevated") which could possibly be use in Windows, but I can't understand why not stick to open PowerShell with 'sudo' if you need to create a script to run with high privilege?
Especially If you're automating a task which will eventually be scheduled to run with some kind of high privilege credentials anyway.
:)

Because that is not the typical workflow. You don't 'sudo' and live there forever, you sudo specific commands and live in non-sudo world. There is no quick way to do so in Windows and powershell itself is terribly slow to start, especially with few profile elements included.

Thanks @majkinetor!
:)

The sudo should be CLI variant of UAC prompt. Windows, until recently, was never CLI friendly, but now I think we need this. The time has come when you can do 100% Windows things in shell only - I personally just use shell and the browser, almost nothing else.

@majkinetor: As far as I know, the only way to launch an elevated process is through the UAC prompt.
FWIW: You can accomplish this on windows without  a powershell change using ShellExecuteEx.
However, if you're expecting to stream back the results; it's a very different story.

As far as I know, the only way to launch an elevated process is through the UAC prompt.

Specific apps can be exluded from UAC which could I suppose  then handle elevation in its own way.

Wanted to offer my solution/workaround for Sudo on Windows. Any feedback/criticism would be welcome. If it's not appropriate to post this type of thing here I apologize in advance.
https://github.com/pldmgg/misc-powershell/tree/master/MyModules/Sudo
https://www.powershellgallery.com/packages/Sudo
There are three functions in the Sudo Module:

New-SudoSession
Remove-SudoSession
Start-SudoSession

Start-SudoSession (alias "sudo") is for one-off commands that you need to elevate. It will prompt for credentials and give you a UAC prompt before carrying out the command.
.EXAMPLE
$ModuleToInstall = "PackageManagement"
$LatestVersion = $(Find-Module PackageManagement).Version
# PLEASE NOTE the use of single quotes in the below $InstallModuleExpression string
$InstallModuleExpression = 'Install-Module -Name $ModuleToInstall -RequiredVersion $LatestVersion'
Start-SudoSession -Credentials $MyCreds -Expression $InstallModuleExpression

New-SudoSession if for opening an ElevatedPSSession into which elevated commands can be injected.  The idea is that in a longer script with multiple operations that require elevation, you create an ElevatedPSSession at the beginning and receive a UAC prompt ONCE, and then inject those elevated commands using Invoke-Comman into that ElevatedPSSession when needed.
.EXAMPLE
PS C:\Users\zeroadmin> $MyElevatedSession = New-SudoSession -UserName zeroadmin -Credentials $MyCreds
PS C:\Users\zeroadmin> Get-PSSession
 Id Name            ComputerName    ComputerType    State         ConfigurationName     Availability
 -- ----            ------------    ------------    -----         -----------------     ------------
  1 ElevatedSess... localhost       RemoteMachine   Opened        Microsoft.PowerShell     Available

PS C:\Users\zeroadmin> Invoke-Command -Session $MyElevatedSession.ElevatedPSSession -Scriptblock {Install-Package Nuget.CommandLine -Source chocolatey}

Finally, the Remove-SudoSession removes the ElevatedPSSession created by the New-SudoSession function. The idea is to place this at the end of your script, at which point you will receive a UAC prompt. So in total, to run any number of elevated operations in a particular script, you only get hit with two UAC prompts - one to open an ElevatedPSSession and one to close it. Remove-PSSession usage:
.EXAMPLE
$ModuleToInstall = "PackageManagement"
$LatestVersion = $(Find-Module PackageManagement).Version
# PLEASE NOTE the use of single quotes in the below $InstallModuleExpression string
$InstallModuleExpression = 'Install-Module -Name $ModuleToInstall -RequiredVersion $LatestVersion'

$SudoSession = Start-SudoSession -Credentials $MyCreds -Expression $InstallModuleExpression

Remove-SudoSession -Credentials $MyCreds -OriginalConfigInfo $SudoSession.OriginalWSManAndRegistryStatus -SessionToRemove $SudoSession.ElevatedPSSession

Under the hood, here's what it does from a Non-Elevated PowerShell session (if the session is already elevated, it doesn't do anything):

Checks to make sure WinRM/WSMan is enabled and configured to allow CredSSP Authentication (if not then
configuration changes are made)

Checks the Local Group Policy Object...
Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials
...to make sure it is enabled and configured to allow connections via WSMAN/

Creates an Elevated PSSession using the New-PSSession cmdlet

Runs the expression passed to the -Expression parameter in the Elevated PSSession

Removes the Elevated PSSession and reverts all changes made (if any) to Local Group Policy and WSMAN/WinRM config.

@pldmgg I don't see what license your code is under so we can't even look at what you've done.  Can you add a LICENSE file?  MIT would be most friendly and allow us to use your code or derive from it.  Thanks!

@pldmgg also, very very cool!

@ferventcoder Thanks for the reference https://choosealicense.com! As you guys (+ @SteveL-MSFT) probably suspected, I wasn't really sure what license to pick. I updated my entire misc-powershell repo to use Apache 2.0, and I updated the Sudo.psd1 to reference Apache 2.0 in my git repo as well as PowerShell Gallery. Hope this can be of use to folks! All advice/criticism welcome!

@SteveL-MSFT Can you use it if the license is Apache 2.0? If you need it to be MIT, let me know and I'll update.

@pldmgg my biggest problem with your solution is use of CredSSP. That is a less secure method for credential handling and I think exposes a lot of risk to the UAC boundary.
To quote from Powershell Magaize,

"It is a bad idea to use CredSSP to authenticate to a user’s workstation using a domain administrator account; you are essentially giving away the keys to the kingdom."

"Don’t  put high trust credentials on low trust computers"

The whole point of UAC is about not trusting the applications on the computer. Even though I may consent to a sudo command that ends up running havoc on my machine, it usually won't have my credentials. If the sudo command now has clear access to my domain credentials, it could do far more damage in compromising my network.
Can your solution be made to work without CredSSP? If not, what problem were you trying to solve in using CredSSP? That information could be useful for the PowerShell team to find a more secure solution.

@pldmgg I believe Apache 2.0 is sufficient.  Thanks!

@dragonwolf83 This is a common concern. I actually put forth my whole argument that it's okay in this specific situation in this thread:
https://www.reddit.com/r/PowerShell/comments/6c778m/startsudosession_sudo_for_powershell_written_in/dhsretm/
But, to summarize, I think it's okay here because:

It's connecting to the localhost (not remote)

Since Windows 8.1 / Server 2012R2, CredSSP no longer sends passwords in clear text

Remote Desktop Protocol is still vulnerable to pass-the-hash attacks, just like CredSSP, so if you're worried about that for CredSSP you should also be worried about that for RDP. (Of course, there is RDP Restricted Admin mode or the new "Credential Guard")

P.S. This article has become my goto reference for PowerShell Security. I highly recommend it.
https://blogs.msdn.microsoft.com/daviddasneves/2017/05/25/powershell-security-at-enterprise-customers/#comment-95

For 6.0.0, I think where we will end up is:
A script function called sudo that only exists on Linux (we're deferring Windows elevation support).  If the argument is a cmdlet/scriptblock, then it will sudo powershell with those arguments.  This does mean that for now, pipelining objects won't work.  If the argument is a native command, we just pass that directly to sudo.
Post-6.0.0, we would like to eventually get to an experience like:
Get-Item foo.txt | sudo Remove-Item

and have it work on both Windows and Linux.  cc @joeyaiello

Based on @PowerShell/powershell-committee discussion, this is not required for 6.0.0 and recommendation is to invest in a Invoke-AsUser type cmdlet

To change elevation in general, you would need something with setuid bit under UNIX and that would be sudo itself. sudo is a special binary that cannot be easily emulated and should not be emulated for security's sake. Please let the actual sudo be used to launch a temporary instance of powershell that runs the command in question. Also, sudoing a whole shell is rather unsafe considering that one may forget the shell open on a remote server. sudo has a mechanism to forget that the user elevated after a few minutes which protects the machine in the long run. The resolution fo this issue would allow more people to use powershell in production on Linux servers. As things stand, powershell will remain a sideline novelty since security is paramount in production.

With #1527 and this issue getting pushed further and further back the milestones, I'm starting to wonder: Is everyone really that comfortable logging in to root sessions to do admin stuff? There is practically no convenient way to invoke PowerShell commands when PS is involved in any way.

@MathiasMagnus  I haven't tested this thoroughly, but you can configure common or repeatedly used commands to not require a password on sudo. To test I added this with visudo:
mark ALL=(ALL:ALL) NOPASSWD: /usr/bin/pwsh

I was then able to call sudo pwsh -c 'cat /etc/sudoers' over a PowerShell SSH remoting session. Depending on how you are doing your security and what exactly you configure in sudoers (for example, All=(ALL:ALL) is a bit open...) this could be safe or dangerous.
If you ssh to Linux (i.e to bash shell instead of PowerShell SSH remoting) you can run sudo with normal password prompting so far as I can tell.
Its not so much that it's impossible, just that the current workarounds comes with some baggage.

@MathiasMagnus #1527 is still targeted for 6.1.0 as there is no good workaround for that.  For cmdlets, the main issue is the complication of pipelining to/from a sudo'd cmdlet.  For single operations sudo pwsh -c is viable.  Of course if someone from the community submits a PR, we'd be more than happy to take it.

On Windows, this is now an issue that I don't think can be solved without not elevating ssh connections, which then requires a way to elevate from the command line.

I know it is easy to b*tch about things not working and not taking action, but my expertise lay elsewhere. I mostly contribute to C++ and GPGPU libraries and Vcpkg doing lots of CMake porting. I've never written C# and I don't think I'll have the capacity to. However I do administer a small cluster of ~12 machines. It's on the border of being manageable by hand, but sudo capability is missing direly, that is if I don't intend on creating login for the root user on Ubuntu, something that is frowned upon. DSC Core would be a solution, but even though it's been announced a year ago, it's recently been delayed indefinitely.
PowerShell Core on Linux as it currently stands is kinda stuck between the automated way of doing stuff and the ad-hoc style that is familiar to Linux sysadmins. I hope someone will find the time to attend this issue.

@MathiasMagnus this is something everyone wants, but is not a simple problem to solve.  Note that using sudo against native commands work fine, it's really just not available to run sudo against cmdlets.  Workaround is to invoke pwsh within pwsh:

sudo pwsh -c remove-item something

The main complication is when it's something within a pipeline:

get-item foo* | sudo remove-item

@SteveL-MSFT It conceptional it is not that complex. Please tell me what you think.
We simply need a combination of the sudo, su and login binaries, to handle all cases.
It needs to do:

Create a unix socket for callbacks and only allow the destination user access to it.
Validate that the caller is allowed sudo access (I think one can simply copy the source code of su, sudo and login)

If /etc/sudoers exists, it needs to be parsed

Only specific commands
By using the destination users password
Without validating credentials (passwordless)

If it does not, one needs to invoke pem to check if the user "knows" the credentials for the user root directly.
If he also does not know the destination users credentials, deny access and throw an exception in powershell.

If the validation passed, we need to switch the user context into either root, or the destination user.
Once we switched the user context the new process needs to establish communication back to the original powershell running by connecting it to the unix socket.
If the user enters "exit", we signal over the unix socket, that we're finished and as we exit, the user will automatically return to the callers privileges, so we only need the hosting powershell to display a prompt or execute the next instruction.
If instead the host powershell terminates, the unix socket gets closed and the elevated powershell should halt execution and terminate, just like if one closes the terminal.

Execution flow would look like this:
PWSH (creates socket /proc/self/change-user.socket) => PWSH-SU (invoked with the socket and destination user as parameter; PWSH-SU is also set suid to run as root itself) => PWSH as destination user connects to the unix socket.
The most time consuming part is to allow the powershell to connect internally over a unix socket. Just redirecting input and output linke other unix applications do is not enough, as we deal with objects and not just with strings when invoking pipes.
Why use all three binaries?
sudo is required to allow multiple users to switch into root context without losing auditability.
su is used to switch into any other user by using the destination users credentials.
login is used to create a whole new login session.
Having all of these functionality also in powershell can be useful in many cases, compared to only have one.

Using pipes could make this work on Windows too in a manner that is less surprising and more convenient - I hate that I get another shell with all "sudo" scripts + UAC clicking but with pipes like this it could be done within the same shell just like on linux by communicating over pipe with another interpreter already running as admin and maybe implementing some real sudo stuff (prompt timeout for example or sudoers file with commands as alternative to custom powershell endpoints)

I'm really happy to see the thoughts on this, but as far as the actual implementation, it seems to me we're getting a little ahead of ourselves. The first thing is the system needs a way to create an elevated process, thread, whatever from an unelevated one. None of the cmdlet concerns can truly be solved if we can't create an elevated instance of PowerShell to start with, without going through UAC. IMO, the first scenario to be addressed here should be - you have a limited SSH session - how do you execute a regular exe with admin permissions?
I started experimenting with this here (currently broken as I've been refactoring it, but the concept works), but I don't think a 3rd-party app is the real solution. I'd like to see Windows ship a 'sudo' exe first. This could be as simple as enabling runas to create elevated process when developer mode is on, but without the first step this is all theoretical.

None of the cmdlet concerns can truly be solved if we can't create an elevated instance of PowerShell to start with, without going through UAC

One possibility to do this involves using scheduled task with option 'run with highest privelege'.

Yeah but to create that, you have to already have admin permissions right? That's what psexec does. As far as I know, right now, you have to at some point go through UAC. I'd like to see that change, and with all SSH sessions being elevated, it's sort of a security concern. If some sketchy software tries to SSH into my Windows machine, say from another computer where I have a private key set up (or the loopback scenario), it can do anything it wants.

Yeah but to create that, you have to already have admin permissions right?

Right, but it doesn't trigger UAC popup.
UAC can also be skipped the official way with Microsoft's Application Compatibility Toolkit.

Windows does not support SUID and GUID.

Windows doesn't have to support it and concept is not valid on that OS.
Its permission model is based on ACL's and there is no single group ownership.
It also doesn't have to be full sudo replica on windows, just a more friendly way to invoke admin commands.

I think it's fine to defer Windows support as Windows users are probably accustomed to opening an elevated PowerShell session today while Linux users expect to run as non-root and sudo as needed.  We just want to make sure any design doesn't preclude future Windows support.  I would also probably focus on simply enabling sudo for root rather than any arbitrary user to simplify it and I believe this is 90+% of the usage.

@SteveL-MSFT

would also probably focus on simply enabling sudo for root rather than any arbitrary user`
I think this will not make a big difference, but provide the full su/sudo experience for the abstract I've outlined above.

I think it's fine to defer Windows support as Windows users are probably accustomed to opening an elevated PowerShell session today

Majority of the people I worked with just disable UAC if they can.

Unfortunately, that isn't really an option in many environments, and I very much doubt MS is going to up and ditch UAC completely. 😕

I recently added the following to my $profile. I covered it in more detail over at https://stackoverflow.com/a/56265080/118098
function Invoke-MySudo { & /usr/bin/env sudo pwsh -command "& $args" }
set-alias sudo invoke-mysudo

At least on the face of it, this works for me, and allows "sudo ". This doesn't cover the case of "able to sudo a cmdlet within an existing PowerShell Core session" per https://github.com/PowerShell/PowerShell/issues/3232#issuecomment-354853084
However, I wonder how important it is to give the elevated context the entire session of the calling command. In other shells, sudo still runs the provided command in a new context.

I have implemented a basic sudo that works well for running commands as administrator on Windows. You would probably NOT want to use this on linux/mac.
Edit your profile:
PS > notepad $PROFILE

Add the following sudo function:
function sudo {
    Start-Process -Verb RunAs -FilePath "pwsh" -ArgumentList (@("-NoExit", "-Command") + $args)
}

Then invoke in your shell. Supports cmdlets, executables, anything that could normally be typed into a PS prompt:
PS > sudo { Remove-Item .\test.txt } # Remove a file
PS > sudo { Copy-Item .\test.txt C:\ } # Copy a file
PS > sudo { net start w3svc } # Start IIS

Note: You don't always need wrap the command in braces, but you DO need the braces if you want to pass in variables without having them evaluated before execution.
Remove "-NoExit" from the sudo function if you'd prefer to have the administrator window close when complete.

@vsalvino This is a useful workaround when GUI is available and is helpful in the meantime, but this is still not a real sudo because it doesn't work without GUI access. In a remote shell (ssh), literally the only way to make this work is a service and client as I tried to demonstrate here.
To address some common suggestions, because believe me I've looked at every possibility:

Disabling UAC is not a solution. It's a workaround that can be made as a personal choice but it's not a general solution to this problem.
Anything that pops up UAC (every "sudo" script I've seen) is not a solution, including doing it once to start an elevated remote session.
Anything that requires GUI at all is not a solution. Let's assume we're using ssh here and GUI is not available.
Anything that requires major changes to Windows is not a solution. We can't count on UAC turning into something better.
Even a signed binary from Microsoft is not a solution, because it won't work when UAC is set to high (I got this wrong on the wsudo readme; I'll correct it later).
The only real solution to sudo on Windows is a service that elevates user processes on successful authentication. I'd love to hear other ideas but please do your research first.

Basically, somebody is going to have to do a lot of work, no way around it. What we want is something that, once PowerShell supports this on Unix, is a drop in replacement on Windows, and works as you'd expect sudo to work (no GUI, no UAC).

Can we please clarify the scope of this issue first?
Is this issue:
a) About implementing sudo within powershell for linux/mac systems?
b) Implement a sudo replica into windows?
c) Allow to elevate privileges when psremoting?
d) Allow to impersonate other users on windows?
e) something completely different?
For a) https://github.com/PowerShell/PowerShell/issues/3232#issuecomment-444849067
For b) Same as a, but instead of a suid binary it needs to be spawned by a service and that service also needs to check privileges. Or implement SUID/GUID concept on windows.
For c) not required you already have highest privileges when remoting. There is no privilege separation when accessing remote hosts (There have also already been some localhost loopback UAC bypasses that worked this way).
For d) Also the approach from a/b can be taken, but I don't know how that should work when trying to access network resources, without knowing the users credentials or crafting a new windows/activedirectory authentication backend.

IMO this issue should be about implementing sudo in PowerShell where the underlying functionality already exists. Discussion about a sudo equivalent for Windows is probably more appropriate in this terminal issue.

Discussion about a sudo equivalent for Windows is probably more appropriate in this terminal issue.

Why would terminal app be a better place to discuss sudo, given that its only yet another frontend to the CLI world ? By the same logic you could file a ticket at ConEmu repository.

IMO this issue should be about implementing sudo in PowerShell where the underlying functionality already exists.

One of the points of the next Powershell is less compatibility issues between systems using it. Regarding that, doing something only on system X is IMO not acceptable.
I as a CLI user couldn't care less if sudo is full blown linux sudo using suders file or some windows alike. Sudo is just an interface to elevation features of the OS. Such an interface could be made to work near identically regardless the 'backend'.
Otherwise, @parkovski  point about GUI stands - I would just add Windows Core among the reasons why.

Any opinion on this ?
http://blog.lukesampson.com/sudo-for-windows
Installed with scoop install sudo, its the closest I can think of. It works like unix sudo - run commands with elevation. I use it with pip or Install-Module for all users.

@Restia666Ashdoll If it is renamed to Invoke-ElevatedCommand I'm fine with that.
That's because sudo is not only responsible for elevating commands, but also for impersonating users. Also reusing already existing names already has proven to be a bad idea, especially if the functionality and parameters differ.
I already outlined above what a true sudo with impersonation would look like and how it could work.

@Restia666Ashdoll Please read this comment in this thread.

@parkovski Thats just a wrapper for for -Verb RunAs, which only works with a few commands. The one I linked to can be used almost with everything. For example I use it like this - sudo pip install httpie.

You didn't read my post did you?

I don't suppose there's any way to get the title edited to include something like "NOT A SUDO ON WINDOWS DISCUSSION"? I know I'm not personally under any obligation to keep answering this, but people keep showing up saying the same thing without doing their research.

I don't know who is who dude
On Mon, Dec 9, 2019, 5:47 PM Parker Snell<EMAIL_ADDRESS>wrote:

I don't suppose there's any way to get the title edited to include
something like "NOT A SUDO ON WINDOWS DISCUSSION"? I know I'm not
personally under any obligation to keep answering this, but people keep
showing up saying the same thing without doing their research.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/3232?email_source=notifications&email_token=AN6RWNIRMRVQVCX53TKND3LQX3KKLA5CNFSM4DB3JEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGLDN6Q#issuecomment-563492602,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN6RWNP7UAJMVAGF2I5YVQTQX3KKLANCNFSM4DB3JELQ
.

Last few messages got screen shotted to my phone
On Mon, Dec 9, 2019, 5:49 PM Baby J<EMAIL_ADDRESS>wrote:

I don't know who is who dude
On Mon, Dec 9, 2019, 5:47 PM Parker Snell<EMAIL_ADDRESS>wrote:

I don't suppose there's any way to get the title edited to include
something like "NOT A SUDO ON WINDOWS DISCUSSION"? I know I'm not
personally under any obligation to keep answering this, but people keep
showing up saying the same thing without doing their research.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/3232?email_source=notifications&email_token=AN6RWNIRMRVQVCX53TKND3LQX3KKLA5CNFSM4DB3JEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGLDN6Q#issuecomment-563492602,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN6RWNP7UAJMVAGF2I5YVQTQX3KKLANCNFSM4DB3JELQ
.

They were saved to drafts
On Mon, Dec 9, 2019, 5:47 PM Parker Snell<EMAIL_ADDRESS>wrote:

I don't suppose there's any way to get the title edited to include
something like "NOT A SUDO ON WINDOWS DISCUSSION"? I know I'm not
personally under any obligation to keep answering this, but people keep
showing up saying the same thing without doing their research.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/3232?email_source=notifications&email_token=AN6RWNIRMRVQVCX53TKND3LQX3KKLA5CNFSM4DB3JEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGLDN6Q#issuecomment-563492602,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN6RWNP7UAJMVAGF2I5YVQTQX3KKLANCNFSM4DB3JELQ
.

I deleted it what you wanna dobro tell me something fast
On Mon, Dec 9, 2019, 5:47 PM Parker Snell<EMAIL_ADDRESS>wrote:

I don't suppose there's any way to get the title edited to include
something like "NOT A SUDO ON WINDOWS DISCUSSION"? I know I'm not
personally under any obligation to keep answering this, but people keep
showing up saying the same thing without doing their research.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/3232?email_source=notifications&email_token=AN6RWNIRMRVQVCX53TKND3LQX3KKLA5CNFSM4DB3JEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGLDN6Q#issuecomment-563492602,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN6RWNP7UAJMVAGF2I5YVQTQX3KKLANCNFSM4DB3JELQ
.

I tried to click this guy's unsubscribe link and it unfortunately won't let me do that without being logged in as him.

Who is this I am looking for one person if you not the person I ain't got
shit for u. So stop sending ads
On Mon, Dec 9, 2019, 5:42 PM Parker Snell<EMAIL_ADDRESS>wrote:

You didn't read my post did you?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/3232?email_source=notifications&email_token=AN6RWNP43FTHE5NLLLH5KODQX3JXPA5CNFSM4DB3JEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGLDD7A#issuecomment-563491324,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN6RWNLUVP4UFRV7IBVX5GDQX3JXPANCNFSM4DB3JELQ
.

I've reported @troymoore to GitHub already

I would like to propose a unique and different solution that I have not seen talked about here. What about using something like named pipes to serialize commands to an elevated process which then returns it's serialized output to the calling process?
Here is a functioning module that demonstrates how this would work on NT: https://github.com/mmillar-bolis/Invoke-AsAdmin
It's not perfect, of course, but it accomplishes elevating simple tasks and piplines without opening another console. I do not intend to pitch this as a sudo-alike per se as I don't believe cloning sudo's design will be the best long-term solution, but I thought that a different approach to this nebulous elevation problem might further constructive discussion.

It looks like JEA.
As for serialization, not all modules support this.

It looks like JEA.

Yes, that is the idea.

As for serialization, not all modules support this.

As you probably saw in the code, this is mitigated with text streams that reconstruct the code on the other end of the pipe. I admit that this is slow, but nonetheless a novel workaround. Your mention of JEA was again an influential factor here; if some part of one's code does not need to be elevated, it should not be.
The module is meant to solve a very specific problem of elevating interactive commands within GUI sessions on NT and nothing more. The thing was started like five years ago before anyone imagined native ssh might be a thing for NT. I agree with @parkovski that this an issue related to how NT handles elevation, so without a service listening for and providing a contoured form of command elevation, it is rather difficult to achieve an ease of use case similar to sudo, pkexec or doas.
Yet, instead of being halted by a nirvana fallacy that a sudo-like implementation must exist on NT before PowerShell can support any form of command elevation, why don't we first push for any form of JEA interactive elevation within the shell session?
This would at least promote improved security practice in the NT world. Why not implement both a cmdlet to run interactively, and one to start a separate console session? Or even better, just promote the current ways to start an elevated session alongside a more spartan set of cmdlets with different use cases? It's at least a step forward.
I might also add that even the Python elevate library cannot do what this module does. Have you found another module to not work with it already? Because my main point is that maybe smarter minds than mine can take this module and it's ideas and run with it in a direction that will fit for NT. After that, we may have the beginnings of a platform for NT and *nix to meet in the middle, allowing us to revise a more common implementation to elevate commands.
That's my two cents, at least. But having seen the code, if one feels that the ideas within are no good, I will understand. I just had not seen anyone even try something like this yet.

Gonna step back from my frustrated grievings of explaining the point of sudo for a minute because (a) yes this is a very difficult problem, (b) can really only be solved properly by MS (thanks for not being open source, Windows), (c) it really is cool to see that others are passionate about this too.
I know how hard it is to do this properly because I started down that road. So if the only thing keeping us from that for now is a UAC dialog, so be it. At least this way we can test a cross platform solution with a minor effort.
What I'd personally like to see from PowerShell is comprehensive support for the Unix sudo, but designed to support some form of "pseudo-sudo" script as it is now as well as a future potential real Windows sudo. My thought is that if someone prototypes out how a Windows sudo will eventually work but leaves the UAC restriction, it should be fairly straightforward, give us something that's basically as good as it gets for now, and when we get the real thing it should pretty much just be a drop-in replacement.
Obviously this means someone's going to have to come up with a model that understands or at least translates to both the Unix uid/gid model and the Windows sid/acl model. Hopefully this person likes a challenge. Guessing this will also require some talks with the terminal and windows security teams within MS.
I guess that with as many people having created their own best-effort workarounds, and that supporting something like this could well help design a robust way of doing this, why not?

We could think about Start-Process pwsh -NoNewWindow -Credential $cred. It does not work but could.

Obviously this means someone's going to have to come up with a model that understands or at least translates to both the Unix uid/gid model and the Windows sid/acl model. Hopefully this person likes a challenge. Guessing this will also require some talks with the terminal and windows security teams within MS.

Unix also has acls and windows has posix compatibility and at least if it is domain joint there is also a primary group attribute that we could use (as well as posix attributes). It just would need to be implemented for non domain joined windows clients (or for now assumed to be User).
Than we could map the unix permissions as:
uid => Owner SID
gid => The primary-group SID of the user who created the object.
user => Creator Owner ID S-1-3-0
group => Creator Group ID S-1-3-1
other => World/Everyone S-1-1-0
Mapping the uids from the acl list on unix is a bit more complicated as we need to consider that the system may be part of an ldap, active directory, or any other directory. The only two cases I would consider in scope for powershell are no directory and ldap/active directory.
In the first case I'd suggest using S-1-6-1-uid and S-1-6-2-gid (assuming S-1-6 is still available and the responsible team is willing to allocate it for this purpose).
And for the 2nd case we just need to have some sort of resolving the uid though the authentication backend. The ldap/active directory server is than responsible for providing an sid.
And finally there are some special cases to map:
uid 0 => S-1-5-32-544
gid 0 => S-1-6-500 (and S-1-5-21-*-500)
most other well-known sids can be managed through a config file or through an api of some sort (or just drop them as they are most likely not used anyway)
If we do this in the shell build in commands like Get-Acl/Set-Acl would than start to work on unix systems without knowing about how the permissions are stored on disk.
@mmillar-bolis I already suggested an approach using sockets here: https://github.com/PowerShell/PowerShell/issues/3232#issuecomment-444849067

We could think about Start-Process pwsh -NoNewWindow -Credential $cred. It does not work but could.

Update: .Net Core (and I guess Windows API too) doesn't allow to run new process attached to the same console.
So single way we can use is a elevated Windows Service. But we have to create such service process per "sudo" to be secure.
So solution will be New-PSSession (or invoke in PSSession) to localhost with elevated user credentials.

@iSazonov One of the only things that would allow you to attach it to the same console is what I already mentioned here: https://github.com/PowerShell/PowerShell/issues/3232#issuecomment-444849067

@agowa338 Your proposal "de-facto" is PowerShell remoting. It is already implemented.

But

So solution will be New-PSSession (or invoke in PSSession) to localhost with elevated user credentials.

does not work for localhost. It only throws AccessDenied.
Except if the process (powershell) is already elevated.
Here is a good explanation why that is by @jborean93: https://github.com/PowerShell/Win32-OpenSSH/issues/1308#issuecomment-448430464

@agowa338 Comment you referenced is about local Windows API, not PowerShell remoting that was a question there.

@iSazonov:  Have you even tried doing powershell remoting to localhost? I did and it does not work for the reasons outlined above. The assignment of the accesstoken is blocked by the os.
PowerShell remoting to localhost does not work to get elevated privileges on the local computer.
PowerShell remoting however grants you elevated privileges on all other hosts in the network except localhost.

@agowa338 It does not work for you because of security protection. It is not OS feature. You can configure WinRM as described in docs https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting . Issue you referenced also says that this works for SSH (steps are in referenced there article).

as the functionality would already exists.

Request is to get working "sudo Remove-Item foo.txt where foo.txt is owned by root".
It does not works but we would want.
The problem consists of two parts: syntax sugar in language and implementation.
If you think more about your proposal you discover that you need to have per user/per session/per runspace/per scope powershell context. Then you have to address security compliance requirements and you will get "access denied" in default configuration. After that your proposal will the same as already implemented PowerShell remoting.

It does not work for you because of security protection. It is not OS feature. You can configure WinRM as described in docs
@iSazonov Can you elaborate that a bit more? I can remote to that machine and from any machine to any other machine in the network, but from none of them to localhost. And yes I read that page.

Request is to get working "sudo Remove-Item foo.txt where foo.txt is owned by root".
And you started talking about windows, for non windows systems we could use the unix socket approach to implement impersonation/elevation for powershell remoting there.

Can you elaborate that a bit more? I can remote to that machine and from any machine to any other machine in the network, but from none of them to localhost. And yes I read that page.

Most attacks target local elevation. So all configs is "secure by default". WMI, WinRM, IIS loopback and etc - all subsystems disable features which allows local elevations.
It is not so important for the discussion. Even if PowerShell remoting does not allow us to do sudo by default, we could implement it turned off by default or allow only for an interactive session.

You started talking about windows, for non windows systems we could use the unix socket approach to implement impersonation/elevation for powershell remoting there.

We should have the same UX for all platforms. Really there PSRP works over a transport - WinRM or SSH. MSFT said that they like SSH but I do not see any noticeable progress over the past two years. And it's unbelievable that they will want a third protocol in the near future - too much work (the need to maintain compatibility with old systems).

Most attacks target local elevation. So all configs is "secure by default". WMI, WinRM, IIS loopback and etc - all subsystems disable features which allows local elevations.
It is not so important for the discussion. Even if PowerShell remoting does not allow us to do sudo by default, we could implement it turned off by default or allow only for an interactive session.

I tried to enable that for a while ago, and I was told repetitively by many others that this is restricted by the os internally and it is not possible in any without an application hooking deep into windows internals. In fact many have pointed at the above referenced windows api restrictions and used that as argument for why powershell could never used to do that. And someone even referenced an CVE where loopback elevation was intentionally removed. Therefore apologies going down that rabbit hole a bit deeper, but what do I need to configure for it to work? Is that even documented anywhere?

We should have the same UX for all platforms. Really there PSRP works over a transport - WinRM or SSH. MSFT said that they like SSH but I do not see any noticeable progress over the past two years. And it's unbelievable that they will want a third protocol in the near future - too much work (the need to maintain compatibility with old systems).

Well than we should push forward either of both solutions as both work on any platform.

PSRP: SSHing to localhost works for elevation on Windows and Linux, therefore using the psrp subsystem we already have the correct permissions, so only the powershell layer has to be uniformed to allow passing objects. Right?
Using unix sockets would also provide a similar functionality like powershell remoting, but as time of writing I assumed it is a hard limitation to do local elevation without any kind of additional service running as local system to perform token swapping...

And someone even referenced an CVE where loopback elevation was intentionally removed.

I cannot confirm. I guess the CVE could just disable loopback by default but not at all.
See also https://github.com/PowerShell/PowerShell/issues/3874#issuecomment-510715727

@iSazonov: That does not work, it only provides the low privilege access token but not the elevated access token (e.g. Mandatory Label\High Mandatory Level). I do not get Administrative permissions out of a low privilege powershell even though TrustedHosts is set to * for me. The logon token is always of type interactive, even after Enter-PSSession.
I can in fact Enter-PSSession localhost -ScriptBlock {} but passing credentials causes "Access Denied".
But I now tried it also using SSH and that works as expected it provides the elevated token (Mandatory Label\High Mandatory Level) with logon type Network.
Therefore in PSCore we can rely upon psrp for elevation (even locally through Enter-PSSession -HostName localhost that also works with explicit credentials being passed.
Where Enter-PSSession -ComputerName localhost -Credential $foo does not (even if $foo.Username is the same as the current user)

@agowa338 I think we should not discuss bypassing security features of WinRM here (it is compliance sensetive area). I can only indicate (1) that regardless of a protocol, security should remain at the same level, which implies that SSH loopback should behave the same as for WinRM taking in account how Windows internals work, (2) PS sudo implementation should works over any transport.

@iSazonov: I did not ask for an exploit, but only for what needs to be configured to enable it. Also you seam to be the only one that figured out how to configure WinRM in order to allow loopback elevation.
I've tried to enable that for a very long time. All questions (on stackoverflow, reddit, github issues, ...) I come across end in "windows is wird", "don't know what windows does there", "It is not documented anywhere", "Windows does not provide that capability", "Use Linux instead", "Disable UAC", "You need to write a broker service that runs with system privileges". So please if you figured it out, share your knowledge.

I can only indicate (1) that regardless of a protocol, security should remain at the same level

What do you mean with that?

which implies that SSH loopback should behave the same as for WinRM taking in account how Windows internals work

Well SSH has a system service that acts as a broker in the background to do exactly that. It provides a Network access token...

(2) PS sudo implementation should works over any transport.

Well it does not over WinRM for exactly that reason. So if it is true what you said we need documentation for how to enable loopback WinRM.

if you figured it out, share your knowledge.

@agowa338 MSFT team asked me do not discuss security publicly and I follow the CoC. I support your desire to explore this topic deeply, but as part of this discussion, this is a headache for MSFT how to integrate this solution into Windows and keep security compliance.

Well that does not help anyone.
To summon it up:

You say windows has sudo like capabilities within WinRM.
It's neither documented that it exists nor how to enable/disable it.
Disclosing how to use it would be a security risk.

Sorry, but that sounds like a backdoor and not a feature. It is unusable for anyone except you than.
So we're back at it's currently not implemented.

@agowa338 We have gathered enough information for MSFT team to conclude. If they find security issues, they will show us an acceptable alternative way.

It was possible but was patched earlier this year https://devblogs.microsoft.com/powershell/windows-security-change-affecting-powershell/ with the patch KB4480116 and any subsequent cumulative updates.. Before this update it was possible to elevate your privileges if you have the LocalAccountTokenFilterPolicy set to 1 which is what winrm quickconfig does (and is required for WinRM really).
There's a note there saying JEA endpoints are not affected so potentially you could create your own PSSessionConfiguration and connect to that but I haven't tested this to verify. Personally I think this patch is silly as this patch just stops the PowerShell client from connecting to localhost but you can easily bypass it if you know what you are doing. For example I can still go from limited to elevated without touching UAC by using SSH or another PSRemoting client like so
PS C:\Users\vagrant> whoami.exe /groups  # prove the current process is limited

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
======================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Group used for deny only

BUILTIN\Administrators                                        Alias            S-1-5-32-544 Group used for deny only

BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Performance Log Users                                 Alias            S-1-5-32-559 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\REMOTE INTERACTIVE LOGON                         Well-known group S-1-5-14     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\INTERACTIVE                                      Well-known group S-1-5-4      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
LOCAL                                                         Well-known group S-1-2-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\Medium Mandatory Level                        Label            S-1-16-8192

PS C:\Users\vagrant> ssh vagrant@localhost whoami.exe /groups  # prove that SSH is elevated
vagrant@localhost's password:

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
===================================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Mandatory group, Enabled by
default, Enabled group
BUILTIN\Administrators                                        Alias            S-1-5-32-544 Mandatory group, Enabled by
default, Enabled group, Group owner
BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NETWORK                                          Well-known group S-1-5-2      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\High Mandatory Level                          Label            S-1-16-12288

PS C:\Users\vagrant> python -c "from pypsrp.client import Client; c = Client('localhost', username='vagrant', password='
<password>', ssl=False); print(c.execute_ps('whoami.exe /groups')[0])"

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
===================================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Mandatory group, Enabled by
default, Enabled group
BUILTIN\Administrators                                        Alias            S-1-5-32-544 Mandatory group, Enabled by
default, Enabled group, Group owner
BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NETWORK                                          Well-known group S-1-5-2      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\High Mandatory Level                          Label            S-1-16-12288

We can see that using SSH we have an elevated token, we can also see that using a 3rd party library we can still use localhost PSRemoting that creates an elevated token and that the patch is not a total block of this functionality.
I don't see this as a security issue or crossing a security boundary as MS has repeatedly said that UAC is not a security boundary

https://blogs.technet.microsoft.com/markrussinovich/2007/02/12/psexec-user-account-control-and-security-boundaries/
https://blogs.msdn.microsoft.com/e7/2009/02/05/update-on-uac/

It might be close or act similar to one but it is not foolproof. One of those ways of bypassing UAC is the known and documented LocalAccountTokenFilterPolicy registry property. The explicit purpose of this property to ensure that network logons are always elevated and not the filtered token and it explicitly says that not having this enabled prevents "loopback" attacks

To better protect those users who are members of the local Administrators group, we implement UAC restrictions on the network. This mechanism helps prevent against "loopback" attacks. This mechanism also helps prevent local malicious software from running remotely with administrative rights.

Ultimately what that means is there is no really official way on Windows to elevate your privileges from limited to an admin in a non-interactive fashion. It's quite simple to use Start-Process ... -Verb Runas but that requires an interactive logon to display the UAC prompt. Having a sudo-like mechanism would help alleviate this problem but to do it properly would require work in Windows itself and not be PowerShell specific. There are "workarounds" but I wouldn't call them official and are just a known byproduct of enabling WinRM.

@iSazonov None of these suggestions will accomplish a user-interactive command elevation from within the same console session, especially in an environment that lacks UAC. It appears that you can speak on behalf of Microsoft in these matters, so would you clarify whether they are simply not interested in in introducing such a feature as I have described it?
If that is the case, as I have interpreted from the above posts, it seems prudent to close this thread, as the rest of us users will have to look elsewhere for solutions such as @parkovski's TokenServer idea.

It appears that you can speak on behalf of Microsoft in these matters

I am a community maintainer of the project, not MSFT member and I can not speak on behalf of Microsoft.

would you clarify whether they are simply not interested in in introducing such a feature as I have described it?

All proposals have value; none of them are rejected. The discussion is just for collecting all possible proposals.
Currently I am trying to summarize all proposals so that we can move forward and not stagnate.
That I see.
Main scenario is adoption Unix users on Windows.

Historically Unix users works in one console and sudo natively helps them to do a work with elevated rights in the same console
Historically Windows users open new window with elevated rights console if needed. This works well many years because it’s convenient in a multi-windows environment. (Windows users could benefit from pssudo too taking in account Windows Core and Nano)

So expectations are:

pssudo works only in interactive sessions
pssudo does not open new console (UAC window is acceptable on Windows, we don't want break Windows security and spirit)
pssudo timely cache credentals
pssudo does not cache a session state for security
the same UX (as possible) is on all platforms
pssudo runs native commands
pssudo runs PowerShell script blocks/files

Implementation details:

PowerShell remoting is most power and functional solution. It is already implemented and works. Others would have to emulate this functionality too to excecute PowerShell script blocks in per user/per session/per runspace/ per scope state.
Preferred transport is WinRM because all Windows infrastructure based on it. Some investment is required in WinRM, although MSFT does not want this because it is based on SOAP.
SSH transport could be. This is still not the standard for Windows. Requires a large investment for implementation and maintenance. And there is a problem supporting older systems.
Other transports like Unix sockets. Requires a large investments not only in infrastructure but in PowerShell too.

@mklement0 I wonder that I do here that you do usually great :-) You rob me of being an opponent :-)

Why not write an windows binary that requires privileges that starts a powershell instance with whatever commands passed to it. It would have to be a console mode app to work properly. Then for linux, we write a script that requires permissions that starts a powershell instance with the commands provided. If this works in practice like it does in theory, powershell will be launched with elevated permissions, runs the commands and exits.

Why not write an windows binary that requires privileges that starts a powershell instance with whatever commands passed to it. It would have to be a console mode app to work properly.

Cause the windows API prevents that and the console app would open in a new window. We already talked about possible workarounds.

One thing to keep in mind is that no matter how this gets implemented, there is always a process hop to and from an elevated process.  This means that you'll always have deserialized objects in the pipeline and those limitations will apply.  In many cases, this won't be an issue, but if a cmdlet expects a live .NET object, then it won't work.
To support JEA with SSH, we would eventually need a generalized daemon/service that replaces the need for WinRM as that service anyways.  At that time, we would evaluate using that to elevate a part of the pipeline.

FYI: https://github.com/gerardog/gsudo

 GitHub**gerardog/gsudo**A Sudo for Windows - run elevated without spanning a new Console Host Window - gerardog/gsudo

Even better
http://blog.lukesampson.com/sudo-for-windows

Even better

No.
Gsudo doesnt prompt for password each time and is noticebly faster to install and use.

It looks to me that this issue should be accepted (which means some more time and organization should be given to it) judging from the interest not only from this ticket. Its not correct not to officially recognize it as a work task as currently perceived technical difficulties are not going to be solved without active involvement.
I am using gsudo for a few months now and I can't imagine going back to traditional Windows UAC all the time horror.

@majkinetor this issue got spun off in https://github.com/PowerShell/PowerShell/issues/11343 to further discussion on the design

Is there an update for this feature request? The last referenced Ticket #11343 was already marked as done a while ago.

With Windows supporting sudo now (in preview) as first class citizen, this will allow at least wrap-around functionality: https://devblogs.microsoft.com/commandline/introducing-sudo-for-windows/

@bergmeister only client versions of windows. What is with servers?

This issue goes back 7 years, so I may have missed somebody sharing this already, but in case it hasn't, here it is.
It seems that sudo -s will read the $SHELL environment variable to determine what shell to use to execute the command. I changed it to point to pwsh and that seems to work for my current need of moving a file.
#!/usr/bin/env pwsh

$Env:SHELL = '/opt/microsoft/powershell/7/pwsh'
$source = /tmp/file.csv
$dst = /home/user/tmp/file.csv
sudo -s Move-Item -Path $source -Destination $dst -Force

However, if I append -Confirm:$false to the Move-Item cmdlet, I get the following error:
Move-Item: A parameter cannot be found that matches parameter name 'Confirm\'.

So this kinda works for using sudo against some simple cmdlets on Linux, but for more complex commands you will definitely get unexpected results. YMMW. Use with caution.

Just ran into this while creating a script to transfer my published project data over to my home server. I'm using a bash command to achieve it now but would be great to have some sort of sudo mechanism built into to Powershell so I don't have to change style depending on the privileges I hold.


--no-deploy traefik servicelb not respected

I'm having trouble disabling the auto deployment of traefik.
I have added:
k3os-8393 [/var/lib/rancher/k3os]$ cat config.yaml
k3os:
  k3s_args:
  - server
  - "--no-deploy traefik servicelb"

and deleted all the jobs/pods/services related to traefik, but still after 120minutes everything is recreated.
ps-ax gives the following:
 2007 ?        S      0:00 supervise-daemon k3s-service --start --pidfile /var/run/k3s-service.pid --respawn-delay 5 /sbin/k3s -- server --no-deploy traefik
 2009 ?        Ssl   96:56 /sbin/k3s server --no-deploy traefik

Any thoughts on what I can do to stop this from happing? I have to deploy my own LB and Ingress server to handle TLS, ACME etc..

@bbergshaven - You can accomplish this by turning it off on k3os installation

Create a config.yaml that has

k3os:
  k3_args:
  - server
  - "--no-deploy traefik"

On installation of k3os, either add it to the automated Installation (k3os.install.config_url = config.yaml)  or you can add it manually through the setup steps.  Once i did that, you will notice that traefik was not installed.

No matter what is set in the config.yaml is affecting traefik deployment. Also removing /var/lib/rancher/k3s/server/manifests/traefik.yaml does not help. Only way to keep is uninstalled is to remove everything except job.batch/helm-install-traefik otherwise it will be recreated.
Really, please fix it and document...

@bbergshaven kubectl -n kube-system delete helmcharts traefik have to be also invoked to get rid of default traefik...

I'm also experiencing this issue. If I only disable traefik it works but once you disable traefik and servicelb both are started.
Working:
--no-deploy traefik

Not working variants
--no-deploy traefik,servicelb
--no-deploy traefik servicelb
--no-deploy traefik --no-deploy servicelb

A few days ago we added the ability to specify --no-deploy with comma delimited entries (2 or more entries). The next k3os release should include an updated k3s release with this ability. See https://github.com/rancher/k3s/pull/851

On master (v0.8.0+) this is working for both
k3os:
  k3s_args:
  - "--no-deploy"
  - "traefik,servicelb"

and
k3os:
  k3s_args:
  - "--no-deploy=traefik,servicelb"

neither of those work for me.
k3os:
        password: supersecure
        k3s_args:
                - server
                - "--no-deploy=traefik,servicelb"

is what worked for me. v0.10

use --disable=traefik instead. --no-deploy is deprecated

Where is this stuff even documented? I feel like there is only the code and the readme in the repo root.
Am I missing something?

Where is this stuff even documented? I feel like there is only the code and the readme in the repo root.
Am I missing something?

Yes, their docs are very confusing. I got the info from k3s server -h. Then I found they did have this: https://rancher.com/docs/k3s/latest/en/installation/install-options/server-config/#kubernetes-components

Thanks! I've seen the k3s docs, but it's difficult to discern the separation between k3os and k3s.
Very blended together, and unclear what is part of what.
consider:
k3os:
  k3s_args:

so k3s_args is a child of k3os? Why not it's own section, or a different file that is passed to k3s config? vs os?
Is my model of this broken :(

Note that --no-deploy and --disable are slightly different. --disable will delete any file with that name, so make sure your custom traefik file is not named traefik.yaml or you will be confused as to why it doesn't exist.


Don't crash when sending a push when user has no networks

Fixes #231. @johnlage can you verify that this fix works?

I'm just hoping he hasn't already moved on to some new problem, like his Sopel bot. 😆

For the record, I just did this on my test instance, no crash.
[21:42:07] -*status- You have no networks configured. Use /znc AddNetwork <network> to add one.
[21:42:19] <dgw> send test with no networks configured
[21:42:19] <*push> Ok

@johnlage has to bug someone else to compile the patch, so the timing of his confirmation is "whenever the server admin can be bothered".

Good enough for me!


Too big visual editor size

Scale the default UI size down, as all buttons are too big.

Found out that the font size is too big on Windows, maybe change it together with screen dpi?

This now has been fixed

Good


Add catalog.cattle.io/os=linux

Need to add new annotation: catalog.cattle.io/os=linux to all of our current charts so that they will be hidden in the Apps/Market Place when it's a windows cluster.

[x]  CIS
[x]  Logging
[x]  Backup/restore
[x]  OPA
[x]  Istio
[x]  Monitoring
[x]  Longhorn
[x]  external-ip-webhoook

Tested with Rancher server rancher\rancher:master-head version 495f7a1d6 and rancher\rancher:v2.5-head version 182e3de71
On Ubuntu 20.04, OPA v3.2.1 is available. Annotation is seen:

Rancher version: v2.5-head (12/15/2020) 182e3de
Rancher version: master-head (12/15/2020) 495f7a1
rancher-logging:3.8.201
Logging chart has these annotations in a Linux only cluster:
annotations:
        catalog.cattle.io/certified: rancher
        catalog.cattle.io/hidden: "true"
        catalog.cattle.io/namespace: cattle-logging-system
        catalog.cattle.io/release-name: rancher-logging-crd
        catalog.cattle.io/ui-source-repo: rancher-charts
        catalog.cattle.io/ui-source-repo-type: cluster

rancher/rancher:v2.5-head 182e3de
Istio 1.7.302 deploys successfully
annotations:
...
        catalog.cattle.io/os: linux
...

rancher/rancher:v2.5-head 182e3de
Monitoring 9.4.202 deployed successfully
annotations:
...
        catalog.cattle.io/namespace: cattle-monitoring-system
        catalog.cattle.io/os: linux
...

rancher/rancher:v2.5-head 182e3de
rancher-externalip-webhook deployed successfully:
annotations:
...
        catalog.cattle.io/namespace: cattle-externalip-system
        catalog.cattle.io/os: linux
...

On 2.5-head - commit id: e2295c6

cis benchmarks was deployed. Annotations seen: catalog.cattle.io/os: linux


Exchange -Number of swaps update

Related to https://github.com/atomiclabs/hyperdex/pull/445 I do not see a "View all swaps" button.
Version: alpha 12
OS: win 10
Errors: none
Severity: low

It only shows up at the bottom of the list when you have more than 50 swaps. It doesn't matter though as in the next alpha, which I'm releasing later today, we will no longer limit it as we now only show open orders in the Exchange view. And we'll add an always visible button to view the history (complete/failed swaps): #495 I'll write more about it in the release notes ;)


Duplicated call of start

The start function called 2 times which cause a generation of Recon\target.com\Recon\target.com
all(){
	start
	if [ -n "$list" ]
	then
		...
	else
		start

dir generation caused by:
       dir=$PWD/Recon/$domain
	mkdir -p $dir

I suggest to protect those calls: checking the existance of the output dir before the call of mkdir and not use $PWD.

Done! Thanks

Done! Thanks

Quick fix!

Quick fix!


feat: default ADDRESS env var on deploy

:gift: Requests that deployed functions listen on all interfaces for requests.

Runtimes should, by default, only listen on the loopback interface for security (they may be func run locally).
The ADDRESS environment variable added here on deploy requests the runtime to listen on all interfaces (<IP_ADDRESS>) when deployed, since they will need to listen for client requests and for health readiness/liveness probes.
Additionally, now a user who wishes to securely open their function to only receive requests on a specific interface, such as a WireGuard-encrypted mesh network which presents as a specific interface; that can be achieved by explicitly setting the ADDRESS on their function.
NOTE this env variable is only a suggestion, and it is up to the runtimes to read and use.  This is currently respected by scaffolded Go functions (func-runtime-go library), with other runtimes expected to implement as they are updated to support scaffolding.
/kind enhancement

/unhold


Support to selectively enable or disable login access to applications.

Is your feature request related to a problem? Please describe.
In CIAM solutions, there's a need to selectively disable application access for users for various reasons, like security concerns or compliance requirements. Currently, Identity server do not has this support.
Describe the solution you would prefer
Add support to selectively enable and disable application login access through Application Mgt API
Phase 1

[x] BackEnd and API capability to enable/disable user login/access for an application
[x] Administrative UI in the Console to enable/disable Myaccount at the organization level

Phase 2

[x] Consent and active token revocation while disabling the access

Being supported with

https://github.com/wso2/identity-api-server/pull/612

This introduces a change to the application mgt APIs and hence require documentation update.

Phase 2:
Revoke consents

https://github.com/wso2/carbon-identity-framework/pull/5732

Doc update

[ ] #20387

Improvement suggestions

[ ] https://github.com/wso2/product-is/issues/21258
[ ]


fix(picker): prevent diacritic text cutoff

Description
Addressing CSS-810, this fix addresses a bug that was called out recently, similar to what was seen in Textfield for both Spectrum CSS and React Spectrum with text with diacritics being cut off vertically. In this case, as the affected text occurs in a <span> rather than an <input> tag, the line-height does not need an adjustment, and changing the margin to padding appears to be sufficient to allow the vertical cutoff to be displayed.
There is also a draft PR to fix the same issue that uses the same line-height fix that is seen in textfield.
Note: When testing with Assistiv Labs, this cutoff issue did not appear to be present (in production)--this fix has been tested in Assistiv Labs (Chrome, Firefox, Edge) and does not appear to have an impact there.
How and where has this been tested?
Please tag yourself on the tests you've marked complete to confirm the tests have been run by someone other than the author.
Validation steps

Check out the Picker in Storybook locally or in the deploy preview
Change text to Thai:

In the Storybook controls, you can change the text for both "Label" and "Placeholder" to the Thai phrase that was causing an issue previously, "ทั้งหมด". You can also do this in the deployed version of Picker or from the main branch to see the cutoff issue.
If checking out Picker locally, you can alternatively cherry pick commit a1fab905fba48b9d3cf641a19160bee1b07e376a to temporarily change the English in Picker to Thai. This was a temporary commit I'd put in the PR but reverted in order to run VRTs.

Confirm that the text within the Picker is not being cut off vertically. The best way to know is to compare the field label ("Label" text, which has not been experiencing cutoff) with the picker label ("Placeholder" text, which is the element experiencing cutoff), applying zoom as needed.
Confirm that this continues to be true for:

[x] all sizes of Picker
[x] all variants of Picker
[x] in more than one browser (I checked Chrome, Firefox, Edge, and Safari, all for Mac)

Check the Tabs component in Storybook:

[x] confirm that there do not appear to be any regressions or issues as the result of this change to Picker

Regression testing
Validate:

The documentation pages for at least two other components are still loading, including:

[x] The pages render correctly, are accessible, and are responsive.

If components have been modified, VRTs have been run on this branch:

[X] VRTs have been run and looked at.
[ ] Any VRT changes have been accepted (by reviewer and/or PR author), or there are no changes--there is a 2px length difference in the snapshots for the Tabs component, this cannot be replicated in the browser, and I am unsure if it's an indication of significant diffs that might be visible downstream.

Screenshots
Before:

After:

To-do list

[x] I have read the contribution guidelines.
[x] I have updated relevant storybook stories and templates.
[x] I have tested these changes in Windows High Contrast mode (and AssistivLabs).
[x] If my change impacts other components, I have tested to make sure they don't break.
[ ] ✨ This pull request is ready to merge. ✨

My only question now is do we drop those 2 temp commits (changing the text to Thai, and then the corresponding revert)? If we merged it right now, it would be ok, but do we have a preference for "temporary" commits?

My original intention was to not have reverted the temporary commit for validation purposes and then to drop the commit before merging, but then I reverted it to run VRTs and ran into that unexpected diff that I wanted feedback on, so I left it that way. I think I would probably just squash/fixup those commits. Also was thinking there wasn't a lot of reason to keep the spelling change for "country" as a separate commit, so that'd be squashed in with the fix here.

Checking if there is any action I need to take in RSP.
Where was this reported against React Spectrum? it looks like we've already implemented this? https://react-spectrum.adobe.com/react-spectrum/Picker.html
Does anyone have the actual string which is cutoff? I have no idea what those characters are in the screenshot, can't copy and paste them :-/


Information on how to handle sub-components (like /users/user)

I cannot find any good information with examples on how the setup should be for child routes (children of a component) in the Angular New Router docs.
If I have missed such documentation, I would be glad to get a hint on where that is (I naturally also tried Google). If not, maybe somebody could give me a quick hint on how to do it until the docs are improved?
As I understand the router config is per component. And a component is self-contained and not aware of other components.
If I have a users component, and this component gives all users, and then this components has a child component that gives info on a specific user, so the path would then be /users/user/, then would the following setup correct?
/app.js
/app.html
/components/users/users.js
/components/users/users.html
/components/users/components/user/user.js
/components/users/components/user/user.html

Where /app.js contains the following router config:
$router.config([
 {path: '/users', component: 'users' }
]);

And /components/users/users.js contains the following route config:
$router.config([
 {path: '/user', component: 'user' }
]);

I probably have misunderstood, because when I tried it, it did not work. See this plnkr.
And how to use ng-link to a child-child like /users/user?

I finally found out that this is yet not possible. Eagerly waiting for this new router...


feat(open-webui): init

ported from: https://github.com/shivaraj-bh/ollama-flake/blob/main/services/open-webui.nix
This was also recently upstreamed to nixpkgs: https://github.com/NixOS/nixpkgs/pull/316248
TODO:

[x] Document how to use it with ollama service
[x] Use open-browser process in example and documentation

Ready for preview:
nix run "github:juspay/services-flake/open-webui?dir=example/llm"

Ready for preview:

I get the following on mac:
       error: The option `perSystem.aarch64-darwin.process-compose.default.services.open-webui' does not exist. Definition values:
       - In `/nix/store/7a9x52qf14dkvnhj4219jd0i5l9yhdj3-source/example/llm/flake.nix, via option perSystem':
           {
             open-webui1 = {
               enable = true;
               environment = {
                 OLLAMA_API_BASE_URL = "http://<IP_ADDRESS>:11434";

Ready for preview:

I get the following on mac:
       error: The option `perSystem.aarch64-darwin.process-compose.default.services.open-webui' does not exist. Definition values:
       - In `/nix/store/7a9x52qf14dkvnhj4219jd0i5l9yhdj3-source/example/llm/flake.nix, via option perSystem':
           {
             open-webui1 = {
               enable = true;
               environment = {
                 OLLAMA_API_BASE_URL = "http://<IP_ADDRESS>:11434";

Ah sorry (I was just checking with just ex-llm in devShell), this should work:
 nix run "github:juspay/services-flake/open-webui?dir=example/llm" --refresh --override-input services-flake github:juspay/services-flake/open-webui

The processes are running in two different namespaces (default and ollama1) ... shouldn't they be under the same namespace?

The processes are running in two different namespaces (default and ollama1) ... shouldn't they be under the same namespace?

In our current design, every service belongs to its own namespace. We could manually modify this, if that’s what we desire here.

Fantastic, worked on mac!

In our current design, every service belongs to its own namespace.

I don't remember what we do. But this doesn't seem to be the case for the llm example because only the ollama1 service is running in its own namespace (ollama). Not the open-webui1 service, as it is running in the default namespace.

In our current design, every service belongs to its own namespace.

I don't remember what we do. But this doesn't seem to be the case for the llm example because only the ollama1 service is running in its own namespace (ollama1). Not the open-webui1 service, as it is running in the default namespace.

 This will be a cool video demo (especially if it finishes with writing prompts in the browser app).

Thanks for all the feedback @srid and @drupol! ❤


Screenshot tests fail on mac

python3 -m pytest --vv

cc @thiagowfx

WPT tests are failing as well because of the screen dimensions

@sadym-chromium this is e2e on a local mac (not related to WPT failure)

This is quite odd, because my platform is also macOS. I thought setting the viewport would be enough to make the test deterministic, but maybe there's something else we're missing.

@thiagowfx I think the display might matter

I assume it is somehow related to the "nightshift" setting of the mac.

Tentatively sent  https://github.com/GoogleChromeLabs/chromium-bidi/pull/558 but I expect it will fail CI.
Possible workaround: Have the E2E test detect whether it's a CI environment. If it is, use one golden. If it's a local environment, use another.

Fixed by #558

Updated issue title and first comment to reflect current state.

It's also different on Linux.


Add localization optional to varscan somatic.

This required building a newer image with varscan and a newer samtools that supports reading gs:// URLs.
There are some differences in the varscan output as a result of this change.  The most dramatic change comes not from upgrading to 1.16.1 but from switching from the custom samtools 1.3.1/htslib 1.3.2 combo in the CLE image to any other version I tried (1.3.1 and 1.7). So not sure if there's something special about the combination in the CLE image...
This is part of #64.

Varscan variant calling seems to be working based on the final outputs.


Issue in constructFrom with records

Description:
Consider the following code:
import ballerina/io;

type BRec record {
    int i;
};

type CRec record {
    int i?;
};

public function main() {
    CRec c = {  };
    var b = BRec.constructFrom(c);
    io:println(b is BRec);
    io:println(b is error);
}

The conversion should fail since c does not have the field i. But the conversion succeeds and prints true and false respectively.
The spec also says, "if a record type descriptor specifies default values, these will be used to supply any missing members", which we don't seem to be doing at the moment.
Affected Versions:
0.992.0-m8

https://github.com/ballerina-platform/ballerina-lang/pull/17568 add a test case verifying fist half of this issue is fixed now.


Grunt (with grunt-contrib-watch) is using 2.5% of my CPU, would increasing the options.interval value reduce the CPU usage?

I am considering increasing the options.interval to 2000 ms. This means, if I understand correctly, that the watch worker will check the files for changes every 2 seconds. I assume this should reduce the CPU usage, is that correct? Thanks.

Yes, see this related issue: https://github.com/gruntjs/grunt-contrib-watch/issues/429


NIFI-12123: Added additional @UseCase and @MultiProcessorUseCase anno…

…tations as well as some trivial cleanup that was flagged by IntelliJ such as making inner class static, updating some deprecated references, etc.

Summary
NIFI-00000
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[ ] Apache NiFi Jira issue created

Pull Request Tracking

[ ] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[ ] Pull Request based on current revision of the main branch
[ ] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[ ] Build completed using mvn clean install -P contrib-check

[ ] JDK 21

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

Changes look good.  Letting local build wrap up and assuming that plus github checks run well i'll merge soon.


Question about BFV params

In BFV README, the param P  follows the constraint  by a small margin (~20 bits), but I don't understand in
PN12QP109 = ParametersLiteral{
LogN:  12,
T:     65537,
Q:     []uint64{0x7ffffec001, 0x8000016001}, // 39 + 39 bits
P:     []uint64{0x40002001},                 // 30 bits
Sigma: rlwe.DefaultSigma,
}
Is PQ>Q^2? Or P here only represents "using one more small coprime modulus than equation Q"? But why P exceeds 20 bits?

There is indeed a mismatch between the documentation and the implementation here.
The current BFV implementation now handles the multiplication modulus transparently, without the need to specify it as a parameter. Hence, there is a mismatch between the definition of P in this documentation (the modulus extension for multiplication) and the modulus P in the ParametersLiteral type (the general modulus extension for key-switching).
Thanks for the feedback.

#379


testing: T and B should implement -ln methods

Like fmt and log, testing should provide -ln methods for T and B; that is, Errorln, Fatalln, Logln, and Skipln.

Why ? Those methods already have an implicit line break appended, how would these new methods improve this ?

Same reasoning as for log.Println, log.Fatalln, etc.
I often write things like
log.Println("Updating foo bar in", baz)

or
log.Fatalln("Error while doing x y z:", err)

but when writing tests, I have to remember to use an alternate form:
t.Fatal("Cannot x y z: ", err)    // need space
t.Fatalf("Cannot x y z: %s", err) // need formatting code

I think the latter are clearer, having to remember that the -ln version adds a space between the arguments, as well as trailing \n feels less clear to me.

If one agreed with you, this would be "unfortunate". T.Fatal already exists, it cannot be removed or changed, and having an alias is worse than having just one slightly badly named function.
However, there's another point here: T.Fatal doesn't necessarily have to be understood as "print this fatal line". It's much rater a statement about the test (it ended fatally). It's not analogous to fmt or log.

@davecheney that argument seems to apply just as much to log.Println, log.Fatalln, etc. Would you have rather seen those functions removed prior to Go 1, or do you feel that there's some significant difference between log and the T/B methods?
I almost always want a space, so I use log.Println/Fatalln much more than I use log.Print/Fatal; this is why the lack of T.Errorln/Fatalln is noticeable to me.

@dominikh sure, one could view it that way.
I just filed this to register the fact that I've consistently felt that these are missing during a few years of writing Go tests. Even if unintentional, that's the impression I got after using the log and testing packages a bunch.

We can't extend the TB interface so I have a preference to not add common methods to T and B, so TB doesn't look lacking.

@bradfitz TB contains unexported methods, so it should be possible to extend it?

Oh, pleasant surprise whenever evidence of past foresight is found.

@davecheney that argument seems to apply just as much to log.Println, log.Fatalln, etc. Would you have rather seen those functions removed prior to Go 1, or do you feel that there's some significant difference between log and the T/B methods?

I don't have a position on those, we cannot change the past, but I don't see the argument for adding extra methods to testing to be compelling.

Oh, pleasant surprise whenever evidence of past foresight is found.

eh ?

@davecheney by "foresight" @bradfitz is referring to the private method in the interface, and its associated comment:
// TB is the interface common to T and B.
type TB interface {
	Error(args ...interface{})
	Errorf(format string, args ...interface{})
	Fail()
	FailNow()
	Failed() bool
	Fatal(args ...interface{})
	Fatalf(format string, args ...interface{})
	Log(args ...interface{})
	Logf(format string, args ...interface{})
	Skip(args ...interface{})
	SkipNow()
	Skipf(format string, args ...interface{})
	Skipped() bool

	// A private method to prevent users implementing the
	// interface and so future additions to it will not
	// violate Go 1 compatibility.
	private()
}

That's a nice trick.
On Wed, 5 Aug 2015 08:49 Andrew Gerrand<EMAIL_ADDRESS>wrote:

@davecheney https://github.com/davecheney by "foresight" @bradfitz
https://github.com/bradfitz is referring to the private method in the
interface, and its associated comment:
// TB is the interface common to T and B.
type TB interface {
Error(args ...interface{})
Errorf(format string, args ...interface{})
Fail()
FailNow()
Failed() bool
Fatal(args ...interface{})
Fatalf(format string, args ...interface{})
Log(args ...interface{})
Logf(format string, args ...interface{})
Skip(args ...interface{})
SkipNow()
Skipf(format string, args ...interface{})
Skipped() bool
// A private method to prevent users implementing the
// interface and so future additions to it will not
// violate Go 1 compatibility.
private()

}
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/12011#issuecomment-127784069.

For consistency with other printing things, this is probably a good thing to do although barely worthwhile.

I just noticed that t.Fatal and t.Error do insert the spaces between arguments (they call fmt.Sprintln), so this change doesn't make sense. It's still inconsistent with fmt/log, but it's probably too late to change now.
I'm not sure how I didn't notice this before, though. The code in question doesn't look like it has changed since 2011.


Automatic updates and version ranges

It would be useful for dependency resolution to support version ranges for each provider that supports it (e.g. NuGet) and automatically keep the dependency up to date within the version constraint in the same manner as NuGet v3 references in a C# app.

Relates to https://github.com/cake-build/cake/issues/787

Closing due to inactivity.


how to judge whether it track failed?

I wanna ask as title describe..

Hi,
This is an open question and still under active research. For now, the simplest way to judge if the tracker is correctly following your target is by checking the magnitude of the response. If the response is high, the tracker is confident, otherwise, it may have failed.


WebTransport  Feature

How is the Web Transport support with xitca?

it's already supported. you can use xitca's http library to handle webtransport just fine like this example:
use quinn::ServerConfig;
use xitca_io::net::UdpStream;
use xitca_service::fn_service;

fn main() -> std::io::Result<()> {
    xitca_server::Builder::new()
        .bind_h3("wt", "localhost:8080", h3_config(), fn_service(handler)?
        .build()
        .wait()
}

async fn handler(stream: UdpStream) -> io::Result<()> {
    let conn = stream.connecting().await?;
    // do whatever with h3 connection.
    Ok(())
}

fn h3_config() -> ServerConfig {
    todo!("your quinn config goes here")
}

There is no plan to support it inside xitca-web yet. The webtransport API is too alien to a web framework and in most time you end up with hijacking the connection and dealing with ugly low level code anyway.


Reduce the times that we instantiantiate the rules

For each file detekt instantiate (at least) once each rule (and only the default rules are around 200 rules). I say at least because I think that they are twice but I'm not 100%. That seems like a waste of resources and that should make our analysis slower. This PR fixes that. The idea is that the rules shouldn't contain any state so we can instantiate them once and then reuse those instances all the times we need.
This PR is draft for two different reasons:

This PR aims to improve the performance but I don't have any reliable benchmark to ensure if this is really an improvement or not.
Right now this breaks the parallelism because Rule now uses a MutableList to store the findings. That MutableList is a state inside the Rule. But I don't want to focus on this until I check the first point.

Warnings

:warning:
It looks like this PR contains functional changes without a corresponding test.

  Generated by :no_entry_sign: dangerJS against cc7253202129b0e62c8db8a4b38485ee646b0327

Hi, @BraisGabin for The idea is that the rules shouldn't contain any state so we can instantiate them once and then reuse those instances all the times we need. won't that break our rules where we are storing some info in the instance variable. I am also curious how we can tests these types of issue in UTs

won't that break our rules where we are storing some info in the instance variable.

You are right. But if the performance improvement is relevant then we should fix that.

I am also curious how we can tests these types of issue in UTs

I think that it's not possible to "ensure" that this doesn't happen. But if we create only one instance of each rule and execute all the tests using that single instance I think it could be "good enough".

I think then immediate step would be to make the changes for a single instance of the rules and first fix the broken UTs. Not sure will they break deterministically or do we need to run those multiple times

I think then immediate step would be to make the changes for a single instance of the rules and first fix the broken UTs. Not sure will they break deterministically or do we need to run those multiple times

No idea. Also I want to know if a change like this one would make detekt faster. Because if doesn't make it faster there is no point on doing this.

This PR is stale because it has been open 90 days with no activity. Please comment or this will be closed in 7 days.

This PR is stale because it has been open 90 days with no activity. Please comment or this will be closed in 7 days.

This code changed a lot. I still want to see if we improve performance but I will open a new pr.


[Scheduled Maintenance] Site down for Maintenance

Additional context
Who/what/when/where/why is this maintenance happening

This is an example comment


Is this project still being maintained?

No update in 2 years, a lot of outstanding issues... what is the status?

I've asked @mzgoddard to make me a repo admin so we can knock out a few of the long-outstanding pieces, @sarink , and he's given me those perms as of today. We could probably use some help though so if you're able to help test or maintain this, please let me know!

I see a flurry of PR merges on May 19, and then none since then, and no releases.  I guess the question remains, is this project under active maintenance?