121–130 of 146 posts
Earlier quoted context omitted.
This is a key thing I'm curious about. How is drive mapping handled? If I "net use d: \\host\share" from one session, it won't nessarily translate and mount D: to all sessions (or will it)?
I can't check right now, but if you have two local users, Delta and Gamma, and Gamma mounts D:\, does Delta see it or is it specific to Gamma's session?
Earlier quoted context omitted.
This is a key thing I'm curious about. How is drive mapping handled? If I "net use d: \\host\share" from one session, it won't nessarily translate and mount D: to all sessions (or will it)?
I can't check right now, but if you have two local users, Delta and Gamma, and Gamma mounts D:\, does Delta see it or is it specific to Gamma's session?
The more things change..., from: https://github.com/PowerShell/Win32-OpenSSH/wiki/Deploy-Win3... "If you need key-based authentication: Install key-auth package run setup-ssh-lsa.cmd reboot " Reboot? And this gem: "SSH daemon needs to run as System to support key-based authentication". Which means, either use weak authentication, or run the daemon as system. I don't even understand why, it's not like the public keys…
Earlier quoted context omitted.
SUA was not half-baked, this is a very, very hard problem. There is a very serious difference in the way POSIX and Windows model a lot of really important OS primitives, from asynchronicity model in signals, to the semantics of syscalls like `fork`. Every process using these primitives on POSIX has specific behavior defined under those primitives, and if you don't choose _exactly_ the right behavior on the POSIX subs…
Microsoft does control the kernel, and given that, none of this stuff is particularly complicated. As for choosing "_exactly_ the right behavior" ... the whole point of POSIX is to clearly define the exact right behavior!
The more things change..., from: https://github.com/PowerShell/Win32-OpenSSH/wiki/Deploy-Win3... "If you need key-based authentication: Install key-auth package run setup-ssh-lsa.cmd reboot " Reboot? And this gem: "SSH daemon needs to run as System to support key-based authentication". Which means, either use weak authentication, or run the daemon as system. I don't even understand why, it's not like the public keys…
Earlier quoted context omitted.
This. Everything about Windows and automation just feels like Bill & co really hates you personally, hates your company, and even the air you breath
... while also hating malaria.
Earlier quoted context omitted.
Was just coming here to voice my concerns over this choice as well, wondering what their reasoning is for changing crypto systems.
A crypto system is a big and complex thing, subtle and quick to anger, and I can't blame Microsoft for wanting to concentrate on the one they're already supporting, instead of having to support two. On the other hand, for the exact same reason, I expect OpenSSH probably isn't interested in supporting anything besides LibreSSL and maybe OpenSSL, at least while they're so closely related.
> Leverage Windows crypto api’s instead of OpenSSL/LibreSSL and run as Windows Service Was wondering about that. I'm surprised the OpenBSD team is accepting the commits - something so fundamental and Windows specific doesn't seem like their kind of thing - but great! PS. If you're coming from a Unix background and interested in learning posh: https://certsimple.com/rosetta-stone
>I'm surprised the OpenBSD team is accepting the commits What commits? From the comments you will learn there were no commits and this is a classic embrace and extend. They are hijacking OpenSSL name, and rewriting it to use Microsoft crypto and APIs.
Earlier quoted context omitted.
Was just coming here to voice my concerns over this choice as well, wondering what their reasoning is for changing crypto systems.
I really don't like that there replacing an open source crypto with a closed source one. Putting on my tin foil hat but didn't Microsoft hand over a back door to the NSA already.
From the Snowden documents;
July 31, 2012
Microsoft (MS) began encrypting web-based chat with the introduction of the new outlook.com service. This new Secure Socket Layer (SSL) encryption effectively cut off collection of the new service for FAA 702 and likely 12333 (to some degree) for the Intelligence Community (IC). MS, working with the FBI, developed a surveillance capability to deal with the new SSL. These solutions were successfully tested and went live 12 Dec 2012.