openssh unix dev - Oct 2018 - please remove permission check that disallows private-group access.

Damien Miller <djm at mindrot.org> writes:
> We don't plan to remove this check. Accidental key exposure is still an
> unfortunately common problem and, while this check isn't perfect,
I'm
> pretty sure that it avoids enough real-world misconfiguration to
> justify it's continued existence.
Maybe the check could have a configuration option to disable it?  That
ways newbies would still be protected but folks that need to use the
group permissions to sort out NFS / UID issues could still use ssh
without going to great lengths to circumvent the check?

-wolfgang

Damien Miller <djm at mindrot.org> writes:
    > We don't plan to remove this check. Accidental key exposure is
still an
    > unfortunately common problem and, 

Could you please explain where you got this data from? I'd like a reference,
please.

    > while this check isn't perfect, I'm
    > pretty sure that it avoids enough real-world misconfiguration to
    > justify it's continued existence.

If this check "while not perfect ... avoids real-world
misconfiguration", why is there "accidental key exposure"?

Is there a contradiction?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20181022/1fe9b827/attachment.p7s>

I'm new here, but I feel like chiming in, I hope my opinions are 
welcome. At first glance at this thread it seems unnecessary to argue 
about the necessity of these checks when when the option exists to give 
users the choice.

Adding configuration option(s) for users who wish to bypass these checks 
could allow experienced users to do what they need to, and less 
experienced users could still benefit form the protection by default.

Generally, giving users the choice should not be controversial, but I 
will note that there is the mild fear of a user googling the error and 
finding misguided advice to simply disable the check.

Charlie

On 23/10/18 7:28 am, Wolfgang S. Rupprecht wrote:
> Damien Miller <djm at mindrot.org> writes:
>> We don't plan to remove this check. Accidental key exposure is
still an
>> unfortunately common problem and, while this check isn't perfect,
I'm
>> pretty sure that it avoids enough real-world misconfiguration to
>> justify it's continued existence.
> Maybe the check could have a configuration option to disable it?

+1.? It's rude of SSH to refuse to use the key it was told to use.? A 
warning is acceptable, as is an option to avoid any kerfuffle.