similar to: Call for testing: OpenSSH 7.4

On 2016-12-15 at 01:05, Darren Tucker wrote: > On Thu, Dec 15, 2016 at 6:58 AM, Blumenthal, Uri - 0553 - MITLL > <uri at ll.mit.edu> wrote: > [OSX launchd diff] >> I for one would like to see it merged. > > I took the patch and addressed the comments in > https://bugzilla.mindrot.org/show_bug.cgi?id=2341. If we can get some > confirmation that it >

I conjecture that only few of the existing use cases rely on remote expansion. In any case (no pun intended), IMHO it would be better to break a few of the current use cases but leave the majority functional - than kill scp for all. Regards, Uri > On Aug 3, 2020, at 02:50, Jakub Jelen <jjelen at redhat.com> wrote: > > ?On Sat, 2020-08-01 at 00:17 +0000, Blumenthal, Uri - 0553

On Sun, 12 Aug 2018, Blumenthal, Uri - 0553 - MITLL wrote: > Tone aside, let me second what Bob said. OpenSSH maintainers seem to > be able to find time for many updates and upgrades - but ECC support > over PKCS#11 appears to repulse them for more than two years (I don't > care to check for exactly how many more). There's no "repulsion" involved, just a lack of

I hear you - but it seems that the choice is between (a) limiting "scp" functionality to address the security vulnerability, and (b) killing "scp" altogether. I'd much prefer (a), even if it means I lose "scp remotehost:foo\* .". Especially, since (almost always) I have equal privileges on both local and remote hosts, so in that case I just originate that

https://bugzilla.mindrot.org/show_bug.cgi?id=2341 Bug ID: 2341 Summary: XQuartz X11 forwarding not working in OS X 10.10 Yosemite Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: Mac OS X Status: NEW Severity: normal Priority: P5 Component: ssh

Also, if password-based auth is not allowed, WTF would you want to log passwords? This whole idea is ugly, and smacks of a teenage-level prank attempt. I would strongly object against any such modification of the main source (though I'm sure the maintainers are sane enough to never let such a crap in). Of course the original poster is free to hack his own copy in whatever way he wants.?

On Mon, 13 Aug 2018, Blumenthal, Uri - 0553 - MITLL wrote: > Lack of time on the Open Source projects is understandable, and not uncommon. > > However, PKCS11 has been in the codebase practically forever - the ECC > patches that I saw did not alter the API or such. It is especially > non-invasive when digital signature is concerned. > > Considering how long those patches have

PKCS#11 support for ECC should have been integrated years ago. Let's not complicate it now, just integrate the existing patches so that people stuck with EC keys at least can use them somehow... Jan Sent from my iPhone > On 14 Aug 2018, at 17:04, Ben Lindstrom <mouring at offwriting.org> wrote: > > Wasn't there a proposal at one time to create something like

OpenSSL developers believed that there was a need for a significant change. A part of that change was a conscious choice to break (some of) the existing API. They considered that pain unavoidable. So far I happen to agree with their rationale and approach. Move from visible internal structures to accessor functions is a good thing, regardless of what you may think of it. And the new API *is*

What I?m saying is that TPM should be able to behave like a PKCS#11 token. Loading TPM keys is similar to provisioning a PKCS#11 token (and hopefully needs to be done as rarely). The normal use of a TPM seems to be operating on the keys already installed ? rather than loading keys in every time you need to do something. TPM, like other hardware tokens, was designed for storing things (keys)

>> Let me rephrase my question: what does using OpenSSL engines enable >> that we can't already do via PKCS#11? > > It allows you to use the TPM2 as a secure key store, because there's no > current PKCS11 code for it. > > The essential difference is that Engine files are just that: flat files >

Why can the local and remote paths be sanitized? Regards, Uri > On Jul 31, 2020, at 19:57, Ethan Rahn <ethan.rahn at gmail.com> wrote: > > ?I wanted to bring this up again due to: > https://github.com/cpandya2909/CVE-2020-15778/. This showcases a clear > issue with scp which it sounds like cannot be fixed without breaking scp. > This seems like it would lend some impetus

I find this approach very bad in general.? PKCS#11 standard says that *private* keys should not be accessible without authentication. *Public* keys and certificates of course can and should be accessible with no authentication. SoftHSM misinterpreted this originally (older pkcs11 documents were less clear :), but they rectified this mistake. We should not repeat it.?

Also, Jerry Solinas, the person listed as an author of the curves, also is the author of DUAL_EC_DRBG. On Tue, May 29, 2018 at 3:43 AM, Damien Miller <djm at mindrot.org> wrote: > On Tue, 29 May 2018, Damien Miller wrote: > >> We're aware of those arguments but don't find them convincing enough to >> switch early. > > (but we will be switching to ssh-ed25519

I concur with Nico ? logging plaintext passwords is an extremely bad idea. The tone of the poster also leaves much to be desired ? but I?ll hold my tongue for now. -- Regards, Uri Blumenthal On 12/18/16, 11:48, "openssh-unix-dev on behalf of Nico Kadel-Garcia" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of nkadel at gmail.com> wrote: On Sun, Dec 18,

On 11/16/16, 8:55 AM, "openssh-unix-dev on behalf of Juha-Matti Tapio" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of jmtapio at ssh.com> wrote: On Wed, Nov 16, 2016 at 12:54:44PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > I find this approach very bad in general. > > PKCS#11 standard says that *private* keys should not be

On Mon, 2020-08-03 at 19:17 +0200, Thorsten Glaser wrote: > That would be the same as killing scp? Better that... than having an inherently insecure scp... or at least make it absolutely clear and rename it to i[nsecure]scp. If the core functionality of a program (which is here probably the "secure") is no longer given, then it's IMO better to rather cause breakage (at least for

> Uri (earlier in this thread) does answer this question clearly (that > the principal should be the hostname only), and, now that I've found > PROTOCOL.certkeys, this seems to be spelt out unambiguously there too: In turn this means: One cannot expect several SSH services on a single host to be securely distinguishable from each other by their particular

Hi, I was trying to get OpenSSH portable working with my Yubikey.? A key was present on the token but generated using the ECCP384 algorithm. This lead to many obscure goose-chase red-herring error messages from OpenSSH such as the delightful "Could not add card : agent refused operation" or other nonsense that was meaningless and unhelpful. Many hours later in Mr Google's company,

scp may be an ugly protocol, but it works, works nicely from a command line, and is quite convenient. FTP (and, presumably, sftp) is not nearly as convenient. Why do you think your recommendation to "use sftp instead" keeps falling on the deaf ear? Usability, perhaps? Perhaps it's time to stop preaching to people about what they should use, but instead - if you really want a change